idnits 2.17.00 (12 Aug 2021) /tmp/idnits40045/draft-ietf-pwe3-p2mp-pw-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (August 18, 2010) is 4293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-mpls-ldp-p2mp has been published as RFC 6388 == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-vpms-frmwk-requirements-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 P. Niger 4 Category: Informational France Telecom Orange 5 Expires: January 2011 6 Y. Kamite 7 L. Martini NTT Communications 8 Cisco 9 S. Delord 10 R. Aggarwal Testra 11 Juniper Networks 12 L. Wang 13 M. Bocci Telenor 14 M. Vigoureux 15 Alcatel-Lucent G. Heron 16 BT 17 L. Jin 18 ZTE August 18, 2010 20 Requirements for Point-to-Multipoint Pseudowire 22 draft-ietf-pwe3-p2mp-pw-requirements-03.txt 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on January, 2011. 46 Abstract 48 This document presents a set of requirements for providing a Point- 49 to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The 50 requirements identified in this document are related to architecture, 51 signaling and maintenance aspects of a Point-to-Multipoint PW 52 operation. They are proposed as guidelines for the standardization of 53 such mechanisms. Among other potential applications Point-to- 54 Multipoint PWs SHOULD be used to optimize the support of multicast 55 services (Virtual Private LAN Service and Virtual Private Multicast 56 Service) as defined in the Layer 2 Virtual Private Network working 57 group. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 Table of Contents 67 1. Introduction....................................................3 68 1.1. Problem Statement.............................................3 69 1.2. Scope of the document.........................................4 70 2. Definition......................................................4 71 2.1. Acronyms......................................................4 72 2.2. Terminology...................................................4 73 3. P2MP SS-PW Requirements.........................................5 74 3.1. P2MP SS-PW Reference Model....................................5 75 3.2. P2MP SS-PW Underlying Layer...................................7 76 3.3. P2MP SS-PW Construction.......................................8 77 3.4. P2MP SS-PW Signaling Requirements.............................8 78 3.4.1. PW Identifier...............................................8 79 3.4.2. PW type mismatch............................................8 80 3.4.3. Interface Parameters sub-TLV................................8 81 3.4.4. Leaf Grafting/Pruning.......................................9 82 3.5. Failure Detection and Reporting...............................9 83 3.6. Protection and Restoration....................................9 84 3.7. Scalability..................................................11 85 4. P2MP MS-PW Requirements........................................11 86 4.1. P2MP MS-PW Pseudowire Reference Model........................11 87 4.2. P2MP SS-PW Underlying Layer..................................12 88 4.3. P2MP MS-PW Signaling Requirements............................13 89 4.3.1. Dynamically Instantiated P2MP MS-PW........................13 90 4.3.2. P2MP MS-PW Setup Mechanisms................................13 91 4.3.3. PW type mismatch...........................................13 92 4.3.4. Interface Parameters sub-TLV...............................13 93 4.3.5. Leaf Grafting/Pruning......................................14 94 4.3.6. Explicit Routing...........................................14 95 4.4. Failure Detection and Reporting..............................14 96 4.5. Protection and Restoration...................................15 97 4.6. Scalability..................................................15 98 5. Manageability considerations...................................15 99 6. Backward Compatibility.........................................16 100 7. Security Considerations........................................16 101 8. IANA Considerations............................................16 102 9. Acknowledgments................................................16 103 10. References....................................................17 104 10.1. Normative References........................................17 105 10.2. Informative References......................................17 106 Authors' Addresses............ ...................................18 107 Copyright and Licence Notice.. ...................................19 109 1. Introduction 111 1.1. Problem Statement 113 As defined in the PWE3 WG charter, a Pseudowire (PW) emulates a 114 point-to-point bidirectional link over an IP/MPLS network, and 115 provides a single service which is perceived by its user as an 116 unshared link or circuit of the chosen service. A Pseudowire is used 117 to transport non IP traffic (e.g. Ethernet, TDM, ATM, and FR) in an 118 IP/MPLS-based PSN (Packet Switched Network). PWE3 operates "edge to 119 edge" to provide the required connectivity between the two endpoints 120 of the PW. 122 The P2MP topology mentioned in [VPMS REQ] and required to provide 123 P2MP L2VPN services can be achieved via a P2MP PW. The use of PW 124 becomes necessary for some P2MP services requiring specific 125 encapsulation capabilities. This could be achieved using a set of 126 point to point PWs, with traffic replication on the PE, but faces 127 obvious bandwidth limitation issues, as traffic is carried multiple 128 time on shared links. 130 This document defines the requirements for the use of a Point-to- 131 Multipoint PW (P2MP PW). A Point-to-Multipoint (P2MP) Pseudowire (PW) 132 is a mechanism that emulates the essential attributes of a P2MP 133 Telecommunications service such as P2MP ATM over PSN. One of the 134 applicabilities of a P2MP PW is to deliver a non-IP multicast service 135 that carries multicast frames from a multicast source to one or more 136 multicast receivers. The required functions of P2MP PWs include 137 encapsulating service-specific PDUs arriving at an ingress Attachment 138 Circuit (AC), and carrying them across a tunnel to one or more egress 139 ACs, managing their timing and order, and any other operations 140 required to emulate the behavior and characteristics of the service 141 as faithfully as possible. 143 P2MP PWs extend the PWE3 architecture [RFC3985] to offer a P2MP 144 Telecommunications service. 145 This document aims at defining the associated requirements related to 146 the P2MP PW operation (e.g. setup and maintenance, protection, 147 scalability). 149 1.2. Scope of the document 151 The document describes the P2MP PW Reference Model architectures and 152 outlines specific signaling requirements for the set up and 153 maintenance of a P2MP PW. The requirements are divided into two 154 parts, i.e. those applicable in a Single-Segment topology and those 155 applicable in a Multi-Segment topology. For other aspects of P2MP PW 156 implementation like packet processing (section 4) and Faithfulness of 157 Emulated Services (section 7), the document refers to [RFC3916]. 159 Some P2MP PW requirements are derived from the signaling requirements 160 for P2MP Traffic-Engineered MPLS Label Switched Paths [RFC4461]. 162 2. Definition 164 2.1. Acronyms 166 P2P: Point-to-Point 168 P2MP: Point-to-Multipoint 170 PW: Pseudowire 172 SS-PW: Single-Segment Pseudowire 174 MS-PW: Multi-Segment Pseudowire 176 2.2. Terminology 178 This document uses terminology described in [RFC5254], [RFC5659]. 180 It also introduces additional terms needed in the context of P2MP PW. 182 P2MP PW, (also referred as PW Tree) 184 Point-to-Multipoint Pseudowire. A PW attached to a source used to 185 distribute L1/L2 format traffic to a set of one or more receivers (or 186 leaves). The P2MP PW is unidirectional and optionally bidirectional. 188 P2MP SS-PW 190 Point-to-Multipoint Single-Segment Pseudowire. A single segment P2MP 191 PW set up between the PE attached to the source and the PEs attached 192 to the receivers. The P2MP SS-PW relies on P2MP LSP as PSN tunnel. 194 P2MP MS-PW 196 Point-to-Multipoint Multi-Segment Pseudowire. A multi-segment P2MP PW 197 represents an End-to-End PW segmented by means of S-PEs which are in 198 charge of switching the PW label. Each segment can rely on either 199 P2P LSP or P2MP LSP as PSN tunnel. 201 Root PE 203 P2MP PW Root Provider Edge. Router attached to a Customer Equipment 204 (traffic source) via an Attachment Circuit (AC). In a MS-PW 205 architecture the term used is Root T-PE. 207 Leaf PE 209 P2MP PW Leaf Provider Edge. Router attached to a set of one or more 210 Customer Equipments (traffic receivers or leaves). The P2MP PW is 211 attached to an Attachment Circuit (AC). The Leaf PE is therefore in 212 charge of replicating the traffic over the CEs based on its Forwarder 213 function [RFC3985]. 215 Branch S-PE 217 The Branch S-PE is only defined and required in the context of MS-PW. 218 The Branch S-PE has one upstream PW (P2P or P2MP) segment and one or 219 several downstream PW (P2P or P2MP) segments. 221 P2MP PSN Tunnel 223 In the P2MP SS-PW topology, The PSN Tunnel is a general term 224 indicating a virtual P2MP connection between the Root PE and the Leaf 225 PEs. A P2MP tunnel may potentially carry multiple P2MP PWs inside 226 (aggregation). This document uses terminology from the document 227 describing the MPLS multicast architecture [RFC5332] for MPLS PSN. 229 3. P2MP SS-PW Requirements 231 3.1. P2MP SS-PW Reference Model 233 A P2MP SS-PW provides a Point-to-Multipoint connectivity from a Root 234 PE connected to a traffic source to at least two Leaf PEs connected 235 to traffic receivers. The PW endpoints connect the PW to its 236 Attachment Circuit (AC). As for a P2P PW, an AC can be a Frame Relay 237 DLC, an ATM VP/VC, an Ethernet port, a VLAN, a HDLC link on a 238 physical interface. 240 Figure 1 describes the P2MP SS-PW reference model which is derived 241 from [RFC3985] to support P2MP emulated services. 243 |<-----------P2MP SS-PW------------>| 244 Native | | Native 245 Service | |<----P2MP PSN tunnel --->| | Service 246 (AC) V V V V (AC) 247 | +----+ +-----+ +----+ | 248 | |PE1 | | P |=========|PE2 |AC2 | +----+ 249 | | | | ......PW1.......>|---------->|CE2 | 250 | | | | . |=========| | | +----+ 251 | | | | . | +----+ | 252 | | |=========| . | | 253 | | | | . | +----+ | 254 +----+ | AC1 | | | . |=========|PE3 |AC3 | +----+ 255 |CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 | 256 +----+ | | | | . |=========| | | +----+ 257 | | | | . | +----+ | 258 | | |=========| . | | 259 | | | | . | +----+ | 260 | | | | . |=========|PE4 |AC4 | +----+ 261 | | | | ......PW1.......>|---------->|CE4 | 262 | | | | |=========| | | +----+ 263 | +----+ +-----+ +----+ | 265 Figure 1 P2MP SS-PW Reference Model 267 This architecture applies to the case where a P2MP PSN tunnel extends 268 between edge nodes of a single PSN domain to transport a 269 unidirectional P2MP PW with endpoints at these edge nodes. 270 In this model a single copy of each PW packet is sent over the P2MP 271 PSN tunnel and is received by all Leaf PEs due to the P2MP nature of 272 the PSN tunnel. P2MP PW MUST be traffic optimised, only one copy of 273 P2MP PW packet on one single link. P Router is joining P2MP PSN 274 tunnel operation but is not participating in the signaling of P2MP 275 PW. P2MP PW operation is associated with PE1, PE2, PE3 and PE4. 277 Specifics operations that must be perfomed at the PE on the native 278 data units are not described here since the required pre-processing 279 (Forwarder (FWRD) and Native Service Processing (NSP)) defined in the 280 section 4.2 [RFC3985] are also applicable to P2MP PW. 282 In nature the P2MP PW is unidirectional, but it may be required for a 283 Root PE to receive unidirectional P2P traffic from any Leaf PE. For 284 that purpose the P2MP PW MAY support OPTIONAL bidirectional 285 connectivity between the Root PE and each Leaf PE 286 - Downstream: Point-to-Multipoint (Root PE to any Leaf PE) 287 - Upstream: Point-to-Point (any Leaf PE to Root PE) 289 3.2. P2MP SS-PW Underlying Layer 291 The P2MP SS-PW implies an underlying P2MP PSN tunnel. Figure 2 gives 292 an example of P2MP SS-PW topology relying on a P2MP LSP. The PW tree 293 is composed of one Root PE (i1) and several Leaf PEs (e1, e2, e3, 294 e4). 296 The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP 297 [MLDP]. 299 i1 300 / 301 / \ 302 / \ 303 / \ 304 /\ \ 305 / \ \ 306 / \ \ 307 / \ / \ 308 e1 e2 e3 e4 310 Figure 2 Example of P2MP Underlying Layer for P2MP SS-PW 312 The P2MP PW MAY be supported over multiple P2MP PSN tunnel. These 313 P2MP PSN tunnels MUST be able to serve more than one P2MP PW. 315 The P2MP Tunnels MAY also be of different technology (ex. MPLS over 316 GRE, or P-to-MP MPLS LSP ) or just use different setup protocols. 317 (ex. MLDP, and P2MP RSVP-TE ). 319 The P2MP LSP associated to the P2MP PW can be selected either by user 320 configuration or by dynamically using the multiplexing/demultiplexing 321 mechanism. 323 The P2MP PW multiplexing will be based on the overlap rate between 324 P2MP LSP and P2MP PW. The operator should determine whether the P2MP 325 PW can accept partially multiplexing with P2MP LSP, and a minimum 326 congruency rate may be defined. The congruency rate reflects the 327 amount of overlap in the Leaf PE of P2MP PW that is multiplexed to a 328 P2MP LSP. If there is a complete overlap, the congruency is perfect 329 and the rate is 100%. The Root PE can determine whether P2MP PW can 330 multiplex to a P2MP LSP according to the congruency rate. It is also 331 possible to extend P2MP LSP to do P2MP PW multiplexing, but this will 332 reduce the current congruency rate that the P2MP PW is currently 333 taken. The multiplexing should ensure that the P2MP PW congruency 334 that is currently taken under P2MP LSP should be larger than minimum 335 congruency that is configured. 337 With this procedure a P2MP PW is nested within a P2MP LSP. This 338 allows multiplexing several PWs over a common P2MP LSP. Prior to the 339 P2MP PW signaling phase, the Root PE MUST determine which P2MP LSP 340 will be used for this P2MP PW. The PSN Tunnel can be an existing PSN 341 tunnel or the Root PE can create a new P2MP PSN tunnel. 343 3.3. P2MP SS-PW Construction 345 As initial step PE nodes have to be configured with P2MP PW 346 identifier and ACs. 347 Then discovery mechanism SHOULD allow PE to discover remote PEs 348 configuration. 349 Eventually the solution SHOULD allow single-sided operation at the 350 Root PE for the selection of some AC(s) at the Leaf PE(s) to be 351 attached to the PW tree so that the Root PE controls the Leaf 352 attachment. 353 Note that the Root PE single sided operation is a management 354 requirement and does not presume any signaling requirement. 356 The Root PE SHOULD support a method to be informed about the Leaf PE 357 successfully attached to the PW tree. 359 3.4. P2MP SS-PW Signaling Requirements 361 3.4.1. PW Identifier 363 The P2MP PW MUST be uniquely identified. This unique P2MP PW 364 identifier MUST be used for all the signaling procedure related to 365 this PW (PW setup, monitoring). 367 3.4.2. PW type mismatch 369 As for P2P PW, the ACs configured at Root PE and Leaf PEs of a P2MP 370 PW MUST be of the same PW type [RFC4446]. In case of a different 371 type, the passive PE (Root or Leaf PE, depending on the signaling 372 process) MUST support mechanisms to reject attempts to establish the 373 P2MP PW. 375 3.4.3. Interface Parameters sub-TLV 377 Some interface parameters [RFC4446] related to the AC capability have 378 been defined according to the PW type and are signaled during the PW 379 setup. 380 When applicable, this mechanism used for the P2P PW setup MUST be 381 enhanced for P2MP PW setup so as to ascertain that AC at the Leaf PE 382 is capable to support traffic coming from AC at the Root PE. 384 In case of mismatch, the passive PE (Ingress or Leaf PE, depending on 385 the signaling process) MUST support mechanisms to reject attempts to 386 establish the P2MP SS-PW. 388 3.4.4. Leaf Grafting/Pruning 390 Once the PW tree is setup, the solution MUST allow the addition or 391 removal of a Leaf PE, or a subset of leaves to/from the existing 392 tree, without any impact on the PW tree (data and control planes) for 393 the remaining leaf PEs. 394 The addition or removal of a Leaf PE MUST also allow to the P2MP PSN 395 tunnel to be updated accordingly. This MAY cause P2MP PSN tunnel to 396 add or remove the corresponding Leaf PE. 398 3.5. Failure Detection and Reporting 400 Since the underlying layer has an End-to-End P2MP topology between 401 the Root PE and the Leaf PEs, the failure reporting and processing 402 procedures are implemented only on the edge nodes. 404 Failure events MAY cause one or more Leaf PEs to become detached from 405 the PW tree. These events MUST be reported to the Root PE, using 406 appropriate out-band or inband OAM messages. 407 The solution SHOULD allow the Root PE to be informed of Leaf PEs 408 failure for management purposes. 410 Based on these failure notifications the solution MUST allow the Root 411 PE to update the remaining leaves of the PW tree. 413 - A solution MUST support in-band OAM mechanism to detect failures: 414 unidirectional point-to-multipoint traffic failure. This SHOULD be 415 realized by enhancing existing unicast PW methods, such as VCCV for 416 seamless and familiar operation. 418 - In case of failure, it SHOULD correctly report which Leaf PEs are 419 affected. This SHOULD be realized by enhancing existing PW methods, 420 such as LDP Notification for seamless and familiar operation. The 421 notification message SHOULD include the type of fault (P2MP PW, AC or 422 PSN tunnel). 424 - Respectively a Leaf PE also MAY receive the status of the Root PE's 425 AC status. 427 - A solution MUST support OAM message mapping at the Root PE if 428 failure is detected on the AC. The Leaf PE MUST report accordingly at 429 the service layer this OAM message on its associated AC. 431 3.6. Protection and Restoration 433 It is assumed that if recovery procedures are required the P2MP PSN 434 tunnel will support standard MPLS-based recovery techniques 435 (typically based on RSVP-TE). In that case a mechanism SHOULD be 436 implemented to avoid race conditions between recovery at the PSN 437 level and recovery at the PW level. 439 An alternative protection scheme MAY rely on the PW layer. 441 Leaf PEs MAY be protected via a P2MP PW redundancy mechanism. In the 442 example depicted below, a standby P2MP PW is used to protect the 443 active P2MP. In that protection scheme the AC at the Root PE MUST 444 serve both P2MP PWs. In this scenario, the condition when to do the 445 switchover should be implemented, e.g. one or all Leaf failure of 446 active P2MP PW will course P2MP PW switchover. 448 CE1 449 | 450 active PE1 standby 451 P2MP PW .../ \....P2MP PW 452 / \ 453 P2 P3 454 / \ / \ 455 / \ / \ 456 / \ / \ 457 PE4 PE5 PE6 PE7 458 | | | | 459 | \ / | 460 \ CE2 / 461 \ / 462 -------CE3------ 464 Root PE MAY be protected via a P2MP PW redundancy mechanism. In the 465 example depicted below, a standby P2MP PW is used to protect the 466 active P2MP. A single AC at the Leaf PE MUST be used to attach the CE 467 to the primary and the standby P2MP PW. The Leaf PE MUST support 468 protection mechanism in order to select the active P2MP PW. 470 CE1 471 / \ 472 | | 473 active PE1 PE2 standby 474 P2MP PW1 | | P2MP PW2 475 | | 476 P2 P3 477 / \/ \ 478 / /\ \ 479 / / \ _\ 480 / / \ \ 481 PE4 PE5 482 | | 483 CE2 CE3 485 3.7. Scalability 487 The solution SHOULD scale at least as well as linearly with an 488 increase in the number of Leaf PEs. 490 An increase in the number of P2MP PW SHOULD NOT cause the P router to 491 increase its forwarding table linearly. 493 The P2MP PW multiplexed/demultiplexed to P2MP PSN Tunnel can improve 494 the scalability. 496 4. P2MP MS-PW Requirements 498 4.1. P2MP MS-PW Pseudowire Reference Model 500 Figure 3 describes the P2MP MS-PW reference model which is derived 501 from [RFC5659] to support P2MP emulated services. 503 |<-----------P2MP MS-PW------------>| 504 Native | | Native 505 Service | |<-PSN1-->| |<--PSN2->| | Service 506 (AC) V V V V V V (AC) 507 | +----+ +-----+ +----+ | 508 | |T-PE| |S-PE1|=========|T-PE| | +----+ 509 | | 1 | | ......PW2.....> 2|---------->|CE2 | 510 | | | | . |=========| | | +----+ 511 | | |=========| . | +----+ | 512 | | | .....> | | 513 | | | . | . | +----+ | 514 | | | . | . |=========|T-PE| | +----+ 515 | | | . | ......PW3.....> 3|---------->|CE3 | 516 | | | . | |=========| | | +----+ 517 | | | . | | +----+ | 518 +----+ | | | . +-----+ 519 |CE1 |-------->|.......PW1... +-----+ +----+ | 520 +----+ | | | . |S-PE2|=========|T-PE| | +----+ 521 | | | . | | ......> 4|---------->|CE4 | 522 | | | . | | . | | | +----+ 523 | | | . | | . +----+ | 524 | | | ......>...PW4.. | 525 | | | | | . +----+ | 526 | | |=========| | . |T-PE| | +----+ 527 | | | | | ......> 5|---------->|CE5 | 528 | | | | |=========| | | +----+ 529 | | | | | +----+ | 530 | +----+ +-----+ | 532 Figure 3 P2MP MS-PW Reference Model 534 Figure 3 extends the P2MP SS-PW architecture of Figure 1 to a multi- 535 segment configuration. In a P2P MS-PW configuration as described in 536 [RFC5254] the S-PE is responsible to switch a MS-PW from one input 537 segment to only one output segment, based on the PW identifier. Here 538 in a P2MP MS-PW configuration the S-PE is responsible to switch a MS- 539 PW from one input segment to one or several output segments. 541 Referring to Figure 3 T-PE1 is the Root T-PE and T-PE2, T-PE3, T-PE4 542 and T-PE5 are the Leaf T-PEs. In the reference model, the Leaf T-PEs 543 are assumed to be located in the same PSN (PSN2), but it could be 544 envisioned that each output PW is located in a different PSN (PSN2, 545 PSN3, PSN4). The S-PE plays the role of Branch S-PE since S-PE1 and 546 S-PE are in charge respectively of switching simultaneously the input 547 P2MP PW1 segment to the output P2P PW2, P2P PW3 and P2MP PW4 548 segments. 550 A P2MP MS-PW MAY obviously transit through more than one S-PE along 551 its path. 553 As depicted in the Figure 3 a PW segment belonging to a P2MP MS-PW 554 can also be supported over a P2MP PSN tunnel or a P2P PSN tunnel. 556 4.2. P2MP SS-PW Underlying Layer 558 Figure 4 describes an example of P2MP MS-PW topology relying on a 559 combination of both P2P and P2MP LSPs as PSN tunnels. PW segment over 560 P2P LSP MAY address inter-provider requirement. The PW tree is 561 composed of one Root PE (i1) and several Leaf PEs (e1, e2, e3, e4). 562 The Branch S-PEs are represented as b1, b2, b3, b4, b5. In that case 563 the traffic replication along the path of the PW tree is performed at 564 the PW level. For instance the Branch S-PE b5 MUST replicate incoming 565 packets or data received from b2 and send them to Leaf T-PEs e3 and 566 e4. 568 However giving the fact that some PW segments MAY be supported over a 569 P2MP LSP, the traffic replication along the path of these PW segments 570 can be performed as well at the underlying LSP level. 572 Figure 4 describes the case where each segment is supported over a 573 P2P LSP except for the b1-b3b4 P2MP segment which is conveyed over a 574 P2MP LSP on this section. 575 i1 576 / \ 577 b1 b2 578 / \ 579 / \ 580 /\ \ 581 / \ \ 582 b3 b4 b5 583 / \ / \ 584 e1 e2 e3 e4 585 Figure 4 Example of P2P and P2MP underlying Layer for P2MP MS-PW 587 The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP 588 [MLDP]. 590 4.3. P2MP MS-PW Signaling Requirements 592 4.3.1. Dynamically Instantiated P2MP MS-PW 594 The PW tree could be statically configured at the T-PEs and each S-PE 595 crossed. However it is RECOMMENDED that a solution provides the 596 ability to dynamically setup a MS-PW tree, by allowing the MS-PW 597 segments to be dynamically discovered. 599 During the PW tree setup, a Branch S-PE SHOULD be capable to inform 600 the upstream PEs, including the Root T-PE that a set of Leaf T-PEs 601 and associated leaves are not reachable. 603 4.3.2. P2MP MS-PW Setup Mechanisms 605 The requirements described in this section assume that dynamic setup 606 of MS-PW segments allows the T-PE and S-PEs to dynamically signal MS- 607 PW segments and stitch these segments in order to build the MS-PW 608 tree. 610 4.3.3. PW type mismatch 612 As described for P2MP SS-PW, the P2MP MS-PW requires ACs of the same 613 PW type. Therefore the segments composing the P2MP MS-PW MUST be also 614 of the same PW type [RFC4446]. The S-PE MAY only support switching 615 PWs of the same PW type. In case of a different type, the passive PE 616 (S-PE or T-PE) MUST support mechanisms to reject attempts to 617 establish the P2MP MS-PW. 619 4.3.4. Interface Parameters sub-TLV 621 The section 3.4.3 is also relevant to P2MP MS-PW. When applicable, 622 the Leaf T-PE or the Root T-PE MUST signal respectively its AC' 623 interface parameters to the Root T-PE or to the Leaf T-PE so as to 624 make sure that AC at the Leaf T-PE is capable to support traffic 625 coming from AC at the Root T-PE. In the P2MP MS-PW case, S-PEs MUST 626 propagate correctly this information. 627 In case of mismatch, the passive T-PE (Root or Leaf T-PE, depending 628 on the signaling process) MUST support mechanisms to reject attempts 629 to establish the P2MP MS-PW. 631 4.3.5. Leaf Grafting/Pruning 633 Once the PW tree is setup, the solution MUST allow the addition or 634 removal of a Leaf T-PE, or a subset of leaves to/from the existing 635 tree, without any impact on the PW tree (data and control planes) for 636 the remaining Leaf T-PEs. 638 4.3.6. Explicit Routing 640 The P2MP MS-PW signaling solution MUST provide a means of 641 establishing arbitrary P2MP MS-PW, according to pre-computed and 642 configured S-PE paths as well as dynamically computed S-PE paths on 643 the Root T-PE. 645 To support setup of explicitly routed MS-PW tree, the signaling 646 solution SHOULD support some source-based control that can explicitly 647 define particular S-PE nodes as Branch S-PEs for the PW tree. 649 The solution SHOULD let possible Explicit Path Loose Hops. Therefore 650 the P2MP MS-PW MAY be partially specified with only a subset of 651 intermediate Branch S-PEs. 653 4.4. Failure Detection and Reporting 655 The solution SHOULD rely on specific OAM mechanisms to detect a node 656 (T-PE and S-PE) or segment failure of a PW tree. The solution SHOULD 657 also support the ability to inform the Root T-PE of the failure as 658 well as to indicate the identity of affected Leaf T-PEs. 660 Based on these failure notifications the solution MUST allow the Root 661 T-PE to update the remaining Leaf T-PEs of the PW tree. 663 - A solution MUST support in-band OAM mechanism to detect failures: 664 unidirectional point-to-multipoint traffic failure. This SHOULD be 665 realized by enhancing existing unicast PW methods, such as VCCV for 666 seamless and familiar operation. 668 - In case of failure, it SHOULD correctly report which Leaf T-PEs and 669 Branch S-PEs are affected. This SHOULD be realized by enhancing 670 existing unicast PW methods, such as LDP Notification for seamless 671 and familiar operation. The notification message SHOULD include the 672 type of fault (P2MP PW, AC or PSN tunnel). 674 - Respectively a Leaf T-PE also MAY receive the status of the Root 675 PE's AC status. 677 - A solution MUST support OAM message mapping at the Root T-PE if 678 failure is detected on the AC. The Leaf T-PE MUST report accordingly 679 at the service layer this OAM message on its associated AC. 681 4.5. Protection and Restoration 683 The solution SHOULD provide mechanisms to recover as fast as possible 684 following a failure event. The fast protection/recovery is typically 685 dedicated to P2MP applications sensitive to traffic disruption. 687 Considering (i) a Root-initiated PW tree setup and (ii) that a local 688 repair (PSN-tunnel or PW segment-based) is not feasible after a 689 failure event and that (iii) the PE upstream to the failure receives 690 by means of OAM mechanisms a message indicating that a subset of Leaf 691 T-PEs are detached from the PW tree, the solution SHOULD allow the 692 upstream PE to re-compute the path to those particular Leaf T-PEs. If 693 the upstream PE failed to compute an alternative path, the procedure 694 SHOULD be propagated upstream until the Root T-PE is reached. 696 It is also assumed that recovery procedures can be implemented at the 697 underlying P2P or P2MP LSP layer, using standard MPLS-based recovery 698 techniques. These procedures could be used to provide faster recovery 699 time in case of link or node failure affecting this layer. 701 A mechanism SHOULD be implemented to avoid race conditions between 702 recovery at the PSN level and recovery at the PW level. 704 4.6. Scalability 706 In definition of solution for P2MP MS-PW a particular attention MUST 707 be dedicated to scalability. 709 The solution MUST be designed to scale as well as linearly with an 710 increase in the number of Leaf T-PEs, Branch S-PEs. The scalability 711 issues MUST be addressed for the control plane (e.g. addressing of PW 712 endpoints, number of signaling sessions, etc) and for data plane 713 (e.g. duplication of PW segments, OAM mechanism, etc). 715 5. Manageability considerations 717 The solution SHOULD provide a simple provisioning procedure to build 718 a P2MP SS-PW or a P2MP MS-PW. 720 The solution MUST take into consideration the situation where the 721 Root PE and Leaf PEs are not managed by a single NMS. 723 In that case it MUST be possible to manage the whole P2MP PW using a 724 single NMS. Typically the P2MP PW could be managed from the Root PE. 726 6. Backward Compatibility 728 The solution SHOULD be completely backward compatible with 729 the current PW standards. The solution SHOULD take into account the 730 capability advertisement and negotiation procedures for the PEs 731 implementing P2MP PW endpoints. 733 Implementation of OAM mechanisms also implies the advertisement of PE 734 capabilities to support specific OAM features. The solution MAY allow 735 advertising P2MP PW OAM capabilities. 737 A solution MUST NOT allow PW connection with non-compliant PEs. It 738 MUST have a mechanism to report an error for non-compliant PEs. In 739 this case, it SHOULD report which PE (S-PE and T-PEs) are not 740 compliant. 742 In some cases, upstream traffic is required from downstream CE to 743 upstream CE. The P2MPPW solution SHOULD allow a return path (i.e. 744 from the Leaf to the Root) that provides upstream connection. 745 In particular, it is expected to be allowed that the same ACs are 746 shared between downstream and upstream direction. For downstream, a 747 CE receives from its connected AC traffic originated by the Root PE 748 transported over a P2MP PW. For upstream, the CE MAY also send over 749 the same AC traffic destined to the same remote PE. 751 7. Security Considerations 753 The security requirements common to PW are raised in Section 10 of 754 [RFC3916] and common to MS-PW in section 7 of [RFC5254]. P2MP PW (SS 755 or MS) is a variant of the initial P2P PW definition, and that 756 statements also apply to P2MP PW. 758 8. IANA Considerations 760 This draft does not define any new protocol element, and hence does 761 not require any IANA action. 763 9. Acknowledgments 765 The authors thank the contributors of [RFC4461] since the structure 766 and content of this document were, for some sections, largely 767 inspired by [RFC4461]. 769 Many thanks to JL Le Roux and A. Cauvin for the discussions, comments 770 and support. 772 10. References 774 10.1. Normative References 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, March 1997. 779 [RFC3916] McPherson, D.,Pate, P., Xiao, X., "Requirements for 780 Pseudo-Wire Emulation Edge-to-Edge", September 2004 782 [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 784 [RFC4461] Aggarwal, R., Farrel, A., Jork, M., Kamite, Y., 785 Kullberg, A., Le Roux, JL., Malis, A., Papadimitriou, 786 D., Vasseur, JP., Yasukawa, S., "Signaling Requirements 787 for P2MP TE MPLS LSPs",April 2006 789 [RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S., 790 "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", 791 MAY 2007 793 [RFC4446] Martini, L. "IANA Allocations for Pseudowire Edge to 794 Edge Emulation (PWE3)", April 2006 796 [RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for 797 inter domain Pseudo-Wires", June 2008 799 [RFC5332] Rosen, E. et al., "MPLS Multicast Encapsulations", 800 August 2008 802 [RFC5659] Bocci, M., and Bryant, S.,T., " An Architecture for 803 Multi-Segment Pseudo Wire Emulation Edge-to-Edge", 804 October 2009 806 10.2. Informative References 808 [MLDP] Minei, I., Wijnands, I., Thomas, B., "Label 809 Distribution Protocol Extensions for Point-to- 810 Multipoint and Multipoint-to-Multipoint Label Switched 811 Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-10, 812 July 2010 814 [VPMS REQ] Kamite, Y., Jounay, F. "Framework and Requirements for 815 Virtual Private Multicast Service (VPMS)", Internet 816 Draft, draft-ietf-l2vpn-vpms-frmwk-requirements-03, 817 July 2010 819 Author's Addresses 821 Frederic Jounay 822 France Telecom 823 2, avenue Pierre-Marzin 824 22307 Lannion Cedex 825 FRANCE 826 Email: frederic.jounay@orange-ftgroup.com 828 Philippe Niger 829 France Telecom 830 2, avenue Pierre-Marzin 831 22307 Lannion Cedex 832 FRANCE 833 Email: philippe.niger@orange-ftgroup.com 835 Yuji Kamite 836 NTT Communications Corporation 837 Tokyo Opera City Tower 838 3-20-2 Nishi Shinjuku, Shinjuku-ku 839 Tokyo 163-1421 840 Japan 841 Email: y.kamite@ntt.com 843 Luca Martini 844 Cisco Systems, Inc. 845 9155 East Nichols Avenue, Suite 400 846 Englewood, CO, 80112 847 EMail: lmartini@cisco.com 849 Giles Heron 850 BT 851 UK 852 EMail: giles.heron@gmail.com 854 Simon Delord 855 Telstra 856 242 Exhibition St 857 Melbourne VIC 3000 858 Australia 859 Email: simon.a.delord@team.telstra.com 861 Lei Wang 862 Telenor 863 Snaroyveien 30 864 Fornebu 1331 865 Norway 866 Email: lei.wang@telenor.com 868 Rahul Aggarwal 869 Juniper Networks 870 1194 North Mathilda Ave. 872 Sunnyvale, CA 94089 873 Email: rahul@juniper.net 875 Martin Vigoureux 876 Alcatel-Lucent France 877 Route de Villejust 878 91620 Nozay 879 FRANCE 880 Email: martin.vigoureux@alcatel-lucent.fr 882 Matthew Bocci 883 Alcatel-Lucent Telecom Ltd, 884 Voyager Place 885 Shoppenhangers Road 886 Maidenhead 887 Berks, UK 888 E-mail: matthew.bocci@alcatel-lucent.co.uk 890 Lizhong JIN 891 ZTE Corporation 892 889, Bibo Road, 893 Shanghai, 201203, China 894 Email: lizhong.jin@zte.com.cn 896 Copyright and License Notice 898 Copyright (c) 2010 IETF Trust and the persons identified as the 899 document authors. All rights reserved. 900 This document is subject to BCP 78 and the IETF Trust's Legal 901 Provisions Relating to IETF Documents 902 (http://trustee.ietf.org/license-info) in effect on the date of 903 publication of this document. Please review these documents 904 carefully, as they describe your rights and restrictions with 905 respect to this document. Code Components extracted from this 906 document must include Simplified BSD License text as described 907 in Section 4.e of the Trust Legal Provisions and are provided 908 without warranty as described in the Simplified BSD License. 910 This document may contain material from IETF Documents or IETF 911 Contributions published or made publicly available before November 912 10, 2008. The person(s) controlling the copyright in some of this 913 material may not have granted the IETF Trust the right to allow 914 modifications of such material outside the IETF Standards Process. 915 Without obtaining an adequate license from the person(s) 916 controlling the copyright in such materials, this document may not 917 be modified outside the IETF Standards Process, and derivative 918 works of it may not be created outside the IETF Standards Process, 919 except to format it for publication as an RFC or to translate it 920 into languages other than English.