Mechanism for performing LSP-Ping over RSVP protection paths
draft-nitinb-lsp-ping-rsvp-protection-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 30, 2009.

Abstract

This document describes methods for performing lsp ping over mpls rsvp-te protection paths, when the protection paths are not in use. Conventional LSP-Ping follows the same path as data traffic. In some cases, it might be useful to follow the data path of protection paths (detours and bypasses) to ensure that the those paths are fully functional. This document describes enhancements to LSP-Ping to perform ping over such paths.

Table of Contents

1.  Introduction
2.  Motivation
3.  Exercising the protection path
    3.1.  Transit node re-route indication
        3.1.1.  RSVP IPv4 LSP Target FEC Stack Sub-TLV
        3.1.2.  RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV
        3.1.3.  RSVP IPv6 LSP Target FEC Stack Sub-TLV
        3.1.4.  RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV
    3.2.  Transit node re-route error reporting
    3.3.  Transit node automatic forwarding along protected path
4.  Performing LSP Ping along a protection path
    4.1.  Ingress node procedure
    4.2.  Transit node procedure
    4.3.  Egress node procedure
    4.4.  P2MP Considerations
    4.5.  Re-routing echo requests via forwarding plane
    4.6.  Multiple protection path consideration
    4.7.  Traceroute along protection path
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

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 [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) 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 [RFC3209] (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.), protection mechanisms have been defined in [RFC4090] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.) 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.

1.1.  Conventions used in this document

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Motivation

[RFC4090] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.) 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. I 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 [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) 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:

1. Point of local repair (PLR) does not currently forward the incoming LSP traffic onto the protection path
2. Actual forwarding failure with the protection path
3. 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

3.  Exercising the protection path

3.1.  Transit node re-route indication

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 [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) for RSVP FECs.

3.1.1.  RSVP IPv4 LSP Target FEC Stack Sub-TLV

0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RSVP IPv4 LSP is a sub-TLV of Target FEC Stack TLV, defined in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). 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" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).

3.1.2.  RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV

0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           P2MP ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RSVP P2MP IPv4 Session is a sub-TLV of Target FEC Stack TLV, defined in [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.). 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" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).

3.1.3.  RSVP IPv6 LSP Target FEC Stack Sub-TLV

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 tunnel end point address                 |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|          Tunnel ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv6 tunnel sender address                  |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RSVP IPv4 LSP is a sub-TLV of Target FEC Stack TLV, defined in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). 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" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).

3.1.4.  RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                           P2MP ID                             |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|          Tunnel ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv6 tunnel sender address                  |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RSVP P2MP IPv6 Session is a sub-TLV of Target FEC Stack TLV, defined in [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.).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" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).

3.2.  Transit node re-route error reporting

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:

          Value    Meaning
          -----    -------
           TBD     Protection path not available

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

3.3.  Transit node automatic forwarding along protected path

LSP-Ping [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) mandates that the destination IP of the lsp-ping echo request MUST be from the 127/8 range. This document proposes the use of address 127.255.255.255/32 to reflect that the packet be forwarded along a protection path. Details of the procedure are described in Section 4.5 (Re-routing echo requests via forwarding plane).

4.  Performing LSP Ping along a protection path

4.1.  Ingress node procedure

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, [RFC4090] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.) 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.

4.2.  Transit node procedure

Ingress                                       Egress
   A           B          C           D           E
    o -------- o -------- o --------- o --------- o
                          |                      |
                           \____________________/
                                   Bypass

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 Section 3.1 (Transit node re-route indication). 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:

1. If C does not understand the P-bit, C MAY respond back to A with an error.
2. If C ignores the P-bit, then C MAY respond back to A with a return code indicating that it is a transit node
3. 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.

4.3.  Egress node procedure

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.

4.4.  P2MP Considerations

[RFC4875] (Aggarwal, R., Papadimitriou, D., and S. Yasukawa, “Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs),” May 2007.) specifies P2MP extenions for RSVP-TE and [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) 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 ( [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) ), 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.

4.5.  Re-routing echo requests via forwarding plane

The above mechanisms described for re-routing the echo requests on transit nodes onto a protection path may involve processing the lsp-ping echo request in the slow (non-forwarding) path. This document proposes the use of 127.255.255.255/32 IP destination address in the lsp-ping echo request to indicate that the packet should be forwarded along a protection path, if one exists. Thus, a transit node forwards packets along a protection path if and only if the destination IP address is 127.255.255.255/32 and the MPLS-TTL=1

The above technique is NOT mandatory and in the absence of the above, the packet will get processed by the slow-path on node C.

4.6.  Multiple protection path consideration

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.

4.7.  Traceroute along protection 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 [I‑D.ietf‑mpls‑remote‑lsp‑ping] (Swallow, G. and V. Lim, “Proxy LSP Ping,” November 2008.) could be used to automate the network-troubleshooting by performing both the procedures from the LSP ingress itself.

5.  Security Considerations

The draft does not introduce any new security considerations. Those discussed in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) 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).

6.  IANA Considerations

A new Return Code is defined in Section 3.2 (Transit node re-route error reporting). 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.

          Value    Meaning
          -----    -------
           TBD     Protection path not available

7.  Acknowledgements

The authors would like to thank Kenji Kumaki and Vach Kompella for their suggestions on the draft.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.