idnits 2.17.1 draft-ietf-mpls-mp-ldp-reqs-06.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 (December 01, 2010) is 4894 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-08 Summary: 0 errors (**), 0 flaws (~~), 2 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 4 Intended status: Informational V. Parfait 5 Expires: June 4, 2011 France Telecom - Orange 6 L. Fang 7 Cisco 8 L. Wang 9 Telenor 10 Y. Kamite 11 NTT 12 S. Amante 13 Level3 14 December 01, 2010 16 Requirements for Point-To-Multipoint Extensions to the Label 17 Distribution Protocol 18 draft-ietf-mpls-mp-ldp-reqs-06 20 Abstract 22 This document lists a set of functional requirements for Label 23 Distribution Protocol (LDP) extensions for setting up point-to- 24 multipoint (P2MP) Label Switched Paths (LSP), in order to deliver 25 point-to-multipoint applications over a Multi Protocol Label 26 Switching (MPLS) infrastructure. It is intended that solutions that 27 specify LDP procedures for setting up P2MP LSP satisfy these 28 requirements. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on June 4, 2011. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 3. Problem Statement and Requirements Overview . . . . . . . . . 6 87 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 88 3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7 89 4. Application scenario . . . . . . . . . . . . . . . . . . . . . 7 90 5. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 91 5.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9 92 5.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 9 93 5.3. P2MP LDP routing . . . . . . . . . . . . . . . . . . . . . 9 94 5.4. Setting up, tearing down and modifying P2MP LSPs . . . . . 9 95 5.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10 96 5.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 10 97 5.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 10 98 5.8. P2MP LSP Re-routing . . . . . . . . . . . . . . . . . . . 11 99 5.9. Support for LAN interfaces . . . . . . . . . . . . . . . . 12 100 5.10. Support for encapsulation in P2P and P2MP TE tunnels . . . 12 101 5.11. Label spaces . . . . . . . . . . . . . . . . . . . . . . . 12 102 5.12. IPv4/IPv6 support . . . . . . . . . . . . . . . . . . . . 12 103 5.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 12 104 5.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 5.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 13 106 5.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 13 107 5.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 108 5.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14 109 6. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 14 110 6.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15 111 7. Evaluation criteria . . . . . . . . . . . . . . . . . . . . . 16 112 7.1. Performances . . . . . . . . . . . . . . . . . . . . . . . 16 113 7.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 16 114 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 116 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 122 1. Definitions 124 1.1. Acronyms 126 P2P: Point-To-Point 128 P2MP: Point-To-MultiPoint 130 MP2MP: MultiPoint-To-Multipoint 132 PE: Provider Edge router 134 P: Provider router 136 IGP: Interior Gateway Protocol 138 AS: Autonomous System 140 1.2. Terminology 142 The reader is assumed to be familiar with the terminology in 143 [RFC3031], [RFC5036], and [RFC4026]. 145 Ingress LSR: 146 Router acting as a sender of an LSP 148 Egress LSR: 149 Router acting as a receiver of an LSP 151 P2P LSP: 152 A LSP that has one unique Ingress LSR and one unique Egress LSR 154 MP2P LSP: 155 A LSP that has one or more Ingress LSRs and one unique Egress LSR 157 P2MP LSP: 158 A LSP that has one unique Ingress LSR and one or more Egress LSRs 160 MP2MP LSP: 161 A LSP that as one or more Leaf LSRs acting indifferently as 162 Ingress or Egress LSR 164 Leaf LSR: 165 Egress LSR of a P2MP LSP or Ingress/Egress LSR of a MP2MP LSP 167 Transit LSR: 168 A LSR of a P2MP or MP2MP LSP that has one or more Downstream LSRs 170 Branch LSR: 171 A LSR of a P2MP or MP2MP LSP that has more than one downstream LSR 173 Bud LSR: 174 A LSR of a P2MP or MP2MP LSP that is an egress but also has one or 175 more directly connected downstream LSR(s) 177 P2MP tree: 178 The ordered set of LSRs and links that comprise the path of a P2MP 179 LSP from its ingress LSR to all of its egress LSRs. 181 2. Introduction 183 LDP [RFC5036] has been deployed for setting up point-to-point (P2P) 184 and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point 185 services in MPLS backbones. 187 There are emerging requirements for supporting delivery of point-to- 188 multipoint applications in MPLS backbones, such as those defined in 189 [RFC4834] and [RFC5501]. 191 This requires mechanisms for setting up point-to-multipoint LSPs 192 (P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, 193 and with MPLS traffic replication at some Branch LSRs. 195 RSVP-TE extensions for setting up Point-To-Multipoint Traffic 196 Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875]. They 197 meet requirements expressed in [RFC4461]. This approach is useful, 198 in network environments where P2MP Traffic Engineering capabilities 199 are needed (Optimization, QoS, Fast recovery). 201 However for operators who want to support point-to-multipoint traffic 202 delivery on an MPLS backbone, without Traffic Engineering needs, and 203 have already deployed LDP for P2P traffic, an interesting and useful 204 approach would be to rely on LDP extensions in order to setup point- 205 to-multipoint (P2MP) LSPs. This would bring consistency with P2P 206 MPLS applications and would ease the delivery of point-to-multipoint 207 services in an MPLS backbone. 209 This document focuses on the LDP approach for setting up P2MP LSPs. 210 It lists a detailed set of requirements for P2MP extensions to LDP, 211 so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. 212 These requirements should be used as guidelines when specifying LDP 213 extensions. It is intended that solutions that specify LDP 214 procedures for P2MP LSP setup, satisfy these requirements. 216 Note that generic requirements for P2MP extensions to MPLS are out of 217 the scope of this document. Rather this document describes solution 218 specific requirements related to LDP extensions in order to set up 219 P2MP LSPs. 221 Note also that other mechanisms could be used for setting up P2MP 222 LSPs, such as for instance PIM extensions, but these are out of the 223 scope of this document. The objective is not to compare these 224 mechanisms but rather to focus on the requirements for an LDP 225 extension approach. 227 The document is structured as follows: 229 o Section 3 points out the problem statement; 231 o Section 4 illustrates an application scenario; 233 o Section 5 addresses detailed requirements for P2MP LSPs; 235 o Section Section 6 finally discusses requirements for shared trees 236 and MultiPoint-to-MultiPoint (MP2MP) LSPs. 238 3. Problem Statement and Requirements Overview 240 3.1. Problem Statement 242 LDP [RFC5036] has been deployed for setting up P2P and MP2P MPLS LSPs 243 as PE-to-PE tunnels so as to carry point-to-point traffic essentially 244 in Layer 3 and Layer 2 VPN networks. There are emerging requirements 245 for supporting multicast traffic delivery within these VPN 246 infrastructures ([RFC4834] and [RFC5501]). For various reasons, 247 including consistency with P2P applications, and taking full 248 advantages of MPLS network infrastructure, it would be highly 249 desirable to use MPLS LSPs for the delivery of multicast traffic. 250 This could be implemented by setting up a group of P2P or MP2P LSPs, 251 but such an approach may be sub-optimal since it would result in data 252 replication at the ingress LSR, and bandwidth inefficiency (duplicate 253 data traffic within the network). Hence new mechanisms are required 254 that would allow traffic from an Ingress LSR to be efficiently 255 delivered to a number of Egress LSRs in an MPLS backbone, avoiding 256 duplicate copies of a packet on a given link. 258 Such efficient traffic delivery requires setting up P2MP LSPs. A 259 P2MP LSP is an LSP starting at an Ingress LSR, and ending on a set of 260 one or more Egress LSRs. Traffic sent by the Ingress LSR is 261 replicated on one or more Branch LSRs down to Egress LSRs. 263 RSVP-TE extensions for setting up P2MP TE LSPs, which meet 264 requirements expressed in [RFC4461], have been defined in [RFC4875]. 265 This approach is useful, in network environments where Traffic 266 Engineering capabilities are required. However, for operators that 267 deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and without 268 the need for traffic engineering, an interesting approach would be 269 using LDP extensions for setting up P2MP LSPs. 271 The following gives a set of guidelines that a specification of LDP 272 extensions for setting up P2MP LSPs should follow. 274 3.2. Requirements overview 276 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs 277 with one Ingress LSR and one or more Egress LSRs, with traffic 278 replication at some Branch LSRs. 280 The P2MP LDP mechanism MUST allow the addition or removal of leaves 281 associated with a P2MP LSP. 283 The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and 284 inherit its capability sets from [RFC5036]. It is of paramount 285 importance that the P2MP LDP mechanism MUST NOT impede the operation 286 of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co- 287 exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It 289 is of paramount importance that the P2MP LDP mechanism MUST NOT 290 impede the operation of existing P2P and P2MP RSVP-TE LSPs. 292 The P2MP LDP mechanism MAY also allow setting up multipoint-to- 293 multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting 294 indifferently as Ingress LSR or Egress LSR. This may allow a 295 reduction in the amount of LDP state that needs to be maintained by a 296 LSR. 298 4. Application scenario 300 Figure 1 below illustrates an LDP enabled MPLS provider network, used 301 to carry both unicast and multicast traffic of VPN customers 302 following for instance the architecture defined in 303 [I-D.ietf-l3vpn-2547bis-mcast] for BGP/MPLS VPNs, or the one defined 304 in [I-D.ietf-l2vpn-vpls-mcast]. 306 In this example, a set of MP2P LDP LSPs are setup between Provider 307 Edge (PE) routers to carry unicast VPN traffic within the MPLS 308 backbone. 310 And in this example a set of P2MP LDP LSPs are setup between PE 311 routers acting as Ingress LSRs and PE routers acting as Egress LSRs, 312 so as to support multicast VPN traffic delivery within the MPLS 313 backbone. 315 For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and 316 Egress LSRs PE2, PE3, and PE4. It is used to transport multicast 317 traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it 318 replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are 319 non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 320 and PE4 respectively. 322 PE1 323 *| *** P2MP LDP LSP 324 *|***** 325 P1-----PE2 326 */ \* 327 */ \* 328 *****/ \****** 329 PE3----P2 P3----PE4 330 | | 331 | | 332 | | 333 PE5 PE6 335 Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4. 337 If later there are new receivers attached to PE5 and PE6, then PE5 338 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and 339 replicate traffic received from P1, to PE3 and PE5, and to PE4 and 340 PE6 respectively (see Figure 2 below). 342 PE1 343 *| *** P2MP LDP LSP 344 *|***** 345 P1-----PE2 346 */ \* 347 */ \* 348 *****/ \****** 349 PE3----P2 P3----PE4 350 *| |* 351 *| |* 352 *| |* 353 PE5 PE6 355 Figure 2: Attachment of PE5 and PE6. 357 The above example is provided for the sake of illustration. Note 358 that P2MP LSPs ingress and egress LSRs may not necessarily be PE 359 routers. Also branch LSRs may not necessarily be P routers. 361 5. Detailed Requirements 363 5.1. P2MP LSPs 365 The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane 366 aspects related to P2MP LSPs are those already defined in [RFC4461]. 367 That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. 368 Traffic sent by the Ingress LSR is received by all Egress LSRs. The 369 specific aspects related to P2MP LSPs is the action required at a 370 Branch LSR, where data replication occurs. Incoming labelled data is 371 appropriately replicated to several outgoing interfaces which may use 372 different labels. Only one copy of a packet MUST be sent on a given 373 link of a P2MP LSP. 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 5.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 As such, a new LDP FEC that is suitable for P2MP forwarding MUST be 388 specified. 390 5.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 a shortest path 397 to the Ingress LSR so as to setup an MPLS shortest path tree. 399 5.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 5.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 5.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 5.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 6.8). 442 5.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 5.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 also implies the underlying routing 471 protocols (IGP, etc.). 473 5.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 will rely on IGP dampening but may be 483 completed by specific dampening at the LDP level. 485 5.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 5.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 5.9. Support for LAN interfaces 503 The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send 504 a single copy of the data onto an Ethernet LAN interface and reach 505 multiple adjacent downstream nodes. This requires that the same 506 label be negotiated with all downstream LSRs for the LSP. 508 When there are several candidate upstream LSRs on a LAN interface, 509 the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs 510 of a given P2MP LSP to select the same upstream LSR, so as to avoid 511 traffic replication. In addition, the P2MP LDP mechanism SHOULD 512 allow for an efficient balancing of a set of P2MP LSPs among a set of 513 candidate upstream LSRs on a LAN interface. 515 5.10. Support for encapsulation in P2P and P2MP TE tunnels 517 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and 518 P2MP TE tunnels. 520 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP 521 LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a 522 single copy of the data onto the tunnel and reach all downstream LSRs 523 on the P2MP LSP, which are also Egress LSRs of the tunnel. As with 524 LAN interfaces, this requires that the same label be negotiated with 525 all downstream LSRs of the P2MP LDP LSP. 527 5.11. Label spaces 529 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or 530 dedicated label spaces. 532 Note that dedicated label spaces will require the establishment of 533 separate P2P and P2MP LDP sessions. 535 5.12. IPv4/IPv6 support 537 The P2MP LDP mechanism MUST support the establishment of LDP sessions 538 over both IPv4 and IPv6 control planes. 540 5.13. Multi-Area/AS LSPs 542 The P2MP LDP mechanism MUST support the establishment of multi-area 543 P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP 544 area as the Ingress LSR. This SHOULD be possible without requiring 545 the advertisement of Ingress LSRs' addresses across IGP areas. 547 The P2MP LDP mechanism MUST also support the establishment of 548 inter-AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the 549 same AS as the Ingress LSR. This SHOULD be possible without 550 requiring the advertisement of Ingress LSRs' addresses across ASes. 552 5.14. OAM 554 LDP management tools ([RFC3815], etc.) will have to be enhanced to 555 support P2MP LDP extensions. This may yield a new MIB module, which 556 may possibly be inherited from the LDP MIB. 558 Built-in diagnostic tools MUST be defined to check the connectivity, 559 trace the path and ensure fast detection of data plane failures on 560 P2MP LDP LSPs. 562 Further and precise requirements and mechanisms for P2MP MPLS OAM 563 purpose are out of the scope of this document and are addressed in 564 [RFC4687]. 566 5.15. Graceful Restart and Fault Recovery 568 LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery 569 mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs. 571 5.16. Robustness 573 A solution MUST avoid single points of failures provided there is 574 enough network connectivity. 576 5.17. Scalability 578 Scalability is a key requirement for the P2MP LDP mechanism. It MUST 579 be designed to scale well with an increase in the number of any of 580 the following: 582 o number of Leaf LSRs per P2MP LSP; 584 o number of Downstream LSRs per Branch LSR; 586 o number of P2MP LSPs per LSR. 588 In order to scale well with an increase in the number of leaves, it 589 is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one 590 particular LSP, depend only on the number of adjacent LSRs on the 591 LSP. 593 5.17.1. Orders of magnitude expected in operational networks 595 Typical orders of magnitude that we expect should be supported are: 597 o tens of thousands of P2MP trees spread out across core network 598 routers; 600 o hundreds, or a few thousands, of leaves per tree; 602 See also section 4.2 of [RFC4834]. 604 5.18. Backward Compatibility 606 In order to allow for a smooth migration, the P2MP LDP mechanism 607 SHOULD offer as much backward compatibility as possible. In 608 particular, the solution SHOULD allow the setup of a P2MP LSP along 609 non-Branch Transit LSRs that do not support P2MP LDP extensions. 611 Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms 612 and inherit its capability sets from [RFC5036]. The P2MP LDP 613 solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP 614 solution MUST be designed in such a way that it allows P2P/MP2P and 615 P2MP LSPs to be signalled on the same interface. 617 6. Shared Trees 619 For traffic delivery between a group of N Leaf LSRs which are acting 620 indifferently as Ingress or Egress LSRs, it may be useful to setup a 621 shared tree connecting all these LSRs, instead of having N P2MP LSPs. 622 This would reduce the amount of control and forwarding state that has 623 to be maintained on a given LSR. 625 There are actually two main options for supporting such shared trees: 627 o This could rely on the applications protocols that use LDP LSPs. 628 A shared tree could consist of the combination of a MP2P LDP LSP 629 from Leafs LSRs to a given root node, with a P2MP LSP from this 630 root to Leaf LSRs. For instance with Multicast L3 VPN 631 applications, it would be possible to build a shared tree by 632 combining (see [I-D.ietf-l3vpn-2547bis-mcast]): 634 * a MP2P unicast LDP LSP, from each PE of the group to a 635 particular root PE acting as tree root, 637 * with a P2MP LDP LSP from this root PE to each PE of the group. 639 o Or this could rely on a specific LDP mechanism allowing to setup 640 multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). 642 The former approach (Combination of MP2P and P2MP LSPs at the 643 application level) is out of the scope of this document while the 644 latter (MP2MP LSPs) belong to the scope of this document. 645 Requirements for the set up of MP2MP LSPs are listed below. 647 6.1. Requirements for MP2MP LSPs 649 A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting 650 indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf 651 LSR is received by all other Leaf LSRs of the group. 653 Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. 654 An implementation that support P2MP LDP LSPs MAY also support MP2MP 655 LDP LSP. 657 The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP. 659 Requirements for P2MP LSPs, set forth in section 6, apply equally to 660 MP2MP LSPs. Particular attention should be given on the below 661 requirements: 663 o The solution MUST support recovery upon link and transit node 664 failure and there MUST NOT be any single point of failure 665 (provided network connectivity is redundant); 667 o The size of MP2MP state on a LSR, for one particular MP2MP LSP, 668 SHOULD only depend on the number of adjacent LSRs on the LSP; 670 o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that 671 may trigger exponential growth of traffic. Note that this 672 requirement is more challenging with MP2MP LSPs as a LSR can 673 receive traffic for a given LSP on multiple interfaces. 675 There are additional requirements specific to MP2MP LSPs: 677 o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a 678 specific LSR called root LSR; 680 o It is RECOMMENDED to define several root LSRs (e.g. a primary and 681 a backup) to ensure redundancy upon root LSR failure; 683 o The receiver SHOULD NOT receive back a packet it has sent on the 684 MP2MP LSP; 686 o The solution SHOULD avoid that all traffic between any pair of 687 leaves is traversing a root LSR, and SHOULD as much as possible 688 minimize the distance between two leaves (similarly to PIM-Bidir 689 trees); 691 o It MUST be possible to check connectivity of a MP2MP LSP in both 692 directions. 694 7. Evaluation criteria 696 7.1. Performances 698 The solution will be evaluated with respect to the following 699 criteria: 701 (1) Time to add or remove a Leaf LSR; 703 (2) Time to repair a P2MP LSP in case of link or node failure; 705 (3) Scalability (state size, number of messages, message size). 707 Particularly the P2MP LDP mechanism SHOULD be designed with as key 708 objective to minimize the additional amount of state and additional 709 processing required in the network. 711 Also, the P2MP LDP mechanism SHOULD be designed so that convergence 712 times in case of link or node failure are minimized, in order to 713 limit traffic disruption. 715 7.2. Complexity and Risks 717 The proposed solution SHOULD NOT introduce complexity to the current 718 LDP operations to such a degree that it would affect the stability 719 and diminish the benefits of deploying such solution. 721 8. Security Considerations 723 This document does not introduce any new security issue beyond those 724 inherent to LDP, and a P2MP LDP solution will rely on the security 725 mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature). 727 An evaluation of the security features for MPLS networks may be found 728 in [RFC5920], and where issues or further work is identified by that 729 document, new security features or procedures for the MPLS protocols 730 will need to be developed. 732 9. IANA Considerations 734 This informational document makes no requests to IANA for action. 736 10. Acknowledgments 738 We would like to thank Christian Jacquenet (France Telecom), Hitoshi 739 Fukuda (NTT), Ina Minei (Juniper), Dean Cheng (Cisco), and Benjamin 740 Niven-Jenkins (BT), for their highly useful comments and suggestions. 742 We would also like to thank authors of [RFC4461] from which some text 743 of this document has been inspired. 745 11. References 747 11.1. Normative References 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, March 1997. 752 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 753 Label Switching Architecture", RFC 3031, January 2001. 755 [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful 756 Restart Mechanism for Label Distribution Protocol", 757 RFC 3478, February 2003. 759 [RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution 760 Protocol (LDP)", RFC 3479, February 2003. 762 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 763 of Managed Objects for the Multiprotocol Label Switching 764 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, 765 June 2004. 767 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 768 Specification", RFC 5036, October 2007. 770 11.2. Informative References 772 [I-D.ietf-l2vpn-vpls-mcast] 773 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 774 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work 775 in progress), October 2010. 777 [I-D.ietf-l3vpn-2547bis-mcast] 778 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 779 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 780 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 781 in progress), January 2010. 783 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 784 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 785 Tunnels", RFC 3209, December 2001. 787 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 788 Private Network (VPN) Terminology", RFC 4026, March 2005. 790 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 791 Multipoint Traffic-Engineered MPLS Label Switched Paths 792 (LSPs)", RFC 4461, April 2006. 794 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 795 "Operations and Management (OAM) Requirements for Point- 796 to-Multipoint MPLS Networks", RFC 4687, September 2006. 798 [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 799 Provider-Provisioned Virtual Private Networks (PPVPNs)", 800 RFC 4834, April 2007. 802 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 803 "Extensions to Resource Reservation Protocol - Traffic 804 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 805 Switched Paths (LSPs)", RFC 4875, May 2007. 807 [RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, 808 "Requirements for Multicast Support in Virtual Private LAN 809 Services", RFC 5501, March 2009. 811 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 812 Networks", RFC 5920, July 2010. 814 Authors' Addresses 816 Jean-Louis (editor) 817 France Telecom - Orange 819 Email: jeanlouis.leroux@orange-ftgroup.com 821 Thomas Morin 822 France Telecom - Orange 824 Email: thomas.morin@orange-ftgroup.com 825 Vincent Parfait 826 France Telecom - Orange, Orange Business Services 828 Email: vincent.parfait@orange-ftgroup.com 830 Luyuan Fang 831 Cisco Systems, Inc. 833 Email: lufang@cisco.com 835 Lei Wang 836 Telenor 838 Email: lei.wang@telenor.com 840 Yuji Kamite 841 NTT Communications Corporation 843 Email: y.kamite@ntt.com 845 Shane Amante 846 Level 3 Communications, LLC 848 Email: shane@level3.net