idnits 2.17.1 draft-ietf-mpls-mp-ldp-reqs-08.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 (May 26, 2011) is 4718 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Historic ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-08 == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS J. Le Roux, Ed. 3 Internet-Draft T. Morin, Ed. 4 Intended status: Historic France Telecom - Orange 5 Expires: November 27, 2011 May 26, 2011 7 Requirements for Point-To-Multipoint Extensions to the Label 8 Distribution Protocol 9 draft-ietf-mpls-mp-ldp-reqs-08 11 Abstract 13 This document lists a set of functional requirements that served as 14 input to the design of Label Distribution Protocol (LDP) extensions 15 for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), 16 in order to deliver point-to-multipoint applications over a Multi 17 Protocol Label Switching (MPLS) infrastructure. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 27, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 4 67 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.4. Context and Motivations . . . . . . . . . . . . . . . . . 6 70 1.5. Document Scope . . . . . . . . . . . . . . . . . . . . . . 7 71 2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 7 72 3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 8 73 4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 74 4.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.3. P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10 77 4.4. Setting Up, Tearing Down and Modifying P2MP LSPs . . . . . 10 78 4.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10 79 4.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 10 80 4.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11 81 4.8. P2MP LSP Re-routing . . . . . . . . . . . . . . . . . . . 11 82 4.9. Support for Multi-Access Networks . . . . . . . . . . . . 12 83 4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12 84 4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.12. IPv4/IPv6 Support . . . . . . . . . . . . . . . . . . . . 13 86 4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13 87 4.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 4.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 13 89 4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 13 90 4.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14 92 5. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 5.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15 94 6. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 16 95 6.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16 96 6.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 17 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 104 1. Introduction 106 This document lists a set of functional requirements that served as 107 input to the design of Label Distribution Protocol (LDP) extensions 108 for setting up point-to-multipoint (P2MP) Label Switched Paths 109 (LSP)[I-D.ietf-mpls-ldp-p2mp], in order to deliver point-to- 110 multipoint applications over a Multi-Protocol Label Switching (MPLS) 111 infrastructure. It is published with Historic status with the 112 perspective of documenting the work done. 114 The document is structured as follows: 116 o Section 2 is an overview of the requirements; 118 o Section 3 illustrates an application scenario; 120 o Section 4 addresses detailed requirements for P2MP LSPs; 122 o Section 5 finally discusses requirements for shared trees and 123 MultiPoint-to-MultiPoint (MP2MP) LSPs. 125 1.1. Contributing Authors 127 The following people contributed to the text and content of this 128 document: 130 o Shane Amante, Level 3 Communications, LLC 132 o Luyuan Fang, Cisco Systems 134 o Yuji Kamite, NTT Communications Corporation 136 o Jean-Louis Le Roux, France Telecom - Orange 138 o Thomas Morin, France Telecom - Orange 140 o Vincent Parfait, France Telecom - Orange, Orange Business Services 142 o Lei Wang, Telenor 144 1.2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 1.3. Definitions 152 1.3.1. Acronyms 154 P2P: Point-To-Point 156 MP2P: Multipoint-to-Point 158 P2MP: Point-To-MultiPoint 160 MP2MP: MultiPoint-To-Multipoint 162 LSP: Label Switched Path 164 LSR: Label Switching Router 166 PE: Provider Edge router 168 P: Provider router 170 IGP: Interior Gateway Protocol 172 AS: Autonomous System 174 1.3.2. Terminology 176 The reader is assumed to be familiar with the terminology in 177 [RFC3031], [RFC5036], and [RFC4026]. 179 Ingress LSR: 180 Router acting as a sender of an LSP 182 Egress LSR: 183 Router acting as a receiver of an LSP 185 P2P LSP: 186 An LSP that has one unique Ingress LSR and one unique Egress LSR 188 MP2P LSP: 189 An LSP that has one or more Ingress LSRs and one unique Egress LSR 191 P2MP LSP: 192 An LSP that has one unique Ingress LSR and one or more Egress LSRs 194 MP2MP LSP: 195 An LSP that as one or more Leaf LSRs acting indifferently as 196 Ingress or Egress LSR 198 Leaf LSR: 199 An Egress LSR of a P2MP LSP or an Ingress/Egress LSR of a MP2MP 200 LSP 202 Transit LSR: 203 An LSR of a P2MP or MP2MP LSP that has one or more Downstream LSRs 205 Branch LSR: 206 An LSR of a P2MP or MP2MP LSP that has more than one downstream 207 LSR 209 Bud LSR: 210 An LSR of a P2MP or MP2MP LSP that is an egress but also has one 211 or more directly connected downstream LSR(s) 213 P2MP tree: 214 The ordered set of LSRs and links that comprise the path of a P2MP 215 LSP from its ingress LSR to all of its egress LSRs. 217 1.4. Context and Motivations 219 LDP [RFC5036] has been deployed for setting up point-to-point (P2P) 220 and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point 221 services in MPLS backbones. 223 There are emerging requirements for supporting delivery of point-to- 224 multipoint applications in MPLS backbones, such as those defined in 225 [RFC4834] and [RFC5501]. 227 For various reasons, including consistency with P2P applications, and 228 taking full advantages of MPLS network infrastructure, it would be 229 highly desirable to use MPLS LSPs for the delivery of multicast 230 traffic. This could be implemented by setting up a group of P2P or 231 MP2P LSPs, but such an approach may be inefficient since it would 232 result in data replication at the ingress LSR and duplicate data 233 traffic within the network. Hence new mechanisms are required that 234 would allow traffic from an Ingress LSR to be efficiently delivered 235 to a number of Egress LSRs in an MPLS backbone on a point-to- 236 multipoint LSP (P2MP LSP), avoiding duplicate copies of a packet on a 237 given link and with MPLS traffic replication at some Branch LSRs. 239 RSVP-TE extensions for setting up Point-To-Multipoint Traffic 240 Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875]. They 241 meet requirements expressed in [RFC4461]. This approach is useful, 242 in network environments where P2MP Traffic Engineering capabilities 243 are needed (Optimization, QoS, Fast recovery). 245 However for operators who want to support point-to-multipoint traffic 246 delivery on an MPLS backbone, without Traffic Engineering needs, and 247 who have already deployed LDP for P2P traffic, an interesting and 248 useful approach would be to rely on LDP extensions in order to setup 249 point-to-multipoint (P2MP) LSPs. This would bring consistency with 250 P2P MPLS applications and would ease the delivery of point-to- 251 multipoint services in an MPLS backbone. 253 1.5. Document Scope 255 This document focuses on the LDP approach for setting up P2MP LSPs. 256 It lists a detailed set of requirements for P2MP extensions to LDP, 257 so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. 258 The original intent was that these requirements should be used as 259 guidelines when specifying LDP extensions. 261 Note that generic requirements for P2MP extensions to MPLS are out of 262 the scope of this document. Rather this document describes solution 263 specific requirements related to LDP extensions in order to set up 264 P2MP LSPs. 266 Note also that other mechanisms could be used for setting up P2MP 267 LSPs, such as for instance PIM extensions, but these are out of the 268 scope of this document. The objective is not to compare these 269 mechanisms but rather to focus on the requirements for an LDP 270 extension approach. 272 2. Requirements Overview 274 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs 275 with one Ingress LSR and one or more Egress LSRs, with traffic 276 replication at some Branch LSRs. 278 The P2MP LDP mechanism MUST allow the addition or removal of leaves 279 associated with a P2MP LSP. 281 The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and 282 inherit its capability sets from [RFC5036]. It is of paramount 283 importance that the P2MP LDP mechanism MUST NOT impede the operation 284 of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co- 285 exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It 286 is of paramount importance that the P2MP LDP mechanism MUST NOT 287 impede the operation of existing P2P and P2MP RSVP-TE LSPs. 289 The P2MP LDP mechanism MAY also allow setting up multipoint-to- 290 multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting 291 indifferently as Ingress LSR or Egress LSR. This may allow a 292 reduction in the amount of LDP state that needs to be maintained by a 293 LSR. 295 3. Application Scenario 297 Figure 1 below illustrates an LDP enabled MPLS provider network, used 298 to carry both unicast and multicast traffic of VPN customers 299 following for instance the architecture defined in 300 [I-D.ietf-l3vpn-2547bis-mcast] for BGP/MPLS VPNs, or the one defined 301 in [I-D.ietf-l2vpn-vpls-mcast]. 303 In this example, a set of MP2P LDP LSPs are setup between Provider 304 Edge (PE) routers to carry unicast VPN traffic within the MPLS 305 backbone. 307 And in this example a set of P2MP LDP LSPs are setup between PE 308 routers acting as Ingress LSRs and PE routers acting as Egress LSRs, 309 so as to support multicast VPN traffic delivery within the MPLS 310 backbone. 312 For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and 313 Egress LSRs PE2, PE3, and PE4. It is used to transport multicast 314 traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it 315 replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are 316 non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 317 and PE4 respectively. 319 PE1 320 *| *** P2MP LDP LSP 321 *|***** 322 P1-----PE2 323 */ \* 324 */ \* 325 *****/ \****** 326 PE3----P2 P3----PE4 327 | | 328 | | 329 | | 330 PE5 PE6 332 Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4. 334 If later there are new receivers attached to PE5 and PE6, then PE5 335 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and 336 replicate traffic received from P1, to PE3 and PE5, and to PE4 and 337 PE6 respectively (see Figure 2 below). 339 PE1 340 *| *** P2MP LDP LSP 341 *|***** 342 P1-----PE2 343 */ \* 344 */ \* 345 *****/ \****** 346 PE3----P2 P3----PE4 347 *| |* 348 *| |* 349 *| |* 350 PE5 PE6 352 Figure 2: Attachment of PE5 and PE6. 354 The above example is provided for the sake of illustration. Note 355 that P2MP LSPs ingress and egress LSRs may not necessarily be PE 356 routers. Also branch LSRs may not necessarily be P routers. 358 4. Detailed Requirements 360 4.1. P2MP LSPs 362 The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane 363 aspects related to P2MP LSPs are those already defined in [RFC4461]. 364 That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. 365 Traffic sent by the Ingress LSR is received by all Egress LSRs. The 366 specific aspects related to P2MP LSPs is the action required at a 367 Branch LSR, where data replication occurs. Incoming labelled data is 368 appropriately replicated to several outgoing interfaces which may use 369 different labels. 371 An LSR SHOULD NOT send more than one copy of a packet on any given 372 link of a P2MP LSP. Exceptions to this are mentioned in Section 4.9 373 and Section 4.18. 375 A P2MP LSP MUST be identified by a constant and unique identifier 376 within the whole LDP domain, whatever the number of leaves, which may 377 vary dynamically. This identifier will be used so as to add/remove 378 leaves to/from the P2MP tree. 380 4.2. P2MP LSP FEC 382 As with P2P MPLS technology [RFC5036], traffic MUST be classified 383 into a FEC in this P2MP extension. All packets which belong to a 384 particular P2MP FEC and which travel from a particular node MUST use 385 the same P2MP LSP. 387 If existing FECs cannot be used for this purpose, a new LDP FEC that 388 is suitable for P2MP forwarding MUST be specified. 390 4.3. P2MP LDP Routing 392 As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support 393 hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the 394 information maintained in LSR Routing Information Bases (RIB). 396 It is RECOMMENDED that the P2MP LSP routing rely upon the unicast 397 route to the Ingress LSR to build a reverse path tree. 399 4.4. Setting Up, Tearing Down and Modifying P2MP LSPs 401 The P2MP LDP mechanism MUST support the establishment, maintenance 402 and teardown of P2MP LSPs in a scalable manner. This MUST include 403 both the existence of a large amount of P2MP LSPs within a single 404 network and a large amount of leaf LSRs for a single P2MP LSP (see 405 also Section 4.17 for scalability considerations and figures). 407 In order to scale well with a large number of leaves it is 408 RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For 409 that purpose, leaves will have to be aware of the P2MP LSP 410 identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely 411 on the applications that will use P2MP LSPs, and are out of the scope 412 of this document. 414 The P2MP LDP mechanism MUST allow the dynamic addition and removal of 415 leaves to and from a P2MP LSP, without any restriction (provided 416 there is network connectivity). It is RECOMMENDED that these 417 operations be leaf-initiated. These operations MUST NOT impact the 418 data transfer (packet loss, duplication, delay) towards other leaves. 419 It is RECOMMENDED that these operations do not cause any additional 420 processing except on the path from the added/removed Leaf LSR to the 421 Branch LSR. 423 4.5. Label Advertisement 425 The P2MP LDP mechanism MUST support downstream unsolicited label 426 advertisement mode. This is well suited to a leaf-initiated approach 427 and is consistent with P2P/MP2P LDP operations. 429 Other advertisement modes MAY also be supported. 431 4.6. Data Duplication 433 Data duplication refers to the receipt of multiple copies of a packet 434 by any leaf. Although this may be a marginal situation, it may also 435 be detrimental for certain applications. Hence, data duplication 436 SHOULD as much as possible be avoided, and limited to (hopefully 437 rare) transitory conditions. 439 Note, in particular, that data duplication might occur if P2MP LSP 440 rerouting is being performed (See also Section 4.8). 442 4.7. Detecting and Avoiding Loops 444 The P2MP LDP extension MUST have a mechanism to detect routing loops. 445 This MAY rely on extensions to the LDP Loop detection mechanism 446 defined in [RFC5036]. A loop detection mechanism MAY require 447 recording the set of LSRs traversed on the P2MP Tree. The P2MP loop 448 avoidance mechanism MUST NOT impact the scalability of the P2MP LDP 449 solution. 451 The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops 452 in the data plane even during transient events. 454 Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the 455 data plane, that may trigger unexpected non-localized exponential 456 growth of traffic. 458 4.8. P2MP LSP Re-routing 460 The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in 461 the following cases: 463 o Network failure (link or node); 465 o A better path exists (e.g. new link, metric change); 467 o Planned maintenance. 469 Given that P2MP LDP routing should rely on the RIB, the achievement 470 of the following requirements relies on the underlying routing 471 protocols (IGP, etc.). 473 4.8.1. Rerouting upon Network Failure 475 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 476 of link or node failure(s), by relying upon update of the routes in 477 the RIB. The rerouting time SHOULD be minimized as much as possible 478 so as to reduce traffic disruption. 480 A mechanism MUST be defined to prevent constant P2MP LSP teardown and 481 rebuild which may be caused by the instability of a specific link/ 482 node in the network. This can rely on IGP dampening but may be 483 completed by specific dampening at the LDP level. 485 4.8.2. Rerouting on a Better Path 487 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 488 a better path is created in the network, for instance as a result of 489 a metric change, a link repair, or the addition of links or nodes. 490 This will rely on update of the routes in the RIB. 492 4.8.3. Rerouting upon Planned Maintenance 494 The P2MP LDP mechanism MUST support planned maintenance operations. 495 It MUST be possible to reroute a P2MP LSP before a link/node is 496 deactivated for maintenance purposes. Traffic disruption and data 497 duplication SHOULD be minimized as much as possible during such 498 planned maintenance. P2MP LSP rerouting upon planned maintenance MAY 499 rely on a make before break procedure. 501 4.9. Support for Multi-Access Networks 503 The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send 504 a single copy of the data onto an interface to a multi-access network 505 (e.g. an Ethernet LAN) and reach multiple adjacent downstream nodes. 506 This requires that the same label be negotiated with all downstream 507 LSRs for the LSP. 509 When there are several candidate upstream LSRs on an interface to a 510 multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all 511 downstream LSRs of a given P2MP LSP to select the same upstream LSR, 512 so as to avoid traffic replication. In addition, the P2MP LDP 513 mechanism SHOULD allow for an efficient balancing of a set of P2MP 514 LSPs among a set of candidate upstream LSRs on a LAN interface. 516 4.10. Support for Encapsulation in P2P and P2MP TE Tunnels 518 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and 519 P2MP TE tunnels. 521 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP 522 LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a 523 single copy of the data onto the tunnel and reach all downstream LSRs 524 on the P2MP LSP, which are also Egress LSRs of the tunnel. As with 525 LAN interfaces, this requires that the same label be negotiated with 526 all downstream LSRs of the P2MP LDP LSP. 528 4.11. Label Spaces 530 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or 531 dedicated label spaces. 533 Note that dedicated label spaces will require the establishment of 534 separate P2P and P2MP LDP sessions. 536 4.12. IPv4/IPv6 Support 538 The P2MP LDP mechanism MUST support the establishment of LDP sessions 539 over both IPv4 and IPv6 control planes. 541 4.13. Multi-Area/AS LSPs 543 The P2MP LDP mechanism MUST support the establishment of multi-area 544 P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP 545 area as the Ingress LSR. This SHOULD be possible without requiring 546 the advertisement of Ingress LSRs' addresses across IGP areas. 548 The P2MP LDP mechanism MUST also support the establishment of 549 inter-AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the 550 same AS as the Ingress LSR. This SHOULD be possible without 551 requiring the advertisement of Ingress LSRs' addresses across ASes. 553 4.14. OAM 555 LDP management tools ([RFC3815], etc.) will have to be enhanced to 556 support P2MP LDP extensions. This may yield a new MIB module, which 557 may possibly be inherited from the LDP MIB. 559 Built-in diagnostic tools MUST be defined to check the connectivity, 560 trace the path and ensure fast detection of data plane failures on 561 P2MP LDP LSPs. 563 Further and precise requirements and mechanisms for P2MP MPLS OAM 564 purpose are out of the scope of this document and are addressed in 565 [RFC4687]. 567 4.15. Graceful Restart and Fault Recovery 569 LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery 570 mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs. 572 4.16. Robustness 574 A solution MUST be designed to re-establish connectivity for P2MP and 575 MP2MP LSPs in the event of failures, provided there exists network 576 connectivity between ingress and egress nodes (i.e. designed without 577 introducing single points of failure). 579 4.17. Scalability 581 Scalability is a key requirement for the P2MP LDP mechanism. It MUST 582 be designed to scale well with an increase in the number of any of 583 the following: 585 o number of Leaf LSRs per P2MP LSP; 587 o number of Downstream LSRs per Branch LSR; 589 o number of P2MP LSPs per LSR. 591 In order to scale well with an increase in the number of leaves, it 592 is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one 593 particular LSP, depend only on the number of adjacent LSRs on the 594 LSP. 596 4.17.1. Orders of Magnitude Expected in Operational Networks 598 Typical orders of magnitude that we expect should be supported are: 600 o tens of thousands of P2MP trees spread out across core network 601 routers; 603 o hundreds, or a few thousands, of leaves per tree; 605 See also section 4.2 of [RFC4834]. 607 4.18. Backward Compatibility 609 In order to allow for a smooth migration, the P2MP LDP mechanism 610 SHOULD offer as much backward compatibility as possible. In 611 particular, the solution SHOULD allow the setup of a P2MP LSP along 612 non-Branch Transit LSRs that do not support P2MP LDP extensions. 614 Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms 615 and inherit its capability sets from [RFC5036]. The P2MP LDP 616 solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP 617 solution MUST be designed in such a way that it allows P2P/MP2P and 618 P2MP LSPs to be signalled on the same interface. 620 5. Shared Trees 622 For traffic delivery between a group of N LSRs that act as egress 623 and/or egress nodes on different P2MP flows, it may be useful to 624 setup a shared tree connecting all these LSRs, instead of having N 625 P2MP LSPs. This would reduce the amount of control and forwarding 626 state that has to be maintained on a given LSR. 628 There are actually two main options for supporting such shared trees: 630 o This could rely on the applications protocols that use LDP LSPs. 631 A shared tree could consist of the combination of a MP2P LDP LSP 632 from Leafs LSRs to a given root node, with a P2MP LSP from this 633 root to Leaf LSRs. For instance with Multicast L3 VPN 634 applications, it would be possible to build a shared tree by 635 combining (see [I-D.ietf-l3vpn-2547bis-mcast]): 637 * a MP2P unicast LDP LSP, from each PE of the group to a 638 particular root PE acting as tree root, 640 * with a P2MP LDP LSP from this root PE to each PE of the group. 642 o Or this could rely on a specific LDP mechanism allowing to setup 643 multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). 645 The former approach (Combination of MP2P and P2MP LSPs at the 646 application level) is out of the scope of this document while the 647 latter (MP2MP LSPs) belong to the scope of this document. 648 Requirements for the set up of MP2MP LSPs are listed below. 650 5.1. Requirements for MP2MP LSPs 652 A Multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group 653 of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by 654 any Leaf LSR is received by all other Leaf LSRs of the group. 656 Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. 657 An implementation that support P2MP LDP LSPs MAY also support MP2MP 658 LDP LSP. 660 The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP. 662 Requirements for P2MP LSPs, set forth in Section 4, apply equally to 663 MP2MP LSPs. Particular attention should be given on the below 664 requirements: 666 o The solution MUST support recovery upon link and transit node 667 failure and be designed to re-establish connectivity for MP2MP 668 LSPs in the event of failures, provided there exists network 669 connectivity between ingress and egress nodes (i.e. designed 670 without introducing single points of failure); 672 o The size of MP2MP state on a LSR, for one particular MP2MP LSP, 673 SHOULD only depend on the number of adjacent LSRs on the LSP; 675 o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that 676 may trigger exponential growth of traffic. Note that this 677 requirement is more challenging with MP2MP LSPs as a LSR may need 678 to receive traffic for a given LSP on multiple interfaces. 680 There are additional requirements specific to MP2MP LSPs: 682 o It is RECOMMENDED that a MP2MP MPLS LSP is built based on the 683 unicast route to a specific LSR called root LSR; 685 o It is RECOMMENDED to define several root LSRs (e.g. a primary and 686 a backup) to ensure redundancy upon root LSR failure; 688 o The receiver SHOULD NOT receive back a packet it has sent on the 689 MP2MP LSP; 691 o The solution SHOULD avoid that all traffic between any pair of 692 leaves is traversing a root LSR (similarly to PIM-Bidir trees) and 693 SHOULD provide the operator with means to minimize the delay 694 between two leaves; 696 o It MUST be possible to check connectivity of a MP2MP LSP in both 697 directions. 699 6. Evaluation Criteria 701 6.1. Performance 703 The solution will be evaluated with respect to the following 704 criteria: 706 (1) Efficiency of network resource usage; 708 (2) Time to add or remove a Leaf LSR; 710 (3) Time to repair a P2MP LSP in case of link or node failure; 712 (4) Scalability (state size, number of messages, message size). 714 Particularly the P2MP LDP mechanism SHOULD be designed with as key 715 objective to minimize the additional amount of state and additional 716 processing required in the network. 718 Also, the P2MP LDP mechanism SHOULD be designed so that convergence 719 times in case of link or node failure are minimized, in order to 720 limit traffic disruption. 722 6.2. Complexity and Risks 724 The proposed solution SHOULD NOT introduce complexity to the current 725 LDP operations to such a degree that it would affect the stability 726 and diminish the benefits of deploying such solution. 728 7. Security Considerations 730 It is expected that addressing the requirements defined in this 731 document should not introduce any new security issue beyond those 732 inherent to LDP, and that a P2MP LDP solution will rely on the 733 security mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature). 735 An evaluation of the security features for MPLS networks may be found 736 in [RFC5920], and where issues or further work is identified by that 737 document, new security features or procedures for the MPLS protocols 738 will need to be developed. 740 8. IANA Considerations 742 This informational document makes no requests to IANA for action. 744 9. Acknowledgments 746 We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina 747 Minei, Dean Cheng, and Benjamin Niven-Jenkins, for their highly 748 useful comments and suggestions. We would also like to thank Adrian 749 Farrel for reviewing this document before publication. 751 We would also like to thank authors of [RFC4461] from which some of 752 the text in this document has been inspired. 754 10. References 756 10.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 762 Label Switching Architecture", RFC 3031, January 2001. 764 [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful 765 Restart Mechanism for Label Distribution Protocol", 766 RFC 3478, February 2003. 768 [RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution 769 Protocol (LDP)", RFC 3479, February 2003. 771 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 772 of Managed Objects for the Multiprotocol Label Switching 773 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, 774 June 2004. 776 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 777 Multipoint Traffic-Engineered MPLS Label Switched Paths 778 (LSPs)", RFC 4461, April 2006. 780 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 781 Specification", RFC 5036, October 2007. 783 10.2. Informative References 785 [I-D.ietf-l2vpn-vpls-mcast] 786 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 787 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work 788 in progress), October 2010. 790 [I-D.ietf-l3vpn-2547bis-mcast] 791 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 792 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 793 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 794 in progress), January 2010. 796 [I-D.ietf-mpls-ldp-p2mp] 797 Minei, I., Wijnands, I., Kompella, K., and B. Thomas, 798 "Label Distribution Protocol Extensions for Point-to- 799 Multipoint and Multipoint-to-Multipoint Label Switched 800 Paths", draft-ietf-mpls-ldp-p2mp-13 (work in progress), 801 April 2011. 803 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 804 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 805 Tunnels", RFC 3209, December 2001. 807 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 808 Private Network (VPN) Terminology", RFC 4026, March 2005. 810 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 811 "Operations and Management (OAM) Requirements for Point- 812 to-Multipoint MPLS Networks", RFC 4687, September 2006. 814 [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 815 Provider-Provisioned Virtual Private Networks (PPVPNs)", 816 RFC 4834, April 2007. 818 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 819 "Extensions to Resource Reservation Protocol - Traffic 820 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 821 Switched Paths (LSPs)", RFC 4875, May 2007. 823 [RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, 824 "Requirements for Multicast Support in Virtual Private LAN 825 Services", RFC 5501, March 2009. 827 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 828 Networks", RFC 5920, July 2010. 830 Authors' Addresses 832 Jean-Louis Le Roux (editor) 833 France Telecom - Orange 835 Email: jeanlouis.leroux@orange-ftgroup.com 837 Thomas Morin (editor) 838 France Telecom - Orange 840 Email: thomas.morin@orange-ftgroup.com 842 Vincent Parfait 843 France Telecom - Orange, Orange Business Services 845 Email: vincent.parfait@orange-ftgroup.com 847 Luyuan Fang 848 Cisco Systems, Inc. 850 Email: lufang@cisco.com 851 Lei Wang 852 Telenor 854 Email: lei.wang@telenor.com 856 Yuji Kamite 857 NTT Communications Corporation 859 Email: y.kamite@ntt.com 861 Shane Amante 862 Level 3 Communications, LLC 864 Email: shane@level3.net