Network Working Group F. Jounay (Editor) Internet Draft P. Niger Category: Standards Track France Telecom Expires: January 2010 Y. Kamite L. Jin NTT Communications Nokia Siemens S. Delord L. Ciavaglia Telstra M. Vigoureux Alcatel-Lucent July 13, 2009 LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03.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 January 13, 2010. Abstract This document provides a solution to extend Label Distribution Protocol (LDP) signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the source-initiated P2MP PW setup and maintenance. Jounay et al. Expires January, 2010 [Page 1] Internet Draft Source-initiated P2MP PW Setup July 2009 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 [RFC2119]. Table of Contents 1. Terminology.....................................................3 2. Introduction....................................................3 3. P2MP SS-PW Setup Mechanism......................................3 3.1. P2MP SS-PW Reference Model....................................3 3.2. Overview of the P2MP SS-PW Setup..............................4 3.3. LDP...........................................................5 3.4. P2MP Generalized ID FEC Element...............................5 3.4.1. P2MP GID FEC Element........................................5 3.4.2. TAII Leaf TLV...............................................8 3.5. Signaling for P2MP SS-PW.....................................10 3.5.1. Configuration/Provisioning.................................10 3.5.2. Capability Negotiation Procedure...........................10 3.5.3. Signaling Process..........................................11 3.5.4. Leaf Attachment Notification Message.......................11 3.5.5. PW Type Mismatch...........................................12 3.5.6. Interface Parameters.......................................13 3.5.7. Interface ID (Underlying P2MP PSN tunnel)..................13 3.5.8. Leaf Grafting/Pruning......................................15 4. Security Considerations........................................15 5. IANA Considerations............................................15 5.1. LDP FEC Type.................................................15 5.2. LDP TLV Type.................................................15 5.3. LDP Status Codes.............................................16 6. Acknowledgments................................................16 7. References.....................................................16 7.1. Normative References.........................................16 7.2. Informative References.......................................17 Authors' Addresses................................................ 18 Copyright and Licence Notice...................................... 19 Jounay et al. Expires January 13, 2010 [Page 2] Internet Draft Source-initiated P2MP PW Setup July 2009 1. Terminology This document uses acronyms and terminologies defined in [RFC5036], [RFC3985], [P2MP PW REQ] and [RFC5254]. 2. Introduction [RFC4447] describes a mechanism for establishing Point-to-Point Single-Segment Pseudowire (P2P SS-PW). These specifications do not provide a solution for setting up a point-to-multipoint Pseudowire (P2MP PW). This document defines extensions to the LDP protocol [RFC5036], [RFC4447], to support P2MP PW satisfying the set of requirements described in [P2MP PW REQ]. The document presents a solution to setup a P2MP SS-PW. The solution relies on the definition of a P2MP GID FEC element derived from the FEC129 used for the single-side provisioning of a P2P PW setup [RFC4447]. The P2MP MS-PW is outside the scope of this document. 3. P2MP SS-PW Setup Mechanism 3.1. P2MP SS-PW Reference Model A unidirectional P2MP SS-PW provides a Point-to-Multipoint connectivity from an Ingress PE connected to a traffic source to one or more Egress PEs connected to traffic receivers. The PW endpoints connect the PW to its attachment circuits (AC). As for a P2P PW [RFC3985], an AC can be a Frame Relay DLCI, an ATM VPI/VC, an Ethernet port, a VLAN, a HDLC link on a physical interface. Note that the use of P2MP PW is only relevant for multicast native protocol. Figure 1 describes the P2MP SS-PW reference model which is extracted from [P2MP PW REQ] to support P2MP emulated services. Jounay et al. Expires January 13, 2010 [Page 3] Internet Draft Source-initiated P2MP PW Setup July 2009 |<-----------P2MP SS-PW------------>| Native | | Native Service | |<----P2MP PSN tunnel --->| | Service (AC) V V V V (AC) | +----+ +-----+ +----+ | | |PE1 | | P |=========|PE2 |AC3 | +----+ | | | | ......PW1.......>|---------->|CE3 | | | | | . |=========| | | +----+ | | | | . | +----+ | | | |=========| . | | | | | | . | +----+ | +----+ | AC1 | | | . |=========|PE3 |AC4 | +----+ |CE1 |-------->|........PW1.............PW1.......>|---------->|CE4 | +----+ | | | | . |=========| | | +----+ | | | | . | +----+ | +----+ |AC2 | |=========| . | | | CE2|<--------| | | . | +----+AC5 | +----+ +----+ | | | | . |=========|PE4 |---------->|CE5 | | | | | ......PW1.......>| | +----+ | | | | |=========| |AC6 | +----+ | | | | | | |---------->| CE6| | +----+ +-----+ +----+ | +----+ Figure 1 P2MP SS-PW Reference Model This architecture applies to the case where a P2MP PSN tunnel extends among edge nodes of a single PSN domain to transport a unidirectional P2MP PW with endpoints at these edge nodes. In this model a single copy of each PW packet is sent over the P2MP PSN tunnel and is received by all Egress PEs due to the P2MP nature of the PSN tunnel. The Ingress PE supports traffic replication over its directly connected ACs toward receiver CEs if necessary, in addition to PSN transport. The Egress PE supports traffic replication over its directly connected ACs toward receiver CEs if necessary. 3.2. Overview of the P2MP SS-PW Setup [RFC4447] defines the LDP signaling for establishing a P2P PW. When a PW is set up, the LDP signaling messages include a forwarding equivalence class (FEC) element containing information about the PW type and an endpoint identifier used by the Ingress and Egress PEs for the selection of the PW forwarder that binds the PW to the attachment circuit at each end. There are two types of FEC elements in [RFC4447] defined for this purpose: PWid FEC (type 128) and the Generalized ID (GID) FEC (type 129). The FEC128 and the FEC129 are used respectively for the double- side provisioning or the single-side provisioning of a P2P PW setup This document defines a P2MP GID FEC element derived from the FEC129 to setup a P2MP SS-PW. Jounay et al. Expires January 13, 2010 [Page 4] Internet Draft Source-initiated P2MP PW Setup July 2009 The Ingress PE maintains one signaling LDP session with every Egress PE. Since the P2MP PW is unidirectional and to avoid replication, the Upstream Label Assignment [LDP UPSTREAM], [RFC5331] MUST be used for the PW label assignment. The Ingress PE initiates the LDP Label Mapping message to announce the PW label used to convey the traffic to the Egress PEs. As represented in Figure 1 the unidirectional P2MP SS-PW traffic transmission and replication relies on the usage of P2MP LSP (s) as PSN tunnel(s) underlying layer, established between the Ingress PE and all Egress PEs. 3.3. LDP The PW label bindings are distributed using the LDP upstream unsolicited label distribution, liberal label retention mode described in [LDP UPSTREAM], [RFC5331] and [RFC5036]. The Ingress PEs will establish LDP session using the Extended Discovery mechanism described in [RFC5036] with each Egress PEs. For setting up and maintaining pseudowires, each FEC TLV MUST contain exactly one FEC element. Note that the Ingress PE does not need to receive a Label Request from the Egress PE to send the Upstream Label Mapping message. In this specification, a FEC Element TLVs is defined to be used for identifying point-to-multipoint pseudowires. 3.4. P2MP Generalized ID FEC Element The P2MP GID FEC element is derived from the GID FEC (FEC129) element defined in [RFC4447].Based on the PW AII address type, the GID FEC used for P2P PW setup is extended to propose: - a P2MP GID (Generalized ID) FEC element containing a VPN identifier, a P2MP identifier and a P2MP PW source address (SAII) - a TAII Leaf TLV containing the list of the PW addresses (TAII) at the leaves AIIs to be attached to the PW tree. 3.4.1. P2MP GID FEC Element The P2MP GID FEC Element format is derived as below. Jounay et al. Expires January 13, 2010 [Page 5] Internet Draft Source-initiated P2MP PW Setup July 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP GID(0x82)|C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP Id | Length | P2MP Id Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ P2MP Id Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When a Notification message have to be exchanged between peer PEs (see below for a detailed description of procedures), the P2MP GID FEC MUST be included in the LDP Notification message to identify the PW tree to which it applies. The AGI (Attachment Group Identifier) is VPN-id. The same AGI value MUST be configured at all endpoints of the PW tree (Ingress and Egress PEs). Note that the AGI SHOULD be used to identify the VPMS instance as outlined in [VPMS REQ]. The AGI is a four-octet number and is unique within the scope of the PE. The SAII (Source Attachment Individual Identifier) is attached to the Ingress PE and identifies the PW tree source. In other words the PW tree is rooted with one Attachment Circuit (AC) at the ingress PE. The attachment circuit address type is derived from [RFC5003] AII type 2 shown here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jounay et al. Expires January 13, 2010 [Page 6] Internet Draft Source-initiated P2MP PW Setup July 2009 In P2MP GID FEC element, the TAII field structure that was defined in Section 5.3.2 of [RFC4447] is replaced with a P2MP Identifier (P2MP Id). The PW tree is identified by means of the pair (SAI, P2MP Identifier). The P2MP Id is a four-octet number. The P2MP identifier is required in particular for some P2MP make- before-break function. Egress PEs may be protected via a P2MP PW redundancy mechanism. In that case a backup P2MP PW over P2MP LSP1 will be used to protect the primary P2MP PW over P2MP LSP2. In the example depicted below, a backup P2MP PW (AGI1, SAII, P2MP2) is used to protect the primary P2MP (AGI1, SAII, P2MP1). CE1 |(SAII) P2MP PW1 PE P2MP PW2 (SAII, P2MP1).../ \...._(SAII, P2MP2) / \ P2 P3 / \ / \ / \ / \ / \ / \ PE4 PE5 PE6 PE7 AII1 AII2 AII3 AII4 | \ / | \ CE2 / \ / -------CE3------ A mechanism should be implemented to avoid race conditions between recovery at the PSN level and recovery at the PW level. In some cases an operator may offer a VPMS delivering multicast content to several customers (wholesale). In such a case P2MP Id allows to assign one P2MP PW per wholesale customer (or other service entity) while considering a single VPMS (AGI1). In that scenario the operator provides a single VPMS for the service delivery but makes a customer differentiation thanks to the P2MP ID. The P2MP Id allows the operator to consider two different P2MP PW to guarantee a specific SLA per customer. The specific SLA MAY rely on a different QoS marking or the use of a different P2MP PSN tunnel (TE and not TE LSP). In the Figure below, PE4 and PE5 are Egress PEs connected to wholesale customer A, PE6 and PE7 Egress PEs to wholesale customer B. Wholesale customers A and B receive the same traffic from different P2MP PW since the traffic is received for both P2MP PWs from the same SAII. Jounay et al. Expires January 13, 2010 [Page 7] Internet Draft Source-initiated P2MP PW Setup July 2009 |(SAII) P2MP PW1 PE P2MP PW2 (AGI1, SAII, P2MP1) .../ \.... (AGI1, SAII, P2MP2) / \ P2 P3 / \ / \ / \ / \ / \ / \ PE4 PE5 PE6 PE7 |(TAII)| |(TAII)| wholesale wholesale customer A customer B All remaining fields are unchanged compared to their definition in [RFC4447], including the Control Word (C bit). 3.4.2. TAII Leaf TLV A TAII Leaf TLV is defined in order to carry the information regarding the P2MP PW addresses at the Egress PE(s) to be connected to the PW tree. The AII type 2 format defined in [RFC5003] and reminded in section 3.4.1 is also used as the address type of the TAII Leaf TLV. The TAII Leaf TLV has the following 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| TAII Leaf Type (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ------------------- ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jounay et al. Expires January 13, 2010 [Page 8] Internet Draft Source-initiated P2MP PW Setup July 2009 + U-bit Unknown TLV bit U is clear (=0), upon receipt of an unknown TLV, a notification with status code "unknown TLV" MUST be returned to the message originator and the entire message MUST be ignored + F-bit Forward unknown TLV bit F is clear (=0), the unknown TLV is not forwarded with the containing message; The TAII has the same structure than in the FEC 129 defined in [RFC4447]. The TAII Leaf TLV comprises a list of one or more TAII Leaf identifiers. The TAII Leaf TLV MUST be included in the Label Mapping message initiated by the Ingress PE. The TAII Leaf TLV is carried as follows in the Label Mapping message: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + P2MP Generalized ID FEC + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Generic Label (0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Assigned Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| TAII Leaf Type (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Interface ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that in the SS-PW topology, the Ingress PE MUST maintain one signaling session with each Egress PE. The TAII Leaf TLV for a given signaling session conveys the TAII leaves related to the corresponding Egress PE. For instance if the Egress PE supports only one AII associated to the PW tree, the TAII Leaf TLV will include only one TAII. Jounay et al. Expires January 13, 2010 [Page 9] Internet Draft Source-initiated P2MP PW Setup July 2009 3.5. Signaling for P2MP SS-PW 3.5.1. Configuration/Provisioning Referring to Figure 1, if the P2MP GID FEC is used the Ingress PE (PE1) MUST be configured with the AGI, SAII and P2MP Id. SAII is considered as the Source Attachment Identifier of the PW tree. Each Egress PE MUST be configured with one or more leaf-TAIIs corresponding to one or more leaves of the PW tree. The AGI and P2MP Id MUST be the same for all endpoints of the PW tree. Once the ACs are configured at all endpoints, the provisioning next step for the PW tree establishment consists in specifying at the Ingress PE all the leaf-TAIIs identifying the leaves of the PW tree at the Egress PE(s). The IP address of the Egress PEs where the Attachment Circuits are connected MUST be configured manually or learnt dynamically by means of auto discovery protocol at Ingress PE. Detailed mechanism of such auto-discovery protocol is out of scope of this document. 3.5.2. Capability Negotiation Procedure To achieve the capability negotiation the solution MUST follow the LDP capability advertisement mechanism described in [LDP CAPA]. The PEs belonging to the PW tree MUST support the P2MP GID FEC element. Procedures defined in [RFC5036] must apply in case of FEC element mismatch. The unidirectional P2MP SS-PW is supported over a P2MP LSP(s), so Upstream Label Assignment as defined in [LDP UPSTREAM], [RFC5331] MUST be used to prevent replication at the PW level. Upstream- assigned label bindings MUST NOT be used unless it is known that the Egress PEs support them. This guarantees not to waste the network bandwidth. Egress PE which supports upstream label assignment can advertise its capability by inserting an Upstream Label Assignment Capability sub-TLV in the LDP Capability TLV, as defined in [LDP UPSTREAM]. The Ingress PE SHOULD NOT initiate the P2MP PW setup unless it is known that the Egress PEs support the PW Status TLV [RFC4447]. An Egress PE which supports the PW Status TLV can advertise its capability by inserting an PW Status Capability sub-TLV in the LDP Capability TLV. This negotiation is a key element in the procedure since it can allow the Ingress PE to adjust P2MP PSN tunnel (P2MP TE- LSP) topology upon receipt of Leaf Attachment Notification at the PW layer from Egress PEs. The PW status is also required to allow the Egress/Ingress PEs to announce some status information later on to the Ingress/Egress PE. Jounay et al. Expires January 13, 2010 [Page 10] Internet Draft Source-initiated P2MP PW Setup July 2009 For an Egress PE which does not support the PW Status TLV, some communication mechanism SHOULD allow the Ingress PE to adjust the P2MP PSN tunnel topology. Definition of such communication mechanisms are outside the scope of this document but a potential candidate could be G-ACH adapted for P2MP topology. Upon detection of a failure of the Egress PE, the Ingress PE could adjust the P2MP PSN tunnel topology. Following is the format of the PW Status Capability Parameter: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status Cap (IANA) | Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved | +-+-+-+-+-+-+-+-+ If a PE includes the PW Status Capability in LDP Initialization Messages it implies that the PE is capable of both distributing and receiving Status Messages. The reserved bits MUST be set to zero on transmission and ignored on receipt. The PW Status Capability Parameter can be exchanged only in LDP initialization messages. 3.5.3. Signaling Process After the Ingress PE is manually configured or discovers dynamically by means of an auto-discovery protocol its peer PEs, it initiates a signaling with every Egress PE. i. A Label Mapping message is sent to every Egress PE containing the SAII configured as the source at the Ingress PE. The TAII Leaf TLV includes one or more AII associated to the Attachment Circuits of the Egress PE(s) defined as leaves of the PW tree. 3.5.4. Leaf Attachment Notification Message The Ingress PE requires the successful leaf information to choose a suitable existing MLDP P2MP LSP or RSVP-TE P2MP LSP for multiplexing. When the Egress PE receives and processes the Label Mapping message, it verifies the P2MP GID/ (optionally leaf-TAIIs), and checks if it matches one of its configured Forwarders. Jounay et al. Expires January 13, 2010 [Page 11] Internet Draft Source-initiated P2MP PW Setup July 2009 i. The (AGI, P2MP Id) fields from the P2MP GID FEC Element in the Label Mapping message MUST be the same as the ones configured on the Egress PE. If not, the Label Mapping is retained according to LDP liberal label retention procedure. In the case the matching is correct the following procedure MUST be followed: ii. If at least one matching is found among the TAII Leaves, the Egress PE carries on the process by responding with a PW Status Notification message "success PW attachment" to the Ingress PE in order to inform it about its tree attachment. The PW status TLV informs the Ingress PE that the Egress PE and some associated leaf(ves) is from now on part of the PW tree. For that purpose the TAII Leaf TLV is attached to the LDP Notification message. The TAII Leaf TLV contains the TAII leaves successfully connected to the PW tree. Therefore the Ingress and the Egress PEs update their PW-to-label bindings. Thanks to the TAII Leaf TLV the Ingress PE can deduce which TAII are connected and which are not. iii. When no TAII leaf matches with one of the leaf-TAIIs configured at the Egress PE, the following procedure MUST be applied: . If the leaf-TAII received by the PE contains the prefix of a locally provisioned prefix on that PE, but an AC ID that is not provisioned, then the LDP liberal label retention procedures apply, and the Label Mapping message is retained. The Ingress PE will update its PW- to-label bindings upon receipt of a LDP Notification message later on. . If no matching (including the global-ID and prefix) is found among the TAII Leaves, a LDP Notification MUST be returned to the PE with a status message of Unassigned/Unrecognized TAII. 3.5.5. PW Type Mismatch As for P2P PW, the ACs configured at Ingress PE and Egress PEs of a P2MP PW MUST be of the same PW type [RFC4446]. In case of a different type, the Egress PE MUST abort processing the message, and MUST send a PW Status message of 0x00000001 - Pseudowire Not Forwarding to its LDP peer signaling an error. Jounay et al. Expires January 13, 2010 [Page 12] Internet Draft Source-initiated P2MP PW Setup July 2009 3.5.6. Interface Parameters Some interface parameters [RFC4446] related to the AC capability have been defined according to the PW type and are signaled during the PW setup from the Egress PE to the Ingress PE. Note that the Interface Parameters are carried in a separate TLV in the LDP Label Mapping message as outlined in [RFC4447] section 5.5. When applicable, this mechanism MUST be used to to ascertain that AC at the Egress PE is capable to support traffic coming from AC at the Ingress PE. When the interface parameters are signalled by the Ingress PE, the Egress PE must check if its configured value(s) is inferior or equal to the threshold value fixed by the Ingress PE (e.g. MTU size (Ethernet), number max of concatenated ATM cells, etc)). For other interface parameters like CEP/TDM Payload bytes (TDM), the value MUST match exactly at the Ingress and at the Egress PEs. If the value configured at the Egress PE is not appropriate to receive the traffic, the Egress PE MUST send a PW Status message of 0x00000001 - Pseudowire Not Forwarding to its LDP peer signaling an error. 3.5.7. Interface ID (Underlying P2MP PSN tunnel) The P2MP SS-PW implies a P2MP underlying tunnel(s) as outlined in [P2MP PW ENCAPS]. Figure 2 extracted from [P2MP PW REQ] gives an example of P2MP SS-PW topology relying on a P2MP LSP. The PW tree is composed of one Ingress PE (i1) and several Egress PEs (e1, e2, e3, e4). The P2MP PSN tunnel MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP [MLDP]. i1 / / \ / \ / \ /\ \ / \ \ / \ \ / \ / \ e1 e2 e3 e4 Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW When the Egress PE updates its PW-to-label bindings table, it MUST verify that an underlying layer (P2MP PSN tunnel) is setup to receive traffic coming from the Ingress PE. Jounay et al. Expires January 13, 2010 [Page 13] Internet Draft Source-initiated P2MP PW Setup July 2009 For that purpose the LDP Label mapping initiated by the Ingress PE MUST provide the Interface ID TLV as defined in [LDP UPSTREAM] and [RFC3472]. The Interface ID TLV is used by the egress PE(s) to determine which PSN Tunnel (MLDP or RSVP-TE P2MP LSP) the P2MP PW is associated to [RFC5331]. In other words the Interface ID contains information about the label space used at the Egress PE to perform the inner (PW) label lookup. If the Interface ID is not indicated in the LDP Label Mapping, the P2MP PW can not be setup. The Interface ID TLV for RSVP-TE P2MP LSP is defined in [LDP UPSTREAM]. 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE P2MP Session Object and the P2MP Sender Template Object [RFC4875]. Both objects are required at the Egress PE to identify the RSVP-TE P2MP LSP. Note that PHP must be disabled on the underlying P2MP PSN tunnel so as to allow an Egress PE to know on which PSN tunnel a packet is received. The P2MP PSN tunnel associated to the P2MP PW can be selected either by user configuration or by dynamically using the multiplexing/demultiplexing mechanism. The P2MP PW multiplexing will be based on the overlap rate between P2MP LSP and P2MP PW. The users should determine whether the P2MP PW can accept partially multiplexing with P2MP LSP, and a minimum congruency rate may be defined. The congruency rate reflects the amount of overlap in the Egress PE of P2MP PW that is multiplexed to a P2MP LSP. If there is a complete overlap, the congruency is perfect and the rate is 100%. The Ingress PE can determine whether P2MP PW can multiplex to a P2MP LSP according to the congruency rate. It is also possible to extend P2MP LSP to do P2MP PW multiplexing, but this will reduce the current congruency rate that the P2MP PW is currently taken. The multiplexing should ensure that the P2MP PW congruency that is currently taken under P2MP LSP should be larger than minimum congruency that is configured. With this procedure a P2MP PW is nested within a P2MP PSN tunnel. This allows multiplexing several PWs over a common P2MP PSN tunnel. Prior to the P2MP PW signaling phase, the Ingress PE MUST determine which PSN tunnel will be used for this P2MP PW. The PSN Tunnel can be an existing PSN tunnel or the Ingress PE can create an new P2MP PSN tunnel. . If the P2MP LSP is based on RSVP-TE, since the Ingress PE knows the Egress PEs, if the P2MP LSP is not yet setup, it MAY setup the P2MP LSP at the same time as the PW tree setup, or after receiving the PW status TLVs from the Egress PEs which informs the Ingress PE of their attachment to the tree. Jounay et al. Expires January 13, 2010 [Page 14] Internet Draft Source-initiated P2MP PW Setup July 2009 Note that in the latter case the LDP Label Mapping MUST convey the Interface ID even though the P2MP LSP has not been yet established. . If the P2MP LSP is based on [MLDP], the P2MP LSP may be setup once the Egress PE retrieves the P2MP LDP FEC from the Interface ID TLV. It may also be setup before. This P2MP FEC is used by the Egress PE to associate the corresponding P2MP LSP with P2MP PW. How to do P2MP PW multiplexing over mLDP based P2MP PSN tunnel is outside the scope of this document. 3.5.8. Leaf Grafting/Pruning Since the grafting/pruning is source-initiated, the Ingress PE MUST send a Label Mapping message to the Egress PE for grafting the new leaf to the PW tree, or a Label Withdraw message for pruning the existing leaf from the PW tree. Note that with P2MP GID FEC element, the Label Release is sent only if the Leaf is the only leaf belonging to the PW tree remaining on the Egress PE. If some TAII are still part from the PW tree on that Egress PE, a LDP Notification with a "Success PW Attachment" code message should be sent to the Ingress PE with an the TAII TLV updated accordingly. 4. Security Considerations This section will be added in a future version. 5. IANA Considerations 5.1. LDP FEC Type This document uses a new FEC element type, FEC P2MP GID, from the 'FEC Type Name Space' for the Label Distribution Protocol (LDP RFC 5036). The following value is suggested for assignment: FEC P2MP GID : 0x82 5.2. LDP TLV Type This document uses a new LDP TLV type, from the "TLV TYPE NAME SPACE" for the Label Distribution Protocol (LDP [RFC5036]). The following value is suggested for assignment: TLV Type Description IANA assigned TAII Leaf Jounay et al. Expires January 13, 2010 [Page 15] Internet Draft Source-initiated P2MP PW Setup July 2009 This document defines a new PW Status Capability Parameter. The following value is suggested for assignment: IANA Assigned 5.3. LDP Status Codes This document uses several new LDP status codes; IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC5036. The following values are suggested for assignment: Range/Value E Description Reference ------------- ----- ---------------------- --------- "Success PW Attachment" 6. Acknowledgments Many thanks to JL Le Roux for the discussions, comments and support. The authors wish to thank Luca Martini for his comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC4447] El-Aawar, N., Heron, G., Martini, L., Smith, T., Rosen, E., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", April 2006 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", October 2008. [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 [RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for inter domain Pseudo-Wires", October 2008 [RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S., "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", May 2007 [RFC5003] Metz, C. and all, "Attachment Individual Identifier (AII) Types for Aggregation", September 2007 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", April 2006 Jounay et al. Expires January 13, 2010 [Page 16] Internet Draft Source-initiated P2MP PW Setup July 2009 [RFC5331] Aggarwal, R. and all, "MPLS Upstream Label Assignment and Context-Specific Label Space", August 2008 [RFC3472] Berger, L., all, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", January 2003 7.2. Informative References [P2MP PW REQ] Jounay, F., Niger, P, Kamite, Y., Martini L., Delord, S. Heron, G., "Use Cases and signaling requirements for Point-to-Multipoint PW", Internet Draft, draft-ietf-pwe3-p2mp-pw- requirements-01.txt, July 2009 [LDP UPSTREAM] Aggarwal, R., Le Roux, JL., "MPLS Upstream Label Assignment for LDP", Internet Draft, draft-ietf- mpls-ldp-upstream-04.txt, July 2009 [MLDP] Minei, I., Kompella, K., Thomas, B., Wijnands, I. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to- Multipoint Label Switched Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-07, July 2009 [LDP CAPA] Aggarwal, R., Le Roux, JL., Thomas, B., "LDP Capabilities" draft-thomas-mpls-ldp- capabilities-02.txt, April 2008 [LEAF INIT P2MP PW] Jounay, F., Kamite, Y., Le Roux, JL., Niger, P., "LDP Extensions for Leaf-initiated Point-to- Multipoint Pseudowire" draft-jounay-pwe3-leaf- initiated-p2mp-pw-01.txt, November 2008 [VPMS REQ] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., Jin. L, "Framework and Requirements for Virtual Private Multicast Service (VPMS)" draft-kamite-l2vpn-vpms-frmwk- requirements-02.txt, December 2008 [P2MP PW ENCAPS] Aggarwal, R., "Point-to-Multipoint Pseudo-Wire Encapsulation", draft-raggarwa-pwe3-p2mp-pw- encaps-01.txt Jounay et al. Expires January 13, 2010 [Page 17] Internet Draft Source-initiated P2MP PW Setup July 2009 Author's Addresses Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: frederic.jounay@orange-ftgroup.com Philippe Niger France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: philippe.niger@orange-ftgroup.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: y.kamite@ntt.com Lizhong Jin Nokia Siemens Networks Building 89, 1122 North QinZhou Road, Shanghai, 200233 P.R.China Email: lizhong.jin@nsn.com Martin Vigoureux Alcatel-Lucent Route de Villejust Nozay, 91620 France Email: martin.vigoureux@alcatel-lucent.com Laurent Ciavaglia Alcatel-Lucent Route de Villejust Nozay, 91620 France Email: Laurent.Ciavaglia@alcatel-lucent.com Simon Delord Telstra 242 Exhibition Street Melbourne, VIC, 3000, Australia E-mail: simon.a.delord@team.telstra.com Jounay et al. Expires January 13, 2010 [Page 18] Internet Draft Source-initiated P2MP PW Setup July 2009 Copyright and License Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Jounay et al. Expires January 13, 2010 [Page 19]