Network working group M. Chen Internet Draft X. Guo Category: Standards Track W. Cao Created: July 2, 2009 Huawei Technologies Co.,Ltd Expires: January 2010 N. So Verizon F. Jounay France Telecom S. Delord Telstra Return Path Specified LSP Ping draft-chen-mpls-return-path-specified-lsp-ping-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 15, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Chen, et al. Expires January 2, 2010 [Page 1] Internet-Draft Return Path Specified LSP Ping July 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines extensions to LSP Ping [RFC 4379] to enable the return path(s) of an echo reply message, so that it can be specified when sending an echo request message to perform LSP failure detection, and the echo reply message is extended to detect the return path(s). This capability could improve the reliability of echo reply and allows failure detection of a Bidirectional LSP or two unidirectional LSPs being performed by one message, resulting in operational saving. 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 RFC-2119 [RFC2119]. Table of Contents 1. Introduction.................................................3 2. Problem statements and solution overview.....................3 3. Extensions...................................................4 3.1. Reply Via Specified Path mode...........................5 3.2. The return codes........................................5 3.3. Reply Path (RP) TLV.....................................5 3.4. Bidirectional sub-TLV...................................6 3.5. Any Candidate sub-TLV...................................7 4. Theory of Operation..........................................7 4.1. Sending an Echo Request.................................8 4.2. Receiving an Echo Request...............................8 4.3. Sending an Echo Reply...................................9 4.4. Receiving an Echo Reply.................................9 5. Security Considerations.....................................10 6. IANA Considerations.........................................10 6.1. Reply mode and return codes............................10 6.2. RP TLV.................................................11 6.3. Sub-TLVs for RP TLV....................................11 7. Acknowledgments.............................................12 8. References..................................................12 8.1. Normative References...................................12 8.2. Informative References.................................13 Authors' Addresses.............................................14 Chen, et al. Expires January 2, 2010 [Page 2] Internet-Draft Return Path Specified LSP Ping July 2009 1. Introduction This document defines the extensions to LSP Ping that can be used to specify the return path(s) of the echo reply message in a LSP Ping echo request message. Several new reply mode requirements are added and a new Type-Length-Value (TLV) is defined. With the extensions described in this document, the operators can detect a Co-routed Bidirectional LSP and Associated Bidirectional LSP with a single operational action, resulting in operational savings. It can also detect two unidirectional LSPs without any inherency or binding relationship (one for each direction) in one operational action as well, reduces the opportunity for error, and improves the reliability of the echo reply message. In this document, Bidirectional LSP includes Co-routed Bidirectional LSP defined in [RFC 3471] [RFC 3473] and Associated Bidirectional LSP that is constructed from a pair of unidirectional LSPs (one for each direction), and are associated with one another at the LSP's ingress/egress points. In the rest of this document, if there is no extra explanation, when say Bidirectional LSP, it includes both Co- routed Bidirectional LSP and Associated Bidirectional LSP. 2. Problem statements and solution overview Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping is defined in [RFC 4379]. It can be used to detect data plan failures in MPLS LSPs. More specifically, it is designed for unidirectional LSPs. Co-routed Bidirectional LSP is defined in [RFC 3471] [RFC 3473], but with the existing LSP Ping mechanisms defined in [RFC 4379], the operators have to perform LSP detection on each of the two ends of a specific Bidirectional LSP respectively. It not only doubles the workload of the operators, but may also bring additional difficulties when checking the backward direction of the LSP under the following conditions 1. The LSR that the operator logged on to perform the checking operations may not have out-of-band connectivity to the remote LSR of the LSP. That can result in failing to check the return direction of the Bidirectional LSP. 2. The tested LSP is an inter-domain/inter-AS LSP, the operator of one domain/AS may have no right to log on to the remote LSR reside Chen, et al. Expires January 2, 2010 [Page 3] Internet-Draft Return Path Specified LSP Ping July 2009 in another domain/AS. That can also result in failing to check the return direction of the Bidirectional LSP. 3. The return path of the echo reply message is randomly determined by the egress of the LSP. However, there can be more than one LSPs connecting the two LSRs. When a LSP Ping echo request for detecting one Bidirectional LSP reached remote LSR, the remote LSR may choose another LSP as the return path. This can result in mis-information and mis-diagnostics. For Associated Bidirectional LSPs and even unidirectional LSPs, they have the similar issues listed above. This document defines the extensions to LSP Ping that can be used to specify the return path(s) of the echo reply message in a LSP echo request message. A new TLV is defined to carry the specific return path(s) information required by the initiator. Several new reply mode requirements are added. For example, this document specifies that the echo reply should return along the back direction LSP of the tested Bidirectional LSP, or the specific return path(s) as defined in the echo request message. The detail extensions and procedures are defined in the following sections. 3. Extensions LSP Ping defined in [RFC 4379] is carried out by sending echo request message. It carries the Forwarding Equivalence Class (FEC) information of the tested LSP for indicating which MPLS path is being verified, along the same data path as other normal data packets belonging to the FEC. The only determinant of the echo reply message return path is the four reply modes defined in Section 3 of [RFC 4379]. But it is not enough for the egress LSR of the tested LSP to determine how to choose the return path(s) of the echo reply message. This document defines a new reply mode, Reply Via Specified Path mode. This new mode can be used to direct the egress of the tested LSP to send back the echo reply message along the path specified in the echo request message. This document also adds a new TLV, Reply Path TLV. The Reply Path TLV consists one or more sub-TLVs that can be used to carry the Chen, et al. Expires January 2, 2010 [Page 4] Internet-Draft Return Path Specified LSP Ping July 2009 specified return path information of an echo reply message. The detail definitions listed below. 3.1. Reply Via Specified Path mode The recommended value of the Reply via specified path mode is 5 (SHOULD be confirmed by the IANA). Value Meaning ----- ------- 5 Reply via specified path The Reply via specified path mode is used to notify the remote LSR received the LSP Ping echo request message to send back the echo reply message along the specified path(s) carried in the Reply Path TLV. 3.2. The return codes This document defines two new return codes that can be used to inform the sender the results of the testing. Value Meaning ----- ------- 14 Success to match the specified path 15 The specified reply path not existence Return code 15 is used when egress fails to match the specified reply path which is designated by ingress node. For example ingress node expects to detect the reply path of the bidirectional LSP, but the path being tested isn't bidirectional indeed, and also the condition that the specified path does not exist on egress. Return code 14 will be used when egress matches the specified reply path successfully. The detailed usage of the return codes is described in Section 4. 3.3. Reply Path (RP) TLV The Reply Path (RP) TLV is included in an echo request message. It carries the specified return path(s) that the echo reply message required to follow. The format of RP TLV is as follows: Chen, et al. Expires January 2, 2010 [Page 5] Internet-Draft Return Path Specified LSP Ping July 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP (reply path) TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Path(s) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RP TLV Type field is 2 octets in length, and the type value is TBD (which is needed to be assigned by IANA). Length field is 2 octets in length. It defines the length in octets of the Reply Path(s) field. Reply Path(s) field is variable in length. It has several nested sub-TLVs that describe the specified path(s) the echo reply message is required to follow. Each of the FEC sub-TLVs defined in [RFC 4379] is applicable to be a sub-TLV for inclusion in the RP TLV for expressing a specific return path. In addition, two more new sub-TLVs are defined, Bidirectional sub- TLV and Any Candidate sub-TLV. 3.4. Bidirectional sub-TLV The Bidirectional sub-TLV is used when the return path is required to follow the back direction of the tested Bidirectional LSP. The format of Bidirectional sub-TLV is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bidirectional sub-TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bidirectional sub-TLV Type field is 2 octets in length, and the type value is 17 (which is needed to be confirmed by IANA). Length field is 2 octets in length, the value of length field MUST be 0, it means that there is no any value fields follows. Chen, et al. Expires January 2, 2010 [Page 6] Internet-Draft Return Path Specified LSP Ping July 2009 3.5. Any Candidate sub-TLV The Any Candidate sub-TLV is used when the return path is required to exclude the path(s) that are identified by any other reply path sub-TLVs carried in the echo request message. This is very useful when one/several previous LSP Ping(s) failed. By carrying an Any Candidate sub-TLV and the previous failed reply path sub-TLVs, a new LSP Ping echo request could be used to help the egress to select another candidate path when sending echo reply message. The format of Any Candidate sub-TLV is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Any Candidate sub-TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Any Candidate sub-TLV Type field is 2 octets in length, and the type value is 18 (which is needed to be confirmed by IANA). Length field is 2 octets in length, the value of length field MUST be 0, it means that there is no any value fields follows. 4. Theory of Operation The procedures defined in this document only apply to "ping" mode, how to deal with "traceroute" mode is out of the scope of this document. In RFC 4379, the echo reply is used to report the LSP checking result to the LSP Ping initiator. This document defines a new reply mode and a new TLV (RP TLV) to enable that the return path of the echo reply message could specified by the LSP Ping initiator, and the function of echo reply is extended to detect the return path by carrying specified path FEC TLV. It enables LSP Ping to detect both directions of a path in one operation. When the echo reply message is intended to test the return MPLS LSP path as specified, the destination IP address of the echo reply message is never used in a forwarding decision. For the purpose of detection the specified return MPLS LSP path, the echo reply message also needs to avoid IP forward at the condition of the LSP being tested broken. So the destination IP address of the echo reply message that is transmitted along the specified return path MUST be set numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for Ipv6, and the IP TTL MUST be set 1. If the echo reply message Chen, et al. Expires January 2, 2010 [Page 7] Internet-Draft Return Path Specified LSP Ping July 2009 is not intended for testing the specified return path, the same as defined in [RFC 4379], the destination IP address is copied from the source IP address of the echo request. 4.1. Sending an Echo Request When sending an echo request, in addition to the rules and processing defined in Section 4.3 of [RFC 4379], the reply mode of the echo request MUST be set to "Reply via specified path", and a RP TLV MUST be carried in the echo request message correspondingly. The RP TLV includes one or several reply path sub-TLV(s) to identify the return path(s) that is used to notify the egress which path(s) to send along. For Bidirectional LSP, since the ingress and egress of a Bidirectional LSP are aware of the relationship between the forward and backward direction LSPs, only a Bidirectional sub-TLV SHOULD be carried within the RP TLV. If the operator wants the echo reply to be sent along a different path other than the reverse LSP of the Bidirectional LSP, another FEC sub-TLV SHOULD be carried in the RP TLV instead. In some cases, operators may want to detect two unidirectional LSPs (one for each direction) as a pair. There may not be any binding relationship between the two LSPs. Using the mechanism defined in this document, operators can run LSP Ping one time from one end to complete the failure detection on both unidirectional LSPs. In such condition, when sending the echo request message, one specific FEC sub-TLV MUST be carried in the RP TLV to notify the egress which path to send along and detect. 4.2. Receiving an Echo Request Those processing relevant to "ping" mode defined in Section 4.4 of [RFC 4379] apply in this document. In addition, when an echo request received, if the egress does not know the reply mode defined in this document, an echo reply with return code set to "Malformed echo request" and the Subcode set to zero SHOULD be send back to the ingress. If the egress knows the reply mode, according to the RP TLV, it SHOULD find and select a matched return path, if there is no such a path, an echo reply with return code set to "The specified reply path not existence" and the Subcode to zero SHOULD be sent back to the ingress. If there is a match, an echo reply with return code set to "Success to match the specified path" and Subcode to zero SHOULD be sent back to the ingress. Chen, et al. Expires January 2, 2010 [Page 8] Internet-Draft Return Path Specified LSP Ping July 2009 When received an echo request with reply mode set to "Reply via specified path", if there is no Any Candidate sub-TLV included in the RP TLV, means that the echo reply is required to send along the specified path and to detect the return path as well. Otherwise, means that the echo reply is not required to detect the return path. 4.3. Sending an Echo Reply As described in [RFC 4379], the echo reply message is a UDP packet, and it MUST only be sent response to an MPLS echo request. The source IP address is a routable IP address of the replier, the source UDP port is the well-know UDP port for LSP ping. When the echo reply is intended to test the return path, the destination IP address of the echo reply message MUST be never used in a forwarding decision. For the purpose of detection the specified return MPLS LSP path, the echo reply message also needs to avoid IP forward at the condition of the LSP being tested broken. So the destination IP address of the echo reply message that is transmitted along the specified return path MUST be set numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for Ipv6, and the IP TTL MUST be set 1. If the echo reply is required to test the return path, the echo reply MUST have an FEC stack TLV about the return path, which is used for the ingress to perform FEC validation. The FEC stack TLV of the forward path MUST NOT be copied to the echo reply. If the echo reply message is not intended for testing the specified return path, the same as defined in [RFC 4379], the destination IP address and UDP port are copied from the source IP address and source UDP port of the echo request. When sending the echo reply, the RP TLV carried in the received echo request MAY be copied to the echo reply to give the Ingress enough information about the back direction tested path to verify the consistent of the data plane against control plane. 4.4. Receiving an Echo Reply The rules and process defined in Section 4.6 of [RFC 4379] apply here. And when an echo reply received, if the reply mode is "Reply via specified path" and an FEC stack TLV exists, it means that the echo reply has both Ping result reporting and reverse path checking functions. The ingress MUST do FEC validation as an egress does when received an echo request, the FEC validation process (relevant to "ping" mode) defined in Section 4.4.1 of [RFC 4379] apply here. Chen, et al. Expires January 2, 2010 [Page 9] Internet-Draft Return Path Specified LSP Ping July 2009 When received an echo reply with return code set to "Malformed echo request received" and the Subcode set to zero. It's possible that the egress may not know the "Reply via specified path" reply mode, the operator may choose to re-perform another LSP Ping by using one of the four reply modes defined [RFC 4379]. When the LSP Ping initiator failed to receive the echo reply message, the operator MAY initiate another LSP Ping by resending a new echo request carrying a RP TLV that includes an Any Candidate sub-TLV and the previous sent reply path sub-TLV(s) (Bidirectional sub-TLV or FEC sub-TLVs) to notify the egress LSR to send echo reply message along any other workable path (no matter what MPLS LSP or IP path) excluding the path(s) identified by those Bidirectional sub-TLV or/and FEC sub-TLVs. Hence it could improve the reliability of the echo reply message. In such mode, the echo reply SHOULD NOT be used to detect the return path. 5. Security Considerations Security considerations discussed in [RFC 4379] applies to this document. 6. IANA Considerations IANA is requested to make the following allocations from registries under its control. 6.1. Reply mode and return codes IANA is requested to assign a new reply mode and two new return codes as follows: Reply mode: Value Meaning ----- ------- 5 Reply via specified path Return codes: Chen, et al. Expires January 2, 2010 [Page 10] Internet-Draft Return Path Specified LSP Ping July 2009 Value Meaning ----- ------- 14 Success to match the specified path 15 The specified reply path not existence 6.2. RP TLV IANA is requested to assign a new TLV type (TBD) from the range of 0-16383. We suggest that the value 20 be assigned for the new RP TLV type. Type Value Field ----- ----------- 20 Reply Path 6.3. Sub-TLVs for RP TLV This document defines two new sub-TLV Types (described in Section 3.4 and 3.5) of RP TLV, and those FEC sub-TLVs defined in [RFC 4379] are applicable for inclusion in RP TVL. IANA is requested to assign sub-TLVs as follows. The following numbers are suggested: Chen, et al. Expires January 2, 2010 [Page 11] Internet-Draft Return Path Specified LSP Ping July 2009 Sub-type Value Field Reference -------- ----------- --------- 1 LDP IPv4 prefix RFC 4379 2 LDP IPv6 prefix RFC 4379 3 RSVP IPv4 LSP RFC 4379 4 RSVP IPv6 LSP RFC 4379 5 Not Assigned RFC 4379 6 VPN IPv4 prefix RFC 4379 7 VPN IPv6 prefix RFC 4379 8 L2 VPN endpoint RFC 4379 9 "FEC 128" Pseudowire (Deprecated) RFC 4379 10 "FEC 128" Pseudowire RFC 4379 11 "FEC 129" Pseudowire RFC 4379 12 BGP labeled IPv4 prefix RFC 4379 13 BGP labeled IPv6 prefix RFC 4379 14 Generic IPv4 prefix RFC 4379 15 Generic IPv6 prefix RFC 4379 16 Nil FEC RFC 4379 17 Bidirectional this document 18 Any Candidate this document 7. Acknowledgments The authors would like to thank Adrian Farrel and Ehud Doron for their review and comments to this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 4379] K. Kompella., et al., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Chen, et al. Expires January 2, 2010 [Page 12] Internet-Draft Return Path Specified LSP Ping July 2009 8.2. Informative References [RFC 3471] L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC 3473] L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling", RFC 3473, January 2003. Chen, et al. Expires January 2, 2010 [Page 13] Internet-Draft Return Path Specified LSP Ping July 2009 Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District, Beijing 100085 P.R. China EMail: mach@huawei.com Xinchun Guo Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District, Beijing 100085 P.R. China EMail: guoxinchun@huawei.com Wei Cao Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District, Beijing 100085 P.R. China EMail: caoweigne@chinamobile.com So Ning Verizon 2400 N. Glem Ave., Richerson, TX 75082 Phone: +1 972-729-7905 EMail: ning.so@verizonbusiness.com Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: frederic.jounay@orange-ftgroup.com Chen, et al. Expires January 2, 2010 [Page 14] Internet-Draft Return Path Specified LSP Ping July 2009 Simon Delord Telstra 242 Exhibition St Melbourne VIC 3000 Australia EMail: simon.a.delord@team.telstra.com Chen, et al. Expires January 2, 2010 [Page 15]