Network Working Group Siva Sivabalan (Ed.) Internet Draft Sami Boutros (Ed.) Intended status: Informational Luca Martini Expires: August 26, 2011 Cisco Systems, Inc. February 26, 2011 Stitching Procedures for Static PW in MPLS-TP Environment draft-boutros-pwe3-mpls-tp-ms-pw-01.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 26, 2010. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] Boutros Expires August 26, 2011 [Page 1] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 Abstract The existing procedures for concatenating static and dynamic pseudowires (PWs) do not take into account the PW status Operation, Administration, and Maintenance (OAM) messages defined for static PW. Also, these procedures do not take into account operator functions such Lock Instruct and Loopback introduced as part of MPLS Transport Profile (MPLS-TP). This informational document reiterates stitching procedures for static PW taking into account all the new proposed extensions. This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Operation......................................................4 3.1. Lock Operation............................................5 3.1.1. Locking MPLS-TP LSP..................................5 3.1.2. Locking PW...........................................6 3.2. Loopback Operation........................................7 3.2.1. Loopback at MPLS-TP LSP Level........................7 3.2.2. Loopback at PW Level.................................7 3.3. Switching Point PE TLV....................................8 3.4. LSP-Ping/Trace............................................8 4. Security Considerations........................................8 5. IANA Considerations............................................8 6. References.....................................................8 6.1. Normative References......................................8 6.2. Informative References....................................8 Author's Addresses................................................9 Full Copyright Statement.........................................10 Intellectual Property Statement..................................10 1. Introduction The PWE3 Architecture in [1] defines signaling and encapsulation techniques for establishing Single Segment PW (SS-PW) between a pair of terminating PEs. Procedures for stitching two or more static or dynamic SS-PWs to form Multi-Segment PW (MS-PW) are described in [2]. Boutros Expires August 26, 2011 [Page 2] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 These procedures make use of PW status messages carried in LDP TLV over dynamic PW established via LDP. [3] defines a new PW status OAM message used to carry PW status in-band over static PW. This message makes it possible to exchange PW status end-to-end over a MS-PW consisting of one or more static PW. [5] specifies operator new Operation, Administration, and Maintenance (OAM) functions Lock Instruct (LI) and Loopback (LB) for associated bi-directional circuits such as MPLS-TP LSP, SS-PW, and MS-PW in an MPLS Transport Profile (MPLS-TP) environment. These functions enable network operators to lock a circuit (LSP and PW) and operate it in loopback mode for testing/management purpose. This informational document describes the application of the existing PW stitching procedures taking into consideration LI, LB, as well as PW status OAM messages. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. 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 [1]. 2. Terminology LDP: Label Distribution Protocol. MEP: Maintenance End Point. MIP: Maintenance Intermediate Point. MPLS: Multi Protocol Label Switching. MPLS-TP: MPLS Transport Profile. MS-PW: Multi-Segment PseudoWire. LB: Loopback. Boutros Expires August 26, 2011 [Page 3] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 LI: Lock Instruct. LSP: Label Switched Path. OAM: MPLS Operations, Administration and Maintenance. PE: Provide Edge Node. PW: PseudoWire. S-PE: Switching Provider Edge Node of a MS-PW. SS-PW: Single-Segment PseudoWire. TLV: Type, Length, and Value. T-PE: Terminating Provider Edge Node of a MS-PW. 3. Operation In this section, we explain the use of LI/LB mechanisms referring to the MS-PW model shown in Figure 1. The SS-PW segments PW1 and PW2 can be either static or dynamic. We assume that PWs are carried over MPLS-TP LSPs (transport LSPs) so that LI/LB mechanisms can be applied at the transport LSP level, as well we consider the application of LI/LB at PW level. PW status is sent via LDP message and PW OAM message respectively over dynamic and static PW segments. Note that even though only two PW segments are considered in the examples below, the described procedures are applicable to MS-PWs with more than two segments. +-------+ (PW1) +-------+ (PW2) +-------+ | |------------->| |-------------->| | | T-PE1 | | S-PE | | T-PE2 | | |<-------------| |<--------------| | +-------+ +-------+ +-------+ Figure 1. Reference Model for LI/LB Mechanism Boutros Expires August 26, 2011 [Page 4] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 3.1. Lock Operation 3.1.1. Locking MPLS-TP LSP An MPLS-TP LSP can be taken out of service for maintenance operation using the LI mechanism described in [5]. LI messages are exchanged between MPLS-TP Maintenance End Points (MEPs). In the case of MS-PW, each MPLS-TP LSP associated with a given PW segment can be individually locked for management purpose. This means that, in a MS- PW scenario, a T-PE is always a MEP and an S-PE is a MEP for an MPLS- TP LSP carrying PW segments. Furthermore, a T-PE (MEP) assumes that an MPLS-TP LSP is successfully locked only when the corresponding LI reply is received from the other intended receiver MEP (other T- PE or S-PE). 3.1.1.1. LI originated at T-PE Assume that T-PE1 originates an LI request for the MPLS-TP LSP carrying PW1. The intended recipient of the message will be the S-PE. When T-PE1 receives a positive LI reply from the S-PE, it assumes that the MPLS-TP LSP is successfully locked, and takes PW1 and all other PWs associated with the MPLS-TP LSP out of service. This means that PW1 and all other impacted PWs will no longer carry user data. When S-PE receives an LI request, if the intended MPLS-TP LSP can be locked, the S-PE finds all PWs associated with this MPLS-TP LSP and first sends the PW status code 0x00000018 (Local PSN-facing PW Receive/Transmit Faults) on all stitched PWs segments to T-PE2. PW status code is sent over PW OAM message or LDP message depending on whether the segment PW2 is static or dynamic. After sending the PW status code to T-PE2, S-PE lock the MPLS-TP LSP and sends a positive LI reply to T-PE1. If the MPLS-TP LSP cannot be locked, S-PE sends a negative LI reply with the appropriate error code to T-PE1. When T-PE2 receives the PW status codes, it processes them as described in [3] or [4] depending on whether PW2 is dynamic or static. If PW2 is a dynamic segment and does not support PW status, S-PE needs to withdraw its labels from T-PE2 before locking the MPLS LSP. For better scalability, S-PE may use the notion of group ID described in [6] to send PW status or withdraw labels all impacted dynamic PWs between itself and T-PE2. Use of group ID with PW status OAM over static PW is TBD. Boutros Expires August 26, 2011 [Page 5] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 3.1.1.2. LI originated at S-PE Let's assume that an operator wants to originate an LI request at S- PE for the MPLS-TP LSP carrying PW1. The intended recipient of the LI request is T-PE1. First, S-PE sends PW status code 0x00000018 (Local PSN-facing PW Receive/Transmit Fault) for PW1 as well as all other PWs pinned down to MPLS-TP LSP in question to T-PE1 and PW2 and all other stitched PWs other segments to T-PE2. PW status code is sent over PW OAM message or LDP message depending on whether the segment PW2 is static or dynamic. When T-PE2 receives the PW status codes, it processes them as described in [3] or [4] respectively depending on whether PW2 is dynamic or static. It then sends LI request message to T-PE1. If T-PE1 can successfully lock the MPLS LSP, it sends a positive LI response. Upon receiving the response, S- PE1 assumes that the MPLS-TP LSP is locked, and PW1 is no longer used for carrying regular user data. If T-PE1 is unable to lock the MPLS-TP LSP, it sends a negative LI response with the appropriate error code. In this case, S-PE sends PW status 0x00000000 to T-PE1 and T-PE2 so that services on PW1 and PW2 and all other PWs associated with the MPLS-TP LSP in question can resume. If PW2 is a dynamic segment and PW status, S-PE needs to withdraw its labels from T-PE1 and T-PE2 before sending LI request to T-PE1. For better scalability, S-PE may use the notion of group ID described in [6] to send PW status or withdraw labels all impacted dynamic PWs. Use of group ID with PW status OAM over static PW is TBD. 3.1.2. Locking PW A given PW can also be taken out of service for maintenance operation without impacting services over other PWs using the LI mechanism described in [5]. 3.1.2.1. LI originated at T-PE In our example, let's assume that, T-PE1 sends an LI request message to lock PW1. S-PE is the intended recipient (based on the TTL value of the PW label).If S-PE is able to lock PW1, it sends a PW status message with the status code 0x00000018 (Local PSN-facing PW Receive/Transmit Fault) over PW2 to T-PE2, and locks PW1. S-PE then sends a positive LI reply to T-PE1. Upon receiving the positive LI Boutros Expires August 26, 2011 [Page 6] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 reply, T-PE locks PW1. If S-PE is unable to lock PW1, it sends a negative LI reply to T-PE1. PW status code is sent over PW OAM message or LDP message depending on whether the segment PW2 is static or dynamic. When T-PE2 receives the PW status codes, it processes them as described in [3] or [4] depending on whether PW2 is dynamic or static. . 3.2. Loopback Operation 3.2.1. As described in [5], an MPLS-TP LSP or a PW can be setup to in loopback mode for management purpose, e.g., to test or verify connectivity of the LSP/PW up to a specific node on the path of the MPLS-TP tunnel/PW, and to test the LSP/PW performance with respect to delay/jitter, etc. But, prior to operating in loopback mode, an MPLS- TP LSP or PW must be successfully locked. Loopback at MPLS-TP LSP Level Assume that an operator wants to operate an MPLS-TP LSP between T-PE1 and S-PE carrying PW1 in loopback mode such that S-PE loops all the incoming packets over the MPLS-TP LSP back to the sender (in this case T-PE1). T-PE1 sends an LB request message which is received by S-PE. S-PE can setup the MPLS-TP LSP only if all the PWs carried over that LSP can be setup in loopback mode. If S-PE can setup the MPLS-TP tunnel in loopback mode, it sends a positive LB response. Otherwise, it sends a negative LB response to T-PE1. If the MPLS-TP LSP is successfully setup in loopback mode, all incoming packets over PW1 will be looped back to T-PE1. This is also true for any other PW(s) between T-PE1 and S-PE pinned down to the MPLS-TP LSP in question. Similarly, MPLS-TP LSP between S-PE and T-PE1 can be operated in loopback mode such that T-PE1 loops all incoming packets over the LSP back to S-PE. In this case, S-PE and T-PE1 respectively are sender and receiver of the LB request message. 3.2.2. Loopback at PW Level A SS-PW or MS-PW can be operated in loopback mode. In our example, let's assume that PW1 is to be operated in a loopback mode such that S-PE loops all incoming packets over PW1 back to T- PE1. To setup this mode of operation, T-PE1 sends an LB request Boutros Expires August 26, 2011 [Page 7] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 message to S-PE. TTL value of the PW label is chosen so as to expire on the intended recipient (in our example TTL value should be 1 so that LB request can be processed at S-PE). If S-PE can successfully setup PW1 in loopback mode, it sends a positive LB response to T-PE1. If loopback operation over the entire MS-PW (i.e., over PW1 and PW2) such that T-PE2 loops all the incoming packets over PW2 back to T- PE1, T-PE1 and T-PE2 will be the sender and receiver of LB message. 3.3. Switching Point PE TLV Switching Point PE TLV (S-PE TLV) is used to record information about S-PE(s) that a PW traverses. An S-PE TLV contains many sub-TLVs as described in [3]. One such sub-TLV carries the FEC of the last traversed PW segment. In the case of MS-PW containing static PW segment(s), if the last traversed PW segment is statically provisioned, a new sub-TLV containing the FEC defined for static PW in [7] can be used to represent the last traversed PW segment. The new sub-TLV type will be defined in [4]. 3.4. LSP-Ping/Trace TBD 4. Security Considerations This document does not introduce any additional security constraints. 5. IANA Considerations Not applicable. 6. References 6.1. Normative References [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. 6.2. Informative References [2] Stewart Bryant, et. al, "Pseudowire Emulation Edge-to-Edge (PWE3) Architecture", RFC3985, March 2005. Boutros Expires August 26, 2011 [Page 8] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 [3] Luca Martini, et. al, "Segmented Pseudowire", draft-ietf-pwe3- segmented-pw-15.txt (work in progress), June 2010. [4] Luca Martini, et. al, "Pseudowire Status for Static Pseudowires", draft-ietf-pwe3-static-pw-status-00.txt (work in progress), February 2010. [5] Sami Boutros, et. al, "MPLS Transport Profile Lock Instruct and Loopback Functions", draft-ietf-mpls-tp-li-lb-00.txt (work in progress), June 2010. [6] Luca Martini, et. al, "Pseudowire Setup and Maintenance Using Label Distribution Protocol (LDP)", RFC4447, April 2006. [7] Nitin Bahadur, et. al, "LSP-Ping extensions for MPLS-TP", draft-ietf-mpls-tp-lsp-ping-extensions-01.txt (work in progress), February 2010. Author's Addresses Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: msiva@cisco.com Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 United States Email: lmartini@cisco.com Boutros Expires August 26, 2011 [Page 9] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 Full Copyright Statement Copyright (c) 2010 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 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. Boutros Expires August 26, 2011 [Page 10] Internet-Draft draft-boutros-pwe3-mpls-tp-ms-pw-01.txt February 2011 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. 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 August 26, 2011 [Page 11]