From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6348.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc6348.txt (limited to 'doc/rfc/rfc6348.txt') diff --git a/doc/rfc/rfc6348.txt b/doc/rfc/rfc6348.txt new file mode 100644 index 0000000..18c2696 --- /dev/null +++ b/doc/rfc/rfc6348.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Le Roux, Ed. +Request for Comments: 6348 T. Morin, Ed. +Category: Historic France Telecom - Orange +ISSN: 2070-1721 September 2011 + + + Requirements for Point-to-Multipoint Extensions + to the Label Distribution Protocol + +Abstract + + This document lists a set of functional requirements that served as + input to the design of Label Distribution Protocol (LDP) extensions + for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), + in order to deliver point-to-multipoint applications over a + Multiprotocol Label Switching (MPLS) infrastructure. + + This work was overtaken by the protocol solution developed by the + MPLS working group, but that solution did not closely follow the + requirements documented here. This document is published as a + historic record of the ideas and requirements that shaped the + protocol work. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for the historical record. + + This document defines a Historic Document for the Internet community. + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6348. + + + + + + + + + + + + +Le Roux & Morin Historic [Page 1] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Le Roux & Morin Historic [Page 2] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Context and Motivations . . . . . . . . . . . . . . . . . 6 + 1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . . 7 + 2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 7 + 3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 8 + 4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 + 4.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.3. P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10 + 4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs . . . . 10 + 4.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10 + 4.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 11 + 4.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11 + 4.8. P2MP LSP Rerouting . . . . . . . . . . . . . . . . . . . . 11 + 4.9. Support for Multi-Access Networks . . . . . . . . . . . . 12 + 4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12 + 4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.12. IPv4/IPv6 Support . . . . . . . . . . . . . . . . . . . . 13 + 4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13 + 4.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 14 + 4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14 + 5. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15 + 6. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 16 + 6.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Contributing Authors . . . . . . . . . . . . . . . . . . . . . . . 20 + + + + + + + + + + + + +Le Roux & Morin Historic [Page 3] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +1. Introduction + + This document lists a set of functional requirements that served as + input to the design of Label Distribution Protocol (LDP) extensions + for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP) + [MLDP], in order to deliver point-to-multipoint applications over a + Multiprotocol Label Switching (MPLS) infrastructure. + + This work was overtaken by the protocol solution developed by the + MPLS working group and documented in [MLDP]. That solution did not + closely follow the requirements documented here, and it was + recognized that this document had served its purpose in driving + discussions of how the solution should be designed. At this point, + no further action is planned to update this document in line with the + protocol solution, and this document is published simply as a + historic record of the ideas and requirements that shaped the + protocol work. + + The document is structured as follows: + + o Section 2 is an overview of the requirements. + + o Section 3 illustrates an application scenario. + + o Section 4 addresses detailed requirements for P2MP LSPs. + + o Section 5 discusses requirements for shared trees and multipoint- + to-multipoint (MP2MP) LSPs. + + o Section 6 presents criteria against which a solution can be + evaluated. + +1.1. Requirements Language + + This document is a historic requirements document. To clarify + statement of requirements, key words are used as follows. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in [RFC2119]. + +1.2. Definitions + +1.2.1. Acronyms + + P2P: Point-to-Point + + MP2P: Multipoint-to-Point + + + + +Le Roux & Morin Historic [Page 4] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + P2MP: Point-to-Multipoint + + MP2MP: Multipoint-to-Multipoint + + LSP: Label Switched Path + + LSR: Label Switching Router + + PE: Provider Edge + + P: Provider + + IGP: Interior Gateway Protocol + + AS: Autonomous System + +1.2.2. Terminology + + The reader is assumed to be familiar with the terminology in + [RFC3031], [RFC5036], and [RFC4026]. + + Ingress LSR: + Router acting as a sender of an LSP + + Egress LSR: + Router acting as a receiver of an LSP + + P2P LSP: + An LSP that has one unique Ingress LSR and one unique Egress LSR + + MP2P LSP: + An LSP that has one or more Ingress LSRs and one unique Egress LSR + + P2MP LSP: + An LSP that has one unique Ingress LSR and one or more Egress LSRs + + MP2MP LSP: + An LSP that has one or more Leaf LSRs acting indifferently as + Ingress or Egress LSR + + Leaf LSR: + An Egress LSR of a P2MP LSP or an Ingress/Egress LSR of an MP2MP + LSP + + Transit LSR: + An LSR of a P2MP or MP2MP LSP that has one or more downstream LSRs + + + + + +Le Roux & Morin Historic [Page 5] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + Branch LSR: + An LSR of a P2MP or MP2MP LSP that has more than one downstream + LSR + + Bud LSR: + An LSR of a P2MP or MP2MP LSP that is an Egress but also has one + or more directly connected downstream LSR(s) + + P2MP tree: + The ordered set of LSRs and links that comprise the path of a P2MP + LSP from its Ingress LSR to all of its Egress LSRs. + +1.3. Context and Motivations + + LDP [RFC5036] has been deployed for setting up point-to-point (P2P) + and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point + services in MPLS backbones. + + There are emerging requirements for supporting delivery of point-to- + multipoint applications in MPLS backbones, such as those defined in + [RFC4834] and [RFC5501]. + + For various reasons, including consistency with P2P applications, and + taking full advantages of MPLS network infrastructure, it would be + highly desirable to use MPLS LSPs for the delivery of multicast + traffic. This could be implemented by setting up a group of P2P or + MP2P LSPs, but such an approach may be inefficient since it would + result in data replication at the Ingress LSR and duplicate data + traffic within the network. + + Hence, new mechanisms are required that would allow traffic from an + Ingress LSR to be efficiently delivered to a number of Egress LSRs in + an MPLS backbone on a point-to-multipoint LSP (P2MP LSP), avoiding + duplicate copies of a packet on a given link and relying on MPLS + traffic replication at some Branch LSRs. + + Resource Reservation Protocol - Traffic Engineering (RSVP-TE) + extensions for setting up point-to-multipoint Traffic Engineered LSPs + (P2MP TE LSPs) have been defined in [RFC4875]. They meet + requirements expressed in [RFC4461]. This approach is useful in + network environments where P2MP Traffic Engineering capabilities are + needed (optimization, QoS, fast recovery). + + However, for operators who want to support point-to-multipoint + traffic delivery on an MPLS backbone, without Traffic Engineering + needs, and who have already deployed LDP for P2P traffic, an + interesting and useful approach would be to rely on LDP extensions in + order to set up point-to-multipoint (P2MP) LSPs. This would bring + + + +Le Roux & Morin Historic [Page 6] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + consistency with P2P MPLS applications and would ease the delivery of + point-to-multipoint services in an MPLS backbone. + +1.4. Document Scope + + This document focuses on the LDP approach for setting up P2MP LSPs. + It lists a detailed set of requirements for P2MP extensions to LDP, + so as to deliver P2MP traffic over an LDP-enabled MPLS + infrastructure. The original intent was that these requirements + should be used as guidelines when specifying LDP extensions. + + Note that generic requirements for P2MP extensions to MPLS are out of + the scope of this document. Rather, this document describes + solution-specific requirements related to LDP extensions in order to + set up P2MP LSPs. + + Note also that other mechanisms could be used for setting up P2MP + LSPs (for instance, PIM extensions), but these are out of the scope + of this document. The objective is not to compare these mechanisms + but rather to focus on the requirements for an LDP extension + approach. + +2. Requirements Overview + + The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e., LSPs + with one Ingress LSR and one or more Egress LSRs, with traffic + replication at some Branch LSRs. + + The P2MP LDP mechanism MUST allow the addition or removal of leaves + associated with a P2MP LSP. + + The P2MP LDP mechanism MUST coexist with current LDP mechanisms and + inherit its capability sets from [RFC5036]. It is of paramount + importance that the P2MP LDP mechanism MUST NOT impede the operation + of existing P2P/MP2P LDP LSPs. Also, the P2MP LDP mechanism MUST + coexist with P2P and P2MP RSVP-TE mechanisms [RFC3209] [RFC4875]. It + is of paramount importance that the P2MP LDP mechanism MUST NOT + impede the operation of existing P2P and P2MP RSVP-TE LSPs. + + The P2MP LDP mechanism MAY also allow setting up multipoint-to- + multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting + indifferently as Ingress LSR or Egress LSR. This may allow a + reduction in the amount of LDP state that needs to be maintained by + an LSR. + + + + + + + +Le Roux & Morin Historic [Page 7] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +3. Application Scenario + + Figure 1 below illustrates an LDP-enabled MPLS provider network, used + to carry both unicast and multicast traffic of VPN customers + following, for instance, the architecture defined in [MVPN] for BGP/ + MPLS VPNs or the one defined in [VPLS-MCAST]. + + In this example, a set of MP2P LDP LSPs is set up between Provider + Edge (PE) routers to carry unicast VPN traffic within the MPLS + backbone (not represented in Figure 1). + + In this example, a set of P2MP LDP LSPs is set up between PE routers + acting as Ingress LSRs and PE routers acting as Egress LSRs, so as to + support multicast VPN traffic delivery within the MPLS backbone. + + For instance, a P2MP LDP LSP is set up between Ingress LSR PE1 and + Egress LSRs PE2, PE3, and PE4. It is used to transport multicast + traffic from PE1 to PE2, PE3, and PE4. P1 is a Branch LSR; it + replicates MPLS traffic sent by PE1 to P2, P3, and PE2. P2 and P3 + are non-Branch Transit LSRs; they forward MPLS traffic sent by P1 to + PE3 and PE4, respectively. + + PE1 + *| *** P2MP LDP LSP + *|***** + P1-----PE2 + */ \* + */ \* + *****/ \****** + PE3----P2 P3----PE4 + | | + | | + | | + PE5 PE6 + + Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4 + + + + + + + + + + + + + + + +Le Roux & Morin Historic [Page 8] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + If later there are new receivers attached to PE5 and PE6, then PE5 + and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and + replicate traffic received from P1 to PE3 and PE5 and to PE4 and PE6, + respectively (see Figure 2 below). + + PE1 + *| *** P2MP LDP LSP + *|***** + P1-----PE2 + */ \* + */ \* + *****/ \****** + PE3----P2 P3----PE4 + *| |* + *| |* + *| |* + PE5 PE6 + + Figure 2: Attachment of PE5 and PE6 + + The above example is provided for the sake of illustration. Note + that P2MP LSPs Ingress and Egress LSRs may not necessarily be PE + routers. Also, Branch LSRs may not necessarily be P routers. + +4. Detailed Requirements + +4.1. P2MP LSPs + + The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane + aspects related to P2MP LSPs are those already defined in [RFC4461]. + That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. + Traffic sent by the Ingress LSR is received by all Egress LSRs. The + specific aspect related to P2MP LSPs is the action required at a + Branch LSR, where data replication occurs. Incoming labeled data is + appropriately replicated to several outgoing interfaces, which may + use different labels. + + An LSR SHOULD NOT send more than one copy of a packet on any given + link of a P2MP LSP. Exceptions to this are mentioned in Sections 4.9 + and 4.18. + + A P2MP LSP MUST be identified by a constant and unique identifier + within the whole LDP domain, whatever the number of leaves, which may + vary dynamically. This identifier will be used so as to add/remove + leaves to/from the P2MP tree. + + + + + + +Le Roux & Morin Historic [Page 9] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +4.2. P2MP LSP FEC + + As with P2P MPLS technology [RFC5036], traffic MUST be classified + into a Forwarding Equivalence Class (FEC) in this P2MP extension. + All packets that belong to a particular P2MP FEC and that travel from + a particular node MUST use the same P2MP LSP. + + If existing FECs cannot be used for this purpose, a new LDP FEC that + is suitable for P2MP forwarding MUST be specified. + +4.3. P2MP LDP Routing + + As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support + hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the + information maintained in LSR Routing Information Bases (RIBs). + + It is RECOMMENDED that the P2MP LSP routing rely upon the unicast + route to the Ingress LSR to build a reverse path tree. + +4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs + + The P2MP LDP mechanism MUST support the establishment, maintenance, + and teardown of P2MP LSPs in a scalable manner. This MUST include + both the existence of a large number of P2MP LSPs within a single + network and a large number of Leaf LSRs for a single P2MP LSP (see + also Section 4.17 for scalability considerations and figures). + + In order to scale well with a large number of leaves, it is + RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For + that purpose, leaves will have to be aware of the P2MP LSP + identifier. The ways a Leaf LSR discovers P2MP LSP identifiers rely + on the applications that will use P2MP LSPs and are out of the scope + of this document. + + The P2MP LDP mechanism MUST allow the dynamic addition and removal of + leaves to and from a P2MP LSP, without any restriction (provided + there is network connectivity). It is RECOMMENDED that these + operations be leaf-initiated. These operations MUST NOT impact the + data transfer (packet loss, duplication, delay) towards other leaves. + It is RECOMMENDED that these operations do not cause any additional + processing except on the path from the added/removed Leaf LSR to the + Branch LSR. + +4.5. Label Advertisement + + The P2MP LDP mechanism MUST support downstream unsolicited label + advertisement mode. This is well suited to a leaf-initiated approach + and is consistent with P2P/MP2P LDP operations. + + + +Le Roux & Morin Historic [Page 10] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + Other advertisement modes MAY also be supported. + +4.6. Data Duplication + + Data duplication refers to the receipt of multiple copies of a packet + by any leaf. Although this may be a marginal situation, it may also + be detrimental for certain applications. Hence, data duplication + SHOULD be avoided as much as possible and limited to (hopefully rare) + transitory conditions. + + Note, in particular, that data duplication might occur if P2MP LSP + rerouting is being performed (see also Section 4.8). + +4.7. Detecting and Avoiding Loops + + The P2MP LDP extension MUST have a mechanism to detect routing loops. + This MAY rely on extensions to the LDP loop detection mechanism + defined in [RFC5036]. A loop detection mechanism MAY require + recording the set of LSRs traversed on the P2MP tree. The P2MP loop + avoidance mechanism MUST NOT impact the scalability of the P2MP LDP + solution. + + The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops + in the data plane even during transient events. + + Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the + data plane, which may trigger unexpected non-localized exponential + growth of traffic. + +4.8. P2MP LSP Rerouting + + The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in + the following cases: + + o Network failure (link or node); + + o A better path exists (e.g., new link or metric change); and + + o Planned maintenance. + + Given that P2MP LDP routing should rely on the RIB, the achievement + of the following requirements relies on the underlying routing + protocols (IGP, etc.). + + + + + + + + +Le Roux & Morin Historic [Page 11] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +4.8.1. Rerouting upon Network Failure + + The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case + of link or node failure(s) by relying upon update of the routes in + the RIB. The rerouting time SHOULD be minimized as much as possible + so as to reduce traffic disruption. + + A mechanism MUST be defined to prevent constant P2MP LSP teardown and + rebuild, which may be caused by the instability of a specific link/ + node in the network. This can rely on IGP dampening but may be + completed by specific dampening at the LDP level. + +4.8.2. Rerouting on a Better Path + + The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case + a better path is created in the network, for instance, as a result of + a metric change, a link repair, or the addition of links or nodes. + This will rely on update of the routes in the RIB. + +4.8.3. Rerouting upon Planned Maintenance + + The P2MP LDP mechanism MUST support planned maintenance operations. + It MUST be possible to reroute a P2MP LSP before a link/node is + deactivated for maintenance purposes. Traffic disruption and data + duplication SHOULD be minimized as much as possible during such + planned maintenance. P2MP LSP rerouting upon planned maintenance MAY + rely on a make-before-break procedure. + +4.9. Support for Multi-Access Networks + + The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send + a single copy of the data onto an interface to a multi-access network + (e.g., an Ethernet LAN) and reach multiple adjacent downstream nodes. + This requires that the same label be negotiated with all downstream + LSRs for the LSP. + + When there are several candidate upstream LSRs on an interface to a + multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all + downstream LSRs of a given P2MP LSP to select the same upstream LSR, + so as to avoid traffic replication. In addition, the P2MP LDP + mechanism SHOULD allow for an efficient balancing of a set of P2MP + LSPs among a set of candidate upstream LSRs on a LAN interface. + +4.10. Support for Encapsulation in P2P and P2MP TE Tunnels + + The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and + P2MP TE tunnels. + + + + +Le Roux & Morin Historic [Page 12] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP + LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a + single copy of the data onto the tunnel and reach all downstream LSRs + on the P2MP LSP, which are also Egress LSRs of the tunnel. As with + LAN interfaces, this requires that the same label be negotiated with + all downstream LSRs of the P2MP LDP LSP. + +4.11. Label Spaces + + Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or + dedicated label spaces. + + Note that dedicated label spaces will require the establishment of + separate P2P and P2MP LDP sessions. + +4.12. IPv4/IPv6 Support + + The P2MP LDP mechanism MUST support the establishment of LDP sessions + over both IPv4 and IPv6 control planes. + +4.13. Multi-Area/AS LSPs + + The P2MP LDP mechanism MUST support the establishment of multi-area + P2MP LSPs, i.e., LSPs whose leaves do not all reside in the same IGP + area as the Ingress LSR. This SHOULD be possible without requiring + the advertisement of Ingress LSRs' addresses across IGP areas. + + The P2MP LDP mechanism MUST also support the establishment of + inter-AS P2MP LSPs, i.e., LSPs whose leaves do not all reside in the + same AS as the Ingress LSR. This SHOULD be possible without + requiring the advertisement of Ingress LSRs' addresses across ASes. + +4.14. OAM + + LDP management tools ([RFC3815], etc.) will have to be enhanced to + support P2MP LDP extensions. This may yield a new MIB module, which + may possibly be inherited from the LDP MIB. + + Built-in diagnostic tools MUST be defined to check the connectivity, + trace the path, and ensure fast detection of data plane failures on + P2MP LDP LSPs. + + Further and precise requirements and mechanisms for P2MP MPLS + Operations, Administration, and Maintenance (OAM) purposes are out of + the scope of this document and are addressed in [RFC4687]. + + + + + + +Le Roux & Morin Historic [Page 13] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +4.15. Graceful Restart and Fault Recovery + + LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery + mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs. + +4.16. Robustness + + A solution MUST be designed to re-establish connectivity for P2MP and + MP2MP LSPs in the event of failures, provided there exists network + connectivity between ingress and egress nodes (i.e., designed without + introducing single points of failure). + +4.17. Scalability + + Scalability is a key requirement for the P2MP LDP mechanism. It MUST + be designed to scale well with an increase in the number of any of + the following: + + o Number of Leaf LSRs per P2MP LSP; + + o Number of downstream LSRs per Branch LSR; and + + o Number of P2MP LSPs per LSR. + + In order to scale well with an increase in the number of leaves, it + is RECOMMENDED that the size of a P2MP LSP state on an LSR, for one + particular LSP, depend only on the number of adjacent LSRs on the + LSP. + +4.17.1. Orders of Magnitude Expected in Operational Networks + + Typical orders of magnitude that we expect should be supported are: + + o Tens of thousands of P2MP trees spread out across core network + routers; and + + o Hundreds, or a few thousands, of leaves per tree. + + See also Section 4.2 of [RFC4834]. + +4.18. Backward Compatibility + + In order to allow for a smooth migration, the P2MP LDP mechanism + SHOULD offer as much backward compatibility as possible. In + particular, the solution SHOULD allow the setup of a P2MP LSP along + non-Branch Transit LSRs that do not support P2MP LDP extensions. + + + + + +Le Roux & Morin Historic [Page 14] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + Also, the P2MP LDP solution MUST coexist with current LDP mechanisms + and inherit its capability sets from [RFC5036]. The P2MP LDP + solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP + solution MUST be designed in such a way that it allows P2P/MP2P and + P2MP LSPs to be signaled on the same interface. + +5. Shared Trees + + For traffic delivery between a group of N LSRs that act as egress + and/or egress nodes on different P2MP flows, it may be useful to set + up a shared tree connecting all these LSRs instead of having N P2MP + LSPs. This would reduce the amount of control and forwarding state + that has to be maintained on a given LSR. + + There are two main options for supporting such shared trees: + + o Relying on the applications' protocols that use LDP LSPs. A + shared tree could consist of the combination of an MP2P LDP LSP + from Leaf LSRs to a given root node with a P2MP LSP from this root + to Leaf LSRs. For instance, with Multicast L3 VPN applications, + it would be possible to build a shared tree by combining (see + [MVPN]): + + * An MP2P unicast LDP LSP, from each PE router of the group to a + particular root PE router acting as tree root and + + * A P2MP LDP LSP from this root PE router to each PE router of + the group. + + o Relying on a specific LDP mechanism allowing the setup of + multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). + + The former approach (combination of MP2P and P2MP LSPs at the + application level) is out of the scope of this document while the + latter (MP2MP LSPs) is within the scope of this document. + Requirements for the setup of MP2MP LSPs are listed below. + +5.1. Requirements for MP2MP LSPs + + A multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group + of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by + any Leaf LSR is received by all other Leaf LSRs of the group. + + Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. + An implementation that supports P2MP LDP LSPs MAY also support MP2MP + LDP LSPs. + + The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP. + + + +Le Roux & Morin Historic [Page 15] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + Requirements for P2MP LSPs, set forth in Section 4, apply equally to + MP2MP LSPs. Particular attention should be given to the requirements + below: + + o The solution MUST support recovery upon link and transit node + failure and be designed to re-establish connectivity for MP2MP + LSPs in the event of failures, provided network connectivity + exists between ingress and egress nodes (i.e., designed without + introducing single points of failure). + + o The size of MP2MP state on an LSR, for one particular MP2MP LSP, + SHOULD only depend on the number of adjacent LSRs on the LSP. + + o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that + may trigger exponential growth of traffic. Note that this + requirement is more challenging with MP2MP LSPs as an LSR may need + to receive traffic for a given LSP on multiple interfaces. + + There are additional requirements specific to MP2MP LSPs: + + o It is RECOMMENDED that an MP2MP MPLS LSP is built based on the + unicast route to a specific LSR called root LSR. + + o It is RECOMMENDED to define several root LSRs (e.g., a primary and + a backup) to ensure redundancy upon root LSR failure. + + o The receiver SHOULD NOT receive back a packet it has sent on the + MP2MP LSP. + + o The solution SHOULD avoid that all traffic between any pair of + leaves is traversing a root LSR (similarly to PIM-Bidir trees) and + SHOULD provide the operator with means to minimize the delay + between two leaves. + + o It MUST be possible to check connectivity of an MP2MP LSP in both + directions. + +6. Evaluation Criteria + +6.1. Performance + + The solution will be evaluated with respect to the following + criteria: + + (1) Efficiency of network resource usage; + + (2) Time to add or remove a Leaf LSR; + + + + +Le Roux & Morin Historic [Page 16] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + (3) Time to repair a P2MP LSP in case of link or node failure; and + + (4) Scalability (state size, number of messages, message size). + + Particularly, the P2MP LDP mechanism SHOULD be designed with the key + objective of minimizing the additional amount of state and additional + processing required in the network. + + Also, the P2MP LDP mechanism SHOULD be designed so that convergence + times in case of link or node failure are minimized, in order to + limit traffic disruption. + +6.2. Complexity and Risks + + The proposed solution SHOULD NOT introduce complexity to the current + LDP operations to such a degree that it would affect the stability + and diminish the benefits of deploying such solution. + +7. Security Considerations + + It is expected that addressing the requirements defined in this + document should not introduce any new security issues beyond those + inherent to LDP and that a P2MP LDP solution will rely on the + security mechanisms defined in [RFC5036] (e.g., TCP MD5 Signature). + + An evaluation of the security features for MPLS networks may be found + in [RFC5920], and where issues or further work is identified by that + document, new security features or procedures for the MPLS protocols + will need to be developed. + +8. Acknowledgments + + We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina + Minei, Dean Cheng, and Benjamin Niven-Jenkins for their highly useful + comments and suggestions. We would like to thank Adrian Farrel for + reviewing this document before publication. + + We would also like to thank the authors of [RFC4461], which inspired + some of the text in this document. + + + + + + + + + + + + +Le Roux & Morin Historic [Page 17] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", RFC 3031, + January 2001. + + [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful + Restart Mechanism for Label Distribution Protocol", + RFC 3478, February 2003. + + [RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution + Protocol (LDP)", RFC 3479, February 2003. + + [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, + "Definitions of Managed Objects for the Multiprotocol + Label Switching (MPLS), Label Distribution Protocol + (LDP)", RFC 3815, June 2004. + + [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- + Multipoint Traffic-Engineered MPLS Label Switched Paths + (LSPs)", RFC 4461, April 2006. + + [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP + Specification", RFC 5036, October 2007. + +9.2. Informative References + + [MLDP] Minei, I., Wijnands, I., Kompella, K., and B. Thomas, + "Label Distribution Protocol Extensions for Point-to- + Multipoint and Multipoint-to-Multipoint Label Switched + Paths", Work in Progress, August 2011. + + [MVPN] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, + Y., Rosen, E., Wijnands, I., and S. Yasukawa, + "Multicast in MPLS/BGP IP VPNs", Work in Progress, + January 2010. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, + V., and G. Swallow, "RSVP-TE: Extensions to RSVP for + LSP Tunnels", RFC 3209, December 2001. + + + + + + +Le Roux & Morin Historic [Page 18] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + + [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned + Virtual Private Network (VPN) Terminology", RFC 4026, + March 2005. + + [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, + "Operations and Management (OAM) Requirements for + Point-to-Multipoint MPLS Networks", RFC 4687, + September 2006. + + [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 + Provider-Provisioned Virtual Private Networks + (PPVPNs)", RFC 4834, April 2007. + + [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, + "Extensions to Resource Reservation Protocol - Traffic + Engineering (RSVP-TE) for Point-to-Multipoint TE Label + Switched Paths (LSPs)", RFC 4875, May 2007. + + [RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. + Fang, "Requirements for Multicast Support in Virtual + Private LAN Services", RFC 5501, March 2009. + + [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [VPLS-MCAST] Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, + "Multicast in VPLS", Work in Progress, July 2011. + + + + + + + + + + + + + + + + + + + + + + + + +Le Roux & Morin Historic [Page 19] + +RFC 6348 Reqs for P2MP Extensions to LDP September 2011 + + +Contributing Authors + + Vincent Parfait + France Telecom - Orange, Orange Business Services + + EMail: vincent.parfait@orange-ftgroup.com + + + Luyuan Fang + Cisco Systems, Inc. + + EMail: lufang@cisco.com + + + Lei Wang + Telenor + + EMail: lei.wang@telenor.com + + + Yuji Kamite + NTT Communications Corporation + + EMail: y.kamite@ntt.com + + + Shane Amante + Level 3 Communications, LLC + + EMail: shane@level3.net + +Authors' Addresses + + Jean-Louis Le Roux (editor) + France Telecom - Orange + + EMail: jeanlouis.leroux@orange-ftgroup.com + + + Thomas Morin (editor) + France Telecom - Orange + + EMail: thomas.morin@orange-ftgroup.com + + + + + + + + +Le Roux & Morin Historic [Page 20] + -- cgit v1.2.3