Mechanism for performing LSP-Ping over RSVP protection paths

This document describes methods for performing lsp ping over MPLS RSVP-TE protection paths, when the protection paths are not in use. Convention LSP-ping packets follow the same path as data traffic and thus it validates the LSP control and forwarding planes. For MPLS LSPs signaled using RSVP-TE , protection mechanisms have been defined in enable the re-direction of traffic onto backup LSP tunnels in the event of a failure. Under normal operation, no data traffic passes through the backup tunnels. So under normal conditions, there is no way of verifying that when a failure will happen, data will correctly take the backup tunnel and eventually reach the LSP end point. This document defines enhancements to the LSP-Ping to enable verification of end-to-end data path via the backup LSP tunnel when the backup LSP tunnel is not in use.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

describes mechanisms for performing protection of RSVP-TE signaled MPLS tunnels. The protection can be a one-to-one backup (detour) or a facility backup method (bypass) that creates one or more bypass LSPs for protecting one or more LSPs. In either case, the signaling is done in the control plane and protection path is not used until there is a failure in the LSP path being protected. LSP-Ping allows one to ping and trace the path of a LSP. LSP-Ping can be used (without any new extensions) to ping and trace the path of RSVP-TE protection paths. Thus, one can monitor the health of protection paths. However, this monitoring of the protection paths is done in isolation and not in combination with the actual path(s) being protected. In other words, the protection path might be UP, but on failure of the protected path, data traffic might not make it to the protected LSP end-point. Some of the reasons for this are as described below: Point of local repair (PLR) does not currently forward the incoming LSP traffic onto the protection path Actual forwarding failure with the protection path Merge point (end of protection path) does not correctly merge the traffic back to the LSP path Thus, it is essential to have a mechanism to validate that the LSP protection will actually work in case of a failure. This draft provides extensions to LSP-Ping to allow the PLR to re-route the lsp-ping packets via the protection path

To re-route an incoming packet via a protection path at a transit node, we need to provide some indication to the transit node that it should forward the lsp-ping echo request along the protection path. This is done by adding a flag field in the Target FEC Stack sub-TLV objects for RSVP FECs.

RSVP IPv4 LSP is a sub-TLV of Target FEC Stack TLV, defined in . The P-bit has been added to indicate that the echo-request MUST be forwarded along a protection-path, if one is available. If a node does not understand the P-bit, it MUST return an error code of either" Malformed echo request received" or "One or more of the TLVs was not understood" . If no protection-path is available, then the node MUST return the error code defined in .

RSVP P2MP IPv4 Session is a sub-TLV of Target FEC Stack TLV, defined in . The P-bit has been added to indicate that the echo-request MUST be forwarded along a protection-path, if one is available. If a node does not understand the P-bit, it MUST return an error code of either" Malformed echo request received" or "One or more of the TLVs was not understood" . If no protection-path is available, then the node MUST return the error code defined in .

RSVP P2MP IPv6 Session is a sub-TLV of Target FEC Stack TLV, defined in .The P-bit has been added to indicate that the echo-request MUST be forwarded along a protection-path, if one is available. If a node does not understand the P-bit, it MUST return an error code of either" Malformed echo request received" or "One or more of the TLVs was not understood" . If no protection-path is available, then the node MUST return the error code defined in .

If a transit-node receives a echo request with an indication that the request needs to traverse a protection path, but no protection path is available, then the transit node should respond back with a new return code as defined below:

The Return Subcode for this Return Code MUST be set to zero and MUST be ignored.

The RRO object sent upstream during the signaling of a MPLS RSVP-TE LSP contains information regarding protection availability on the downstream node. More specifically, specifies bits in the RSVP record-route object (RRO), which specify if a transit node provides protection and if it provides node protection. Given this, the ingress node of a RSVP-TE LSP knows the state of protection along all hops of a LSP. Using this information, the ingress MAY choose to perform LSP pings only via nodes where protection is available. Attempting to perform lsp-ping via nodes where no protection is available will not cause harm, except for additional OAM load in the nodes.

In the above figure node C provides node protection. To perform a lsp-ping along the protection path originating at node C, ingress A MUST send a lsp-ping echo request message with TTL=2 and with the P-bit set in the RSVP FEC stack sub-TLV, see . Due to TTL=2, the echo request will expire at node C. The transit node C on receipt of such a request SHOULD perform one of the following: If C does not understand the P-bit, C MAY respond back to A with an error. If C ignores the P-bit, then C MAY respond back to A with a return code indicating that it is a transit node If C understands the P-bit, then C SHOULD forward the lsp-ping echo request along the bypass path. When the lsp-ping echo request is forwarded along the protection path, the following rules MUST be followed: Node C MUST NOT forward the lsp-ping echo request along the regular (non-protection) LSP path.

When the echo request reaches the egress, the egress will either identify it as a malformed packet (if it does not understand the P-bit and enforces the Must-be-zero) or the egress will process the packet as a regular lsp-ping echo request and respond back with an appropriate return code. In either case, a response from the egress indicates that the packet indeed made it via the forwarding plane of the LSP's protection path. An error message from the egress does not necessarily mean that the packet was correctly forwarded to the egress. It only means that the packet made it to the egress.

specifies P2MP extenions for RSVP-TE and specifies extensions to lsp-ping for P2MP. The procedures outlined above are sufficient for P2MP. Using an appropriate MPLS TTL value (in the echo request) and P2MP Responder Identifier TLV ( ), an ingress should be able to direct an echo request along a particular protection path to a particular egress. A protection path in P2MP may be protecting multiple egresses and for scalability considerations, one should regulate the number of lsp-pings exercising the same protection path.

A transit node MAY have multiple paths protecting a downstream link or node. In such a case, which path the transit node chooses to forward the packets is a dependent on the transit node. This document does not make any requirements on the transit node to forward packets along a specific path or provide information along which path the packet was forwarded. In general, the transit node behavior for lsp-ping echo request messaegs should mimic the behavior for data packets in case there is a failure in the LSP path.

At this time, it is not deemed necessary to provide any extensions to support traceroute (starting at LSP ingress) that traverses the protection path. Traceroute is a tool often used during network trouble-shooting. During trouble-shooting, one could use lsp-ping (with extensions specified in this draft) to detect/validate a failure with the path. Once a failure has been detected, one could use traceroute on the main LSP path and a traceroute on the protection path to isolate the issue. Proxy lsp-ping could be used to automate the network-troubleshooting by performing both the procedures from the LSP ingress itself.

The draft does not introduce any new security considerations. Those discussed in are also applicable to this document. Tracing inside a bypass tunnel can be prevented by not propagating the MPLS TTL into the outer tunnel (at the start of the outer tunnel).

A new Return Code is defined in . IANA is requested to assign a new Return Code value for the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, "Return Codes" sub-registry as follows using a Standards Action value.

The authors would like to thank Vach Kompella for his suggestions on the subject.