Network Working Group F. Jounay Internet Draft P. Niger Category: Standards Track France Telecom Expires: August 2007 Y. Kamite NTT Communications February 26, 2007 LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire draft-jounay-niger-pwe3-source-initiated-p2mp-pw-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Daft will expire on August 26, 2007. 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 August 26, 2007 [Page 1] Internet Draft Source-initiated P2MP PW Setup February 2007 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..................................4 4.1. P2MP SS-PW Reference Model..................................4 4.2. Overview of the P2MP SS-PW Setup............................5 4.3. P2MP PWid FEC Element.......................................5 4.4. P2MP Generalized ID FEC Element.............................6 4.4.1. P2MP GID FEC TLV............................................6 4.4.2. TAII Leaf Sub-TLV...........................................7 4.5. Signaling for P2MP SS-PW....................................8 4.5.1. Configuration/Provisioning..................................8 4.5.2. Capability Negotiation Procedure............................9 4.5.3. Signaling Process...........................................9 4.5.4. Underlying LSP Setup.......................................10 4.5.5. Leaf Grafting/Pruning......................................12 4.6. Failure Reporting (to be completed)........................12 4.7. Protection and Restoration.................................12 5. P2MP MS-PW Setup Mechanism with P2MP PSN tunnel............12 5.1. P2MP MS-PW Reference Model.................................12 5.2. Overview of the P2MP MS-PW Setup...........................14 5.3. Signaling for P2MP MS-PW...................................14 5.3.1. Configuration/Provisioning.................................14 5.3.2. Capability Negotiation Procedure...........................15 5.3.3. Signaling Process..........................................15 5.3.4. Explicit Routing...........................................17 5.3.5. Underlying LSP Setup.......................................17 5.3.6. Leaf Grafting/Pruning......................................18 5.4. Failure Reporting..........................................19 5.5. Protection and Restoration.................................19 6. Security Considerations....................................19 7. IANA Considerations........................................19 7.1. LDP FEC Type...............................................19 7.2. LDP Status Codes...........................................20 8. Acknowledgments............................................20 9. References.................................................20 9.1. Normative References.......................................20 9.2. Informative References.....................................20 Authors' Addresses.................................................21 Intellectual Property and Copyright Statements.....................22 Jounay et al. Expires August 26, 2007 [Page 2] Internet Draft Source-initiated P2MP PW Setup February 2007 1. Terminology This document uses acronyms and terminologies defined in [RFC3036], [RFC3985], [P2MP PW REQ] and [MS-PW REQ]. 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 [RFC3036], [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 two new P2MP FEC elements derived from the FEC128 and the FEC129 used respectively for the double-side provisioning and the single-side provisioning of a P2P PW setup The document also presents a solution to setup a P2MP MS-PW. Due to the End-to-End dynamic setup requirement for P2MP MS-PW, the proposed solution relies on the same FEC129-derived P2MP FEC element previously defined for the P2MP SS-PW setup. Jounay et al. Expires August 26, 2007 [Page 3] Internet Draft Source-initiated P2MP PW Setup February 2007 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 at least two Egress PEs connected to traffic receivers. The PW endpoints connect the PW to its attachment circuits (AC). As for a P2P PW, 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. 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 | | +----+ | | | | ......PW1........|-----------|CE2 | | | | | . |=========| | | +----+ | | | | . | +----+ | | | |=========| . | | | | | | . | +----+ | +----+ | | | | . |=========|PE3 | | +----+ |CE1 |---------|........PW1.........|...PW1........|-----------|CE3 | +----+ | | | | . |=========| | | +----+ | | | | . | +----+ | | | |=========| . | | | | | | . | +----+ | | | | | . |=========|PE4 | | +----+ | | | | ......PW1........|-----------|CE4 | | | | | |=========| | | +----+ | +----+ +-----+ +----+ | Figure 1 P2MP SS-PW Reference Model This architecture applies to the case where a P2MP PSN tunnel extends between 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. Jounay et al. Expires August 26, 2007 [Page 4] Internet Draft Source-initiated P2MP PW Setup February 2007 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 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 proposes two P2MP PW FEC elements to setup a P2MP SS- PW, one derived from the FEC128 and the other one from the FEC129. As represented in Figure 1 the unidirectional P2MP SS-PW relies on the use of P2MP LSP as PSN tunnel underlying layer, setup between the Ingress PE and all Egress PEs. The Ingress PE maintains one signaling 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. Note : Whatever the signaling initialization is (leaf or source- initiated), the use of the P2MP PWiD FEC to setup the P2MP SS-PW has no particular effect on the required provisioning procedure, since both sides (source and leaves) MUST be configured with the P2MP PWid and the IP address of the remote PE. However when the P2MP GID FEC is used for the PW tree setup, the document describes below a preferred solution based on a source-initiated process, since the single sided configuration alleviates considerably the required provisioning procedure. 4.3. P2MP PWid FEC Element A new FEC element is defined and is derived from the PWid FEC element defined in [RFC4447]. The P2MP PWid FEC is defined as follows: Jounay et al. Expires August 26, 2007 [Page 5] Internet Draft Source-initiated P2MP PW Setup February 2007 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 PWid (TBD)|C| P2MP PW type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Parameter Sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The P2MP PWid defines the new FEC Element. All remaining fields are unchanged compared to their definition in [RFC4447]. 4.4. P2MP Generalized ID FEC Element Based on the benefit provided by the PW AII addresses, the FEC129 used for P2P PW setup is extended to propose: - a new P2MP GID FEC element containing a P2MP identifier and a PW source address (SAII) - a new TAII Leaf sub-TLV containing the list of leaves (identified by AIIs) to be attached to the PW tree. 4.4.1. P2MP GID FEC TLV The P2MP GID FEC is derived from the format of the GID FEC (FEC129) defined in [RFC4447]. The AGI 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). The SAII is attached to the Ingress PE and identifies the PW tree source. The AGI and the SAII have the same structure than for the FEC 129. The TAII is replaced by a P2MP Identifier (P2MP Id). The PW tree is identified by means of the pair [SAI, P2MP Identifier]. Jounay et al. Expires August 26, 2007 [Page 6] Internet Draft Source-initiated P2MP PW Setup February 2007 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 | 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 description of procedures), the P2MP GID FEC MUST be included in the message to identify the PW tree to which it applies. 4.4.2. TAII Leaf Sub-TLV In order to carry the information regarding the leaves to be connected to the tree, a new TAII Leaf sub-TLV is defined. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| TAII Leaf Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ------------------- ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | Jounay et al. Expires August 26, 2007 [Page 7] Internet Draft Source-initiated P2MP PW Setup February 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TAII have the same structure than for the FEC 129. The TAII Leaf sub-TLV comprises a list of one or more TAII Leaves. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| TAII Leaf Type | 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. 4.5. Signaling for P2MP SS-PW 4.5.1. Configuration/Provisioning Referring to Figure 1, if the P2MP PWid FEC is used, the Ingress PE (PE1) and the Egress PEs (PE2, PE3 and PE4) MUST be configured with the same P2MP PWid. Jounay et al. Expires August 26, 2007 [Page 8] Internet Draft Source-initiated P2MP PW Setup February 2007 Referring to Figure 1, if the P2MP GID FEC is used the Ingress PE (PE1) MUST be configured with the AGI and SAII. SAI is considered as the Source Attachment Identifier of the PW tree. Each Egress PE MUST be configured with one or more TAII corresponding to one or more leaves of the PW tree. The AGI MUST be the same for all endpoints of the PW tree. Once the AIs are configured at all endpoints, the provisioning next step for the PW tree establishment consists in specifying at the Ingress PE all the TAIIs identifying the leaves of the PW tree. Regardless of the FEC element used, the IP address of the Egress PEs where the TAII are attached can be configured manually or learnt dynamically by means of auto discovery protocol at Ingress PE. 4.5.2. Capability Negotiation Procedure To achieve the capability negotiation the solution MUST follow the LDP capability advertisement mechanism described in [LDP CAPA]. New code points if required SHOULD be defined. The PEs belonging to the PW tree MUST support the same P2MP PW FEC element. The unidirectional P2MP SS-PW is supported over a P2MP LSP, so Upstream Label Assignment as defined in [LDP UPSTREAM] MUST be used to prevent replication at the PW level. So that guarantees not to waste the network bandwidth. An Upstream Label Assignment Capability sub-TLV is introduced to signal a PE's support of upstream label assignment, to its LDP peers. This sub-TLV is carried in the LDP Capability TLV. The Ingress PE MUST also negotiate with its remote Egress PEs the capability of supporting the PW status TLV. 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 session with every Egress PE. If the P2MP PWid FEC is used, the same Label Mapping message is sent to every Egress PE containing the same P2MP PWid. If the P2MP GID FEC is used, a Label Mapping message is sent to every Egress PE containing the SAII configured as the source at the Ingress PE. The TAII Leaf sub-TLV includes one or more AII associated to the Egress PE defined as leaves of the tree. Jounay et al. Expires August 26, 2007 [Page 9] Internet Draft Source-initiated P2MP PW Setup February 2007 The Label Mapping message MUST include an upstream assigned PW label carried within the Upstream Assigned Label TLV. The Ingress PE MUST NOT distribute the Upstream Assigned Label TLV to the Egress PE if the Egress PE had not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages. Note that the Ingress PE does not need to receive a Label Request from the Egress PE to send the Label Mapping message. When the Egress PE receives and processes the Label Mapping message, it verifies the PWid or the TAII(s) and checks if it matches to one of its configured Forwarders. If a matching is found for the PWid, the Egress PE carries on the process by responding with a PW status TLV to the Ingress PE. The PW status TLV informs the Ingress PE that the Egress PE and associated leaf(ves) is from now part of the PW tree. For this purpose a Success Status Code is used. Therefore the Ingress and the Egress PEs update their PW-to-label bindings. If no matching is found the Egress PE sends a Label Release message. The FEC TLV sent in a Label Release is the same FEC TLV received in the Label Mapping message initiated by the Ingress PE. 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 part of the PW tree. Therefore the Ingress and the Egress PEs update their PW-to-label bindings. When some TAII leaves do not match with ones configured at the Egress PE, an error procedure must be applied as defined in [SEG PW]. If no matching is found among the TAII leaves, the Egress PE sends a Label Release message. The FEC TLV sent in a Label Release is the same FEC TLV received in the Label Mapping message initiated by the Ingress PE. Note that a matching addresses the PWid or the TAII-sub TLV for the GID but other parameters are also checked as described in RFC4447 (Type, possible interface parameters). 4.5.4. Underlying LSP Setup 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. If it is not the case the Egress PE MUST join the P2MP PSN tunnel. Two possible options are described hereafter. The P2MP SS-PW implies a P2MP underlying tunnel. Figure 2 extracted from [P2MP PW REQ] gives an example of P2MP SS-PW topology relying on Jounay et al. Expires August 26, 2007 [Page 10] Internet Draft Source-initiated P2MP PW Setup February 2007 a P2MP LSP. The PW tree is composed of one Ingress PE (i1) and several Egress PEs (e1, e2, e3, e4). Depending on the Traffic-Engineering requirements, the P2MP LSP set up will be based on [P2MP RSVP-TE] or [MLDP] signaling. i1 / / \ / \ / \ /\ \ / \ \ / \ \ / \ / \ e1 e2 e3 e4 Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW As defined in [LDP UPSTREAM], the Interface ID TLV is used for signaling the underlying Tunnel Identifier. The Ingress PE MUST include the identifier of the underlying P2MP LDP or RSVP-TE LSP in Interface ID TLV in the Label Mapping messages along with the Upstream Assigned Label TLV. 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. With this procedure a P2MP PW is nested within a P2MP PSN tunnel. This allows aggregating several PW LSPs over a common P2MP PSN tunnel. If the P2MP LSP is based on [P2MP 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. If the P2MP LSP is based on [MLDP], the P2MP LSP is 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 join the P2MP LSP by initiating a LDP Label Mapping messages. Remark: need to check if upstream label assignment procedure works when the underlying interface is not established in advance. Jounay et al. Expires August 26, 2007 [Page 11] Internet Draft Source-initiated P2MP PW Setup February 2007 4.5.5. 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 tree, or a Label Withdraw message for pruning the existing leaf from the tree. The Egress PE MUST confirms the pruning by sending a Label Release message. 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 AII is used to identify the leaf. An alternative solution based on in-band OAM could also be used (e.g. based on BFD/VCCV). If the Egress PE itself fails, specific OAM features MUST be used (TBD: LDP status or extended VCCV BFD). 4.7. Protection and Restoration The P2MP SS-PW is supported over a P2MP LSP. If required a first level of protection/restoration MUST be implemented at the LSP layer with classic recovery techniques. At the PW layer the only equipments to protect are the Ingress PE and the Egress PEs. A mechanism should be implemented to avoid race conditions between recovery at the PSN level and recovery at the PW level. 5. P2MP MS-PW Setup Mechanism with P2MP PSN tunnel 5.1. P2MP MS-PW Reference Model Figure 3 describes the P2MP MS-PW reference model which is derived from [P2MP PW REQ] to support P2MP emulated services. Jounay et al. Expires August 26, 2007 [Page 12] Internet Draft Source-initiated P2MP PW Setup February 2007 |<-----------P2MP MS-PW------------>| Native | P2MP P2MP | Native Service | |<-PSN1-->| |<-PSN2-->| | Service (AC) V V tunnel V V tunnels V V (AC) | +----+ +-----+ +----+ | | |T-PE| |S-PE1|=========|T-PE| | +----+ | | 1 | | ........2.|-----------|CE2 | | | |=========| | . | | | +----+ | | | ...............PW2 +----+ | | | | . | | . +----+ | | | | . | | . |T-PE| | +----+ | | | . | ........3.|-----------|CE3 | +----+ | | | . | |=========| | | +----+ |CE1 |---------|........PW1 +-----+ +----+ | +----+ | | | . +-----+ +----+ | | | | . |S-PE2|=========|T-PE| | +----+ | | | . | | ........4.|-----------|CE4 | | | | . | | . | | | +----+ | | | . | | . +----+ | | | | ...............PW3 +----+ | | | |=========| | . |T-PE| | +----+ | | | | | ........5.|-----------|CE5 | | | | | |=========| | | +----+ | +----+ +-----+ +----+ | Figure 3 P2MP MS-PW over P2MP PSN tunnels Reference Model Figure 3 extends the P2MP SS-PW architecture of Figure 1 to a multi- segment configuration. In a P2P MS-PW configuration as described in [MS-PW REQ] the S-PE is responsible to switch a MS-PW from one input segment to only one output segment, based on the PW identifier. Here in a P2MP MS-PW configuration the S-PE is responsible to switch a MS- PW from one input segment to one or several output segments depending on the underlying layer. In this document the underlying layer is a P2MP LSP, so the S-PE switches one P2MP input segment to one or several P2MP output segment. Referring to Figure 3 T-PE1 is the Ingress T-PE and T-PE2, T-PE3, T- PE4 and T-PE5 are the Egress T-PEs. The S-PE1 and S-PE2 play the role of branch S-PE since they are in charge of switching simultaneously the input P2MP PW segment PW1 to respectively the output P2MP PW segments PW2 and PW3 respectively. Note that a P2MP MS-PW may obviously transit trough more than one S- PE along its path. Note that if the P2MP SS-PW case mandatory implies the use of P2MP PSN tunnel (underlying layer) between the edge nodes, the P2MP MS-PW does not imply such a requirement since each PW segment can be supported over a P2P PSN tunnel. The coexistence of both kinds of PSN tunnel (P2P and P2MP) MUST be considered. The case where the PW Jounay et al. Expires August 26, 2007 [Page 13] Internet Draft Source-initiated P2MP PW Setup February 2007 segment composing a MS-PW tree is supported over P2P PSN tunnels will be described in a future version. 5.2. Overview of the P2MP MS-PW Setup The P2MP MS-PW setup relies on the use of the P2MP GID FEC Element defined in 4.4. The solution aims at setting up a unidirectional P2MP Multi-Segment PW to be capable to extend the P2MP PW to inter-domain. The principle proposed here relies on a source-initiated P2MP MS-PW setup. In the proposed approach the source is assumed to know all the leaves of the PW tree, so the source is able to initiate the signaling procedure. Another added value of the P2MP MS-PW source initiated approach is to make possible the implementation of CR (Constraint-based Routed) MS-PW. In that case an explicit route defining the PW tree topology is represented as a list of S-PEs that the P2MP MS-PW must use along the constraint-based route. The document describes the solution to setup the P2MP MS-PW in the case the PW segments inside a given PSN are supported over a P2MP PSN tunnel. Since the P2MP PW segment is unidirectional and to avoid replication, after a negotiation procedure between Ingress T-PE/S-PE and S-PE/Egress T-PEs, the Upstream Label Assignment [LDP UPSTREAM] MUST be used for the PW label assignment. Note that by definition a P2MP LSP can have a single leaf, so mechanisms defined in this document apply to P2P PSN Tunnels. But since the P2P PSN case does not require upstream label assignment simpler procedures that rely on downstream label assignment will be defined in a future version. 5.3. Signaling for P2MP MS-PW 5.3.1. Configuration/Provisioning After configuring on each T-PE of the attached AIIs, it is assumed that all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII PW routing table which gives for each AII as entry the "next hop" to reach that AII. This AII routing table can be filled manually or updated dynamically by means of some extended routing protocol like proposed in [DYN MS-PW]. The construction of the table is out of scope of the present document. Each PE relies on its AII PW routing table to select the next hop PE (S-PE or T-PE) to reach a given TAII. In the source-initiated P2MP MS-PW setup, the provisioning of the PW tree is only required at the source side, on the Ingress PE instead of all destination PEs. For the P2MP MS-PW setup the provisioning task consists in specifying at the Ingress PE all the TAII considered Jounay et al. Expires August 26, 2007 [Page 14] Internet Draft Source-initiated P2MP PW Setup February 2007 as the leaves of the tree (information transported in the TAII sub- TLV for signaling procedure). 5.3.2. Capability Negotiation Procedure To achieve the capability negotiation the solution MUST follow the LDP capability advertisement mechanism described in [LDP CAPA]. New code points are defined in this document (TBC). The unidirectional P2MP PW segment is supported over a P2MP LSP, so Upstream Label Assignment as defined in [LDP UPSTREAM] MUST be used to prevent traffic replication at the PW level. The Upstream Label Assignment Capability sub-TLV is used to signal a PE's support of upstream label assignment, to its LDP peers. This sub-TLV is carried in the LDP Capability TLV. The PEs belonging to a given P2MP MS-PW MUST support the P2MP GID FEC Element. The PEs MUST also negotiate with their remote PEs the capability of supporting the PW status TLV. This negotiation is a key element in order to allow these PEs to announce some status information later on. 5.3.3. Signaling Process Note: in the next release of the document this paragraph will have to be changed for a more normative formulation (MUST, SHOULD, etc). It is assumed to use the Upstream Label Assignment for the PW label Assignment to set up a P2MP MS-PW since in this document the P2MP PW segment is assumed to be supported over a P2MP PSN tunnel. Ingress T-PE To set up the P2MP MS-PW, the Ingress T-PE initiates a signaling session with the S-PEs selected to join the TAIIs. If the Ingress T- PE is attached to several S-PEs, and according to the TAII Leaf sub- TLV, and the AII routing table, the Ingress T-PE can select a unique S-PE or several S-PEs. In the last case, several signaling sessions have to be set up, one with each selected S-PE. Otherwise only one signalling session is established between the Ingress T-PE and the next hop S-PE. The Ingress T-PE sends a Label Mapping message to the S-PE which contains the P2MP GID TLV and the TAII Leaf sub-TLV which identify the subset of MS-PW leaves of the multicast tree that are reachable via the S-PE. A given TAII does not appear in more than once signaling messages in order to avoid building several branches to the same leaf via different paths. Branch S-PE Jounay et al. Expires August 26, 2007 [Page 15] Internet Draft Source-initiated P2MP PW Setup February 2007 When a branch S-PE receives a Label Mapping message, it checks if one or several TAIIs belonging to the TAII Leaf sub-TLV matches to its AII PW routing table. If at least one matching is found the S-PE sends a PW Status Notification message to the upstream PE (Ingress T- PE or S-PE) in order to inform it about its tree attachment. Using such information the T-PE is able to validate its forwarding plane by acknowledging its PW-to-Label bindings. If no matching is found or if some TAIIs are not reachable from the S-PE, an error procedure must be applied as defined in [SEG PW] and reminded in 5.4.Based on the result of the matching the S-PE validates as well its PW-to-label bindings for upstream allocated labels. This ends PW set up between the S-PE and the upstream node (T-PE or S-PE). Here we assume that even though all the TAII from the TAI Leaf sub-TLV are not reachable (which leads to an error message), the PW tree continues to be setup for those reachable. In turn the S-PE selects the "next hops" to reach the TAIIs. One or more next hop PEs can be identified. A next hop can be another S-PE or directly an Egress T-PE. The S-PE sends one Label Mapping message to each selected next hop with the same FEC containing the source AII and the P2MP MS-PW identifier. For each next hop the Label Mapping message issued by the S-PE carries in TAII Leaf sub-TLV the leaves that can be reached using the selected next hop. To avoid inconsistency the sub-TLV includes only the TAIIs which are reachable using the selected next hop (other TAIIs are pruned from the received TAII Leaf sub-TLV). The branch S-PE validates its forwarding plane by specifying that the PW-to-label bindings for this segment is active only if it receives a successful PW Status Notification message from its downstream PE (S-PE or Egress T-PE). This process is repeated hop by hop until the P2MP MS-PW is completely built, when all reachable leaves are connected to the source. That means that the last PW segment connecting an Egress T-PE is set up based on a TAII Leaf TLV containing only the TAIIs that are attached to this Egress T-PE (only one TAII if there is only one leaf attached to the Egress T-PE). Egress PE When receiving a Label Mapping message an Egress PE checks that the TAIIs included in the TAII Leaf sub-TLV are configured and could be associated to a forwarder. If it is the case (at least for one TAII) the Egress T-PE sends a PW Status Notification message to the upstream PE (Ingress T-PE or S-PE) in order to inform it about its tree attachment. The Egress T-PE validates its forwarding plane by acknowledging the PW-to-label binding for this last segment. The P2MP MS-PW is then built and the corresponding leaves (TAIIs) are connected to the source (SAII). Jounay et al. Expires August 26, 2007 [Page 16] Internet Draft Source-initiated P2MP PW Setup February 2007 If no AII belonging to the TAII Leaf sub-TLV are configured at the Egress T-PE, the Egress T-PE generates an error message (Label Release message) to the upstream S-PE to tear down the PW segment and prune it from the tree. At turn if this PW segment is the only output PW segment of the P2MP MS-PW for this S-PE, it generates a Label Release message to the upstream S-PE (or Ingress T-PE). Since the PW segment is assumed here P2MP, the S-PE MUST make sure before sending the Label Release to the upstream PE that no leaf is still attached. 5.3.4. Explicit Routing The P2MP MS-PW source-initiated approach allows the implementation of CR (Constraint-based Routed) P2MP MS-PW. In that case an explicit route determining the P2MP tree topology must be defined. This explicit route could be represented as the list of S-PEs that the P2MP MS-PW must use along the constraint-based route. The implementation of such CR P2MP MS-PW requires an extension of existing signaling mechanism in order to allow the signaling message to transport the explicit route used to set up the multicast tree. This point requires further studies. 5.3.5. Underlying LSP Setup Figure 4 describes an example of P2MP MS-PW topology relying on P2MP LSPs as PSN tunnels. The PW tree is composed of one Ingress PE (i1) and several Egress PEs (e1, e2, e3, e4, e5, e6). The branch S-PEs are represented as b1,b2. In that case the traffic replication along the path of the PW tree is performed at the PW level and at the underlying LSP level. For instance the branch S-PE b2 MUST replicate incoming packets or data received from i1 and send them to Egress T- PEs, e3, and e4 via a P2MP PW segment supported over a P2MP PSN tunnel and to e5 and e6 via another P2MP PSN tunnel. Figure 4 describes the case where each P2MP PW segment is supported over a P2MP LSP. i1 / /\ / \ b1 \ / \ /\ \ / \ b2 e1 e2 / \ /\ /\ e3e4e5e6 Figure 4 Example of P2MP underlying Layer for P2MP MS-PW Jounay et al. Expires August 26, 2007 [Page 17] Internet Draft Source-initiated P2MP PW Setup February 2007 When a PW segment is supported over a P2MP LSP, the way to proceed to setup the underlying layer is the same as described for SS-PW 4.5.4 except that the procedure applies to a P2MP PW segment and not to a P2MP End-to-End PW. P2P PSN is supported by methods defined in this draft but simpler method specific to P2P PSN will be described in a future version. 5.3.6. Leaf Grafting/Pruning After a P2MP MS-PW has been established, it MUST be possible to add/remove one or more individual leaves. It is required to be able to achieve this addition without damaging the current tree. Leaf Grafting In that case the procedure is the same as for the P2MP MS-PW construction, except that the procedure is applied with only one TAII identifying the new leaf in the TAII Leaf sub-TLV. The Ingress T-PE initiates a Label Mapping message with the P2MP GID FEC [SAI, P2MP Id] of the tree to which the leaf must be added and the TAII Leaf sub-TLV identifying the leaf. The signaling message is processed as described above by PEs (T-PEs and S-PEs). The upstream PE reuses the same upstream label previously assigned for the existing segments of the P2MP tree identified with the P2MP GID FEC [SAI, P2MP Id]. Each S-PE checks if an extension of the existing PW tree is required to reach the TAII. If a PW segment already exists to the next hop the signaling message is simply propagated to the next hop. A new PW segment is set up to a next hop only if the next hop was not still used so far for existing leaves of the PW tree. The extension of the PW tree is built hop by hop up to the Egress T-PE where the new leaf is added to the tree. The TAII MUST be configured on the Egress T-PE. Otherwise an error message is issued by the Egress T-PE in the reverse direction (as described above). The error message triggers as well a Label Release message from the Egress T-PE if the given TAII is the only leaf configured at the Egress T-PE. Leaf Pruning The Ingress T-PE initiates a Label Withdraw message with the P2MP GID FEC [SAI, P2MP Id] of the tree to which the leaf must be removed and the TAII Leaf sub-TLV identifying the leaf. The Label Withdraw message must be processed by the receiving T-PE. The S-PE processes this message only to propagate the message up to the Egress T-PE. It is proposed that the Label Withdraw is propagated up to the corresponding Egress T-PE. Jounay et al. Expires August 26, 2007 [Page 18] Internet Draft Source-initiated P2MP PW Setup February 2007 The Egress T-PE verifies that the TAII matches with one of its configured local AII. If it is the case the Egress T-PE removes the leaf corresponding to the AII from the PW tree. Then the T-PE checks if the TAII is its only AII attached to the PW tree identified by the P2MP GID FEC. If it is the case the T-PE sends a Label Release message to its upstream PE to tear down the PW segment and prune it from the PW tree. At turn if this PW segment is the only output PW segment of the P2MP MS-PW for this S-PE, it generates a Label Release message to the upstream S-PE (or Ingress T-PE). Note: A Label Withdraw message initiated from the Ingress T-PE which does not include a TAII Leaf sub-TLV aims at pruning all the PW tree. The message is processed by all the PEs and propagated up to the Egress T-PEs. 5.4. Failure Reporting When a notification message must be sent in the backward direction, the P2MP GID FEC is added to the message to identify the P2MP tree concerned. It could be used to announce to the source that a given leaf is not reachable or is no longer reachable (e.g. the corresponding TAII does not exist on the Egress T-PE). It could also be used to send to the source other kinds of information like leaf status reporting, OAM defect indication, etc. Solutions on specific OAM features to detect and announce a node or a segment failure are left for future study. 5.5. Protection and Restoration This section will be added in a future version. 6. Security Considerations This section will be added in a future version. 7. IANA Considerations 7.1. LDP FEC Type This document uses two new FEC element types, FEC P2MP PWid, FEC P2MP GID , from the "FEC Type Name Space" for the label Distribution Protocol (LDP RFC 3036). The following values are suggested for assignment: FEC P2MP PWid : 0x82 FEC P2MP GID : 0x83 Jounay et al. Expires August 26, 2007 [Page 19] Internet Draft Source-initiated P2MP PW Setup February 2007 7.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 RFC3036. The following values are suggested for assignment: Range/Value E Description Reference ------------- ----- ---------------------- --------- LDP Capabilities 8. Acknowledgments Many thanks to JL Le Roux for the discussions, comments and support. 9. References 9.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 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", January 2001. [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 9.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-jounay-pwe3-p2mp-pw- requirements-00.txt, February 2007 [MS-PW REQ] Bitar, N., Bocci, M., and Martini, L., "Requirements for inter domain Pseudo-Wires", Internet Draft, draft-ietf-pwe3-ms-pw- requirements-03.txt, October 2006 [DYN MS-PW] Balus, F., Bocci, M., Martini. L, " Dynamic Placement of Multi Segment Pseudo Wires", Internet Draft, draft-ietf-pwe3-dynamic-ms-pw- 02.txt, October 2006 Jounay et al. Expires August 26, 2007 [Page 20] Internet Draft Source-initiated P2MP PW Setup February 2007 [SEG PW] Martini et al, "Segmented Pseudo Wire", Internet Draft, draft-ietf-pwe3-segmented-pw-03.txt, October 2006 [LDP UPSTREAM] Aggarwal, R., Le Roux, JL., "MPLS Upstream Label Assignment for LDP", Internet Draft, draft-ietf- mpls-ldp-upstream-00.txt, March 2006 [P2MP RSVP-TE] Aggarwal, R., Papadimitriou, D., Yasukawa, S., "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", Internet Draft, draft-ietf-mpls-rsvp- te-p2mp-06.txt, July 2006 [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-02, June 2006 [LDP CAPA] Aggarwal, R., Aggarwal, S., Le Roux, JL., Thomas, B., "LDP Capabilities" draft-thomas- mpls-ldp-capabilities-01.txt, October 2006 [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-00.txt, February 2007 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 Jounay et al. Expires August 26, 2007 [Page 21] Internet Draft Source-initiated P2MP PW Setup February 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jounay et al. Expires August 26, 2007 [Page 22]