idnits 2.17.1 draft-ietf-pwe3-p2mp-pw-requirements-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2014) is 3591 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Jounay, Ed. 3 Internet-Draft Orange CH 4 Category: Informational Y. Kamite, Ed. 5 Expires: December 20, 2014 NTT Communications 6 G. Heron 7 Cisco Systems 8 M. Bocci 9 Alcatel-Lucent 10 June 20, 2014 12 Requirements and Framework for Point-to-Multipoint Pseudowires 13 over MPLS Packet Switched Networks 15 draft-ietf-pwe3-p2mp-pw-requirements-10.txt 17 Abstract 19 This document presents a set of requirements and a framework for 20 providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet 21 Switched Networks. The requirements identified in this document are 22 related to architecture, signaling and maintenance aspects of Point- 23 to-Multipoint PW operation. They are proposed as guidelines for the 24 standardization of such mechanisms. Among other potential 25 applications, Point-to-Multipoint PWs can be used to optimize the 26 support of multicast layer 2 services (Virtual Private LAN Service 27 and Virtual Private Multicast Service). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 20, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document MUST 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction.....................................................3 63 1.1. Problem Statement........................................... 3 64 1.2. Scope of this document...................................... 3 65 1.3. Conventions used in this document........................... 4 66 2. Definition...................................................... 4 67 2.1. Acronyms.................................................... 4 68 2.2. Terminology ................................................ 4 69 3. P2MP PW Requirements.............................................5 70 3.1. Reference Model............................................. 5 71 3.2. P2MP PW and Underlying Layer ............................... 7 72 3.3. P2MP PW Construction........................................ 9 73 3.4. P2MP PW Signaling Requirements.............................. 9 74 3.4.1. PW Identifier........................................... 9 75 3.4.2. PW type mismatch ....................................... 9 76 3.4.3. Interface Parameters sub-TLV............................ 9 77 3.4.4. Leaf Grafting/Pruning ..................................10 78 3.4.5. Failure Detection and Reporting.........................10 79 3.4.6. Protection and Restoration..............................11 80 3.4.7. Scalability.............................................12 81 4. Backward Compatibility..........................................12 82 5. Security Considerations.........................................13 83 6. IANA Considerations.............................................13 84 7. Contributing Authors............................................13 85 8. Acknowledgments.................................................14 86 9. References......................................................15 87 9.1. Normative References........................................15 88 9.2. Informative References......................................15 90 1. Introduction 91 1.1. Problem Statement 93 As defined in the pseudowire architecture [RFC3985], a Pseudowire 94 (PW) is a mechanism that emulates the essential attributes of a 95 telecommunications service (such as a T1 leased line or Frame Relay) 96 over an IP or MPLS Packet Switched Network. It provides a single 97 service which is perceived by its user as an unshared link or circuit 98 of the chosen service. A Pseudowire is used to transport layer 1 or 99 layer 2 traffic (e.g. Ethernet, TDM, ATM, and FR) over a layer 3 PSN. 100 Pseudowire Emulation Edge-to-Edge (PWE3) operates "edge to edge" to 101 provide the required connectivity between the two endpoints of the 102 PW. 104 The Point-to-Multipoint (P2MP) topology described in 105 [I-D.ietf-l2vpn-vpms-frmwk-requirements] and required to provide P2MP 106 Layer2 VPN service can be achieved using one or more P2MP PWs. 107 The use of PW encapsulation enables P2MP services transporting layer1 108 or layer2 data. This could be achieved using a set of point to point 109 PWs, with traffic replication on the Provider Edge (PE), but at the 110 cost of bandwidth efficiency, as duplicate traffic would be carried 111 multiple times on shared links. 113 This document defines the requirements for a Point-to-Multipoint PW 114 (P2MP PW). A P2MP PW is a mechanism that emulates the essential 115 attributes of a P2MP telecommunications service such as a P2MP ATM 116 VC over a Packet Switch Networks. 117 The required functions of P2MP PWs include encapsulating 118 service-specific Protocol data Units (PDU) arriving at an ingress 119 Attachment Circuit (AC), and carrying them across a tunnel to one or 120 more egress ACs, managing their timing and order, and any other 121 operations required to emulate the behavior and characteristics of 122 the service as faithfully as possible. 124 1.2. Scope of this document 126 The document describes the general architecture of P2MP PW with 127 reference model, mentions the notion of data encapsulation, and 128 outlines specific requirements for the setup and maintenance of a 129 P2MP PW. In this document, the requirements focus on the Single- 130 Segment PW model. It is for further study how it should be realized 131 in Multi-Segment PW model. For other aspects of P2MP PW 132 implementation, such as packet processing (section 4) and 133 Faithfulness of Emulated Services (section 7), the document refers to 134 [RFC3916]. 136 1.3. Conventions used in this document 138 Although this is a requirements specification not a protocol 139 specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 140 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted to apply to 142 protocol solutions designed to meet these requirements as described 143 in [RFC2119] . 145 2. Definition 146 2.1. Acronyms 148 P2P: Point-to-Point 149 P2MP: Point-to-Multipoint 150 PW: Pseudowire 151 PSN: Packet Switched Network 152 SS-PW: Single-Segment Pseudowire 153 MS-PW: Multi-Segment Pseudowire 155 2.2. Terminology 157 This document uses terminology described in [RFC5659]. It also 158 introduces additional terms needed in the context of P2MP PW. 160 P2MP PW, (also referred as PW Tree): 161 Point-to-Multipoint Pseudowire. A PW attached to a source 162 Customer Edge (CE) used to distribute Layer1 or Layer2 traffic 163 to a set of one or more receiver CEs. The P2MP PW is 164 unidirectional (i.e., carrying traffic from Root PE to Leaf 165 PEs), and optionally supports a return path. 166 P2MP SS-PW: 167 Point-to-Multipoint Single-Segment Pseudowire. A single 168 segment P2MP PW set up between the Root PE attached to the 169 source CE and the Leaf PEs attached to the receiver CEs. The 170 P2MP SS-PW uses P2MP Label Switched Paths (LSP) as PSN tunnels. 171 The requirements in this document is targeted for SS-PW model. 172 Application of MS-PW (Multi-segment PW) model [RFC5254] is out 173 of scope and left for future work. 174 Root PE: 175 P2MP PW Root Provider Edge. The PE attached to the traffic 176 source CE for the P2MP PW via an Attachment Circuit (AC). 177 Leaf PE: 178 P2MP PW Leaf Provider Edge. A PE attached to a set of one or 179 more traffic receiver CEs, via ACs. The Leaf PE replicates 180 traffic to the CEs based on its Forwarder function [RFC3985]. 181 P2MP PSN Tunnel: 182 In the P2MP SS-PW topology, The PSN Tunnel is a general term 183 indicating a virtual P2MP connection between the Root PE and 184 the Leaf PEs. A P2MP tunnel may potentially carry multiple 185 P2MP PWs inside (aggregation). This document uses terminology 186 from the document describing the MPLS multicast architecture 187 [RFC5332] for MPLS PSN. 189 3. P2MP PW Requirements 191 3.1. Reference Model 193 As per the definition of [RFC3985], a pseudowire (PW) both originates 194 and terminates on the edge of the same packet switched network (PSN). 195 The PW label is unchanged between the originating and terminating 196 Provider Edges (PEs). This is also known as a single-segment 197 pseudowire (SS-PW), as the most fundamental network model of PWE3. 199 P2MP PW can be defined as Point-to-Multipoint connectivity from a 200 Root PE connected to a traffic source CE to one or more Leaf PEs 201 connected to traffic receiver CEs. It is considered to be an 202 extended architecture of the existing unicast-based SS-PW technology. 204 Figure 1 describes the P2MP reference model which is derived from 205 [RFC3985] to support P2MP emulated services. 207 |<-------------P2MP PW------------->| 208 Native | | Native 209 ROOT Service | |<----P2MP PSN tunnel --->| | Service LEAF 210 V (AC) V V V V (AC) V 211 | +----+ +-----+ +----+ | 212 | |PE1 | | P |=========|PE2 |AC2 | +----+ 213 | | | | ......PW1.......>|---------->|CE2 | 214 | | | | . |=========| | | +----+ 215 | | | | . | +----+ | 216 | | |=========| . | | 217 | | | | . | +----+ | 218 +----+ | AC1 | | | . |=========|PE3 |AC3 | +----+ 219 |CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 | 220 +----+ | | | | . |=========| | | +----+ 221 | | | | . | +----+ | 222 | | |=========| . | | 223 | | | | . | +----+AC4 | +----+ 224 | | | | . |=========|PE4 |---------->|CE4 | 225 | | | | ......PW1.......>| | +----+ 226 | | | | |=========| |AC5 | +----+ 227 | | | | | | |---------->|CE5 | 228 | +----+ +-----+ +----+ | +----+ 229 Figure 1 P2MP PW Reference Model 231 This architecture applies to the case where a P2MP PSN tunnel extends 232 between edge nodes of a single PSN domain to transport a 233 unidirectional P2MP PW with endpoints at these edge nodes. In this 234 model a single copy of each PW packet is sent over the PW on the P2MP 235 PSN tunnel and is received by all Leaf PEs due to the P2MP nature of 236 the PSN tunnel. The P2MP PW SHOULD be traffic optimized, i.e., only 237 one copy of a P2MP PW packet or PSN tunnel (underlying layer) is sent 238 on any single link along the P2MP path. P routers participate in P2MP 239 PSN tunnel operation but not in the signaling of P2MP PWs. 241 The Reference Model outlines the basic pieces of a P2MP PW. However, 242 several levels of replication needs to be considered when designing a 243 P2MP PW solution: 245 - Ingress PE replication to CEs: traffic is replicated to a set of 246 local receiver CEs 247 - P router replication in the core: traffic replicated by means of 248 P2MP PSN tunnel (P2MP LSP) 249 - Egress PE replication to CEs: traffic replicated to local receiver 250 CEs 252 Theoretically, it is also possible to consider Ingress PE replication 253 in the core; that is, all traffic is replicated to a set of P2P PSN 254 transport tunnels at ingress, not using P router replication at all. 256 However, this approach may easily lead to more than one-stream 257 bandwidth consumption at a single link, particularly if the PSN 258 tunnels logically go over the same physical link. Hence this 259 approach is not preferred. 261 Specific operations that MUST be performed at the PE on the native 262 data units are not described here since the required pre-processing 263 (Forwarder (FWRD) and Native Service Processing (NSP)) defined in 264 section 4.2 of [RFC3985] are also applicable to P2MP PW. 266 P2MP PWs are generally unidirectional, but a Root PE may need to 267 receive unidirectional P2P return traffic from any Leaf PE. For that 268 purpose the P2MP PW solution MAY support an optional return path from 269 each Leaf PE to Root PE. 271 3.2. P2MP PW and Underlying Layer 273 The definition of MPLS multicast encapsulation [RFC5332] specifies 274 the procedure to carry MPLS packets that are to be replicated and a 275 copy of the packet sent to each of the specified next hops. This 276 notion is also applicable to P2MP PW (as a MPLS) packet carried by a 277 P2MP PSN tunnel. 279 To be more precise, a P2MP PSN tunnel corresponds to a "point-to- 280 multipoint data link or tunnel" described in [RFC5332] Section 3. 281 Similarly, P2MP PW labels correspond to "the top labels (before 282 applying the data link or tunnel encapsulation) of all MPLS packets 283 that are transmitted on a particular point-to-multipoint data link or 284 tunnel." 286 In P2MP PW architecture, PW label with PW-PDU [RFC3985] is replicated 287 by underlying P2MP PSN tunnel layer in SS-PW network model. In other 288 words, it is intended to utilize PSN technology designed for 289 efficient multicast/broadcast transport. Note that PW label is 290 unchanged and hidden in switching by transit P routers as long as the 291 model of SS-PW is taken. 293 In a solution, a P2MP PW MUST be supported over a single P2MP PSN 294 tunnel as underlying layer of traffic distribution. Figure 2 gives 295 an example of P2MP PW topology relying on a single P2MP LSP. The 296 PW tree is composed of one Root PE (i1) and several Leaf PEs (e1, e2, 297 e3, e4). 298 The mechanisms for establishing the PSN tunnel are outside the scope 299 of this document, as long as they enable the essential attributes of 300 the service to be emulated. 302 i1 303 / 304 / \ 305 / \ 306 / \ 307 /\ \ 308 / \ \ 309 / \ \ 310 / \ / \ 311 e1 e2 e3 e4 313 Figure 2 Example of P2MP Underlying Layer for P2MP PW 315 A single P2MP PSN tunnel MUST be able to serve more than one P2MP PW 316 traffic in an aggregated way, i.e., multiplexing. 318 A P2MP PW solution MAY support different P2MP PSN tunneling 319 technology (e.g., MPLS over GRE [RFC4023], or P2MP MPLS LSP) or 320 different setup protocols. (e.g., MLDP [RFC6388], and P2MP RSVP-TE 321 [RFC4875]). 323 The P2MP LSP associated to the P2MP PW can be selected either by user 324 configuration or by dynamically using a multiplexing/demultiplexing 325 mechanism. 327 The P2MP PW multiplexing SHOULD be used based on the overlap rate 328 between P2MP LSP and P2MP PW. As an example, an existing P2MP LSP 329 may attach more leaves than the ones defined as Leaf PEs for a given 330 P2MP PW. It may be attractive to reuse it to minimize new 331 configuration, but using this P2MP LSP would imply non- 332 Leaf PEs (i.e. not part of the P2MP PW) to receive unwanted traffic. 334 Note: no special configuration is needed for non-Leaf PEs to drop 335 those unwanted traffic because they do not have forwarding 336 information entry unless they process corresponding P2MP PWs set-up 337 operation (e.g. signaling). 339 The operator SHOULD determine whether the P2MP PW can accept 340 partially multiplexing with P2MP LSP, and a minimum congruency rate 341 may be defined. The Root PE can determine whether P2MP PW can 342 multiplex to a P2MP LSP according to the congruency rate. The 343 congruency rate SHOULD take into account several items, such as: 345 - the amount of overlap between the number of Leaf PEs of P2MP PW 346 and existing egress PE routers of a P2MP LSP. If there is a 347 complete overlap, the congruency is perfect and the rate is 100%. 348 - at the expense of the additional traffic (e.g. other VPNs) 349 supported over the P2MP LSP. 351 With this procedure a P2MP PW is nested within a P2MP LSP. This 352 allows multiplexing several PWs over a common P2MP LSP. Prior to the 353 P2MP PW signaling phase, the Root PE determines which P2MP LSP will 354 be used for this P2MP PW. The PSN Tunnel can be an existing PSN 355 tunnel or the Root PE can create a new P2MP PSN tunnel. In addition, 356 if ideal congruency rate is desired, if the P2MP PW has one or more 357 extra leaf nodes that are not covered by the existing P2MP LSP, the 358 P2MP LSP SHOULD be modified or re-created to cover them. 360 3.3. P2MP PW Construction 362 [RFC5332] introduces two approaches to assign MPLS label (meaning PW 363 label in P2MP PW context): Upstream-Assigned[RFC5331] and 364 Downstream-Assigned. However, it is out of scope of this document 365 which one should be used in PW construction. It is left to the 366 specification of the solution work. 368 The following requirements apply to the establishment of P2MP PWs: 370 - PE nodes MUST be configurable with the P2MP PW identifiers and 371 ACs. 372 - A discovery mechanism SHOULD allow the Root PE to discover the 373 Leaf PEs, or vice versa. 374 - Solutions SHOULD allow single-sided operation at the Root PE for 375 the selection of some AC(s) at the Leaf PE(s) to be attached to 376 the PW tree so that the Root PE controls the Leaf attachment. 378 The Root PE SHOULD support a method to be informed about whether a 379 Leaf PE has successfully attached to the PW tree. 381 3.4. P2MP PW Signaling Requirements 383 3.4.1. P2MP PW Identifier 385 The P2MP PW MUST be uniquely identified. This unique P2MP PW 386 identifier MUST be used for all signaling procedures related to this 387 PW (PW setup, Monitoring, etc). 389 3.4.2. PW type mismatch 391 The Root PE and Leaf PEs of a P2MP PW MUST be configured with the 392 same PW type as defined in [RFC4446] for P2P PW. In case of a 393 different type, a PE SHOULD abort attempts to attach the Leaf PE to 394 the P2MP PW. 396 3.4.3. Interface Parameters sub-TLV 397 Some interface parameters [RFC4446] related to the AC capability have 398 been defined according to the PW type and are signaled during the PW 399 setup. 401 Where applicable, a solution is REQUIRED to ascertain whether the AC 402 at the Leaf PE is capable of supporting traffic coming from the AC at 403 the Root PE. 405 In case of a mismatch, the passive PE (Root or Leaf PE, depending on 406 the signaling process) SHOULD support mechanisms to reject attempts 407 to attach the Leaf PE to the P2MP PW. 409 3.4.4. Leaf Grafting/Pruning 411 Once the PW tree is established, the solution MUST allow the addition 412 or removal of a Leaf PE, or a subset of leaves to/from the existing 413 tree, without any impact on the PW tree (data and control planes) for 414 the remaining Leaf PEs. 416 The addition or removal of a Leaf PE MUST also allow the P2MP PSN 417 tunnel to be updated accordingly. This may cause the P2MP PSN tunnel 418 to add or remove the corresponding Leaf PE. 420 3.4.5. Failure Detection and Reporting 422 Since the underlying layer has an End-to-End P2MP topology between 423 the Root PE and the Leaf PEs, the failure reporting and processing 424 procedures are implemented only on the edge nodes. 426 Failure events may cause one or more Leaf PEs to become detached from 427 the PW tree. These events MUST be reported to the Root PE, using 428 appropriate out-of-band or inband Operations, Administration, and 429 Maintenance (OAM) messages for monitoring. 430 It MUST be possible for the operator to choose the out-of-band or 431 inband Monitoring tools or both to monitor the Leaf PE status. 432 The solution SHOULD allow the Root PE to be informed of Leaf PEs 433 failure for management purposes. 435 Based on these failure notifications, solutions MUST allow the Root 436 PE to update the remaining leaves of the PW tree. 438 - A solution MUST support in-band status notification mechanism 439 to detect failures: 440 unidirectional point-to-multipoint traffic failure. This MUST 441 be realized by enhancing existing unicast PW methods, such as VCCV 442 for seamless and familiar operation defined in [RFC5085]. 443 - In case of failure, it MUST correctly report which Leaf PEs are 444 affected. This MUST be realized by enhancing existing PW 445 methods, such as LDP Status Notification. The notification 446 message SHOULD include the type of fault (P2MP PW, AC or PSN 447 tunnel). 448 - A Leaf PE MAY be notified of the status of the Root PE's AC. 449 - A solution MUST support OAM message mapping [RFC6310] at the 450 Root PE and Leaf PE if a failure is detected on the source CE. 452 3.4.6. Protection and Restoration 454 It is assumed that if recovery procedures are required, the P2MP PSN 455 tunnel will support standard MPLS-based recovery techniques 456 (typically based on RSVP-TE). In that case a mechanism SHOULD be 457 implemented to avoid race conditions between recovery at the PSN 458 level and recovery at the PW level. 460 An alternative protection scheme MAY rely on the PW layer. 462 Leaf PEs MAY be protected via a P2MP PW redundancy mechanism. In the 463 example depicted below, a standby P2MP PW is used to protect the 464 active P2MP PW. In that protection scheme the AC at the Root PE MUST 465 serve both P2MP PWs. In this scenario, the condition when to do the 466 switchover SHOULD be implemented, e.g. one or all Leaf failure of 467 active P2MP PW will trigger the whole P2MP PW's switchover. 469 CE1 470 | 471 ROOT active PE1 standby 472 P2MP PW .../ \....P2MP PW 473 / \ 474 P2 P3 475 / \ / \ 476 / \ / \ 477 / \ / \ 478 LEAF PE4 PE5 PE6 PE7 479 | | | | 480 | \ / | 481 \ CE2 / 482 \ / 483 ------CE3----- 485 Figure 3: Example of P2MP PW redundancy for protecting Leaf PEs 487 Note that some of the nodes/links in this figure can be physically 488 shared, which depends on the service provider policy of network 489 redundancy. 491 The Root PE MAY be protected via a P2MP PW redundancy mechanism. In 492 the example depicted below, a standby P2MP PW is used to protect the 493 active P2MP. A single AC at the Leaf PE MUST be used to attach the 494 CE to the primary and the standby P2MP PW. The Leaf PE MUST support 495 protection mechanisms in order to select the active P2MP PW. 497 CE1 498 / \ 499 | | 500 ROOT active PE1 PE2 standby 501 P2MP PW1 | | P2MP PW2 502 | | 503 P2 P3 504 / \/ \ 505 / /\ \ 506 / / \ \ 507 / / \ \ 508 LEAF PE4 PE5 509 | | 510 CE2 CE3 511 Figure 4: Example of P2MP PW redundancy for protecting Root PEs 513 3.4.7. Scalability 515 The solution SHOULD scale at worst linearly for message size, memory 516 requirements, and processing requirements, with the number of 517 Leaf PEs. 518 Increasing the number of P2MP PWs between a Root PE and a given set 519 of Leaf PEs SHOULD NOT cause the P router to increase the number of 520 entries in its forwarding table by the same or greater proportion. 521 Multiplexing P2MP PWs to P2MP PSN Tunnels achieves this. 523 4. Backward Compatibility 525 Solutions MUST be backward compatible with current PW standards. 526 Solutions SHOULD utilize existing capability advertisement and 527 negotiation procedures for the PEs implementing P2MP PW endpoints. 529 The implementation of OAM mechanisms also implies the advertisement 530 of PE capabilities to support specific OAM features. 531 The solution MAY allow advertising P2MP PW OAM capabiltities. 532 A solution MUST NOT allow a P2MP PW to be established 533 to PEs that do not support P2MP PW functionality. It MUST have a 534 mechanism to report an error for incompatible PEs. 536 In some cases, upstream traffic is needed from downstream CEs to 537 upstream CEs. The P2MP PW solution SHOULD allow a return path (i.e. 538 from the Leaf to the Root) that provides upstream connectivity. 540 In particular, the same ACs MAY be shared between downstream and 541 upstream directions. For downstream, a CE receives traffic 542 originated by the Root PE over its AC. For upstream, the CE MAY also 543 send traffic destined to the same Root PE over the same AC. 545 5. Security Considerations 547 The security requirements common to PW are raised in Section 10 of 548 [RFC3916]. P2MP PW is a variant of the initial P2P PW definition, 549 and those requirements also apply to P2MP PW. The security 550 considerations from [RFC5920], [RFC3985] and [RFC6941] also apply 551 respectively to IP/MPLS and MPLS-TP deployment scenario. 552 Some issues specifically due to P2MP topology MUST be addressed in 553 the definition of the solution: 554 - The solution SHOULD provide means to guarantee the traffic delivery 555 to receivers (Integrity, Confidentially) 556 - The solution SHOULD support means to protect the P2MP PW as a whole 557 against attacks that would lead to any kind of denial-of-service. 558 Specifically, it would be desirable to consider safeguard mechanisms 559 to avoid any negative impact on the whole PW Tree under the attack 560 against its particular receiver(s). Considerations about both control 561 plane and data plane are necessary. 563 6.IANA Considerations 565 This document does not require any IANA action. 567 7. Contributing Authors 569 Philippe Niger 570 France Telecom 571 2, avenue Pierre-Marzin 572 22307 Lannion Cedex 573 France 575 Email: philippe.niger@orange-ftgroup.com 577 Luca Martini 578 Cisco Systems, Inc. 579 9155 East Nichols Avenue, Suite 400 580 Englewood, CO, 80112 582 EMail: lmartini@cisco.com 583 Lei Wang 584 Telenor 585 Snaroyveien 30 586 Fornebu 1331 587 Norway 589 Email: lei.wang@telenor.com 591 Rahul Aggarwal 592 Juniper Networks 593 1194 North Mathilda Ave. 594 Sunnyvale, CA 94089 596 Email: rahul@juniper.net 598 Simon Delord 599 Telstra 600 380 Flinders lane. Melbourne 602 Email: simon.delord@gmail.com 604 Martin Vigoureux 605 Alcatel-Lucent France 606 Route de Villejust 607 91620 Nozay 608 France 610 Email: martin.vigoureux@alcatel-lucent.fr 612 Lizhong Jin 613 ZTE Corporation 614 889, Bibo Road 615 Shanghai, 201203, China 617 Email: lizho.jin@gmail.com 619 8. Acknowledgments 621 The authors thank the following people: the authors of [RFC4461] 622 since the structure and content of this document were, for some 623 sections, largely inspired by [RFC4461], JL Le Roux and A. Cauvin 624 for the discussions, comments and support, Adrian Farrel for 625 his Routing Area Director review, and IESG reviewers. 627 9. References 629 9.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC2119, March 1997. 634 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 635 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 636 September 2004. 638 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 639 Edge (PWE3) Architecture", RFC 3985, March 2005. 641 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 642 Multicast Encapsulations", RFC 5332, August 2008. 644 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 645 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 646 October 2009. 648 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 649 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 651 [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., 652 Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, 653 Administration, and Maintenance (OAM) Message Mapping", 654 RFC 6310, July 2011. 656 9.2. Informative References 658 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 659 Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., 660 and L. Jin, "Framework and Requirements for Virtual 661 Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms- 662 frmwk-requirements-05 (work in progress), October 2012. 664 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 665 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 666 4023, March 2005. 668 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 669 Multipoint Traffic-Engineered MPLS Label Switched Paths 670 (LSPs)", RFC 4461, April 2006. 672 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 673 "Extensions to Resource Reservation Protocol - Traffic 674 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 675 Switched Paths (LSPs)", RFC 4875, May 2007. 677 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 678 Connectivity Verification (VCCV): A Control Channel for 679 Pseudowires", RFC 5085, December 2007. 681 [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for 682 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", 683 RFC 5254, October 2008. 685 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 686 Label Assignment and Context-Specific Label Space", RFC 687 5331, August 2008. 689 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 690 "Label Distribution Protocol Extensions for Point-to- 691 Multipoint and Multipoint-to-Multipoint Label Switched 692 Paths", RFC 6388, November 2011. 694 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 695 Networks", RFC 5920, July 2010. 697 [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., Graveman, R., 698 "MPLS Transport Profile (MPLS-TP) Security Framework", 699 RFC 6941, April 2013. 701 Authors' Addresses 703 Frederic Jounay (editor) 704 Orange CH 705 4 rue caudray 1020 Renens 706 Switzerland 708 Email: frederic.jounay@orange.ch 710 Yuji Kamite (editor) 711 NTT Communications Corporation 712 Granpark Tower 713 3-4-1 Shibaura, Minato-ku 714 Tokyo 108-8118 715 Japan 717 Email: y.kamite@ntt.com 718 Giles Heron 719 Cisco Systems, Inc. 720 9 New Square 721 Bedfont Lakes 722 Feltham 723 Middlesex 724 TW14 8HA 725 United Kingdom 727 Email: giheron@cisco.com 729 Matthew Bocci 730 Alcatel-Lucent Telecom Ltd 731 Voyager Place 732 Shoppenhangers Road 733 Maidenhead 734 Berks 735 United Kingdom 737 Email: matthew.bocci@alcatel-lucent.co.uk 739 This document may contain material from IETF Documents or IETF 740 Contributions published or made publicly available before 741 November 10, 2008. The person(s) controlling the copyright in 742 some of this material may not have granted the IETF Trust the 743 right to allow modifications of such material outside the IETF 744 Standards Process. Without obtaining an adequate license from the 745 person(s) controlling the copyright in such materials, this 746 document may not be modified outside the IETF Standards Process, 747 and derivative works of it may not be created outside the IETF 748 Standards Process, except to format it for publication as an RFC 749 or to translate it into languages other than English.