RFC 6348

Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol

📅 published September 2011, from ietf

Abstract 🌸

Okay bestie, so this doc is basically a wishlist of requirements 📝 that helped shape some LDP extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSPs), so apps can deliver one-to-many traffic over an MPLS network 🚀. The protocol solution that came out of the MPLS working group ended up going its own way and didn't really follow these requirements closely. So this doc is kept as a historic record of the ideas that got the whole conversation started 🦋

Status of This Memo ✨

This one is not an Internet Standards Track spec. It's published purely for the historical record 📚

This document defines a Historic Document for the Internet community 🏛️ It's a product of the Internet Engineering Task Force (IETF), it represents IETF community consensus, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 💅

Want the latest status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc6348 🌈

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 🧐 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 🔥

Some material in here may come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control copyright on some of that stuff may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So without a proper license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside that process either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

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

1. Introduction ✨

This doc lists a set of functional requirements that helped design LDP (Label Distribution Protocol) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP) [MLDP]. The goal is delivering point-to-multipoint apps over a Multiprotocol Label Switching (MPLS) infrastructure 🧚

The MPLS working group later built its own protocol solution, documented in [MLDP], and it didn't closely follow the requirements in here. Everyone agreed this doc had done its job by kicking off design discussions 💅 No further updates are planned to bring it in line with the final solution, so it's just a historic record of the ideas and requirements that shaped the protocol work 🦋

The doc is laid out like this:

  • Section 2 is an overview of the requirements. 🌸
  • Section 3 illustrates an application scenario. 🎀
  • Section 4 addresses detailed requirements for P2MP LSPs. 💜
  • Section 5 discusses requirements for shared trees and multipoint-to-multipoint (MP2MP) LSPs. 🌈
  • Section 6 presents criteria against which a solution can be evaluated. ⭐

1.1. Requirements Language

This doc is a historic requirements document 📜 To make the requirements clear, the 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]. It's giving official vibes, periodt 💅

1.2. Definitions

1.2.1. Acronyms

Here's the acronym cheat sheet 📝

  • P2P: Point-to-Point 🫶
  • MP2P: Multipoint-to-Point
  • 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

You're assumed to already know the terminology in [RFC3031], [RFC5036], and [RFC4026], so no pressure 😌 Here are the terms this doc leans on:

  • 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 🚌
  • 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, so operators can offer point-to-point services in MPLS backbones 🏗️

There are emerging requirements for supporting delivery of point-to-multipoint apps in MPLS backbones, like the ones defined in [RFC4834] and [RFC5501] 👀

It's highly desirable to use MPLS LSPs for delivering multicast traffic, for lots of reasons. One is consistency with P2P apps, and another is fully taking advantage of the MPLS network infrastructure ✨ You could do this by setting up a group of P2P or MP2P LSPs, but that can be inefficient 😬 It would mean data replication at the Ingress LSR and duplicate data traffic inside the network 🙈

So new mechanisms are required. They'd let traffic from an Ingress LSR get efficiently delivered to a bunch of Egress LSRs across an MPLS backbone, using a point-to-multipoint LSP (P2MP LSP). That avoids duplicate copies of a packet on any given link and relies 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) were already defined in [RFC4875]. They meet the requirements in [RFC4461]. This approach is useful where P2MP Traffic Engineering capabilities are needed, like for optimization, QoS, and fast recovery 🏎️

But some operators want point-to-multipoint traffic delivery on an MPLS backbone without Traffic Engineering needs, and they've already deployed LDP for P2P traffic. For them, an interesting and useful approach is relying on LDP extensions to set up P2MP LSPs 💜 That keeps things consistent with P2P MPLS apps and makes delivering point-to-multipoint services across an MPLS backbone way easier 🦋

1.4. Document Scope 🎀

okay so this doc is all about the LDP approach for setting up P2MP LSPs 🦋. It lists a detailed set of requirements for P2MP extensions to LDP, so P2MP traffic can get delivered over an LDP-enabled MPLS infrastructure 💅. The original intent was for these requirements to be used as guidelines when specifying LDP extensions ✨.

Note that generic requirements for P2MP extensions to MPLS are out of scope here 🙈. Instead, this doc describes solution-specific requirements related to LDP extensions for setting up P2MP LSPs.

Also, other mechanisms could be used for setting up P2MP LSPs (PIM extensions, for instance), but those are out of scope too 💜. The goal isn't to compare them. It's 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 🧚.

