Network Working Group F. Jounay (Editor) Internet Draft P. Niger Category: Standards Track France Telecom Expires: September 2009 Y. Kamite L. Jin NTT Communications Nokia Siemens L. Ciavaglia M. Vigoureux Alcatel-Lucent March 09, 2009 LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02.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 September 09, 2009. 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 Jounay et al. Expires September, 2009 [Page 1] Internet Draft Source-initiated P2MP PW Setup March 2009 applications. The document deals with the source-initiated P2MP PW setup and maintenance. 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. Preliminary Notes...............................................3 3. Introduction....................................................3 4. P2MP SS-PW Setup Mechanism......................................3 4.1. P2MP SS-PW Reference Model....................................3 4.2. Overview of the P2MP SS-PW Setup..............................4 4.3. LDP...........................................................5 4.4. P2MP Generalized ID FEC Element...............................5 4.4.1. P2MP GID FEC Element........................................6 4.4.2. TAII Leaf Sub-TLV...........................................8 4.5. Signaling for P2MP SS-PW.....................................10 4.5.1. Configuration/Provisioning.................................10 4.5.2. Capability Negotiation Procedure...........................10 4.5.3. Signaling Process..........................................10 4.5.4. Leaf Attachment Notification Message.......................11 4.5.5. PW Type Mismatch...........................................12 4.5.6. Interface Parameters.......................................12 4.5.7. Interface ID (Underlying P2MP PSN tunnel)..................12 4.5.8. Leaf Grafting/Pruning......................................14 4.6. Failure Reporting (to be completed)..........................14 4.7. Protection and Restoration...................................15 5. Security Considerations........................................15 6. IANA Considerations............................................15 6.1. LDP FEC Type.................................................16 6.2. LDP Status Codes.............................................16 7. Acknowledgments................................................16 8. References.....................................................16 8.1. Normative References.........................................16 8.2. Informative References.......................................17 Authors' Addresses................................................17 Intellectual Property and Copyright Statements....................18 Jounay et al. Expires September 9, 2009 [Page 2] Internet Draft Source-initiated P2MP PW Setup March 2009 1. Terminology This document uses acronyms and terminologies defined in [RFC5036], [RFC3985], [P2MP PW REQ] and [RFC5254]. 2. Preliminary Notes The current version of the document does not cover: - Leaf-initiated unidirectional P2MP PW setup, Leaf-initiated grafting/pruning. This mode is described in a separate document [LEAF INIT P2MP PW]. - Downstream Label Assignment for the P2MP PW label. The solution relies on [LDP UPSTREAM] for the PW Label Assignment since the underlying layer is assumed to be a P2MP PSN tunnel. For the MS-PW architectures which do not imply the use of an underlying P2MP LSP to support the PW segment but a P2P LSP this mode is not necessary. The P2MP PW Downstream Label Assignment and detailed procedures for setting up a P2MP PW over a P2P LSP will be described in a future version. The Working Group feedback is required on the points described above. 3. Introduction [RFC4447] describes a mechanism for establishing Point-to-Point Single-Segment Pseudowire (P2P SS-PW). [DYN MS-PW] describes a mechanism for establishing P2P Multi-Segment Pseudowire (P2P MS-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 first a solution to setup a P2MP SS-PW. The proposed solution relies on the definition of a P2MP FEC element derived from the FEC129 used the single-side provisioning of a P2P PW setup. 4. P2MP SS-PW Setup Mechanism 4.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 Jounay et al. Expires September 9, 2009 [Page 3] Internet Draft Source-initiated P2MP PW Setup March 2009 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, a PPP connection 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. |<-----------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. 4.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 Jounay et al. Expires September 9, 2009 [Page 4] Internet Draft Source-initiated P2MP PW Setup March 2009 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 PW FEC element derived from the FEC129 to setup a P2MP SS-PW. The Ingress PE maintains one signaling LDP session with every Egress PE. Since the P2MP PW is unidirectional and to avoid replication, after a negotiation procedure between Ingress and Egress PEs, the Upstream Label Assignment [LDP UPSTREAM] MUST be used for the PW label allocation. In case of source-initiated PW tree setup, 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 relies on the usage of P2MP LSP (s) as PSN tunnel(s) underlying layer, established between the Ingress PE and all Egress PEs. 4.3. LDP The PW label bindings are distributed using the LDP upstream unsolicited label distribution, liberal label retention mode described in [LDP UPSTREAM] 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, we define a FEC Element TLVs to be used for identifying point-to-multipoint pseudowires. 4.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) Jounay et al. Expires September 9, 2009 [Page 5] Internet Draft Source-initiated P2MP PW Setup March 2009 - a TAII Leaf sub-TLV containing the list of the P2MP PW destination addresses (leaf nodes identified by AIIs) to be attached to the PW tree. 4.4.1. P2MP GID FEC Element The P2MP GID FEC Element is derived from the format of the GID FEC Element (FEC129) defined in [RFC4447]. 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 (TBD)|C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP Id | Length | P2MP Id Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ P2MP Id Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When a Notification message have to be exchanged between peer PEs (see below detailed fo a detail 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, which plays the same role as for the GID FEC. 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: Jounay et al. Expires September 9, 2009 [Page 6] Internet Draft Source-initiated P2MP PW Setup March 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The AGI and the SAII have the same structure than for the FEC 129 defined in [RFC4447] and [RFC5003]. In P2MP GID FEC element, the TAII field structure that was defined in Section 5.3.2 of [RFC4447] is now replaced with a P2MP Identifier (P2MP Id). The PW tree is identified by means of the pair (SAI, P2MP Identifier).The P2MP identifier is required in particular for some P2MP make-before-break function (see 4.8 section). The P2MP Id is a four-octet number. 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 make 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. |(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 Jounay et al. Expires September 9, 2009 [Page 7] Internet Draft Source-initiated P2MP PW Setup March 2009 All remaining fields are unchanged compared to their definition in [RFC4447], including the Control Word (C bit). 4.4.2. TAII Leaf Sub-TLV A TAII Leaf sub-TLV is defined in order to carry the information regarding the P2MP PW destination 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 4.4.1 is also used as the address type of the TAII Leaf sub-TLV. The TAII Leaf sub-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 TBD | 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.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 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; Jounay et al. Expires September 9, 2009 [Page 8] Internet Draft Source-initiated P2MP PW Setup March 2009 The TAII has the same structure than in the FEC 129 defined in [RFC4447]. The TAII Leaf sub-TLV comprises a list of one or more TAII Leaf identifiers. The TAII Leaf sub-TLV MUST be included in the Label Mapping message initiated by the Ingress PE. The TAII Leaf sub-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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| TAII Leaf Type TBD | 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 sub-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 sub-TLV will include only one TAII. Jounay et al. Expires September 9, 2009 [Page 9] Internet Draft Source-initiated P2MP PW Setup March 2009 4.5. Signaling for P2MP SS-PW 4.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. SAI is considered as the Source Attachment Identifier of the PW tree. Each Egress PE MUST be configured with one or more leaf-TAII 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 can 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. 4.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 same P2MP PW 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] MUST be used to prevent replication at the PW level. This also guarantees not to waste the network bandwidth. A 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 also negotiate with its remote Egress PEs the capability of supporting the PW status TLV [RFC4447]. This negotiation is a key element in order to allow the Egress PEs to announce some status information later on to the Ingress PE. 4.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. For P2MP GID FEC-based PW i. A Label Mapping message is sent to every Egress PE containing the SAII configured as the source at the Ingress PE. The TAII Jounay et al. Expires September 9, 2009 [Page 10] Internet Draft Source-initiated P2MP PW Setup March 2009 Leaf sub-TLV includes one or more AII associated to the Attachment Circuits of the Egress PE(s) defined as leaves of the PW tree. 4.5.4. Leaf Attachment Notification Message When the Egress PE receives and processes the Label Mapping message, it verifies the P2MP GID/leaf-TAII(s) and checks if it matches one of its configured Forwarders. For P2MP GID FEC-based PW 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 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 sub-TLV is attached to the LDP Notification message. The TAII Leaf sub-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 sub-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. Jounay et al. Expires September 9, 2009 [Page 11] Internet Draft Source-initiated P2MP PW Setup March 2009 4.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 send an "Non Compliant PW Type" Notification message to its LDP peer signaling an error. "Non Compliant PW Type" TBD 4.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. This mechanism used for the P2P PW setup SHOULD be enhanced for P2MP PW setup so as to ascertain that AC at the Egress PE is capable to support traffic coming from AC at the Ingress PE. Note that the signaling of such parameters is not mandatory and can also be configured statically at PW endpoints. 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, a LDP Notification MUST be returned to the T-PE with a status message indicating the appropriate "interface parameters incompatibility" as defined in [RFC4446]. 4.5.7. Interface ID (Underlying P2MP PSN tunnel) The P2MP SS-PW implies a P2MP underlying tunnel(s). 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]. Jounay et al. Expires September 9, 2009 [Page 12] Internet Draft Source-initiated P2MP PW Setup March 2009 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. For that purpose the LDP Label mapping initiated by the Ingress PE MUST provide the Interface ID TLV as defined in [LDP UPSTREAM]. 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. 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 described below. 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. Jounay et al. Expires September 9, 2009 [Page 13] Internet Draft Source-initiated P2MP PW Setup March 2009 This is a trade-off we have already expressed in the P2MP bypass draft. 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. 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 still under study. 4.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 Status code message should be sent to the Ingress PE with an the TAII sub-TLV updated accordingly. 4.6. Failure Reporting (to be completed) If a PW tree endpoint configured on an Egress PE or the corresponding AC fails, the Egress PE MUST report by means of PW status TLV transported in a LDP Notification message to the Ingress PE (as defined in [RFC4447]) that the associated leaf is no more reachable . The TAII Leaf sub-TLV is used to identify the leaf. If the Egress PE itself fails, specific OAM features MUST be used (TBD: LDP status or extended VCCV BFD). Jounay et al. Expires September 9, 2009 [Page 14] Internet Draft Source-initiated P2MP PW Setup March 2009 4.7. Protection and Restoration The P2MP SS-PW is supported over a P2MP PSN LSP. If required a first level of protection/restoration MUST be implemented at the LSP layer with classic recovery techniques. |(SAII) PE1 / \ / \ P2 P3 / \ / \ //--\--/ \ // \-----\\ PE4 PE5 |(TAII) |(TAII) An alternative protection scheme may rely on the PW layer. 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). |(SAII) P2MP PW1 PE P2MP PW2 (SAII, P2MP1).../ \...._(SAII, P2MP2) / \ P2 P3 / \ / \ / \ / \ / \ / \ PE4 PE5 PE6 PE7 |(TAII)| |(TAII)| A mechanism should be implemented to avoid race conditions between recovery at the PSN level and recovery at the PW level. 5. Security Considerations This section will be added in a future version. 6. IANA Considerations Jounay et al. Expires September 9, 2009 [Page 15] Internet Draft Source-initiated P2MP PW Setup March 2009 6.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 values are suggested for assignment: FEC P2MP GID : 0x82 6.2. 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 ------------- ----- ---------------------- --------- LDP Capabilities 7. Acknowledgments Many thanks to JL Le Roux for the discussions, comments and support. 8. References 8.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 Jounay et al. Expires September 9, 2009 [Page 16] Internet Draft Source-initiated P2MP PW Setup March 2009 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", April 2006 8.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-00.txt, September 2008 [DYN MS-PW] Balus, F., Bocci, M., Martini. L, " Dynamic Placement of Multi Segment Pseudo Wires", Internet Draft, draft-ietf-pwe3-dynamic-ms-pw- 08.txt, July 2008 [LDP UPSTREAM] Aggarwal, R., Le Roux, JL., "MPLS Upstream Label Assignment for LDP", Internet Draft, draft-ietf- mpls-ldp-upstream-03.txt, July 2008 [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-05, May 2008 [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 Author's Addresses Frederic Jounay France Telecom 2, avenue Pierre-Marzin Jounay et al. Expires September 9, 2009 [Page 17] Internet Draft Source-initiated P2MP PW Setup March 2009 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 Email: martin.vigoureux@alcatel-lucent.com Laurent Ciavaglia Alcatel-Lucent Email: Laurent.Ciavaglia@alcatel-lucent.com Derivative Works and Publication Limitations 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. Copyright and License Notice Jounay et al. Expires September 9, 2009 [Page 18] Internet Draft Source-initiated P2MP PW Setup March 2009 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. Jounay et al. Expires September 9, 2009 [Page 19]