Network Working Group F. Jounay Internet Draft P. Niger Category: Informational Track France Telecom Expires: August 2007 Y. Kamite L. Martini NTT Communications Cisco S. Delord G. Heron Uecomm Tellabs L. Wang Telenor February 26, 2007 Use Cases and signaling requirements for Point-to-Multipoint PW draft-jounay-pwe3-p2mp-pw-requirements-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-Draft will expire on August 26, 2007. Abstract This document provides some use cases advocating for the definition of a unidirectional Point-to-Multipoint Pseudowire (P2MP PW). Based on these use cases it also presents a set of requirements for the set up and maintenance of P2MP PW, proposed as guidelines for possible solutions. Jounay et al. Expires August 26, 2007 [Page 1] Internet Draft P2MP PW Requirements 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. Introduction................................................3 1.1. Problem Statement...........................................3 1.2. Scope of the document.......................................3 2. Definition..................................................4 2.1. Acronyms....................................................4 2.2. Terminology.................................................4 3. Use Cases for P2MP PW.......................................5 3.1. TDM-based Use Case..........................................5 3.2. ATM-based Use Case..........................................6 3.3. Ethernet-based Use Case.....................................6 3.3.1. P2MP PW for VPLS............................................6 3.3.2. P2MP PW for Ethernet-based VPWS.............................6 4. P2MP SS-PW Requirements.....................................7 4.1. P2MP SS-PW Reference Model..................................7 4.2. P2MP SS-PW Underlying Layer.................................8 4.3. P2MP SS-PW Signaling Requirements...........................8 4.3.1. P2MP SS-PW Setup Mechanisms.................................8 4.3.2. Leaf Grafting/Pruning.......................................8 4.4. Failure Reporting and Processing............................9 4.5. Advertisement of P2MP Capability............................9 4.6. Scalability.................................................9 4.7. Order of Magnitude.........................................10 5. P2MP MS-PW Requirements....................................10 5.1. P2MP MS-PW Pseudowire Reference Model......................10 5.2. P2MP SS-PW Underlying Layer................................11 5.3. P2MP MS-PW Signaling Requirements..........................12 5.3.1. PW Addresses Routing.......................................12 5.3.2. P2MP MS-PW Setup Mechanisms................................12 5.3.3. Leaf Grafting/Pruning......................................12 5.3.4. Explicit Routing...........................................13 5.4. Failure Reporting..........................................13 5.5. Protection and Restoration.................................13 5.6. Advertisement of P2MP Capability...........................14 5.7. Scalability................................................14 5.8. Order of Magnitude.........................................14 6. Manageability considerations...............................15 7. Backward Compatibility.....................................15 8. Security Considerations....................................15 9. IANA Considerations........................................15 10. Acknowledgments............................................15 Jounay et al. Expires August 26, 2007 [Page 2] Internet Draft P2MP PW Requirements February 2007 11. References.................................................15 11.1. Normative References........................................15 11.2. Informative References......................................15 Authors' Addresses.................................................16 Intellectual Property and Copyright Statements.....................17 1. Introduction 1.1. Problem Statement As defined in the PWE3 WG charter, a Pseudowire (PW) emulates a point-to-point bidirectional link over an IP/MPLS network, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. A Pseudowire is used to transport non IP traffics (e.g. Ethernet, TDM, ATM, and FR) in a MPLS-based PSN (Packet Switched Network). PWE3 operates "edge to edge" to provide the required connectivity between the two endpoints of the PW. For some use cases described hereafter, some P2MP services require the use of Pseudowire for their encapsulation capabilities. This could be achieved using a set of point to point PWs, with traffic replication on the Ingress PE, but faces obvious bandwidth limitation issues, as traffic is carried multiple time on shared links. To avoid such bandwidth wastings, an alternative solution consists of using a unique Point to Multipoint PW (P2MP PW) that is a unidirectional PW with one Ingress PE and a set of one or more Egress PEs, and without traffic replication on Ingress PE. This document aims at describing possible use cases for P2MP PW and defining the associated requirements related to the P2MP PW setup and maintenance. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for the signaling of P2MP Pseudowire satisfy these requirements. 1.2. Scope of the document The first part of the document aims at listing a set of use cases which would take benefits of the use of a unidirectional P2MP Pseudowire rather than multiple point to point Pseudowires. The second part describes the specific signaling requirements for the set up and maintenance of a P2MP PW. The requirements are divided into two parts, i.e. those applicable in a Single-Segment topology and those applicable in a Multi-Segment topology. For other aspects of P2MP PW implementation like packet processing, maintenance, etc, the document refers to [RFC3916]. Some P2MP PW requirements are derived from the signaling requirements for P2MP Traffic-Engineered MPLS Label Switched Paths [RFC4461]. Jounay et al. Expires August 26, 2007 [Page 3] Internet Draft P2MP PW Requirements February 2007 2. Definition 2.1. Acronyms P2P: Point-to-Point P2MP: Point-to-Multipoint PW: Pseudowire SS-PW: Single-Segment Pseudowire MS-PW: Multi-Segment Pseudowire 2.2. Terminology This document uses terminology described in [MS-PW REQ], [MS-PW ARCH], [SEG PW]. It also introduces additional terms needed in the context of unidirectional P2MP PW. P2MP PW, (also referred as PW Tree) Point-to-Multipoint Pseudowire. A PW attached to a source used to distribute L1/L2 format traffic to a set of one or more receivers (or leaves). The P2MP PW is unidirectional. P2MP SS-PW Point-to-Multipoint Single-Segment Pseudowire. A single segment P2MP PW set up between the PE attached to the source and the PEs attached to the receivers. The P2MP SS-PW relies on a P2MP LSP as PSN tunnel. P2MP MS-PW Point-to-Multipoint Multi-Segment Pseudowire. A multi-segment P2MP PW represents an End-to-End PW segmented by means of S-PEs which are in charge of switching the PW label. Each segment can rely on either P2P LSP or a P2MP LSP as PSN tunnel. Ingress PE P2MP PW Ingress Provider Edge. Router attached to a Customer Equipment (traffic source) via an Attachment Circuit (AC). In a MS-PW architecture the term used is Ingress T-PE. Egress PE P2MP PW Egress Provider Edge. Router attached to a set of on or more Customer Equipments (traffic receivers or leaves) via a set of one or Jounay et al. Expires August 26, 2007 [Page 4] Internet Draft P2MP PW Requirements February 2007 more Attachment Circuits (AC). In a MS-PW architecture the term used is Egress T-PE. Branch S-PE The branch S-PE is only defined and required in the context of MS-PW. The branch S-PE has one upstream PW segment and one or several downstream PW segments. 3. Use Cases for P2MP PW 3.1. TDM-based Use Case In a PSN environment, PWs allow supporting 2G/3G mobile backhauling (e.g. TDM traffic for GSM's Abis interface, ATM traffic for Release 99 UMTS's Iub interface). At the time being, the Mobile backhauling architecture is always built as a star topology between the 2G/3G controller (e.g. BSC or RNC) and the 2G/3G Base Stations (BTS or NodeB). Therefore P2P PWs are used between each Base Station and their corresponding controller and nothing more is required. As far as synchronization in a PSN environment is concerned, different mechanisms can be considered to provide frequency and phase clock required in the 2G/3G Mobile environment to guarantee mobile handover and strict QoS. One of them consists in using Adaptive Clock Distribution and Recovery. With this method a Master element distributes a reference clock at protocol level by regularly sending TDM PW packets (SAToP, CESoPSN or TDMoIP) to Slave elements. This process is based on the fact that the volume of transmitted data arrival is considered as an indication of the source frequency that could be used by the Slave element to recover the source clock frequency. Consequently, with the current methods, the PE connected to the Master must setup and maintain as many P2P PWs as we have Slave elements, and it has to replicate the traffic. A better solution to deliver the clock frequency would be to use a P2MP PW. This may scale much more than P2P PWs with regards to the forwarding plane at the Ingress PE since the traffic coming from the Master is no more replicated to the P2P PWs but only to the outgoing interface corresponding to the P2MP PW. It may ease the provisioning process since only one PW source endpoint must be configured at the Ingress PE. This alleviated provisioning process would be particularly appreciated for the introduction of new Base Stations. The main gain would be to avoid replication on the Ingress PE and hence save bandwidth consumed by the synchronization traffic which typically requires the highest level of QoS. This kind of traffic will be competing with equivalent QOS traffic like VoIP, that is why it is significant to save the slightest bandwidth. Jounay et al. Expires August 26, 2007 [Page 5] Internet Draft P2MP PW Requirements February 2007 3.2. ATM-based Use Case A use case of ATM-based P2MP PW could be to offer the capability for service providers to support IP multicast wholesale services over ATM in case the wholesale customer relies on ATM infrastructure. The PW P2MP alleviates the constraint in terms of replication for ATM to support IP multicast services. Today most video distribution networks require point-to-multipoint as well as point-to-point transport for live broadcasting and non-live contents distribution. As for point- to-multipoint traffic, there are some traditional approaches to convey it, for example, by ATM based duplication (point-to-multipoint PVP/PVCs). Terminal CE devices in such environment support legacy protocol interfaces only as such. However, the trend to migrate such an old network onto MPLS/IP-based backbone is still growing now. Hence it is expected that a standard Pseudo Wire setup/encapsulation method will support point-to-multipoint transport of various kinds of conventional protocols. 3.3. Ethernet-based Use Case 3.3.1. P2MP PW for VPLS The requirements for Multicast Support in VPLS is described in [VPLS MCAST REQ]. P2MP Pseudo wire might be able to be applied as an efficient PW forwarding mechanism for multicast VPLS. 3.3.2. P2MP PW for Ethernet-based VPWS VPLS supports only Ethernet service. If you need other protocols be natively transported in point-to-multipoint way, P2MP PW would be a candidate alternative. VPLS natively requires MAC-based learning and forwarding, however video distribution applications generally use a single tree like network topology, and do not require the added expense of MAC learning. VPLS natively connects multiple all CEs as default, but for some applications that provide just point-to-multipoint type transport, traffic from receiver to sender is not needed, and traffic between different receivers directly are not needed, either. In this case, P2MP PWS provides much simpler operation to it. Note that P2MP PW has a limitation in the point of its uni- directional service model. If the application layer needs bi- directional communication at CE, some additional techniques may be necessary to support. As mentioned above the use case related to Ethernet-based P2MP PW is particularly focused on VPWS which does not require features hold by the VSI (MAC learning, MAC forwarding) or auto-discovery procedures in VPLS. Jounay et al. Expires August 26, 2007 [Page 6] Internet Draft P2MP PW Requirements February 2007 The P2MP VPWS is typically a service required when a service provider wants to deliver in a cross-connect mode traffic from one endpoint to several endpoints. 4. P2MP SS-PW Requirements 4.1. P2MP SS-PW Reference Model Note: the P2MP SS-PW reference model presented in this document refers to the one defined in [PW MCAST]. The format differs only to get a common model for the P2MP SS-PW and P2MP MS-PW. 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 derived from [RFC3985] 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. Jounay et al. Expires August 26, 2007 [Page 7] Internet Draft P2MP PW Requirements February 2007 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. 4.2. P2MP SS-PW Underlying Layer The P2MP SS-PW implies an underlying P2MP PSN tunnel. Figure 2 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). Depending on the Traffic-Engineering requirements, the P2MP PSN will be signaled with P2MP RSVP-TE [P2MP RSVP-TE] or MLDP [MLDP]. i1 / / \ / \ / \ /\ \ / \ \ / \ \ / \ / \ e1 e2 e3 e4 Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW As described in 4.3.1 the PW label MUST be upstream assigned by the Ingress PE. When the Egress PE receives the upstream label, it MUST learn in meantime the associated context, i.e. the P2MP LSP on which the P2MP PW is setup. When the traffic is received at the Egress PE, the Egress PE MUST check the PW label but also the LSP label to determine the L2VPN to which the packet belongs to. To achieve the PHP (Penultimate Hop Popping) must be deactivated on the P2MP LSP. 4.3. P2MP SS-PW Signaling Requirements 4.3.1. P2MP SS-PW Setup Mechanisms The PW setup could be either leaf initiated or source initiated. Some P2MP application may request a dynamic tree setup with efficient provisioning procedure. In that case a source-initiated mode SHOULD be selected. Due to the underlying P2MP PSN tunnel, the PW label MUST be upstream assigned by the Ingress PE. 4.3.2. Leaf Grafting/Pruning Once the PW tree is setup, the solution MUST allow the addition or removal of a leaf, or a subset of leaves to/from the existing tree, Jounay et al. Expires August 26, 2007 [Page 8] Internet Draft P2MP PW Requirements February 2007 without any impact on the PW tree (data and control planes) for the remaining leaves. Such PW Tree leaf grafting/pruning could be source or leaf-initiated. 4.4. Failure Reporting and Processing Since the underlying layer has an End-to-End P2MP topology between the Ingress PE and the Egress PEs, the failure reporting and processing procedures are implemented only on the edge nodes. Failure events may cause one or more Egress PEs and associated leaves to become detached from the PW tree. These events MUST be reported to the Ingress PE, using appropriate in-band or out-band OAM messages. The solution SHOULD allow the Ingress PE to be informed of Egress PEs and associated leaves failure for management purposes. Based on these failure notifications the solution must allow the Ingress PE to update the remaining leaves of the PW tree. - A solution MUST support in-band OAM mechanism to detect failures: unidirectional point-to-multipoint traffic failure. - In case of failure, it SHOULD correctly report which leaf PEs are affected. It SHOULD be realized by enhancing existing unicast PW methods, such as VCCV for seamless and familiar operation. - A solution MAY support OAM message mapping at PE if failure happens i.e., mapping AC service OAM between P2MP PW OAM. (This needs more discussion) In addition it is assumed that if recovery procedures are required the P2MP LSP will support the classic recovery techniques mainly based on RSVP-TE. A mechanism should be implemented to avoid race conditions between recovery at the PSN level and recovery at the PW level. 4.5. Advertisement of P2MP Capability The solution should be completely backward compatible with the current PW standards. The solution should take into account the capability advertisement and negotiation procedures for the PEs implementing P2MP SS-PW endpoints. Implementation of OAM mechanisms also implies the advertisement of PE capabilities to support specific OAM features. The solution SHOULD allow advertising P2MP PW OAM capabilities. 4.6. Scalability Jounay et al. Expires August 26, 2007 [Page 9] Internet Draft P2MP PW Requirements February 2007 The solution should scale at least as well as linearly with an increase in the number of Egress PEs. The solution SHOULD provide a simple provisioning procedure to build a P2MP SS-PW. This is related to manageability not scalability. 4.7. Order of Magnitude This section will be filled in a future version. Number of Egress PE, TAII per Egress PE, dynamicity (Leaf Grafting/Pruning) required, etc. 5. P2MP MS-PW Requirements 5.1. P2MP MS-PW Pseudowire Reference Model Figure 3 describes the P2MP MS-PW reference model which is derived from [MS-PW ARCH] to support P2MP emulated services. |<-----------P2MP MS-PW------------>| Native | | Native Service | |<-PSN1-->| |<--PSN2->| | Service (AC) V V V V V V (AC) | +----+ +-----+ +----+ | | |T-PE| |S-PE |=========|T-PE| | +----+ | | 1 | | ......PW2......2.|-----------|CE2 | | | | | . |=========| | | +----+ | | | | . | +----+ | | | |=========| . | | | | | | . | +----+ | +----+ | | | | . |=========|T-PE| | +----+ |CE1 |---------|........PW1.........|...PW3......3.|-----------|CE3 | +----+ | | | | . |=========| | | +----+ | | | | . | +----+ | | | |=========| . | | | | | | . | +----+ | | | | | . |=========|T-PE| | +----+ | | | | . | .......4.|-----------|CE4 | | | | | . | . | | | +----+ | | | | ....PW4.. +----+ | | | | | | . +----+ | | | | | | . |T-PE| | +----+ | | | | | .......5.|-----------|CE5 | | | | | |=========| | | +----+ | +----+ +-----+ +----+ | Figure 3 P2MP MS-PW Reference Model Jounay et al. Expires August 26, 2007 [Page 10] Internet Draft P2MP PW Requirements February 2007 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. 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. In the reference model, the Egress T-PEs are assumed to be located in the same PSN (PSN2), but it could be envisioned that each output PW is located in a different PSN (PSN2, PSN3, PSN4). The S-PE plays the role of branch S-PE since it is in charge of switching simultaneously the input PW1 segment to the output PW2, PW3, PW4 segments. Note that a P2MP MS-PW may obviously transit through 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. However as we will see hereafter, the coexistence of both kind of PSN tunnel (P2P and P2MP) MUST be considered, as described in Figure 3 where the P2MP PW3 segment is supported over P2MP LSP. 5.2. P2MP MS-PW Underlying Layer Figure 4 describes an example of P2MP MS-PW topology relying on a combination of both P2P and P2MP LSPs as PSN tunnels. The PW tree is composed of one Ingress PE (i1) and several Egress PEs (e1, e2, e3, e4). The branch S-PEs are represented as b1, b2, b3, b4, b5. In that case the traffic replication along the path of the PW tree is performed at the PW level. For instance the branch S-PE b5 MUST replicate incoming packets or data received from b2 and send them to Egress T-PEs e3 and e4. However giving the fact that some PW segments may be supported over a P2MP LSP, the traffic replication along the path of these PW segments can be performed as well at the underlying LSP level. Figure 4 describes the case where each segment is supported over a P2P LSP except for the b1-b3 and b1-b4 segments which are conveyed over a P2MP LSP on this section. Jounay et al. Expires August 26, 2007 [Page 11] Internet Draft P2MP PW Requirements February 2007 i1 / \ b1 b2 / \ / \ /\ \ / \ \ b3 b4 b5 / \ / \ e1 e2 e3 e4 Figure 4 Example of P2P and P2MP underlying Layer for P2MP MS-PW Depending on the Traffic-Engineering requirements, the P2MP PSN may be signaled with P2MP RSVP-TE [P2MP-RSVP-TE or MLDP [MLDP]. As for the P2MP SS-PW and for the same purpose the PHP (Penultimate Hop Popping) must be deactivated on the P2MP LSP as described in 4.2. 5.3. P2MP MS-PW Signaling Requirements 5.3.1. PW Addresses Routing The PW tree could be statically configured at the T-PEs and each S-PE crossed. However it is RECOMMENDED to derive benefit from the use of PW addresses routing procedures (AII addressing used as reachability information) in order to allow dynamic PW tree setup based on principles described in [DYN MS-PW]. 5.3.2. P2MP MS-PW Setup Mechanisms The requirements described in this section assume that a PW addresses routing dissemination procedure allows to dynamically update each T-PE and S-PE PW addresses routing table. The P2MP MS-PW setup could be source or leaf-initiated. However it is RECOMMENDED that the solution provides various optimization options in the P2MP MS-PW construction (Traffic-Engineered P2MP MS-PW). Since a PW segment belonging to the P2MP MS-PW MAY be supported over a P2P LSP, the PW upstream label assignment mode is no longer mandatory. However it is RECOMMENDED to use this mode to be able to deal with configuration where P2MP LSP supports several PW segments. 5.3.3. Leaf Grafting/Pruning Once the PW tree is setup, the solution MUST allow the addition or removal of a leaf, or a subset of leaves to/from the existing tree, without any impact on the PW tree (data and control planes) for the remaining leaves. Jounay et al. Expires August 26, 2007 [Page 12] Internet Draft P2MP PW Requirements February 2007 5.3.4. Explicit Routing The P2MP MS-PW signaling solution MUST provide a means of establishing arbitrary P2MP MS-PW, according to pre-computed and configured S-PE paths as well as dynamically computed S-PE paths on the Ingress PE. To support setup of explicitly routed MS-PW tree, the signaling solution SHOULD support some source-based control that can explicitly define particular S-PE nodes as branch S-PEs for the PW tree. The solution SHOULD let possible Explicit Path Loose Hops (to be defined). Therefore the P2MP MS-PW MAY be partially specified with only a subset of intermediate branch S-PEs. 5.4. Failure Reporting The solution SHOULD rely on specific OAM mechanisms to detect a node (T-PE and S-PE) or segment failure of a PW tree. The solution SHOULD also support the ability to inform the Ingress T-PE of the failure as well as to indicate the identity of affected Egress T-PEs and associated leaves. Based on these failure notifications the solution MUST allow the Ingress T-PE to update the remaining Egress PEs and associated leaves of the PW tree. During the PW tree setup, a branch S-PE SHOULD be capable to inform the upstream PEs, including the Ingress T-PE that a set of Egress T- PEs and associated leaves are not reachable in accordance with the local PW addresses routing table. - A solution MUST support in-band OAM mechanism to detect failures: unidirectional point-to-multipoint traffic failure. - In case of failure, it SHOULD correctly report which leaf T-PEs and branch S-PEs are affected. It SHOULD be realized by enhancing existing unicast PW methods, such as VCCV for seamless and familiar operation. - A solution MAY support OAM message mapping at T-PE if failure happens i.e., mapping AC service OAM between P2MP PW OAM. (This needs more discussion) 5.5. Protection and Restoration The solution SHOULD provide mechanisms to recover as fast as possible following a failure event. The fast protection/recovery is typically dedicated to P2MP applications sensitive to traffic disruption. Jounay et al. Expires August 26, 2007 [Page 13] Internet Draft P2MP PW Requirements February 2007 Considering (i) a source-initiated PW tree setup and (ii) that a local repair (PSN-tunnel or PW segment-based) is not feasible after a failure event and that (iii) the PE upstream to the failure receives by means of OAM mechanisms a message indicating that a subset of Egress T-PEs are detached from the PW tree, the solution SHOULD allow the upstream PE to re-compute the path to those particular Egress T- PEs. If the upstream PE failed to compute an alternative path, the procedure SHOULD be propagated upstream until the Ingress-PE is reached. It is also assumed that recovery procedures can be implemented at the underlying P2P or P2MP LSP layer, using classic recovery techniques. These procedures could be used to provide faster recovery time in case of link or node failure affecting this layer. A mechanism should be implemented to avoid race conditions between recovery at the PSN level and recovery at the PW level. 5.6. Advertisement of P2MP Capability The solution should be completely backward compatible with the current PW standards. The solution should take into account the capability advertisement and negotiation procedures for the T-PEs implementing P2MP MS-PW endpoints and branch S-PEs. Implementation of OAM mechanisms also implies the advertisement of PE capabilities to support specific OAM features. The solution SHOULD allow advertising P2MP OAM PW capabilities. 5.7. Scalability In definition of solution for P2MP MS-PW a particular attention must dedicated to scalability. The solution MUST be designed to scale as well as linearly with an increase in the number of leaves, Egress T-PEs, branch S-PEs. The scalability issues MUST be addressed for the control plane (e.g. addressing of PW endpoints, number of signaling sessions, etc) and for data plane (e.g. duplication of PW segments, OAM mechanism, etc). 5.8. Order of Magnitude This section will be filled in a future version. Number of Egress T-PE per tree, TAII per Egress T-PE, S-PE crossed, replication supported per S-PE, dynamicity (Leaf Grafting/Pruning) required, etc. Jounay et al. Expires August 26, 2007 [Page 14] Internet Draft P2MP PW Requirements February 2007 6. Manageability considerations This section will be added in a future version. 7. Backward Compatibility This section will be added in a future version. 8. Security Considerations This section will be added in a future version. 9. IANA Considerations This draft does not define any new protocol element, and hence does not require any IANA action. 10. Acknowledgments The authors thank the contributors of [RFC4461] since the structure and content of this document were, for some sections, largely inspired by [RFC4461]. Many thanks to JL Le Roux and A. Cauvin for the discussions, comments and support. The authors would like to thank Matthew Bocci, Andy Malis for their valuable comments and suggestions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC3916] McPherson, D.,Pate, P., Xiao, X., "Requirements for Pseudo-Wire Emulation Edge-to-Edge", September 2004 [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 [RFC4461] Aggarwal, R., Farrel, A., Jork, M., Kamite, Y., Kullberg, A., Le Roux, JL., Malis, A., Papadimitriou, D., Vasseur, JP., Yasukawa, S., "Signaling Requirements for P2MP TE MPLS LSPs",April 2006 11.2. Informative References [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 Jounay et al. Expires August 26, 2007 [Page 15] Internet Draft P2MP PW Requirements February 2007 [MS-PW ARCH] Bocci, M., and Bryant, S.,T., " An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", Internet Draft, draft-ietf-pwe3-ms-pw-arch-02.txt, October 2006 [SEG PW] Martini et al, "Segmented Pseudo Wire", Internet Draft, draft-ietf-pwe3-segmented-pw-03.txt, October 2006 [VPLS MCAST REQ] Fang, L., Morin, T., Kamite, Y., Serbest, Y., "Requirements for Multicast Support in Virtual Private LAN Services", Internet Draft, draft-ietf-l2vpn-vpls- mcast-reqts-03.txt, Ocober 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 [PW MCAST] Dong, J., Yang, Y., Zhang, H., "Pseudowire for Supporting Multicast traffic", Internet Draft, draft- ietf-pwe3-pw-mcast-00.txt, February 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., Wijnands, I., Thomas, B., "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 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 Jounay et al. Expires August 26, 2007 [Page 16] Internet Draft P2MP PW Requirements February 2007 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 Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 EMail: lmartini@cisco.com Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK EMail: giles.heron@tellabs.com Simon Delord Uecomm 658 Church St Richmond, VIC, 3121, Australia E-mail: sdelord@uecomm.com.au Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway Email: lei.wang@telenor.com 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 Jounay et al. Expires August 26, 2007 [Page 17] Internet Draft P2MP PW Requirements February 2007 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 18]