3. Application Scenario 🌈

Figure 1 below shows 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

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 👑.

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 🦋.

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:

  • Network failure (link or node);
  • A better path exists (e.g., new link or metric change); and
  • 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.) 💅.

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 🦋.

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 🏷️✨

Okay so, labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or dedicated label spaces 🫶. You get to pick the setup that fits your network best.

Heads up, bestie: if you go with dedicated label spaces, you'll need separate P2P and P2MP LDP sessions 💅. So it's more sessions, but it's still a valid vibe.

4.12. IPv4/IPv6 Support 🌈

The P2MP LDP mechanism MUST support setting up LDP sessions over both IPv4 and IPv6 control planes. Both, no exceptions, periodt 💖

4.13. Multi-Area/AS LSPs 🦋

The P2MP LDP mechanism MUST support multi-area P2MP LSPs. Those are LSPs whose leaves aren't all in the same IGP area as the Ingress LSR 🗺️. This SHOULD be possible without having to advertise the Ingress LSRs' addresses across IGP areas, which is super iconic.

The P2MP LDP mechanism MUST also support inter-AS P2MP LSPs. These are LSPs whose leaves aren't all in the same AS as the Ingress LSR 🌍. This SHOULD be possible without having to advertise the Ingress LSRs' addresses across ASes, no cap.

4.14. OAM 🔍

LDP management tools ([RFC3815], etc.) are going to have to get a glow-up to support P2MP LDP extensions 💄. This may yield a new MIB module, and that module may possibly be inherited from the LDP MIB.

Built-in diagnostic tools MUST be defined to check connectivity, trace the path, and quickly detect data plane failures on P2MP LDP LSPs 🚨.

Further and more precise requirements and mechanisms for P2MP MPLS Operations, Administration, and Maintenance (OAM) are out of the scope of this document. They're covered in [RFC4687], so go check that one out 📖.

4.15. Graceful Restart and Fault Recovery 🔄

The LDP Graceful Restart mechanisms [RFC3478] and the Fault Recovery mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs. The vibe is "level up the old stuff" 🆙.

4.16. Robustness 🛡️

A solution MUST be designed to re-establish connectivity for P2MP and MP2MP LSPs when failures happen. This only applies if there's network connectivity between the ingress and egress nodes (i.e., it's designed so there are no single points of failure) 🫡. No single point of failure is the main character energy we want here.

4.17. Scalability 📈

Scalability is a key requirement for the P2MP LDP mechanism, bestie 👑. It MUST be designed to scale well as any of the following grow:

  • Number of Leaf LSRs per P2MP LSP;
  • Number of downstream LSRs per Branch LSR; and
  • Number of P2MP LSPs per LSR.

To scale well as the number of leaves grows, it is RECOMMENDED that the size of a P2MP LSP's state on an LSR, for one particular LSP, depends only on the number of adjacent LSRs on that LSP 🧩. Lowkey genius.

4.17.1. Orders of Magnitude Expected in Operational Networks 🔢

These are the typical orders of magnitude we expect to be supported:

  • Tens of thousands of P2MP trees spread across core network routers 🌲; and
  • Hundreds, or a few thousands, of leaves per tree 🍃.

See also Section 4.2 of [RFC4834] 📚.

4.18. Backward Compatibility 🤝

To make the migration smooth, the P2MP LDP mechanism SHOULD offer as much backward compatibility as it can 🧁. Specifically, the solution SHOULD allow setting up a P2MP LSP along non-Branch Transit LSRs that don't support P2MP LDP extensions. The tea is that old gear still gets a seat at the table 🪑.

Also, the P2MP LDP solution MUST coexist with the current LDP mechanisms and inherit its capability sets from [RFC5036] 💞. The P2MP LDP solution MUST NOT get in the way of P2P/MP2P LSPs ✋. A P2MP LDP solution MUST be designed so that P2P/MP2P and P2MP LSPs can both be signaled on the same interface. They all get to share the spotlight 🎀.

5. Shared Trees 🌳

If you have a group of N LSRs that act as egress and/or egress nodes (yes, the RFC really says egress twice, the typos are real 🙈) on different P2MP flows, it can be useful to set up one shared tree connecting all of them instead of N P2MP LSPs. That cuts down on the control and forwarding state each LSR has to keep track of 🧠✨.

