Dealing with Equal Cost Multipaths

Frequently, LSPs for a given FEC can have multiple "next hops" at transit LSRs. In addition, LSPs can have backup paths, detour paths, and other alternative paths to take should the primary LSP go down. It is useful if MPLS echo requests can exercise all possible paths. Though desirable, this might not be practical because the algorithms that a given LSR uses to load balance packets over alternative paths might be proprietary.

To achieve some degree of coverage of alternate paths, the MPLS ping/trace mechanism can use the 127/8 address as the destination address of the MPLS echo request packet. This address might affect load-balancing in cases where the LSR uses the destination address in the IP header as a decision for load balancing. Further, in the case of traceroute, each transit LSR provides information about how each of its downstream routers can be exercised. The ingress can then send MPLS echo requests that exercise these paths, based on information received from LSP traceroute.

Noncompliant Routers

Because MPLS ping/trace should be compatible with existing infrastructure, if the egress LSR for the FEC stack being pinged does not support MPLS ping, no reply is sent. If in traceroute mode a transit LSR does not support MPLS ping, no reply is forthcoming from that LSR for some TTLsay, n. The LSR originating the echo request should try sending the echo request with TTL = n + 1, n + 2, ... n + k in the hope that some transit LSR further downstream might support MPLS echo requests and reply.

Table 12-1 summarizes LSP ping and trace functions.

Table 12-1. MPLS LSP Ping/Traceroute

Requirement	Detect MPLS traffic black holes or misrouting Isolate MPLS faults Verify the data plane against the control plane Detect MTU of MPLS LSP paths
Solution	MPLS LSP ping (ICMP) for connectivity checks MPLS LSP traceroute for hop-by-hop fault localization MPLS LSP traceroute for path tracing
Applications	IPv4 LDP prefix, VPNv4 prefix TE tunnel MPLS PE, P connectivity for MPLS transport, MPLS VPN, MPLS TE applications
IETF Standards	RFC 4379

LSR Self-Test

LSR self-test was motivated by a combination of concepts, such as ECMP and liberal label retention. ECMP means that the transfer function of the LSR is MPLS payload dependent. This is unknowable to upstream LSRs, and they must expend a good deal of effort trying to test all the variations of the unknowable. However, the forwarding function is knowable to the self-testing LSR, making it a good option.

In liberal label retention, many labels are offered but few are chosen, and the chosen vary over time. An LSR ensures that the "not yet chosen" actually work when the time comes, which is useful. Instead of dividing the load between the edge LSR, the LSR self-test (see Figure 12-2) divides the load among the LSRs in the path. Another benefit of the LSR self-test is that an operator can validate the condition of unused or dormant paths in the event that the operator would need to use such paths for ECMP.

Figure 12-2. LSR Self-Test: Overview of Operation