summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6348.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6348.txt')
-rw-r--r--doc/rfc/rfc6348.txt1123
1 files changed, 1123 insertions, 0 deletions
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]
+