There are two main options for supporting shared trees:

  • Relying on the applications' protocols that use LDP LSPs. A shared tree could be a combo of an MP2P LDP LSP from the Leaf LSRs to a given root node, plus a P2MP LSP from that root to the Leaf LSRs. For example, with Multicast L3 VPN applications, you could build a shared tree by combining (see [MVPN]):
    • An MP2P unicast LDP LSP, from each PE router in the group to one particular root PE router acting as the tree root, and
    • A P2MP LDP LSP from that root PE router to each PE router in the group.
  • Relying on a specific LDP mechanism that lets you set up multipoint-to-multipoint MPLS LSPs (MP2MP LSPs) 🔁.

The first approach, which combines MP2P and P2MP LSPs at the application level, is out of the scope of this document. The second one, MP2MP LSPs, is in scope here. The requirements for setting up MP2MP LSPs are listed below 👇.

5.1. Requirements for MP2MP LSPs 🔁💫

A multipoint-to-multipoint (MP2MP) LSP connects a group of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by any Leaf LSR gets received by all the other Leaf LSRs in 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 get in the way of P2MP LSP operations 🚧.

The requirements for P2MP LSPs, set forth in Section 4, apply equally to MP2MP LSPs. Pay special attention to these ones:

  • The solution MUST support recovery upon link and transit node failure, and it MUST be designed to re-establish connectivity for MP2MP LSPs when failures happen. This only applies if network connectivity exists between the ingress and egress nodes (i.e., it's designed without single points of failure) 🛟.
  • The size of MP2MP state on an LSR, for one particular MP2MP LSP, SHOULD only depend on the number of adjacent LSRs on that LSP 🧩.
  • The MP2MP LDP mechanism MUST avoid routing loops that may trigger exponential growth of traffic 🌪️. This one is extra spicy, because an LSR may need to receive traffic for a given LSP on multiple interfaces. Loops are a whole mood, and not the good kind 💀.

There are additional requirements specific to MP2MP LSPs:

  • It is RECOMMENDED that an MP2MP MPLS LSP is built based on the unicast route to a specific LSR called the root LSR 🌱.
  • It is RECOMMENDED to define several root LSRs (e.g., a primary and a backup) so there's redundancy if the root LSR fails 🔐.
  • The receiver SHOULD NOT receive back a packet it has sent on the MP2MP LSP 🙅‍♀️.
  • The solution SHOULD avoid having all traffic between any pair of leaves traverse a root LSR (similar to PIM-Bidir trees) 🚫. It SHOULD also give the operator a way to minimize the delay between two leaves ⏱️.
  • It MUST be possible to check connectivity of an MP2MP LSP in both directions ↔️.

6. Evaluation Criteria 📝

6.1. Performance ⚡

The solution will be judged on the following criteria:

  1. Efficiency of network resource usage;
  2. Time to add or remove a Leaf LSR;
  3. Time to repair a P2MP LSP after a link or node failure; and
  4. Scalability (state size, number of messages, message size) 🏆.

The P2MP LDP mechanism SHOULD be designed with the key objective of minimizing the extra state and extra processing required in the network 🎯.

The P2MP LDP mechanism SHOULD also be designed so that convergence times after a link or node failure are minimized, which limits traffic disruption 🌊.

6.2. Complexity and Risks 🧮

The proposed solution SHOULD NOT add so much complexity to current LDP operations that it hurts stability and cancels out the benefits of deploying it. Don't overcomplicate the vibe 🙅‍♀️.

7. Security Considerations 🔐

It is expected that meeting the requirements defined in this document won't introduce any new security issues beyond the ones already inherent to LDP. 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]. Wherever that document identifies issues or further work, new security features or procedures for the MPLS protocols will need to be developed 🚨. Security is not a bit, it's a whole lifestyle 💅.

8. Acknowledgments 💜

We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina Minei, Dean Cheng, and Benjamin Niven-Jenkins for their super useful comments and suggestions 🫶. We would also like to thank Adrian Farrel for reviewing this document before publication 🙌.

We'd also like to give a shoutout to the authors of [RFC4461], who inspired some of the text in this document 🌟.

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 ✨

okay bestie, here's the extra reading list 📚🎀 every single one of these is in here, exactly as written, so you can look them up 💅

[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.

[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.

Contributing Authors

these are the lovely people who helped build this doc 🧚💖

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

and these are the editors who held the pen 🦋✨

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
📦 where this page comes from