Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan Intended status: Standards Track George Swallow Expires: July 2009 David Ward Stewart Bryant Cisco Systems, Inc. January 9, 2009 Connection verification for MPLS Transport Profile LSP draft-boutros-mpls-tp-cv-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 July 9, 2009. Abstract This document specifies method for verifying the connection of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for management purpose. The proposed extension is based on MPLS Operation, Administration, and Maintenance (OAM). The goal is to verify that an MPLS-TP is properly setup in both control and data Boutros Expires June 9, 2009 [Page 1] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 planes, as well as to record the identities of all the LSRs along the path of MPLS-TP LSP. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................5 3. MPLS-TP Connection Verification Mechanism......................5 4. MPLS-OAM Connection Verification Message.......................6 4.1. Connection Verification Request TLV.......................7 4.2. Connection Verification Reply TLV.........................8 4.3. Record Route TLV..........................................8 4.4. Added returned code to the Response TLV defined in [5]....9 4.5. Network Management System.................................9 5. Operation......................................................9 6. Security Considerations.......................................11 7. IANA Considerations...........................................11 TBD..............................................................11 8. References....................................................11 8.1. Normative References.....................................11 8.2. Informative References...................................11 Author's Addresses...............................................12 Full Copyright Statement.........................................12 Intellectual Property Statement..................................13 1. Introduction In traditional transport networks, circuits are provisioned on multiple switches. Service Providers (SP) need to verify that the circuits are provisioned correctly in both control and data plane for management purpose. MPLS-TP bidirectional LSPs emulating traditional transport circuits need to provide the same connection verification capability. In this document, an MPLS-TP LSP means either MPLS transport LSP or MPLS Pseudowire (PW) [2]. The proposed solution is based on new type of MPLS-OAM message called Connection Verification (CV) message. An MPLS-OAM CV message originates at a Maintenance End Point (MEP) but can be directed to by any Maintenance Intermediate Point (MIP) along the path of MPLS-TP LSP as well as the other MEP. Therefore, the proposed mechanism addresses the verification of the full or partial path of an MPLS-TP LSP. Boutros Expires June 9, 2009 [Page 2] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 An MPLS-OAM CV message is intercepted at any MIP based on MPLS TTL expiry, and at MEP simply because it is the end of the LSP (i.e., regardless the value of the TTL). In response to the MPLS-OAM CV request, each LSR along the path of the MPLS-TP LSP appends its ID using a newly defined TLV called Record Route TLV. A Record Route TLV appended by a given LSR contains: . The LSR address. . Local Labels allocated by the LSR for both directions of the MPLS-TP LSP. To describe the connection verification functionality, let us assume an MPLS-TP LSP between LSR-1 and LSR-5 passing through LSR-2, LSR-3, and LSR-4. Thus, LSR-1 and LSR-5 are MEPs whereas LSR-2, LSR-3, and LSR-4 are MIPs. The objective is to verify (both in control and data planes) the MPLS-TP LSP from LSR-1 to LSR-5 (end-to-end), and record all the IDs of the LSRs along the path. This could be accomplished using a conventional traceroute operation in which LSR-1 interrogates each LSR-2 through LSR-5 (using appropriate TTL value) in turn using a new message and response, and compiles the result. This approach requires 8 messages; a request and a response between LSR-1 and each of the other LSRs. On the other hand, the mechanism that we describe below can accomplish the goal with only 5 messages. The same mechanism can work if the MPLS-TP LSP is a Multisegment PseudoWire (MS-PW) [8]. It is possible that the path of an MPLS-TP LSP contains loop(s) due to misconfiguration. Such mistakes are possible with manual configuration. For example, assume that MPLS-TP LSP under discussion is misconfigured such LSR-4 connects to LSR-2 instead of LSR-5. This results in a loop. In this case, the MPLS-OAM CV packets self limit when the MTU is reached, and when it happens, it is good practice to silently drop those packets. If a MIP does not understand the MPLS-OAM CV message, it must silently drop the packet. To trap this condition as well as to trap the looping condition, an ingress MEP that initiates connection verification starts a timer when it sends an MPLS-OAM CV message. If the timer expires before it has received a response, the MEP assumes one of the following conditions: . the MPLS-TP LSP is incomplete. Boutros Expires June 9, 2009 [Page 3] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 . an LSR (either MIP or MEP) does not understand the MPLS-OAM CV message. . there is a loop. The ingress MEP then examines the MPLS-TP LSP by using the classic one-hop at a time, direct response traceroute. In case not all hops on the path of the MPLS-TP LSP are MIPs, an ingress MEP can send conventional trace route with incrementing TTL 1, 2, 3, ...., to all MIPs and to the egress MEP along the path. Some of those requests will be sent to non MIP/MEP LSRs and will be dropped silently. When the MIPs and egress MEP receive the request, they will respond with an MPLS-OAM CV response message. The TTL value of the response SHOULD be large to ensure the response message reaches the ingress MEP without being intercepted at any MIP. Optionally, the TTL value of the response MAY be set to 1 so that each MIP can verify its ID included in the response message as the response travels towards the ingress MEP. An MPLS-OAM CV message contains the following information: 1. Connection ID for the MPLS-TP in question. 2. IDs of the LSR (to record the route). 3. Sequence Number to correlate a given reply with the correct request. The above information is carried in TLV format. The proposed mechanism is based on a set of new TLVs which can be transported using one of the following methods: 1. Using in-band MPLS-OAM messages which are forwarded as MPLS packets (Non-IP-Based). 2. Using in-band LSP-Ping extensions defined in [3] where IP/UDP packets are used (IP-Based). The LSP-Ping messages are sent using the codepoint defined in [4]. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Boutros Expires June 9, 2009 [Page 4] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 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 Error! Reference source not found. 2. Terminology ACH: Associated Channel Header GAL: Generalized Alert Label LSR: Label Switching Router MEP: Maintenance End Point MIP: Maintenance Intermediate Point MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-TP: MPLS Transport Profile MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit MS-PW: Mult-Segment PseudoWire NMS: Network Management System PW: PseudoWire RR: Record Route TLV: Type Length Value TTL: Time To Live 3. MPLS-TP Connection Verification Mechanism For the Non-IP-Based option, the proposed mechanism uses a new code point in the Associated Channel Header (ACH) described in [7]. The IP-Based option will be in compliance to specifications [3] and [4]. Also, the proposed mechanism requires a set of new TLVs called Connection Verification Request TLV, Connection Verification Reply TLV, Record Route TLV. Also, Response TLVs defined in [5], and the Boutros Expires June 9, 2009 [Page 5] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 Address Block and Connection-ID TLVs defined in [6] are also required for this mechanism. The new TLVs are described below. 4. MPLS-OAM Connection Verification Message In the Non-IP-Based option, under MPLS label stack of the MPLS-TP LSP, the ACH with "MPLS-TP Connection Verification" code point indicates that the message is an MPLS OAM Connection Verification message. In addition, a 32-bit field is added to carry the message ID and the message length as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| (MPLS-TP CV code point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MPLS-TP OAM Message Header First nibble = 0001b. The version and the reserved values are both set to 0 as specified in [1]. MPLS-TP Connection Verification code point (value TBD). The Message ID is set by the sender. The receiver MUST include the Message ID in the response. This way, the sender can correlate a reply with the corresponding request. The Message Length is the total length of the message in bytes excluding the length of the MPLS-TP OAM message header. Boutros Expires June 9, 2009 [Page 6] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 4.1. Connection Verification Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ LSR Address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Connection-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connection Verification Request TLV is used to instruct a MEP or a MIP to record the route by appending the Record Route TLV (described below) to the MPLS-OAM message and forward the packet along the path of the MPLS-TP LSP (in the case of a MIP) or send a response back to the sender MEP (in the case of the receiver MEP). The request will contain LSR-Address and connection-ID sub-TLVs defined in [6]. In case of errors, the receiver MEP or MIP MUST send a NAK response to the sender MEP using an MPLS-OAM message with a Response TLV containing the error code described below. Boutros Expires June 9, 2009 [Page 7] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 4.2. Connection Verification Reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ LSR Address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Connection-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Connection Verification Reply TLV is sent by a MEP or a MIP in response to a request. The reply contains the sequence number of the request and the LSR Address of the MEP or MIP and connection-ID Sub- TLVs defined in [6] of the MPLS-TP LSP. Connection verification reply is used to send all the record route TLVs in the connection verification request to the sender MEP. 4.3. Record Route 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forward Local Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse Local Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ LSR Address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Record Route TLV includes the LSR address sub-TLV defined in [6] as well as the forward and reverse local labels (allocated by the LSR for both directions of the LSP). The forward local label is the label allocated by the LSR in the direction of the connection verification request message. The reverse local label at a MEP MUST be 0. Boutros Expires June 9, 2009 [Page 8] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 4.4. Added returned code to the Response TLV defined in [5] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | Length = 0x1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ReturnCode | +-+-+-+-+-+-+-+ Return code Value Meaning ----- ------- 16 LSP is not setup in control or data planes 17 LSR ID not in the MPLS-OAM CV response message Note that the proposed connection verification mechanism also requires the some other return codes specified in [5]. 4.5. Network Management System An operator should be able to provision any given LSR to send MPLS- OAM CV Request packets from a MEP and notify NMS when MPLS-OAM CV Response arrives. 5. Operation Consider an MPLS-TP LSP LSR-1 <--> LSR-2 <--> LSR-3 <--> LSR-4 <--> LSR-5. LSR-1 and LSR-5 are ingress and egress LSR for the respective direction. LSR-1 and LSR-5 are MEPs, and LSR-2 through LSR-4 are MIPs. The proposed mechanism operates as follows: 1. After the MPLS-TP LSP is configured at LSR-1 and LSR-5 with the same connection-ID, LSR-1 sends an MPLS-OAM CV Request message along the path of the LSP. 2. The MPLS-OAM CV Request message is intercepted at LSR-2 (MIP) because of TTL expiry. LSR-2 then verifies the request and: 1. if the message is malformed, it sends a response with the error code 2 back to LSR-1. Boutros Expires June 9, 2009 [Page 9] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 2. if any of the TLV is not known, it sends a response with error code 3 back to LSR-1. It may also include the unknown TLVs. 3. if message authentication fails, it sends a response with the error code 4 back to LSR-1. 4. if connection-ID cannot be matched, it sends a response with error code 14. 5. if the MPLS-TP LSP is not setup in control or data planes, it sends a response with error code 16. Note that MPLS TTL value is set to 255 in the response message. 3. LSR-2 then verifies the request and if connection-ID matches that in the message, and if the MPLS-TP LSP is setup in control and data planes, it appends its address as well as the local labels to the message and forward it to LSR-3 with a TTL = 1. 4. LSR-3 repeats the steps (2) or (3). In the absence of error, the messages progresses towards LSR-5 with each LSR adding its own ID and the local labels. 5. Upon getting the MPLS-OAM CV message, LSR-5 verifies the request, and if an MPLS-TP LSP whose connection-ID matches that in the message is found, and if that MPLS-TP LSP is setup in both control and data planes, LSR-5 sends a response back to the LSR-1. The response contains the record route received by LSR-5. The TTL value of the response will be such that the response message reaches LSR- 1 without further interception at any other LSR. As an optional alternative, LSR-5 may send the packet down the return path with a TTL=1 so that an LSR can verify its ID included in the response. 6. When LSR-1 receives a response with a large TTL (i.e., TTL value is not equal to 1), it becomes aware of the IDs of each LSR on the path as well as how far away (in terms of hop-count) is each LSR from itself. Hence, LSR-1 may send an MPLS-OAM message directly to any LSR using an appropriate TTL value in the future. On the other hand, if LSR-1 receives a response with TTL value equals 1, it gets a confirmation that the path is bidirectionally symmetric, which is a critical consideration in transport networks. Boutros Expires June 9, 2009 [Page 10] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 6. Security Considerations 7. IANA Considerations TBD 8. References 8.1. Normative References [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [2] L. Martini, et. al., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447, April, 2006. [3] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires ", RFC 5085, December 2007. [4] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [5] S. Boutros, et. al., "Operating MPLS Transport Profile LSP in Loopback Mode ", draft-boutros-mpls-tp-loopback-01.txt, Work in Progress, December 2008. 8.2. Informative References [6] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. [7] M. Bocci, et. al., "MPLS Generic Associated Channel", draft- ietf-mpls-tp-gach-gal-01.txt, work in progress, January 6, 2009. [8] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC5254, October 2008. Boutros Expires June 9, 2009 [Page 11] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 Author's Addresses Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: msiva@cisco.com George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MASSACHUSETTS 01719 United States Email: swallow@cisco.com David Ward Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: wardd@cisco.com Stewart Bryant Cisco Systems, Inc. 250, Longwater, Green Park, Reading RG2 6GB, UK UK Email: stbryant@cisco.com Full Copyright Statement 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Boutros Expires June 9, 2009 [Page 12] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. Boutros Expires June 9, 2009 [Page 13] Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009 For the avoidance of doubt, each Contributor to the UETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Boutros Expires June 9, 2009 [Page 14]