Network working group W. Cao Internet Draft M. Chen Category: Standards Track Huawei Technologies Co.,Ltd Created: July 5, 2010 A. Takacs Expires: January 2011 Ericsson LDP extensions for Explicit Pseudowire to transport LSP mapping draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-00.txt Abstract Currently a Pseudowire (PW) uses two reverse unidirectional LSPs as Packet Switching Network (PSN) tunnels, and each PE of a PW or segment of MS-PW selects PSN tunnels independently. In contrast MPLS-TP requires support for both bidirectional and unidirectional LSPs. In addition some transport services may require bidirectional traffic follows with congruent paths. Therefore, PWs may be required to use PSN tunnels with congruent paths. This document specifies some extensions to LDP that ensures both ends of a PW (or segment PW) 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 20, 2010. Chen, et al. Expires January 5, 2011 [Page 1] Internet-Draft PW to LSP Binding July 2010 Copyright Notice 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. 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 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.................................................2 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 1. Introduction Pseudo Wire (PW) Emulation Edge-to-Edge (PWE3) is a mechanism to emulate a number of layer 2 services, such as Asynchronous Transfer Mode (ATM), Frame Relay or Ethernet, etc. Such services are emulated between two Attachment Circuits (ACs) and the PW encapsulated layer 2 service payload is carried through Packet Switching Network (PSN) Chen, et al. Expires January 5, 2011 [Page 2] Internet-Draft PW to LSP Binding July 2010 tunnels between Provider Edges (PEs). Today PWE3 generally uses two reverse unidirectional Label Distribution Protocol (LDP) or Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) LSPs as PSN tunnels, and each of the PEs selects and binds PSN tunnel independently. Today there is no architectural provision as there has been no requirement to explicitly associate a PW with a 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 LSP(s). 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 underling LSPs. This is especially true 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. +----+ +--+ LSP1 +--+ +----+ +-----+ | PE1|===|P1|======|P2|===| PE2| +-----+ | |----| | +--+ +--+ | |----| | | CE1 | |............PW1...............| | CE2 | | |----| | +--+ | |----| | +-----+ | |======|P3|==========| | +-----+ +----+ +--+ LSP2 +----+ Figure 1 SS-PW scenario Above figure (Figure 1) is an example of this inconsistent binding in Single-Segment PW (SS-PW) scenario. There are two bidirectional LSPs (LSP1 and LSP2, along diverse paths) and a PW (PW1) 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 direction of PE1->PE2 of PW1, and PE2 may select LSP2 (PE1-P3-PE2) as the PSN tunnel for the direction of PE2->PE1 of PW1, so a PW is bound to two separate bidirectional LSPs, this may not be desired in MPLS-TP network. It still has the same problems in Multi-Segment PW (MS-PW) scenario. One possible method is binding 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]. Chen, et al. Expires January 5, 2011 [Page 3] Internet-Draft PW to LSP Binding July 2010 2. PW to LSP Binding TLV In this document two new OPTIONAL TLVs are defined: IPv4/IPv6 PW to LSP Binding TLV. 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. And the PW to LSP Binding TLV MAY be carried in an in-band MPLS-TP OAM message that is identified by a new dedicated GACh channel type when LDP is not used. This is for future study. The proposed format of the PW to LSP Binding LSP TLVs is as follows, the value fields are derived from the definition of [I-D.ietf-mpls- tp-identifiers]. (Editor notes: In I-D.ietf-mpls-tp-identifiers, a LSP is identified by the combination of Src-Global_ID, Src-Node_ID, Src-Tunnel_Num, Dst-Global_ID, Dst-Node_ID, Dst-Tunnel_Num, LSP_Num, this is fine for unidirectional and co-routed bidirectional LSP, but it is not enough for associated bidirectional LSP that is combined with two reverse unidirectional LSPs and hence two LSP_Nums are required.) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Tunnel Number | Source LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Tunnel Number | Destination LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure2 IPv4 PW to LSP Binding TLV format Chen, et al. Expires January 5, 2011 [Page 4] Internet-Draft PW to LSP Binding July 2010 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Node ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Tunnel Number | Source LSP Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Destination Node ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Tunnel Number | Destination 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 [I-D.ietf-mpls-tp- identifiers] applies here. In addition, for co-routed bidirectional LSP, since the Source and Destination Tunnel/LSP ID is the same, Destination Tunnel Number and Destination LSP Number MUST be set to the same as the Source Tunnel Number and Source LSP Number, respectively. For associated bidirectional LSP, Destination Tunnel Number and Destination LSP Number MUST be set to the Tunnel ID and LSP ID of the reverse direction component LSP of the associated bidirectional LSP, respectively. For unidirectional LSPs, when the reverse direction tunnel LSP is determined in advance (e.g., in an active/passive mode, the active end may explicitly specify the reverse tunnel LSP for a PW), Destination Tunnel Number and Destination LSP Number SHOULD be set to the Tunnel ID and LSP ID of the reverse LSP, respectively. If the reverse direction tunnel LSP can not be determined in advance, Chen, et al. Expires January 5, 2011 [Page 5] Internet-Draft PW to LSP Binding July 2010 Destination Tunnel Number and Destination LSP Number MUST be set to zero. (Editor notes: In I-D.ietf-mpls-tp-identifiers, the Source/Destination Node is defined as a 32-bits ID, but for a MPLS/GMPLS TE based LSP, the Tunnel Extended ID, Tunnel end point address and Tunnel sender address may be IPv6 addresses, so the current Source/Destination Node ID does not cover this and can not map to IPv6 based Tunnel Extended ID, Tunnel end point address and Tunnel sender address.) 3. LDP Extensions Before sending a Label Mapping message to setup a PW or Segment PW, a PE has to select candidate LSPs for PSN tunnel. The selected LSPs are carried by the PW to LSP binding TLV and then sent with the Label Mapping message to the target/switching PE. Therefore, there may be some collisions of tunnel LSP selection when both PEs of the PW or Segment PW assume active role and independently signal the PW or Segment PW. 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 acts in the signaling of the PW. There exist two situations: Active/Active - Both PEs of a PW or Segment PW assume active (e.g., SS-PW, LDP using FEC 128 MS-PW). Active/Passive - One PE is Active and the others are passive (e.g., LDP using FEC 129 MS-PW). 3.1.1. Active/Active Signaling Procedures In 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 is completed. Otherwise, when the bidirectional LSP selected by one PE (say PE1) differ from the bidirectional LSP selected by the other PE (say PE2), PE1 and PE2 have to make a Chen, et al. Expires January 5, 2011 [Page 6] Internet-Draft PW to LSP Binding July 2010 choice between two tunnel LSPs. In this case PE1 and PE2 can compare the Node ID and the LSP selected by the node with higher ID will be determined to carry the PW. In case of unidirectional LSPs, each PE may select an unidirectional tunnel LSP that is used for its own forward direction of the PW and send it with the Label Mapping message to each other, hence to help the PEs to select two congruent unidirectional LSPs. The mechanisms to determine which LSPs are used are out of scope. 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 higher Node ID will be determined as the tunnel. 3.1.2. Active/Passive Signaling Procedures 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. 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. Chen, et al. Expires January 5, 2011 [Page 7] Internet-Draft PW to LSP Binding July 2010 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 Source Tunnel Number and LSP Number of the PW to LSP Binding LSP SHOULD be exchanged for each other. Accordingly, the Source/Destination Node ID/Global ID of the PW to LSP Binding TLV SHOULD be exchanged as well. 4. Security Considerations The draft does not introduce any new security issues. 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 - TBD IPv6 PW to LSP Binding TLV - TBD Chen, et al. Expires January 5, 2011 [Page 8] Internet-Draft PW to LSP Binding July 2010 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" - TBD 6. Acknowledgments The authors would like to thank 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. 7.2. Informative References [SEG-PW] Luca Martini, et al., "Segmented Pseudowire", "draft-ietf- pwe3-segmented-pw-15.txt", work in progress. [TP-CP-FWK] Loa Andersson, Lou Berger, Luyuan Fang, Nabil Bitar, "MPLS-TP Control Plane Framework", "draft-ietf-ccamp-mpls- tp-cp-framework", work in progess. [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. [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", "draft-ietf-mpls-tp-identifiers-01", work in progress. Chen, et al. Expires January 5, 2011 [Page 9] Internet-Draft PW to LSP Binding 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@huawei.com Wei Cao Huawei Technologies Co., Ltd. No. 3 Xinxi Road Shangdi Information Industry Base Hai-Dian District, Beijing 100085 China EMail: caoweigne@huawei.com Attila Takacs Ericsson Laborc u. 1. Budapest, 1037 Hungary EMail: attila.takacs@ericsson.com Chen, et al. Expires January 5, 2011 [Page 10]