Network working group M. Chen Internet Draft W. Cao Category: Standards Track Huawei Technologies Co.,Ltd Expires: September 2011 A. Takacs Ericsson March 14, 2011 LDP extensions for Explicit Pseudowire to transport LSP mapping draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt Abstract A bidirectional Pseudowire (PW) service currently uses two unidirectional PWs each carried over a unidirectional LSP. Each end point of a PW or segment of multi-segment PW (MS-PW) independently selects the LSP to use to carry the PW for which it is the head end. Some transport services may require that bidirectional PW traffic follows the same paths through the network in both directions. Therefore, PWs may be required to use LSP with congruent paths. Bidirectional LSPs or co-routed associated unidirectional LSPs allow this service to be provided. This document specifies some extensions to LDP that allow both ends of a PW (or segment of a MS-PW) to select and bind to the same bidirectional LSP or use unidirectional LSPs with congruent paths. 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. Chen, et al. Expires September 14, 2011 [Page 1] Internet-Draft PW to LSP Binding March 2011 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 10, 2011. Copyright Notice Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. PW to LSP Binding TLV ........................................ 4 3. LDP Extensions ............................................... 6 3.1.1. Active/Active Signaling Procedures ................. 6 3.1.2. Active/Passive Signaling Procedures ................ 7 4. Security Considerations ...................................... 8 5. IANA Considerations .......................................... 8 5.1. LDP TLV Types ........................................... 8 5.2. LDP Status Codes......................................... 9 6. Acknowledgments .............................................. 9 7. References ................................................... 9 7.1. Normative References .................................... 9 7.2. Informative References .................................. 9 Authors' Addresses ............................................. 10 Chen, et al. Expires September 14, 2011 [Page 2] Internet-Draft PW to LSP Binding March 2011 1. Introduction Pseudo Wire (PW) Emulation Edge-to-Edge (PWE3) [RFC3985] is a mechanism to emulate a number of layer 2 services, such as Asynchronous Transfer Mode (ATM), Frame Relay or Ethernet. Such services are emulated between two Attachment Circuits (ACs) and the PW encapsulated layer 2 service payload is carried through Packet Switching Network (PSN) tunnels between Provider Edges (PEs). Today PWE3 generally uses two reverse unidirectional Label Distribution Protocol (LDP) [RFC5036] or Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [RFC3209] LSPs as PSN tunnels, and each of the PEs selects and binds PSN tunnel independently. There is no protocol-based provision to explicitly associate a PW with a specific PSN tunnel. For transport applications it has been identified that some transport services may require bidirectional traffic to follow congruent paths. When bidirectional LSPs are used as PSN tunnels, this requirement can be fulfilled if both PEs of a specific/segment PW select and bind to the same bidirectional LSPs. In the case of unidirectional LSPs, LSPs with congruent paths need to be selected to support the PW. However, current mechanisms cannot guarantee appropriate mapping of PWs to underlying LSPs. When there are multiple unidirectional/bidirectional LSPs that may be used to provide different levels of Quality of Service (QOS) or protection between the PEs a selection must be made and some form of control is required to ensure that the correct LSPs are used. +----+ +--+ LSP1 +--+ +----+ +-----+ | PE1|===|P1|======|P2|===| PE2| +-----+ | |----| | +--+ +--+ | |----| | | CE1 | |............PW................| | CE2 | | |----| | +--+ | |----| | +-----+ | |======|P3|==========| | +-----+ +----+ +--+ LSP2 +----+ Figure 1 SS-PW scenario Figure 1 shows an example of inconsistent binding in a Single- Segment PW (SS-PW) scenario. There are two bidirectional LSPs (LSP1 and LSP2, along diverse paths) and a bidirectional PW service between PE1 and PE2. With the current mechanisms, it's possible that PE1 may select LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for the PE1- >PE2 direction of the PW, and PE2 may select LSP2 (PE1-P3-PE2) as the PSN tunnel for the PE2->PE1 direction of the PW, so the bidirectional PW service is bound to two separate bidirectional LSPs. If the service requirement is that the two directions of the PW Chen, et al. Expires September 14, 2011 [Page 3] Internet-Draft PW to LSP Binding March 2011 service are routed in the same way through the network, this outcome will be unacceptable. The problem also exists in Multi-Segment PW (MS-PW) scenarios. One possible way to resolve this issue is to bind the PSN tunnel manually at each PE, but this is prone to configuration errors 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 PW based on [RFC4447]. 2. PW to LSP Binding TLV In this document two new OPTIONAL TLVs are defined: the IPv4/IPv6 PW to LSP Binding TLVs. They are used to communicate the selected LSPs between the two PEs of a PW or segment of MS-PW. When using LDP to signal the PW, the identifiers of the LSP are carried in the Label Mapping message utilizing the new TLVs defined in this document. The format of the PW to LSP Binding LSP TLVs is as follows, the value fields are derived from the definition of [TP-ID]. 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| IPv4 PW to LSP binding TLV| TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | East Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | East Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | East Tunnel Number | East LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | West Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | West Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | West Tunnel Number | West LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure2 IPv4 PW to LSP Binding TLV format Chen, et al. Expires September 14, 2011 [Page 4] Internet-Draft PW to LSP Binding March 2011 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| IPv6 PW to LSP Binding TLV| TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | East Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ East Node ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | East Tunnel Number | East LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | West Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ West Node ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | West Tunnel Number | West LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure3 IPv6 PW to LSP Binding TLV format As defined in [RFC3209] and [RFC3473], an RSVP-TE LSP is identified by the combination of LSP ID, Tunnel ID, Tunnel Extended ID, Tunnel end point address, Tunnel sender address, and a mapping between these fields to the fields of IPv4/v6 PW to LSP Binding TLV is needed. The mapping defined in Section 5.3 of [TP-ID] applies here. In addition, this document allows the Node ID can be either IPv4 or IPv6 address. The IPv6 address based Node ID applies in the scenario where the Tunnel end point address and Tunnel sender address is IPv6 address. For co-routed bidirectional LSP, West Tunnel Number and LSP Number MUST be set to the same as the East Tunnel Number and East LSP Number, respectively. For associated bidirectional LSP, East Tunnel Number and LSP Number MUST be set to the Tunnel ID and LSP ID of the LSP from East to West, respectively; West Tunnel Number and LSP Number MUST be set to the Tunnel ID and LSP ID of LSP from West to East, respectively. For unidirectional LSPs, when the reverse direction tunnel LSP can be determined in advance (e.g., in an active/passive mode, the active end may explicitly specify the reverse tunnel LSP for a PW), West Tunnel Number and LSP Number SHOULD be set to the Tunnel ID and LSP ID of the reverse LSP, respectively. Otherwise, West Tunnel Number and LSP Number MUST be set to zero. Chen, et al. Expires September 14, 2011 [Page 5] Internet-Draft PW to LSP Binding March 2011 3. LDP Extensions Before sending a Label Mapping message to set up a PW or PW Segment, a PE has to select candidate LSPs to act as PSN tunnels. The selected LSPs are carried by the PW to LSP binding TLV and sent with the Label Mapping message to the target/switching PE. Therefore, there may be some collisions of tunnel LSP selection when both PEs assume the active role and independently signal the PW or PW Segment. In order to reduce and resolve the collision of tunnel selection, two types of PEs are identified here: a) Active PE: the PE which initiates the selection of the tunnel LSPs and informs the remote PE; b) Passive PE: the PE which obeys the active PE's suggestion. The role of a PE is based on the role that it takes in the signaling of a specific PW. The active/passive role election is defined in the Section 7.2.1 of [SEG-PW] and applies here, this document does not define any new role election procedures. There exist two situations: Active/Active - Both PEs of a PW or PW Segment assume active roles (e.g., SS-PW, LDP using FEC 128 MS-PW). Active/Passive - One PE is Active and the other is passive (e.g., LDP using FEC 129 MS-PW). 3.1.1. Active/Active Signaling Procedures In a bidirectional LSP scenario, both PEs (say PE1 and PE2) send a Label Mapping message carrying their own selected bidirectional LSP to each other. If the bidirectional LSP in the received message from other PE is as same as it was in the Label Mapping message sent by itself, then the PW signaling has converged on an mutually agreed tunnel LSP and selection is completed. Otherwise, when the bidirectional LSP selected by one PE (say PE1) differs from the bidirectional LSP selected by the other PE (say PE2), PE1 and PE2 have to make a choice between two tunnel LSPs. In this case PE1 and PE2 can compare the Node ID, and the LSP selected by the node with numerically higher ID will be determined to carry the PW. In case of unidirectional LSPs, each PE may select a unidirectional tunnel LSP that is used for its own forward direction of the PW and send it with the Label Mapping message to the other PE. It is possible that the two LSPs are not congruent. The mechanisms to determine which LSPs are congruent are out of scope, but it is Chen, et al. Expires September 14, 2011 [Page 6] Internet-Draft PW to LSP Binding March 2011 assumed that each PE is able to look at the paths of LSPs (from information supplied to or by the control plane, or from information supplied by the management plane). In addition, each PE may explicitly specify both the forward and reverse direction tunnel LSPs of the PW and send them with the Label Mapping message to each other. If the two PEs of the PW have the same tunnel selection (e.g., for a specific PW, the forward direction tunnel LSP selected by one PE is the same as the reverse direction tunnel LSP selected by the other PE, and vice versa), then the PW signaling is completed and has converged on an mutually agreed tunnel LSPs. Otherwise, when the tunnel LSPs selected by one PE differ from the tunnel LSPs selected by the other PE, the LSPs selected by the node with numerically higher Node ID will be determined as the tunnel. In case of one PE selects a pair of unidirectional LSPs and the other PE selects a bidirectional LSP, the LSPs selected by the node with numerically higher Node ID will be determined as the tunnel. 3.1.2. Active/Passive Signaling Procedures 3.1.2.1. Active PE Signaling Procedure Before sending the Label Mapping message, the active PE, say PE1, MUST select the tunnel LSPs for the PW or Segment PW. Then PE1 generates a PW to LSP Binding TLV that identifies the selected LSP and sends the Label Mapping message containing it to the passive PE, in this case PE2. In case of bidirectional LSPs, if PE1 receives a Label Mapping message in which the bidirectional LSP is the same as the bidirectional LSP it selected then both directions of the PW or Segment PW are setup. In case of unidirectional LSPs, if PE1 specifies both the forward and reverse direction tunnel LSPs in a previous Label Mapping message sent by itself, when PE1 receives a Label Mapping message in which the reverse tunnel LSP is the same as the forward tunnel LSP and the forward tunnel LSP is the same as the reverse tunnel LSP it selected, then both directions of the PW or segment PW are setup. According to the passive PE procedures described in Section 3.1.2.2, the identified LSPs SHOULD match. If they do not, the active PE MUST assume that the peer PE is also in active role, and MUST apply the procedures described in Section 3.1.1. Chen, et al. Expires September 14, 2011 [Page 7] Internet-Draft PW to LSP Binding March 2011 3.1.2.2. Passive PE Signaling Procedure When a Label Mapping message carrying a PW to LSP Binding TLV is received by the passive PE (say PE2) it may decide, based on local policy and/or success or failure in matching the LSP to accept or reject it. If the suggested tunnel LSPs cannot be matched successfully or if local policy prohibits its acceptance, a Label Release message MUST be sent, with a "No matched tunnel LSPs" code, and the processing of the Label Mapping message is complete. If the tunnel LSPs proposed by PE1 are accepted by PE2 then PE2 attempts setup of the PW in the opposite (PE2->PE1) direction, it sends a Label Mapping message to PE1, with a PW to LSP Binding TLV that identifies the tunnel LSPs, proposed by PE1, that it has accepted for this PW. That is, for bidirectional LSPs, the PW to LSP Binding TLV SHOULD identify the same bidirectional LSP proposed by PE1. In case of unidirectional LSPs, if the received PW to LSP Binding TLV including both forward and reverse direction tunnel LSPs, the East Tunnel Number and LSP Number of the PW to LSP Binding LSP SHOULD be exchanged for each other. Accordingly, the East/West Node ID/Global ID of the PW to LSP Binding TLV SHOULD be exchanged as well. 4. Security Considerations The ability to control which LSPs are used to carry a PW is a potential security risk both for denial of service and for interception of traffic. It is RECOMMENDED that PEs do not accept the use of LSPs identified in the LSP Binding TLV unless the LSP end points match the PW or PW segment end points. Furthermore, where security of the network is believed to be at risk, it is RECOMMENDED that PEs implement the LDP security mechanisms described in [RFC5036] and [RFC5920]. 5. IANA Considerations 5.1. LDP TLV Types This document defines two new TLVs [Section 2 of this document] for inclusion in LDP Label Mapping message. IANA is required to assigned TLV type values to the new defined TLVs from LDP "TLV Type Name Space" registry. IPv4 PW to LSP Binding TLV - 0x0971 (to be confirmed by IANA) Chen, et al. Expires September 14, 2011 [Page 8] Internet-Draft PW to LSP Binding March 2011 IPv6 PW to LSP Binding TLV - 0x0972 (to be confirmed by IANA) 5.2. LDP Status Codes This document defines a new LDP status codes, IANA is required to assigned status codes to these new defined codes from LDP "STATUS CODE NAME SPACE" registry. "No matched tunnel LSPs" - 0x0000003B (to be confirmed by IANA) 6. Acknowledgments The authors would like to thank Adrian Farrel, 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. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [TP-ID] Bocci, M., Swallow G., "MPLS-TP Identifiers", "draft-ietf- mpls-tp-identifiers-04", work in progress. 7.2. Informative References [SEG-PW] Luca Martini, et al., "Segmented Pseudowire", "draft-ietf- pwe3-segmented-pw-15.txt", work in progress. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling", RFC 3473, January 2003. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. Chen, et al. Expires September 14, 2011 [Page 9] Internet-Draft PW to LSP Binding March 2011 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co., Ltd. No. 3 Xinxi Road Shangdi Information Industry Base Hai-Dian District, Beijing 100085 China EMail: mach.chen@huawei.com Wei Cao Huawei Technologies Co., Ltd. No. 3 Xinxi Road Shangdi Information Industry Base Hai-Dian District, Beijing 100085 China EMail: wayne.caowei@huawei.com Attila Takacs Ericsson Laborc u. 1. Budapest, 1037 Hungary EMail: attila.takacs@ericsson.com Chen, et al. Expires September 14, 2011 [Page 10]