idnits 2.17.1 draft-ietf-pwe3-p2mp-pw-requirements-02.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Unrecognized Status in 'Category: Informational Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (Janvier 08, 2010) is 5224 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3916 ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 4461 ** Downref: Normative reference to an Informational RFC: RFC 5254 ** Downref: Normative reference to an Informational RFC: RFC 5659 == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-08 == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-vpms-frmwk-requirements-02 Summary: 6 errors (**), 0 flaws (~~), 4 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 Track France Telecom 5 Expires: June 2010 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 Janvier 08, 2010 20 Requirements for Point-to-Multipoint Pseudowire 22 draft-ietf-pwe3-p2mp-pw-requirements-02.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 June, 2010. 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 586 Figure 4 Example of P2P and P2MP underlying Layer for P2MP MS-PW 588 The P2MP PSN MAY be signaled with P2MP RSVP-TE [RFC4875] or MLDP 589 [MLDP]. 591 4.3. P2MP MS-PW Signaling Requirements 593 4.3.1. Dynamically Instantiated P2MP MS-PW 595 The PW tree could be statically configured at the T-PEs and each S-PE 596 crossed. However it is RECOMMENDED that a solution provides the 597 ability to dynamically setup a MS-PW tree, by allowing the MS-PW 598 segments to be dynamically discovered. 600 During the PW tree setup, a Branch S-PE SHOULD be capable to inform 601 the upstream PEs, including the Root T-PE that a set of Leaf T-PEs 602 and associated leaves are not reachable. 604 4.3.2. P2MP MS-PW Setup Mechanisms 606 The requirements described in this section assume that dynamic setup 607 of MS-PW segments allows the T-PE and S-PEs to dynamically signal MS- 608 PW segments and stitch these segments in order to build the MS-PW 609 tree. 611 4.3.3. PW type mismatch 613 As described for P2MP SS-PW, the P2MP MS-PW requires ACs of the same 614 PW type. Therefore the segments composing the P2MP MS-PW MUST be also 615 of the same PW type [RFC4446]. The S-PE MAY only support switching 616 PWs of the same PW type. In case of a different type, the passive PE 617 (S-PE or T-PE) MUST support mechanisms to reject attempts to 618 establish the P2MP MS-PW. 620 4.3.4. Interface Parameters sub-TLV 622 The section 3.4.3 is also relevant to P2MP MS-PW. When applicable, 623 the Leaf T-PE or the Root T-PE MUST signal respectively its AC' 624 interface parameters to the Root T-PE or to the Leaf T-PE so as to 625 make sure that AC at the Leaf T-PE is capable to support traffic 626 coming from AC at the Root T-PE. In the P2MP MS-PW case, S-PEs MUST 627 propagate correctly this information. 628 In case of mismatch, the passive T-PE (Root or Leaf T-PE, depending 629 on the signaling process) MUST support mechanisms to reject attempts 630 to establish the P2MP MS-PW. 632 4.3.5. Leaf Grafting/Pruning 634 Once the PW tree is setup, the solution MUST allow the addition or 635 removal of a Leaf T-PE, or a subset of leaves to/from the existing 636 tree, without any impact on the PW tree (data and control planes) for 637 the remaining Leaf T-PEs. 639 4.3.6. Explicit Routing 641 The P2MP MS-PW signaling solution MUST provide a means of 642 establishing arbitrary P2MP MS-PW, according to pre-computed and 643 configured S-PE paths as well as dynamically computed S-PE paths on 644 the Root T-PE. 646 To support setup of explicitly routed MS-PW tree, the signaling 647 solution SHOULD support some source-based control that can explicitly 648 define particular S-PE nodes as Branch S-PEs for the PW tree. 650 The solution SHOULD let possible Explicit Path Loose Hops. Therefore 651 the P2MP MS-PW MAY be partially specified with only a subset of 652 intermediate Branch S-PEs. 654 4.4. Failure Detection and Reporting 656 The solution SHOULD rely on specific OAM mechanisms to detect a node 657 (T-PE and S-PE) or segment failure of a PW tree. The solution SHOULD 658 also support the ability to inform the Root T-PE of the failure as 659 well as to indicate the identity of affected Leaf T-PEs. 661 Based on these failure notifications the solution MUST allow the Root 662 T-PE to update the remaining Leaf T-PEs of the PW tree. 664 - A solution MUST support in-band OAM mechanism to detect failures: 665 unidirectional point-to-multipoint traffic failure. This SHOULD be 666 realized by enhancing existing unicast PW methods, such as VCCV for 667 seamless and familiar operation. 669 - In case of failure, it SHOULD correctly report which Leaf T-PEs and 670 Branch S-PEs are affected. This SHOULD be realized by enhancing 671 existing unicast PW methods, such as LDP Notification for seamless 672 and familiar operation. The notification message SHOULD include the 673 type of fault (P2MP PW, AC or PSN tunnel). 675 - Respectively a Leaf T-PE also MAY receive the status of the Root 676 PE's AC status. 678 - A solution MUST support OAM message mapping at the Root T-PE if 679 failure is detected on the AC. The Leaf T-PE MUST report accordingly 680 at the service layer this OAM message on its associated AC. 682 4.5. Protection and Restoration 684 The solution SHOULD provide mechanisms to recover as fast as possible 685 following a failure event. The fast protection/recovery is typically 686 dedicated to P2MP applications sensitive to traffic disruption. 688 Considering (i) a Root-initiated PW tree setup and (ii) that a local 689 repair (PSN-tunnel or PW segment-based) is not feasible after a 690 failure event and that (iii) the PE upstream to the failure receives 691 by means of OAM mechanisms a message indicating that a subset of Leaf 692 T-PEs are detached from the PW tree, the solution SHOULD allow the 693 upstream PE to re-compute the path to those particular Leaf T-PEs. If 694 the upstream PE failed to compute an alternative path, the procedure 695 SHOULD be propagated upstream until the Root T-PE is reached. 697 It is also assumed that recovery procedures can be implemented at the 698 underlying P2P or P2MP LSP layer, using standard MPLS-based recovery 699 techniques. These procedures could be used to provide faster recovery 700 time in case of link or node failure affecting this layer. 702 A mechanism SHOULD be implemented to avoid race conditions between 703 recovery at the PSN level and recovery at the PW level. 705 4.6. Scalability 707 In definition of solution for P2MP MS-PW a particular attention MUST 708 be dedicated to scalability. 710 The solution MUST be designed to scale as well as linearly with an 711 increase in the number of Leaf T-PEs, Branch S-PEs. The scalability 712 issues MUST be addressed for the control plane (e.g. addressing of PW 713 endpoints, number of signaling sessions, etc) and for data plane 714 (e.g. duplication of PW segments, OAM mechanism, etc). 716 5. Manageability considerations 718 The solution SHOULD provide a simple provisioning procedure to build 719 a P2MP SS-PW or a P2MP MS-PW. 721 The solution MUST take into consideration the situation where the 722 Root PE and Leaf PEs are not managed by a single NMS. 724 In that case it MUST be possible to manage the whole P2MP PW using a 725 single NMS. Typically the P2MP PW could be managed from the Root PE. 727 6. Backward Compatibility 729 The solution SHOULD be completely backward compatible with 730 the current PW standards. The solution SHOULD take into account the 731 capability advertisement and negotiation procedures for the PEs 732 implementing P2MP PW endpoints. 734 Implementation of OAM mechanisms also implies the advertisement of PE 735 capabilities to support specific OAM features. The solution MAY allow 736 advertising P2MP PW OAM capabilities. 738 A solution MUST NOT allow PW connection with non-compliant PEs. It 739 MUST have a mechanism to report an error for non-compliant PEs. In 740 this case, it SHOULD report which PE (S-PE and T-PEs) are not 741 compliant. 743 In some cases, upstream traffic is required from downstream CE to 744 upstream CE. The P2MPPW solution SHOULD allow a return path (i.e. 745 from the Leaf to the Root) that provides upstream connection. 746 In particular, it is expected to be allowed that the same ACs are 747 shared between downstream and upstream direction. For downstream, a 748 CE receives from its connected AC traffic originated by the Root PE 749 transported over a P2MP PW. For upstream, the CE MAY also send over 750 the same AC traffic destined to the same remote PE. 752 7. Security Considerations 754 The security requirements common to PW are raised in Section 10 of 755 [RFC3916] and common to MS-PW in section 7 of [RFC5254]. P2MP PW (SS 756 or MS) is a variant of the initial P2P PW definition, and that 757 statements also apply to P2MP PW. 759 8. IANA Considerations 761 This draft does not define any new protocol element, and hence does 762 not require any IANA action. 764 9. Acknowledgments 766 The authors thank the contributors of [RFC4461] since the structure 767 and content of this document were, for some sections, largely 768 inspired by [RFC4461]. 770 Many thanks to JL Le Roux and A. Cauvin for the discussions, comments 771 and support. 773 10. References 775 10.1. Normative References 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, March 1997. 780 [RFC3916] McPherson, D.,Pate, P., Xiao, X., "Requirements for 781 Pseudo-Wire Emulation Edge-to-Edge", September 2004 783 [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 785 [RFC4461] Aggarwal, R., Farrel, A., Jork, M., Kamite, Y., 786 Kullberg, A., Le Roux, JL., Malis, A., Papadimitriou, 787 D., Vasseur, JP., Yasukawa, S., "Signaling Requirements 788 for P2MP TE MPLS LSPs",April 2006 790 [RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S., 791 "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", 792 MAY 2007 794 [RFC4446] Martini, L. "IANA Allocations for Pseudowire Edge to 795 Edge Emulation (PWE3)", April 2006 797 [RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for 798 inter domain Pseudo-Wires", June 2008 800 [RFC5332] Rosen, E. et al., "MPLS Multicast Encapsulations", 801 August 2008 803 [RFC5659] Bocci, M., and Bryant, S.,T., " An Architecture for 804 Multi-Segment Pseudo Wire Emulation Edge-to-Edge", 805 October 2009 807 10.2. Informative References 809 [MLDP] Minei, I., Wijnands, I., Thomas, B., "Label 810 Distribution Protocol Extensions for Point-to- 811 Multipoint and Multipoint-to-Multipoint Label Switched 812 Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-08, 813 October 2009 815 [VPMS REQ] Kamite, Y., Jounay, F. "Framework and Requirements for 816 Virtual Private Multicast Service (VPMS)", Internet 817 Draft, draft-ietf-l2vpn-vpms-frmwk-requirements-02, 818 October 2009 820 Author's Addresses 822 Frederic Jounay 823 France Telecom 824 2, avenue Pierre-Marzin 825 22307 Lannion Cedex 826 FRANCE 827 Email: frederic.jounay@orange-ftgroup.com 829 Philippe Niger 830 France Telecom 831 2, avenue Pierre-Marzin 832 22307 Lannion Cedex 833 FRANCE 834 Email: philippe.niger@orange-ftgroup.com 836 Yuji Kamite 837 NTT Communications Corporation 838 Tokyo Opera City Tower 839 3-20-2 Nishi Shinjuku, Shinjuku-ku 840 Tokyo 163-1421 841 Japan 842 Email: y.kamite@ntt.com 844 Luca Martini 845 Cisco Systems, Inc. 846 9155 East Nichols Avenue, Suite 400 847 Englewood, CO, 80112 848 EMail: lmartini@cisco.com 850 Giles Heron 851 Tellabs 852 Abbey Place 853 24-28 Easton Street 854 High Wycombe 855 Bucks 856 HP11 1NT 857 UK 858 EMail: giles.heron@tellabs.com 860 Simon Delord 861 Telstra 862 242 Exhibition St 863 Melbourne VIC 3000 864 Australia 865 Email: simon.a.delord@team.telstra.com 867 Lei Wang 868 Telenor 869 Snaroyveien 30 870 Fornebu 1331 871 Norway 872 Email: lei.wang@telenor.com 874 Rahul Aggarwal 875 Juniper Networks 876 1194 North Mathilda Ave. 877 Sunnyvale, CA 94089 878 Email: rahul@juniper.net 880 Martin Vigoureux 881 Alcatel-Lucent France 882 Route de Villejust 883 91620 Nozay 884 FRANCE 885 Email: martin.vigoureux@alcatel-lucent.fr 887 Matthew Bocci 888 Alcatel-Lucent Telecom Ltd, 889 Voyager Place 890 Shoppenhangers Road 891 Maidenhead 892 Berks, UK 893 E-mail: matthew.bocci@alcatel-lucent.co.uk 895 Lizhong JIN 896 ZTE Corporation 897 889, Bibo Road, 898 Shanghai, 201203, China 899 Email: lizhong.jin@zte.com.cn 901 Copyright and License Notice 903 Copyright (c) 2010 IETF Trust and the persons identified as the 904 document authors. All rights reserved. 906 This document is subject to BCP 78 and the IETF Trust's Legal 907 Provisions Relating to IETF Documents in effect on the date of 908 publication of this document (http://trustee.ietf.org/license-info). 909 Please review these documents carefully, as they describe your rights 910 and restrictions with respect to this document. 912 This document may contain material from IETF Documents or IETF 913 Contributions published or made publicly available before November 914 10, 2008. The person(s) controlling the copyright in some of this 915 material may not have granted the IETF Trust the right to allow 916 modifications of such material outside the IETF Standards Process. 917 Without obtaining an adequate license from the person(s) controlling 918 the copyright in such materials, this document may not be modified 919 outside the IETF Standards Process, and derivative works of it may 920 not be created outside the IETF Standards Process, except to format 921 it for publication as an RFC or to translate it into languages other 922 than English.