Network Working Group Siva Sivabalan (Ed.) Internet Draft Sami Boutros (Ed.) Intended status: Informational Luca Martini Expires: January 5, 2011 Cisco Systems, Inc. July 5, 2010 Pseudowire Stitching Procedures in MPLS-TP Networks draft-boutros-pwe3-ms-pw-tp-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 Jaunary 5, 2011. Abstract The existing procedures for concatenating Pseudowire(PW) segments to form Multi-Segment PW (MS-PW) 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 the PW stitching procedures in an MPLS-TP environment. Boutros Expires January 5, 2011 [Page 1] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Operation......................................................3 3.1. Lock Operation............................................4 3.1.1. Locking MPLS-TP LSP..................................4 3.1.2. Locking PW...........................................6 3.2. Loopback Operation........................................6 3.2.1. Loopback at MPLS-TP LSP Level........................6 3.2.2. Loopback at PW Level.................................7 3.3. Switching Point PE TLV....................................7 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..........................................9 Intellectual Property Statement..................................10 1. Introduction The PWE3 Architecture [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]. 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 M-PW in an MPLS Transport Profile (MPLS-TP) environment. These functions enable network operators to lock a circuit and operate it in loopback mode for testing/management purpose. LSP and PW. This informational document describes the application of the existing PW stitching procedures taking into consideration LI, LB, as well as PW status OAM messages. Conventions used in this document Boutros Expires January 5, 2011 [Page 2] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 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. 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 Boutros Expires January 5, 2011 [Page 3] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 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 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 can either be a MIP or 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 LI request for the MPLS-TP LSP carrying PW1. The intended recipient of the message can be either S-PE or T- PE2. When T-PE1 receives positive LI reply from the intended recipient (T-PE2 or 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. If S-PE receives an LI request, and if the intended MPLS-TP LSP can be locked, it first sends the following PW status code 0x00000018 (Local PSN-facing PW Receive/Transmit Faults) to T-PE2. Note that the same PW status code will be sent for all PWs associated with the MPLS Boutros Expires January 5, 2011 [Page 4] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 LSP being locked out. 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 (Sami: Check). 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 PW2 as well as all other PWs pinned down to MPLS-TP LSP in question 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-PE2 so that services on PW2 can resume. If PW2 is a dynamic segment and PW status, S-PE needs to withdraw its labels from 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. Boutros Expires January 5, 2011 [Page 5] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 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. If S-PE is the intended recipient (based on the TTL value of the PW label) and if it 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 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. If T-PE2 is the intended recipient of the LI message (in this case S- PE is a MIP), and if T-PE2 is able to lock PW2, it locks PW2 and sends a positive LI response to T-PE1. If T-PE2 is unable to lock PW2, it sends a negative LI response to T-PE1. Note that TTL value of the PW label in the LI response should be chosen (e.g., 255) such that the LI response will not be intercepted and processed by any node other than T-PE1. 3.2. Loopback Operation 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, 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. 3.2.1. 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 Boutros Expires January 5, 2011 [Page 6] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 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. The loopback operation can as well be between T-PE1 and T-PE2, in this case PW2 and all PWs pinned down over the MPLS-TP LSP (that received the LB request) will be programmed to loopback traffic back to T-PE1. 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 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 defined for FEC129. 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]. Boutros Expires January 5, 2011 [Page 7] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 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. [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-statuc-00.txt (work in progress), February 2010. [5] Sami Boutros, et. al, "MPLS Transport Profile Lock Instruct and Loopback Functions", draft-boutros-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-nitinb-mpls-tp-lsp-ping-extensions-01.txt (work in progress), February 2010. Boutros Expires January 5, 2011 [Page 8] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 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 Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 United States Email: lmartini@cisco.com 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. Boutros Expires January 5, 2011 [Page 9] Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010 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. 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 January 5, 2011 [Page 10]