PWE3 Working Group Wei, Cao Internet Draft Huawei Technologies Expires: April 2009 October 27, 2008 Setup of Pseudowires over bi-directional LSP draft-cao-pwe3-setup-over-bidir-lsp-00.txt 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 27, 2009. Abstract In MPLS and MPLS-TE environments pseudo wires use two unidirectional LSPs as PSN tunnels, the two PEs select LSP tunnels independently. In contrast the MPLS-TP environment supports both bidirectional and unidirectional LSPs and PWE may, therefore, use bidirectional LSPs as PSN tunnels. In order to use MPLS-TP bidirectional LSPs as a PSN tunnels for pseudo wires some modification of the pseudowire signaling procedures Wei Cao Expires April 27, 2009 [Page 1] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 is required. This draft specifies an extension to LDP that ensures pseudo-wires are correctly constructed over bi-directional LSPs. 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. Table of Contents 1. Introduction................................................3 1.1. Motivations and scenarios...............................3 1.2. Scope of this document..................................4 2. Applicability Statement......................................4 2.1. SS-PW architecture......................................4 2.2. MS-PW architecture......................................5 3. LDP Extensions..............................................6 3.1. Bi-directional LSP TLV..................................6 4. SS-PW Signaling Procedures...................................8 4.1. Active/Passive PE Signaling Procedure...................9 4.1.1. Active PE Signaling Procedure......................9 4.1.2. Passive PE Signaling Procedure.....................9 4.2. Active/Active PE Signaling Procedure....................9 5. Security Considerations.....................................10 6. IANA Considerations........................................10 7. Acknowledgments............................................10 8. References.................................................10 8.1. Normative References...................................10 8.2. Informative References.................................10 Author's Addresses............................................11 Intellectual Property Statement................................11 Disclaimer of Validity........................................12 Copyright Statement...........................................12 Acknowledgment................................................12 Wei Cao Expires April 27, 2009 [Page 2] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 1. Introduction The requirements for Transport Network have been discussed in ITU-T for a number of years and a set of T-MPLS documents has been published. With the progress of the IETF and ITU-T Join Work Team (JWT), IETF will design a series of protocol based on current MPLS technology to meet T-MPLS requirement. The solution is called MPLS-TP. One significant change brought about by MPLS-TP is that LSPs may be bi-directional. Bi-directional LSPs have many advantages compared to traditional unidirectional LSP particularly since most of the upper layer services that will use them are bi-directional. Because most of the current application protocols are designed to use unidirectional LSPs, some adaptations are required when bi-directional LSPs are introduced. Pseudo wire is the most important application for MPLS-TP. This draft describes the necessary LDP extensions and signaling procedures to allow migration of PW service from traditional MPLS network to MPLS-TP enabled transport network. 1.1. Motivations and scenarios Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism to emulate a number of layer 2 services, such as ATM, Frame Relay or Ethernet, etc. Such services are emulated between two ACs and the PW encapsulated layer 2 service payload is carried by PSN tunnels between PEs. Today PWE3 generally uses two reverse unidirectional LDP/RSVP-TE LSPs as PSN tunnels. The possibility of asymmetric routing of the reverse LSPs and the lack of effective OAM mechanisms make it hard for unidirectional LSPs to meet the high QOS requirement of emulated layer 2 services. MPLS-TP is designed for transport networks and provides bi-directional LSPs which guarantee symmetric routing of both directions of the LSP. PWE3 is believed to be one of the most important applications for MPLS-TP. In the current architecture the two PW PEs select LSPs independently, the only requirement being that the LSP selected terminates on the 'other' PE. There is no architectural provision or requirement to associate a pseudowire with a PSN tunnel. In contrast, when bi- directional MPLS-TP LSPs are available and we want to run a PW over one of them, the PEs must make sure they select the same LSP for the PW; this is especially true when there are multiple bi-directional LSPs between the two PEs One possible method is binding the PSN tunnel manually at each PE but this is prone to configuration mistakes and it is difficult to maintain a large number of PWs in such a manner. To allow for minimal manual intervention and configuration, this draft discusses an automatic solution by extending FEC 128/129 based on [RFC4447]. Wei Cao Expires April 27, 2009 [Page 3] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 1.2. Scope of this document This document discusses LDP extensions to allow automatic signaling support for deployment of a large number of PWs. Static configuration is operator/vendor specific and is not discussed here. There are two types of PW defined in IETF: single segment PW and multi-segment PW. This document will cover both types of PW. As previously stated the original motivation for this work was a recognition that the MPLS-TP bi-directional LSP is essentially unusable by PWE application without extensions to the signaling mechanisms. We now believe that the LSP selection mechanism described here may be useful in existing MPLS networks and for other applications in addition to PWE. We will address these scenarios in a future version of this document. The method proposed in this draft is based on [RFC4447] and does not modify existing pseudowire or LSP constructs. 2. Applicability Statement Migration from existing MPLS PWE3 networks to MPLS-TP enabled networks will occur over an extended period and it is important to keep the new solution as compatible as possible with existing solutions. In keeping with PW architecture, we wish to minimize the modification of or extensions to current protocols. 2.1. SS-PW architecture Figure 1 illustrates the reference model derived from [RFC3985] which supports single segment PW emulated services. PEs (PE1 and PE2) provide one or more PWs for their CEs (CE1 and CE2) to enable the client CEs to communicate over the PSN. The PSN network uses Bi- directional MPLS-TP LSP to provide a data path for the PW service. In this model both PE1 and PE2 both support bi-directional LSPs. It is important for higher layer services to be able choose the same bi- directional LSP at both PEs. This is a problem when one or more LSP exist between them; multiple LSPs may be used to provide different levels of QOS or provide protection. As an example, when PE1 expects to setup the PW on a bi-directional LSP; it chooses a bi-directional LSP for the PW, and then sends a Label Mapping message to PE2. Because there is currently no mechanism for PE2 to learn the bi-directional LSP information (or indeed any Wei Cao Expires April 27, 2009 [Page 4] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 unidirectional LSP information), from the mapping message, it may choose another bi-directional LSP for the same PW. With this restriction different bi-directional LSPs could be selected for one PW by the two PEs. Similar problem can occur if unidirectional LSP coexists with MPLS-TP bi-directional LSP. |<----------- Emulated Service ------------->| | | | |<------- Pseudowire ------->| | | | | | | | |<-Bi-directional->| | | | V V LSP Tunnel V V | V +----+ +----+ V +-----+ | PE1|==================| PE2| +-----+ | |-------|............PW1.............|-------| | | CE1 | | | | | | CE2 | | |-------|............PW2.............|-------| | +-----+ | |==================| | +-----+ +----+ +----+ Figure 1: SS-PW Reference Model 2.2. MS-PW architecture Figure 2 extends the SS-PW architecture to show a multi-segment case. The PEs that provide PW to CE1 and CE2 are Terminating-PE1 (T-PE1) and Terminating-PE2 (T-PE2) respectively. The PE that joints PW segment 1 and segment 2 is called Switching-PE1 (SPE1). It is assumed that TPE1 and TPE2 need to setup PW segments on bi-directional LSPs. For PW segment 1, S-PE1 does not know which bi-directional LSP is selected by T-PE1. As a consequence S-PE1 may select another bi- directional LSP or a unidirectional LSP for the reverse path to T-PE1. For PW segment 2, the similar issues arise between SPE-1 and TPE-2. Wei Cao Expires April 27, 2009 [Page 5] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 |<------Multi-Segment Pseudowire------>| | Bi-dir. Bi-dir. | | |<-LSP 1->| |<-LSP 2 ->| | V V V V V V +----+ +-----+ +----+ +----+ |TPE1|===========|SPE1 |==========|TPE2| +----+ | |------| | | | | |-------| | | CE1| |..... PW.Seg't1.........PW.Seg't2.....| |CE2 | | |------| | | | | |-------| | +----+ | |===========| |==========| | +----+ ^ +----+ +-----+ +----+ ^ | Provider Edge 1 Provider Edge 2 | | | |<------------------ Emulated Service --------------->| Figure 2: MS-PW Reference Model The key point of our solution is to eliminate the problems illustrated above, we do this by enabling the target PE to learn the bi-directional LSP selected by the Mapping sender. 3. LDP Extensions Before sending a Label Mapping message to setup a PW, PE has selects a bi-directional LSP for the PW. We introduce a bi-directional LSP TLV to allow the identity of this bi-directional LSP to be communicated to the target PE. 3.1. Bi-directional LSP TLV The bi-directional LSP TLV specifies a bi-directional LSP which is selected by the sending PE. This TLV is contained in a Generalized PW FEC (FEC129) or PW ID FEC (FEC128) and sent to the target PE in the Label Mapping message. Note that sending the bi-directional LSP TLV is OPTIONAL, but the target PE must process the TLV upon reception. The proposed format of the bi-directional LSP TLV is as follows: Wei Cao Expires April 27, 2009 [Page 6] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 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| bi-dir. LSP TLV (TBD) | bi-dir. LSP TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel Extended ID (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure3 IPv4 bi-directional LSP TLV format 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| bi-dir. LSP TLV (TBD) | bi-dir. LSP TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Extended Tunnel ID (optional) | + + | (16bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel end point address | + + | (16bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel sender address | + + | (16bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure4 Ipv6 bi-directional LSP TLV format - Bi-directional LSP TLV Length Wei Cao Expires April 27, 2009 [Page 7] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 Specifies the total length of the bi-directional LSP TLV fields in octets - Variable Length Value In an MPLS-TP network, a bi-directional LSP established by RSVP-TE signaling can be identified using a SESSION object and a SENDER_TEMPLATE object, see [RFC3209]. The SESSION object carries the tunnel destination IP address and the tunnel ID to identify a tunnel. The SENDER_TEMPLATE object carries the source IP address of the tunnel and the LSP ID to identify a LSP. This document specifies the following Variables to be included in LSP TLV; their meanings are same in SESSION object and SENDER_TEMPLATE object: - LSP ID - Tunnel ID - IPv4/IPv6 tunnel Extended ID (optional) - IPv4/IPv6 tunnel end point address - IPv4/IPv6 tunnel sender address To identify an IPv4 tunnel, following Variables should be included in the bi-directional LSP TLV: < LSP ID, Tunnel ID, IPv4 tunnel end point address, IPv4 tunnel sender address >. In order to indicate a globally unique tunnel, IPv4 Extended Tunnel ID may also be used. To identify an IPv6 tunnel, following variables should be included in the bi-directional LSP TLV: < LSP ID, Tunnel ID, IPv6 tunnel end point address, IPv6 tunnel sender address>. In order to indicate a globally unique tunnel, IPv6 Extended Tunnel ID may also be used. 4. SS-PW Signaling Procedures PE1 and PE2, known as "LDP Peers", use Label Mapping messages to exchange PW information with each other. Depending on the role they play in the selection of a bi-directional LSP, we identify two types of PEs: a) Active PE: the PE which initiates the selection of a bi- directional LSP and informs the remote PE; b) Passive PE: the PE which obeys the active PE's suggestion If the two PEs both assume the active role in signaling an LSP for the same PWE then competition (a signaling collision) occurs. In this Wei Cao Expires April 27, 2009 [Page 8] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 case, the two PEs should obey a predefined rule to decide which bi- directional LSP will be used, 4.1. Active/Passive PE Signaling Procedure 4.1.1. Active PE Signaling Procedure Before sending the Mapping Message, the active PE, say PE1, must select a bi-directional LSP for the PW. This indicates that PW will be carried through the selected bi-directional LSP tunnel. PE1 generates a "bi-directional LSP TLV" that identifies the selected LSP and sends a Mapping message containing it to the passive PE, in this case PE2. 4.1.2. Passive PE Signaling Procedure When a Label Mapping message carrying a bi-directional LSP TLV is received by PE2 it may decide, based on local policy and/or success or failure in matching the LSP to accept or reject it. If the bi-directional LSP cannot be matched successfully or if local policy prohibits its acceptance, a Label Release message must be sent, with an "Unassigned/Unrecognized bi-directional LSP" code, and the processing of the Label Mapping message is complete. If the bi-directional LSP proposed by PE1 is accepted by PE2 then PE2 attempts setup of the PW in the opposite (PE2->PE1) direction. If PE2 has not already signaled for the opposite direction, it sends a Label Mapping message to PE1, with a "bi-directional LSP TLV" that identifies the same bi-directional LSP, proposed by PE1, that it has accepted for this PW. If PE1 receives a Label Mapping message in which "bi-directional LSP" is equal to the bi-directional LSP it selected then both directions of the PW are setup. 4.2. Active/Active PE Signaling Procedure Sometimes, before PE2 receives the Label Mapping message, it has already sent a Label Mapping message to PE1. If the bi-directional LSP in the received message from PE1 is as same as it was in the message sent by PE2 then the signaling has converged on an mutually agreed LSP and is completed. Otherwise, when the bi-directional LSP selected by PE1 differs from the LSP selected by PE2, PE1 and PE2 have to make a choice between two LSPs. In this case both PE1 and PE2 have assumed 'active' roles and they must have the capability to resolve this contention. In this case PE1 and PE2 will compare the node ID in the received mapping messages with their own node ID. , Wei Cao Expires April 27, 2009 [Page 9] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 The LSP selected by the node with higher ID will be determined to carry PW. MS_PW signaling procedures - TBD. 5. Security Considerations TBD 6. IANA Considerations TBD 7. Acknowledgments Many thanks to my colleague Mingming Zhu and Li Xue for their comments and help in preparing this document. Also this draft has benefited from discussions with Nabil Bitar, Paul Doolan, Frederic Journay and Andy Malis. 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. [RFC5036] Andersson, L., Ina Minei and Thomas, B., "LDP Specification", RFC5036, October 2007. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T.,and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447,April 2006. 8.2. Informative References [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [MS-PW-ARCH] Matthew Bocci and Stewart Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge " Wei Cao Expires April 27, 2009 [Page 10] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 [MPLS-TP] ITU-T - IETF Joint Working Team, Dave Ward and Malcolm Betts,"MPLS Architectural Considerations for a Transport Profile", "http://www.ietf.org/MPLS- TP_overview-22.pdf", April 2008 [MPLS-TP-FWK] Matthew Bocci,et al., "A Framework for MPLS in Transport Networks", "draft-bld-mpls-tp-framework", July 2008. Author's Addresses Wei Cao Huawei Technologies Co., Ltd. Huawei Building., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China Email: caowayne@huawei.com 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. 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. Wei Cao Expires April 27, 2009 [Page 11] Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008 Disclaimer of Validity 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. Copyright Statement Copyright (C) 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wei Cao Expires April 27, 2009 [Page 12]