RFC 6388

Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths

📅 published November 2011, from ietf

RFC 6388 💖 Part 1 of 8

Okay bestie, this one is RFC 6388, titled "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 🦋 It's a Standards Track document (ISSN 2070-1721), dated November 2011. It was published by the IETF, which is the Internet Engineering Task Force (IETF) 🌈 The main editors are IJ. Wijnands (listed as Ed.) from Cisco Systems, Inc., and I. Minei (also Ed.), K. Kompella from Juniper Networks, and B. Thomas. The header doesn't say which company I. Minei or B. Thomas are with, so I'm not going to guess 🙈 There's also no Obsoletes or Updates line in the header, so this doc isn't replacing or patching any older RFC, which is very clean of it ✨

Abstract ✨

Okay so the big idea here is that this doc describes LDP extensions (that's the Label Distribution Protocol, the thing that hands out labels in MPLS networks 💅) so you can set up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) 🎀 The whole package is called multipoint LDP, and the best part is that it builds these multipoint LSPs without talking to or depending on any other multicast tree construction protocol. Main character energy, fr fr 👑

The protocol elements and procedures are written for building these LSPs in a receiver-initiated way, meaning the receivers are the ones who kick off the setup 🫶 Multipoint LSPs can be used for lots of things, like IP multicast or multicast support inside BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs) 🌸 But how an application actually uses an LDP-signaled multipoint LSP is outside the scope of this document, so that's a different story 🙃

Status of This Memo

This is an Internet Standards Track document 🔥

This document is a product of the Internet Engineering Task Force (IETF) 🌷 It represents the consensus of the IETF community, and it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 💜 If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6388 🧚

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

Okay, the legal stuff, but make it cute. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please actually read those, because they explain your rights and restrictions for this document 💅 Any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🍓

This document might contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🌈 The people who control the copyright in some of that older material may not have given the IETF Trust permission to allow modifications of it outside the IETF Standards Process 🙈 So unless you get a proper license from those copyright holders, this document can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process either. The exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🫶

Table of Contents 🌸

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................4
      1.2. Terminology ................................................4
      1.3. Manageability ..............................................5
   2. Setting Up P2MP LSPs with LDP ...................................6
      2.1. Support for P2MP LSP Setup with LDP ........................6
      2.2. The P2MP FEC Element .......................................6
      2.3. The LDP MP Opaque Value Element ............................8
           2.3.1. The Generic LSP Identifier ..........................9
      2.4. Using the P2MP FEC Element .................................9
           2.4.1. Label Mapping ......................................10
           2.4.2. Label Withdraw .....................................12
           2.4.3. Upstream LSR Change ................................13
   3. Setting up MP2MP LSPs with LDP .................................14
      3.1. Support for MP2MP LSP Setup with LDP ......................14
      3.2. The MP2MP Downstream and Upstream FEC Elements ............15
      3.3. Using the MP2MP FEC Elements ..............................15
           3.3.1. MP2MP Label Mapping ................................17
           3.3.2. MP2MP Label Withdraw ...............................20
           3.3.3. MP2MP Upstream LSR Change ..........................21
   4. Micro-Loops in MP LSPs .........................................21
   5. The LDP MP Status TLV ..........................................21
      5.1. The LDP MP Status Value Element ...........................22
      5.2. LDP Messages Containing LDP MP Status Messages ............22
           5.2.1. LDP MP Status Sent in LDP Notification Messages ....23
           5.2.2. LDP MP Status TLV in Label Mapping Message .........24
   6. Upstream Label Allocation on a LAN .............................24
      6.1. LDP Multipoint-to-Multipoint on a LAN .....................24
           6.1.1. MP2MP Downstream Forwarding ........................25
           6.1.2. MP2MP Upstream Forwarding ..........................25
   7. Root Node Redundancy ...........................................25
      7.1. Root Node Redundancy - Procedures for P2MP LSPs ...........26
      7.2. Root Node Redundancy - Procedures for MP2MP LSPs ..........26
   8. Make Before Break (MBB) ........................................27
      8.1.  MBB Overview .............................................27
      8.2. The MBB Status Code .......................................28
      8.3. The MBB Capability ........................................29
      8.4. The MBB Procedures ........................................29
           8.4.1. Terminology ........................................29
           8.4.2. Accepting Elements .................................30
           8.4.3. Procedures for Upstream LSR Change .................30
           8.4.4. Receiving a Label Mapping with MBB Status Code .....31
           8.4.5. Receiving a Notification with MBB Status Code ......31
           8.4.6. Node Operation for MP2MP LSPs ......................32
   9. Typed Wildcard for mLDP FEC Element ............................32
   10. Security Considerations .......................................32
   11. IANA Considerations ...........................................33
   12. Acknowledgments ...............................................34
   13. Contributing Authors ..........................................35
   14. References ....................................................37
      14.1. Normative References .....................................37
      14.2. Informative References ...................................37

1. Introduction ✨

Okay so the LDP protocol is described in [RFC5036] 💖 It already has ways to set up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document extends LDP so it can also set up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs 🦋 Together, these get called multipoint LSPs (MP LSPs) 🌸

Here's the vibe: a P2MP LSP lets traffic from one root (or ingress) node reach a bunch of leaf (or egress) nodes 🧚 An MP2MP LSP lets traffic from several ingress nodes reach several egress nodes 💜 The best part is that only a single copy of the packet gets sent to each LDP neighbor that the MP LSP goes through, and it works without using a multicast protocol in the network 🔥 A given ingress node can have several MP LSPs rooted at it, and each one gets its own identifier 🎀

The solution assumes the leaf nodes of an MP LSP already know the root node and the identifier of the MP LSP they belong to 🫶 How that info gets distributed is outside the scope of this document, and so is how an application would use an MP LSP signaled by LDP 🙈

Related docs you might vibe with include [RFC6348], [L3VPN-MCAST], and [RFC4875] 📚

1.1. Conventions Used in This Document

Here's the key word stuff, and it's important 🔥 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 RFC 2119 [RFC2119] 💅

All new fields shown as "reserved" in this document MUST be set to zero on transmission and MUST be ignored on receipt 🌈

1.2. Terminology

Some of the following terminology is taken from [RFC6348] 🍓 Here's the lineup:

  • mLDP: Multipoint extensions for LDP.
  • P2P LSP: An LSP that has one Ingress LSR and one Egress LSR.
  • P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs.
  • MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR.
  • MP2MP LSP: An LSP with a distinguished root node that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others.
  • MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
  • Ingress LSR: An Ingress LSR for a particular LSP is an LSR that can send a data packet along the LSP. MP2MP LSPs can have multiple Ingress LSRs, P2MP LSPs have just one, and that node is often referred to as the "root node". 👑
  • Egress LSR: An Egress LSR for a particular LSP is an LSR that can remove a data packet from that LSP for further processing. P2P and MP2P LSPs have only a single egress node, but P2MP and MP2MP LSPs can have multiple egress nodes. ✨
  • Transit LSR: An LSR that has reachability to the root of the MP LSP via a directly connected upstream LSR and one or more directly connected downstream LSRs. 🦋
  • Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs. 🌸
  • Leaf node: A leaf node can be either an Egress or Bud LSR when referred to in the context of a P2MP LSP. In the context of an MP2MP LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR. 🧚
  • CRC32: This contains a Cyclic Redundancy Check value of the uncompressed data in network byte order, computed according to the CRC-32 algorithm used in the ISO 3309 standard [ISO3309] and in Section 8.1.1.6.2 of ITU-T recommendation V.42 [ITU.V42.1994]. 💜
  • FEC: Forwarding Equivalence Class 🔥

1.3. Manageability

MPLS LSRs can be modeled and managed using the MIB module defined in [RFC3813] 🎀 That MIB module is fully capable of handling the one-to-many in-segment to out-segment relationships needed to support P2MP LSPs, and no further changes are required. Iconic, right? 🫶

[RFC3815] defines managed objects for LDP 🌷 The MIB module lets you model and manage LDP and LDP speakers for the protocol as defined in [RFC5036]. The protocol extensions defined in this document to support P2MP in LDP may require an additional MIB module or extensions to the modules defined in [RFC3815]. That's for future study, and at the time of this writing, no interest has been expressed in this work 🙈

Future manageability work should pay attention to the protocol extensions defined in this document, especially the configurable and variable elements, along with reporting the new protocol fields that identify individual P2MP LSPs 💅✨

2. Setting Up P2MP LSPs with LDP ✨

okay so a P2MP LSP is basically one root node, zero or more transit nodes, and one or more leaf nodes 🌸 The leaf nodes are the ones who kick off the setup and the tear-down 💅 They also install the forwarding state that delivers the traffic that comes in on the P2MP LSP to wherever it's supposed to go. How they do that is outside the scope of this doc, so no spoilers 🙈 Transit nodes install MPLS forwarding state and pass the P2MP LSP setup (and tear-down) along toward the root 🧚 The root node installs forwarding state to map traffic into the P2MP LSP. How the root figures out which traffic should go over the P2MP LSP is also outside the scope of this document 🦋

2.1. Support for P2MP LSP Setup with LDP

okay this part is giving capability negotiation 🎀 Support for setting up P2MP LSPs gets advertised using LDP capabilities, as defined in [RFC5561]. An implementation that supports the P2MP procedures in this document MUST implement the procedures for Capability Parameters in Initialization messages. Non-negotiable, bestie 💀

A new Capability Parameter TLV gets defined, called the P2MP Capability. Here's the format of the P2MP Capability Parameter:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0| P2MP Capability (0x0508)  |      Length (= 1)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |
   +-+-+-+-+-+-+-+-+

S: As specified in [RFC5561]

The P2MP Capability TLV MUST be advertised in the LDP Initialization message 🔥 Advertising the P2MP Capability tells the peer that you support the P2MP LSP setup procedures in this document. And if the peer hasn't advertised the matching capability, then label messages that use the P2MP FEC Element SHOULD NOT be sent to that peer. Respect the boundaries, babe 🫶

2.2. The P2MP FEC Element

okay the main character of setup is the P2MP FEC Element 👑 We define it as one new protocol entity, and it gets used as a FEC Element inside the FEC TLV. Ngl, the P2MP FEC Element doesn't always identify the traffic that has to get mapped onto the LSP, so calling it a "FEC" is kinda a misnomer 😭 Anyway, here's how it works.

The P2MP FEC Element is made of the address of the root of the P2MP LSP plus an opaque value. The opaque value is one or more LDP MP opaque value elements. The opaque value is unique within the context of the root node. Together, the combination of (Root Node Address type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. Iconic 🦋

The P2MP FEC Element is encoded like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |P2MP Type(0x06)|        Address Family         | Address Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       Root Node Address                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Opaque Length              |    Opaque Value ...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: The type of the P2MP FEC Element is 0x06.
  • Address Family: A two-octet quantity holding a value from IANA's "Address Family Numbers" registry, which encodes the address family for the Root LSR Address.
  • Address Length: The length of the Root LSR Address in octets.
  • Root Node Address: A host address, encoded according to the Address Family field.
  • Opaque Length: The length of the opaque value, in octets.
  • Opaque Value: One or more MP opaque value elements, which uniquely identify the P2MP LSP in the context of the root node. This is described in the next section.

If the Address Family is IPv4, the Address Length MUST be 4. If the Address Family is IPv6, the Address Length MUST be 16. No other Address Lengths are defined at present, so don't go inventing them 🙅‍♀️

If the Address Length doesn't match the defined length for the Address Family, the receiver SHOULD abort processing the message that contains the FEC Element, and send an "Unknown FEC" Notification message to its LDP peer to signal an error. Not a vibe 😭

If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST be the only FEC Element in the FEC TLV. One and only, periodt 💅

2.3. The LDP MP Opaque Value Element

the LDP MP opaque value element is what the P2MP and MP2MP FEC Elements (we'll get to those in later sections) use to carry information. It's meaningful to Ingress LSRs and Leaf LSRs, but Transit LSRs don't need to interpret it 🧚 Think of it as a little note for the people at the ends of the LSP 💌

The LDP MP opaque value element basic type is encoded like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type < 255    | Length                        | Value ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: The Type of the LDP MP opaque value element. IANA maintains a registry of basic types (see Section 11).
  • Length: The length of the Value field, in octets.
  • Value: A string of Length octets, to be interpreted as specified by the Type field.

The LDP MP opaque value element extended type is encoded like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 255    |        Extended Type          | Length (high) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   | Length (low)  |                Value                          |
   +-+-+-+-+-+-+-+-+                                               |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: Type = 255.
  • Extended Type: The Extended Type of the LDP MP opaque value element. IANA maintains a registry of extended types (see Section 11).
  • Length: The length of the Value field, in octets.
  • Value: A string of Length octets, to be interpreted as specified by the Type field.

2.3.1. The Generic LSP Identifier

The generic LSP identifier is a type of opaque value element basic type, encoded like this:

  • Type: 1
  • Length: 4
  • Value: A 32-bit integer, unique in the context of the root, as identified by the root's address.

This type of opaque value element is recommended when mapping traffic to LSPs is non-algorithmic and is done by means outside LDP. So if the mapping is handled elsewhere, this is the one to reach for 🎀

2.4. Using the P2MP FEC Element

this section sets out the rules for processing and propagating the P2MP FEC Element 🧠 Here's the notation the processing rules use:

  1. P2MP FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y.
  2. P2MP Label Mapping <X, Y, L>: a Label Mapping message with a FEC TLV that has a single P2MP FEC Element <X, Y>, and a Label TLV with label L. Label L MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. Using the interface label space is outside the scope of this document.
  3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV that has a single P2MP FEC Element <X, Y>, and a Label TLV with label L.
  4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with root node address X and opaque value Y.
  5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X means that when X receives a packet with label L', it makes n copies of the packet. For copy i of the packet, X swaps L' with Li and sends it out over interface Ii. Copy machine energy 🖨️✨

The procedures below are organized by the role each node plays in the P2MP LSP. Node Z knows it's a leaf node through a discovery process that's outside the scope of this document. While the protocol is running, the root node recognizes its role because it owns the root node address 👑 A transit node is any node (other than the root node) that receives a P2MP Label Mapping message, meaning it has leaf nodes downstream of it.

Note that a transit node (and yes, the root node too) may also be a leaf node. Multitasking queens 💜

2.4.1. Label Mapping

The rest of this section specifies the procedures for originating P2MP Label Mapping messages, and for processing received P2MP Label Mapping messages for a particular LSP. The procedures for a particular LSR depend on the role that LSR plays in the LSP (Ingress, Transit, or Egress) 🦋

All labels discussed here are downstream-assigned [RFC5332], except for those assigned using the procedures of Section 6.

2.4.1.1. Determining One's 'upstream LSR'

Every node that's either a Leaf or Transit LSR of an MP LSP needs to use the procedures below to pick an upstream LSR 🌈 A node Z that wants to join an MP LSP <X, Y> figures out the LDP peer U that is Z's next hop on the best path from Z to the root node X. If there's more than one such LDP peer, only one of them gets picked. U is Z's "upstream LSR" for <X, Y>.

When there are several candidate upstream LSRs, the LSR MUST select one upstream LSR. The algorithm for LSR selection is a local matter 🧚 If the LSR selection happens over a LAN interface and the Section 6 procedures are applied, the following procedure SHOULD be applied, so the same upstream LSR gets elected among a set of candidate receivers on that LAN.

  1. The candidate upstream LSRs are numbered from lower to higher IP address.
  2. The following hash is performed: H = (CRC32(Opaque Value)) modulo N, where N is the number of upstream LSRs. The 'Opaque Value' is the field identified in the FEC Element right after 'Opaque Length'. The 'Opaque Length' indicates the size of the opaque value used in this calculation.
  3. The selected upstream LSR U is the LSR that has the number H.

This procedure makes sure there's a single forwarder over the LAN for a particular LSP. One forwarder, zero drama 💖

2.4.1.2. Determining the Forwarding Interface to an LSR

Okay so say LSR U gets an MP Label Mapping from its downstream buddy LSR D, and the message says label L 🎀. Now, U is connected to D over several LDP enabled interfaces or RSVP-TE Tunnel interfaces 🌸. If U needs to send D a data packet whose top label is L, U can send it out of any of those interfaces 💅. How U picks the interface and next-hop for a given packet is a local matter, totally up to the router 🫶. For completeness, the following procedure MAY be used ✨. LSR U may do a lookup in the unicast routing table to find the best interface and next-hop to reach LSR D. If the next-hop and interface are also advertised by LSR D via the LDP session, it can be used to transmit the packet to LSR D 🦋.

2.4.1.3. Leaf Operation

A leaf node Z of P2MP LSP <X, Y> figures out its upstream LSR U for <X, Y> using Section 2.4.1.1 🧚. Then it allocates a label L and sends a P2MP Label Mapping <X, Y, L> to U 💖.

2.4.1.4. Transit Node Operation

Okay, this one is a little plot twist 😭. Suppose a transit node Z receives a P2MP Label Mapping <X, Y, L> from LSR T. Z checks whether it already has state for <X, Y> 👀. If it doesn't, Z determines its upstream LSR U for <X, Y> as per Section 2.4.1.1. Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR T is equal to LSR U 🙈. If LSR U is different from LSR T, Z will allocate a label L', install state to swap L' with L over interface I associated with LSR T, and send a P2MP Label Mapping <X, Y, L'> to LSR U 🌈. Interface I is determined via the procedures in Section 2.4.1.2.

If Z already has state for <X, Y>, then Z does not send a Label Mapping message for P2MP LSP <X, Y> 💅. If LSR T is not equal to the upstream LSR of <X, Y> and <I, L> does not already exist as forwarding state, the forwarding state is updated. Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>} ✨. If LSR T is equal to the installed upstream LSR, the Label Mapping from LSR T MUST be retained and MUST NOT update the label forwarding table 🔥. Main character energy for the upstream LSR, honestly 👑.

2.4.1.5. Root Node Operation

Now the root node Z gets a P2MP Label Mapping <X, Y, L> from LSR T 🌸. Z checks whether it already has forwarding state for <X, Y>. If not, Z creates forwarding state to push label L onto the traffic that Z wants to forward over the P2MP LSP. (How that traffic gets picked is outside the scope of this document, so no spoilers 🤐.)

If Z already has forwarding state for <X, Y>, then Z adds "push label L, send over interface I" to the next hop 🍓. Here I is the interface associated with LSR T, which is determined via the procedures in Section 2.4.1.2 💜.

2.4.2. Label Withdraw

Okay, time for the breakup era 💀. The following section lists procedures for generating and processing P2MP Label Withdraw messages for nodes that participate in a P2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the P2MP LSP 🧚.

2.4.2.1. Leaf Operation

If a leaf node Z discovers that it has no downstream neighbors in that LSP, and that it has no need to be an Egress LSR for that LSP (by means outside the scope of this document), then it SHOULD send a Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it had previously advertised to U for <X, Y> 😭🫶.

2.4.2.2. Transit Node Operation

If a transit node Z receives a Label Withdraw message <X, Y, L> from a node W, it deletes label L from its forwarding state and sends a Label Release message with label L to W 🦋.

If deleting L from Z's forwarding state for P2MP LSP <X, Y> results in no state remaining for <X, Y>, then Z propagates the Label Withdraw for <X, Y> to its upstream T by sending a Label Withdraw <X, Y, L1>, where L1 is the label Z had previously advertised to T for <X, Y> 🌈. It's giving domino effect, bestie 🫠.

2.4.2.3. Root Node Operation

When the root node of a P2MP LSP receives a Label Withdraw message, the procedures are the same as those for transit nodes, except that it would not propagate the Label Withdraw upstream (as it has no upstream) 👑.

2.4.3. Upstream LSR Change

Suppose that for a given node Z participating in a P2MP LSP <X, Y>, the upstream LSR changes from U to U' as per Section 2.4.1.1. Z MUST update its forwarding state as follows 🔥. It allocates a new label, L', for <X, Y>. The forwarding state for L' is copied from the forwarding state for L, with one exception: if U' was present in the forwarding state of L, it MUST NOT be installed in the forwarding state of L' 🙈. Then the forwarding state for L is deleted and the forwarding state for L' is installed. In addition, Z MUST send a Label Mapping <X, Y, L'> to U' and send a Label Withdraw <X, Y, L> to U 💖. Note, if there was a downstream mapping from U that was not installed in the forwarding due to the procedures defined in Section 2.4.1.4, it can now be installed ✨.

While changing the upstream LSR, the following must be taken into consideration ⚠️. If L' is added before L is removed, there is a potential risk of packet duplication and/or the creation of a transient data-plane forwarding loop 😬. If L is removed before L' is added, packet loss may result 💧. Ideally the change from L to L' is done atomically such that no packet loss or duplication occurs 🧚. If that is not possible, the RECOMMENDED default behavior is to remove L before adding L' 🌸.

3. Setting up MP2MP LSPs with LDP ✨

An MP2MP LSP is kind of like a P2MP LSP in that it has a single root node, zero or more transit nodes, and one or more Leaf LSRs acting equally as Ingress or Egress LSR 🦋. A leaf node joins the setup of an MP2MP LSP by establishing both a downstream LSP, which is pretty much a P2MP LSP from the root, and an upstream LSP, which is used to send traffic toward the root and other leaf nodes 💅. Transit nodes help out by propagating the upstream and downstream LSP setup toward the root and installing the necessary MPLS forwarding state 🫶. Sending packets from the root node of an MP2MP LSP to the receivers works exactly like it does for a P2MP LSP 🌈. Traffic from a downstream node follows the upstream LSP toward the root node and branches downward along the downstream LSP as required to reach other leaf nodes 🍓. A packet that is received from a downstream node MUST never be forwarded back out to that same node 🙈. Mapping traffic to the MP2MP LSP may happen at any leaf node. How that mapping is established is outside the scope of this document 🤐.

Due to how an MP2MP LSP is built, a Leaf LSR that is sending packets on the MP2MP LSP does not receive its own packets 👀. There is also no additional mechanism needed on the root or Transit LSR to match upstream traffic to the downstream forwarding state 💜. Packets that are forwarded over an MP2MP LSP will not traverse a link more than once, with the possible exception of LAN links (see Section 3.3.1), if the procedures of [RFC5331] are not provided 🔥.

3.1. Support for MP2MP LSP Setup with LDP

Support for the setup of MP2MP LSPs is advertised using LDP capabilities as defined in [RFC5561] 🎀. An implementation supporting the MP2MP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages 👑.

A new Capability Parameter TLV is defined: the MP2MP Capability. Here's what the MP2MP Capability Parameter looks like 🧚:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0| MP2MP Capability (0x0509) |      Length (= 1)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |
   +-+-+-+-+-+-+-+-+

S: As specified in [RFC5561] 🦋.

The MP2MP Capability TLV MUST be advertised in the LDP Initialization message 💖. Advertising the MP2MP Capability tells peers that the router supports the procedures for MP2MP LSP setup detailed in this document ✨. If the peer has not advertised the corresponding capability, then label messages using the MP2MP upstream and downstream FEC Elements SHOULD NOT be sent to the peer 🙅‍♀️.

3.2. The MP2MP Downstream and Upstream FEC Elements

For the setup of an MP2MP LSP with LDP, we define 2 new protocol entities: the MP2MP downstream FEC Element and the MP2MP upstream FEC Element 🌸. Both elements get used as FEC Elements in the FEC TLV. Note that the MP2MP FEC Elements do not necessarily identify the traffic that must be mapped to the LSP, so from that point of view, calling them FECs is kind of a misnomer 🙈. The MP2MP FEC Elements are described below 💅.

The structure, encoding, and error handling for the MP2MP downstream and upstream FEC Elements are the same as for the P2MP FEC Element described in Section 2.2 🫶. The difference is that two new FEC types are used: MP2MP downstream type (0x08) and MP2MP upstream type (0x07) 🌈.

If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element MUST be the only FEC Element in the FEC TLV 👑.

Note, except when using the procedures of [RFC5331], the MPLS labels used are "downstream-assigned" [RFC5332], even if they are bound to the "upstream FEC Element" 🍓. Bestie, that's the last big piece of the MP2MP puzzle for now 🥹🎀.

3.3. Using the MP2MP FEC Elements ✨

okay bestie, this is the section where the MP2MP FEC Elements actually get used 💅 it lays out the rules for how they get processed and passed along. first, some shorthand so we're all on the same page 🦋

  1. MP2MP downstream LSP <X, Y> (or just downstream <X, Y>): an MP2MP LSP downstream path with root node address X and opaque value Y.
  2. MP2MP upstream LSP <X, Y, D> (or just upstream <X, Y, D>): an MP2MP LSP upstream path for downstream node D, with root node address X and opaque value Y.
  3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y, used for a downstream MP2MP LSP.
  4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y, used for an upstream MP2MP LSP.
  5. MP2MP-D Label Mapping <X, Y, L>: a Label Mapping message with a FEC TLV holding a single MP2MP downstream FEC Element <X, Y> and a label TLV with label L. Label L MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document. 🌸
  6. MP2MP-U Label Mapping <X, Y, Lu>: a Label Mapping message with a FEC TLV holding a single MP2MP upstream FEC Element <X, Y> and a label TLV with label Lu. Label Lu MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document.
  7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV holding a single MP2MP downstream FEC Element <X, Y> and a label TLV with label L.
  8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a FEC TLV holding a single MP2MP upstream FEC Element <X, Y> and a label TLV with label Lu.
  9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a FEC TLV holding a single MP2MP downstream FEC Element <X, Y> and a Label TLV with label L.
  10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a FEC TLV holding a single MP2MP upstream FEC Element <X, Y> and a label TLV with label Lu.

The procedures below are organized by the role each node plays in the MP2MP LSP. Node Z figures out that it's a leaf through a discovery process that lives outside this document 🔍 The root node knows its role because it owns the root node address. A transit node is any node (other than the root node) that receives an MP2MP Label Mapping message, which basically means it has leaf nodes hanging off of it downstream.

a transit node (and yes, even the root node) can also be a leaf node, and the root node doesn't have to be an Ingress LSR or a leaf of the MP2MP LSP. the roles are not as rigid as they look 👑

3.3.1. MP2MP Label Mapping

the rest of this section is all about how to originate MP2MP Label Mapping messages and how to process the ones you receive for a particular LSP 🎀 what you do depends on the role your LSR plays in the LSP (Ingress, Transit, or Egress).

All labels discussed here are downstream-assigned [RFC5332], except the ones assigned using the procedures of Section 6.

3.3.1.1. Determining one's upstream MP2MP LSR

figuring out your upstream LDP peer U for an MP2MP LSP <X, Y> follows the same procedure as a P2MP LSP, as described in Section 2.4.1.1. no need to reinvent the wheel 🛞

3.3.1.2. Determining One's Downstream MP2MP LSR

if an LDP peer U gets an MP2MP-D Label Mapping from an LDP peer D, then U treats D as its downstream MP2MP LSR 🦋

3.3.1.3. Installing the Upstream Path of an MP2MP LSP

there are two ways to install the upstream path of an MP2MP LSP toward a downstream neighbor, and I'm obsessed with the difference 😭

  1. You can install the upstream MP2MP path (toward a downstream neighbor) based on receiving an MP2MP-D Label Mapping from that downstream neighbor. This installs the upstream path on a hop-by-hop basis.
  2. You can install the upstream MP2MP path (toward a downstream neighbor) based on receiving an MP2MP-U Label Mapping from the upstream neighbor. An LSR doesn't need to wait for that MP2MP-U Label Mapping if it's the root of the MP2MP LSP, or if it has already received one from the upstream neighbor. This is called ordered mode. The typical result is that the downstream path of the MP2MP gets built hop by hop toward the root. Once the root is reached, the root node triggers an MP2MP-U Label Mapping to the downstream neighbor(s).

for setting up the upstream path of an MP2MP LSP, ordered mode SHOULD be used 💖 because of ordered mode, the upstream path is installed at the leaf node only once the path to the root has finished. the perk is that when a leaf starts sending right after the upstream path is installed, packets can reach the root node without getting dropped because the LSP is incomplete. method 1 can't guarantee that the upstream path has completed before the leaf starts sending, so it's not the move 🙅‍♀️

3.3.1.4. MP2MP Leaf Node Operation

a leaf node Z of an MP2MP LSP <X, Y> works out its upstream LSR U for <X, Y> as described in Section 3.3.1.1, allocates a label L, and sends an MP2MP-D Label Mapping <X, Y, L> to U 🧚

then Z waits for an MP2MP-U Label Mapping <X, Y, Lu> from node U, sent in response to the MP2MP-D Label Mapping it sent. Z checks whether it already has forwarding state for upstream <X, Y>. If it doesn't, Z creates forwarding state that pushes label Lu onto the traffic Z wants to forward over the MP2MP LSP. How Z decides which traffic goes on this MP2MP LSP is outside the scope of this document ✨

3.3.1.5. MP2MP Transit Node Operation

say node Z receives an MP2MP-D Label Mapping <X, Y, L> from LSR D. Z checks whether it already has forwarding state for downstream <X, Y>. If not, Z works out its upstream LSR U for <X, Y> as described in Section 3.3.1.1. Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U is different from LSR D, Z allocates a label L' and installs downstream forwarding state that swaps label L' with label L over interface I associated with LSR D, then sends an MP2MP-D Label Mapping <X, Y, L'> to U. Interface I is determined through the procedures in Section 2.4.1.2 🌈

if Z already has forwarding state for downstream <X, Y>, all Z has to do is check that LSR D is not equal to the upstream LSR of <X, Y>, then update its forwarding state. say the old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}. The new forwarding state then becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If LSR D is equal to the installed upstream LSR, the Label Mapping from LSR D MUST be retained and MUST NOT update the label forwarding table 🙈

Node Z checks whether its upstream LSR U has already assigned a label Lu to <X, Y>. If not, transit node Z waits until it receives an MP2MP-U Label Mapping <X, Y, Lu> from LSR U (see Section 3.3.1.3). Once Z has that MP2MP-U Label Mapping from LSR U, it checks whether it already has forwarding state upstream <X, Y, D>. If it does, nothing else needs to happen. If it doesn't, Z allocates a label Lu' and creates a new label swap for Lu' with label Lu over interface Iu. Interface Iu is determined through the procedures in Section 2.4.1.2. On top of that, Z also adds the label swap(s) from the forwarding state downstream <X, Y>, leaving out the swap on interface I for node D. That swap is left out to stop a packet originated by D from being forwarded straight back to D 🔁

Node Z determines its downstream MP2MP LSR as described in Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to node D 💜

3.3.1.6. MP2MP Root Node Operation

3.3.1.6.1. Root Node Is Also a Leaf

say root/leaf node Z receives an MP2MP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state downstream <X, Y>. If not, Z creates downstream forwarding state that pushes label L onto traffic Z wants to forward down the MP2MP LSP. How Z decides what traffic goes on this MP2MP LSP is outside the scope of this document. If Z already has forwarding state for downstream <X, Y>, Z adds the label push for L over interface I to it. Interface I is determined through the procedures in Section 2.4.1.2 🎀

Node Z checks whether it has forwarding state for upstream <X, Y, D>. If not, Z allocates a label Lu' and creates upstream forwarding state that swaps Lu' with the label swap(s) from the forwarding state downstream <X, Y>, except the swap on interface I for node D. This lets upstream traffic go down the MP2MP to the other node(s), except the one it came from. Node Z determines the downstream MP2MP LSR as described in Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to node D. Since Z is the root of the tree, Z will not send an MP2MP-D Label Mapping and will not receive an MP2MP-U Label Mapping 👑

3.3.1.6.2. Root Node is Not a Leaf

say the root node Z receives an MP2MP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state for downstream <X, Y>. If not, Z creates downstream forwarding state and installs an outgoing label L over interface I. Interface I is determined through the procedures in Section 2.4.1.2. If Z already has forwarding state for downstream <X, Y>, Z adds label L over interface I to the existing state 🌸

Node Z checks whether it has forwarding state for upstream <X, Y, D>. If not, Z allocates a label Lu' and creates forwarding state that swaps Lu' with the label swap(s) from the forwarding state downstream <X, Y>, except the swap for node D. This lets upstream traffic go down the MP2MP to the other node(s), except the one it was received from. The root node Z determines its downstream MP2MP LSR D as described in Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to it. Since Z is the root of the tree, Z will not send an MP2MP-D Label Mapping and will not receive an MP2MP-U Label Mapping 🦋

3.3.2. MP2MP Label Withdraw

the following section lists the procedures for generating and processing MP2MP Label Withdraw messages for nodes that take part in an MP2MP LSP. an LSR should apply the procedures that match its role in the MP2MP LSP 🫶

3.3.2.1. MP2MP Leaf Operation

if a leaf node Z discovers (through means outside the scope of this document) that it has no downstream neighbors in that LSP, and that it doesn't need to be an Egress LSR for that LSP (also through means outside the scope of this document), then it SHOULD send an MP2MP-D Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it previously advertised to U for <X, Y>. Leaf node Z will also send an unsolicited label release <X, Y, Lu> to U to indicate that the upstream path is no longer used and that label Lu can be removed 💀

Leaf node Z expects the upstream router U to respond by sending a downstream label release for L 🌈

3.3.2.2. MP2MP Transit Node Operation 🔁

okay so bestie, say a transit node Z gets an MP2MP-D Label Withdraw <X, Y, L> from node D. Z deletes label L from its forwarding state for the downstream <X, Y> and from all of its upstream states for <X, Y> 💅. Then Z sends an MP2MP-D Label Release with label L back to D. Since D isn't part of the downstream forwarding state anymore, Z cleans up the upstream <X, Y, D> state too ✨. There's no need to send an MP2MP-U Label Withdraw <X, Y, Lu> to D, because D already removed Lu and sent a Label Release for Lu to Z. no cap, it's all handled 🫶

If deleting L from Z's forwarding state for downstream <X, Y> leaves nothing behind for <X, Y>, then Z passes the MP2MP-D Label Withdraw <X, Y, L> upstream to its upstream node U for <X, Y>. Z also sends an unsolicited MP2MP-U Label Release <X, Y, Lu> to U 🦋 to say the upstream path isn't being used anymore and that label Lu can be removed. it's giving clean-up crew energy 🧹

3.3.2.3. MP2MP Root Node Operation 👑

When the root node of an MP2MP LSP gets an MP2MP-D Label Withdraw message, it does the same thing a transit node does, with one difference: the root won't pass the Label Withdraw upstream, because it doesn't have an upstream 🌸 (the root is the top, so there's nowhere to go, iykyk).

3.3.3. MP2MP Upstream LSR Change 🌈

Changing the upstream LSR works the same way as it's described in Section 2.4.3 🎀. The only difference is that it's applied to MP2MP FECs, and you follow the procedures from Section 3.3.1 through Section 3.3.2.3 to do it.

4. Micro-Loops in MP LSPs ✨

Micro-loops created by the unicast routing protocol during convergence can also effect mLDP MP LSPs 🙈. The tree building in mLDP is based on unicast routing, so a unicast routing loop can also turn into a micro-loop in the MP LSPs. Micro-loops that involve 2 directly connected routers don't create a loop in mLDP. mLDP can stop this kind of inconsistency by never letting an upstream LDP neighbor get added as a downstream LDP neighbor in the Label Forwarding Table (LFT) for the same FEC 💖. Micro-loops that involve more than 2 LSRs are not prevented, though 😭.

Micro-loops that involve more than 2 LSRs may create a micro-loop in the downstream path of either an MP2MP LSP or a P2MP LSP, and in the upstream path of the MP2MP LSP. These loops are transient, and they'll disappear as soon as the unicast routing protocol converges and mLDP has updated the forwarding state to match 🦋. Micro-loops that happen in the upstream path of an MP2MP LSP may be detected by including an LDP path vector in the MP2MP-U Label Mapping messages. These procedures are currently under investigation and are subject to further study 🔍.

5. The LDP MP Status TLV 🍓

An LDP MP capable router MAY use an LDP MP Status TLV to show extra status for an MP LSP to its remote peers 💜. This includes signaling to peers that are either upstream or downstream of the LDP MP capable router. The value of the LDP MP Status TLV stays opaque to LDP, and it MAY encode one or more status elements 🫧.

The LDP MP Status TLV is encoded like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0| LDP MP Status Type(0x096F)|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value                               |
   ~                                                               ~
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LDP MP Status Type: The LDP MP Status (0x096F).

Length: Length of the LDP MP Status Value in octets.

Value: One or more LDP MP Status Value elements.

5.1. The LDP MP Status Value Element 🎨

The LDP MP Status Value Element that goes inside the LDP MP Status TLV Value has the following encoding 💅:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type          | Length                        | Value ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: The type of the LDP MP Status Value Element. IANA keeps a registry of status value types (see Section 11) 📒.

Length: The length of the Value field, in octets.

Value: A string of Length octets, to be interpreted as specified by the Type field.

5.2. LDP Messages Containing LDP MP Status Messages 💌

The LDP MP Status TLV may appear either in a Label Mapping message or in an LDP Notification message.

5.2.1. LDP MP Status Sent in LDP Notification Messages 🔔

An LDP MP Status TLV sent in a notification message must be accompanied by a Status TLV, as described in [RFC5036] 🫶. The general format of the Notification message with an LDP MP Status TLV looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status TLV                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   LDP MP Status TLV                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Optional LDP MP FEC TLV                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Optional Label TLV                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Status TLV status code is used to show that the LDP MP Status TLV and any extra information follow in the Notification message's "optional parameter" section ✨. Depending on what's actually in the LDP MP Status TLV, an LDP P2MP or MP2MP FEC TLV and a Label TLV may also be there to give context to the LDP MP Status TLV.

Since the notification doesn't refer to any particular message, the Message ID and Message Type fields are set to 0 🙃.

5.2.2. LDP MP Status TLV in Label Mapping Message 🗺️

Here's an example of the Label Mapping message defined in [RFC5036], showing a Label Mapping message with an Optional LDP MP Status TLV present 🧚:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Mapping (0x0400)    |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional LDP MP Status TLV                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Additional Optional Parameters            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Upstream Label Allocation on a LAN 🌊

On a LAN, the procedures we've covered so far would make the upstream LSR send a copy of the packet to each receiver individually 😩. If there's more than one receiver on the LAN, we aren't getting the full benefit of the network's multi-access capability. We can optimize the bandwidth used on the LAN and the replication overhead on the upstream LSR by using upstream label allocation [RFC5331] ✨. The procedures for distributing upstream labels using LDP are documented in [RFC6389] 💜.

6.1. LDP Multipoint-to-Multipoint on a LAN 🪩

The procedure for allocating a context label on a LAN is defined in [RFC5331] 📜. That procedure gives each LSR on a given LAN a context label, which can be used on that LAN to identify it uniquely. Each LSR advertises its context label as an upstream-assigned label, following the procedures of [RFC6389] 🫧. Any LSR for which the LAN is a downstream link on some P2MP or MP2MP LSP will allocate an upstream-assigned label that identifies that LSP. When the LSR forwards a packet downstream on one of those LSPs, the packet's top label must be the LSR's context label, and the packet's second label is the label that identifies the LSP. We'll call the top label the "upstream LSR label" and the second label the "LSP label" 🎀.

6.1.1. MP2MP Downstream Forwarding ⬇️

The downstream path of an MP2MP LSP is pretty much like a normal P2MP LSP, so we use the same procedures defined in [RFC6389] 🙌. A label request for an LSP label is sent to the upstream LSR. The Label Mapping received from the upstream LSR contains the LSP label for the MP2MP FEC and the upstream LSR context label. The MP2MP downstream path (corresponding to the LSP label) gets installed in the context-specific forwarding table that matches the upstream LSR label. Packets sent by the upstream router can be forwarded downstream using this forwarding state, based on a two-label lookup 🔎.

6.1.2. MP2MP Upstream Forwarding ⬆️

An MP2MP LSP also has an upstream forwarding path 🚀. Upstream packets need to go in the direction of the root, and downstream on any node on the LAN that has a downstream interface for the LSP. For a given MP2MP LSP on a given LAN, exactly one LSR is considered to be the upstream LSR. If an LSR on the LAN gets a packet from one of its downstream interfaces for the LSP, and it needs to forward that packet onto the LAN, it makes sure the packet's top label is the context label of the upstream LSR, and that its second label is the LSP label that was assigned by the upstream LSR 💅.

Other LSRs that receive the packet won't be able to tell whether it really came from the upstream router, but that makes no difference in how the packet gets processed 🤷‍♀️. The upstream LSR will see its own upstream LSR in the label, and that lets it work out that the packet is traveling upstream 💖.

7. Root Node Redundancy ✨

okay so the root node is a single point of failure for an MP LSP, whether it's P2MP or MP2MP 💀. For MP2MP it's extra intense, bestie. Every leaf has to use the same root to set up the MP2MP LSP, or the traffic one leaf sends never reaches the others 😭. Since the root is that single point of failure, we need a fast and efficient way to recover when it goes down 🔥.

An MP LSP is uniquely identified in the network by its opaque value and its root node address 🦋. The root node for an MP LSP will likely be defined statically. The root node address may be configured on each leaf statically or learned with a dynamic protocol. How leafs learn about the root node is out of scope for this document 🧚.

Now suppose the same opaque value has two (or more) root node addresses, and we build a tree to each root using that opaque value. The network treats these as different MP LSPs 🌸. Once the trees are built, the procedures are different for P2MP and MP2MP LSPs, and the sections below explain each one 💅.

7.1. Root Node Redundancy - Procedures for P2MP LSPs

Every leaf has set up a P2MP LSP to all the roots, so they're all ready to receive packets on any one of those LSPs 💖. But only one root should be forwarding traffic at any given time, and there are two reasons: 1) it saves bandwidth in the network, and 2) it makes sure the receiving leafs don't get duplicate packets 🙈. Leafs can't be assumed to be able to discard duplicates, so we really don't want them to have to. How the roots figure out which one is the active sender is outside the scope of this document 🍓.

7.2. Root Node Redundancy - Procedures for MP2MP LSPs

Every leaf has set up an MP2MP LSP to each one of the root nodes for this opaque value, so a sending leaf can pick any of the two (or more) MP2MP LSPs to forward a packet on 🦋. The leaf nodes receive the packet on one of the MP2MP LSPs. The client of the MP2MP LSP doesn't care which one the packet shows up on, as long as they're all for the same opaque value 🫶. The sending leaf MUST only forward a packet on one MP2MP LSP at a given point in time 🔥. The receiving leafs can't discard duplicate packets, because they accept on all LSPs 😭. By using all the available MP2MP LSPs, we can build redundancy with the following procedures ✨.

A sending leaf selects a single root node out of the available roots for a given opaque value. A good strategy MAY be to look at the unicast routing table and select the root that is closest in terms of the unicast metric 🗺️. As soon as the root address of the active root disappears from the unicast routing table (or becomes less attractive) because of a root node or link failure, the leaf can select a new best root address and start forwarding to it directly 💨. If multiple root nodes have the same unicast metric, the highest root node addresses MAY be selected, or per session load balancing MAY be done over the root nodes 🎀.

All leafs participating in an MP2MP LSP MUST join all the available root nodes for a given opaque value. Since the sending leaf can pick any MP2MP LSP, it has to be ready to receive on it 👑.

Pre-building multiple MP2MP LSPs for one opaque value has a big upside: convergence after a root node failure happens as fast as the unicast routing protocol can notify, which is iconic 🌈. There's no need for an extra protocol to tell the leafs which root is the active one. Picking a root is a local leaf policy and doesn't need to be coordinated with the other leafs 🧚. The downside is that more label resources get used, depending on how many root nodes are defined 🥲.

8. Make Before Break (MBB) ✨

An LSR picks the LSR that is its next hop toward the root of the LSP as its upstream LSR for an MP LSP 💜. When the best path to the root changes, the LSR must choose a new upstream LSR. Sections 2.4.3 and 3.3.3 describe these procedures 📖.

When the best path to the root changes, the LSP may break for a moment, which means packet loss until it "reconverges" to a new upstream LSR 💀. The goal of MBB here is to keep that packet loss window as short as possible ⏱️. There are also situations where the best path from the LSR to the root changes but the LSP keeps forwarding packets to the previous next hop toward the root. That can happen when a link comes up or routing metrics change 👀. In that case, a new LSP should be established before the old one is removed, so packet loss stays limited 🫧. The procedures below handle both scenarios, and an LSR doesn't need to know which of these events caused its upstream router for an MBB LSP to change 🙌.

The MBB procedures are an optional extension to the MP LSP building procedures described in this document. The procedures in this section give you make-before-break behavior, except where the new path is part of a transient routing loop involving more than 2 LSRs (also see Section 4) 🚧.

8.1. MBB Overview

The MBB procedures use additional LDP signaling 📡.

Say some event makes a downstream LSR-D select a new upstream LSR-U for FEC-A. The new LSR-U may already be forwarding packets for FEC-A, just to downstream LSRs other than LSR-D 🌊. After LSR-U gets a label for FEC-A from LSR-D, it will send LSR-D a notification once it knows the LSP for FEC-A has been established from the root to itself 🎉. When LSR-D gets that MBB notification, it changes its next hop for the LSP root to LSR-U 🦋.

The assumption is that if LSR-U has received an MBB notification from its upstream router for the FEC-A LSP and has installed forwarding state, the LSR can forward packets on the LSP. At that point LSR-U should signal LSR-D, using an MBB notification, that it has become part of the tree identified by FEC-A, and that LSR-D should start its switchover to the LSP 🍰.

At LSR-U, the LSP for FEC-A can be in one of 3 states 🔮:

  1. There is no state for FEC-A.
  2. State for FEC-A exists, and LSR-U is waiting for an MBB notification that the LSP from the root to it exists.
  3. State for FEC-A exists, and either the MBB notification has been received or LSR-U is the root node for FEC-A.

After LSR-U receives LSR-D's Label Mapping message for FEC-A, LSR-U MUST NOT reply with an MBB notification to LSR-D until its state for the LSP is state #3 above 🙅‍♀️. If the state of the LSP at LSR-U is state #1 or #2, LSR-U should remember that it received the Label Mapping message from LSR-D while it waits for an MBB notification from its upstream LSR for the LSP 🧠. When LSR-U gets that MBB notification from its upstream LSR, it moves to LSP state #3 and sends an MBB notification to LSR-D 💖.

8.2. The MBB Status Code

As noted in Section 8.1, establishing an MBB MP LSP works differently from establishing normal MP LSPs 💅.

When a downstream LSR sends a Label Mapping message for an MP LSP to its upstream LSR, it MAY include an LDP MP Status TLV carrying an MBB Status Code to show that MBB procedures apply to the LSP 🎀. This new MBB Status Code MAY also appear in an LDP Notification message that an upstream LSR uses to signal LSP state #3 to the downstream LSR. In other words, the upstream LSR's state for the LSP exists, and it has received notification from its upstream LSR that the LSP is in state #3 🫶.

The MBB Status is a type of the LDP MP Status Value Element, as described in Section 5.1. It's encoded like this 👇:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MBB Type = 1  |      Length = 1               | Status Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      MBB Type:  Type 1
      Length:  1

      Status Code:  1 = MBB request

                    2 = MBB ack

8.3. The MBB Capability

An LSR MAY advertise that it can handle MBB LSPs, using the capability advertisement defined in [RFC5561] 🧃. The LDP MP MBB capability has this format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| LDP MP MBB Capability     |           Length = 1          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+

LDP MP MBB Capability: The MBB Capability Parameter (0x050A) 🏷️

S: As specified in [RFC5561] 📎

If an LSR hasn't advertised that it's MBB capable, its LDP peers MUST NOT send it messages that include MBB parameters 🚫. If an LSR receives a Label Mapping message with an MBB parameter from downstream LSR-D, and its upstream LSR-U hasn't advertised that it's MBB capable, the LSR MUST send an MBB notification immediately to LSR-U (see Section 8.4) ⚡. If this happens, an MBB MP LSP won't get established, but a normal MP LSP will be the result 🥹.

8.4. The MBB Procedures

8.4.1. Terminology

  1. MBB LSP <X, Y>: A P2MP or MP2MP Make Before Break (MBB) LSP entry with root node address X and opaque value Y 🌱.
  2. A(N, L): An accepting element that consists of an upstream neighbor N and Local label L. This LSR assigned label L to neighbor N for a specific MBB LSP. For an active element, the corresponding label is stored in the label forwarding database 💾.
  3. iA(N, L): An inactive accepting element that consists of an upstream neighbor N and local label L. This LSR assigned label L to neighbor N for a specific MBB LSP. For an inactive element, the corresponding label is not stored in the label forwarding database 😴.
  4. F(N, L): A Forwarding state that consists of downstream neighbor N and label L. This LSR is sending label packets with label L to neighbor N for a specific FEC 📤.
  5. F'(N, L): A Forwarding state that has been marked for sending an MBB Notification message to neighbor N with label L 🏁.
  6. MBB Notification <X, Y, L>: An LDP notification message with an MP LSP <X, Y>, label L, and MBB Status code 2 🔔.
  7. MBB Label Mapping <X, Y, L>: A P2MP Label Mapping or MP2MP Label Mapping downstream with a FEC element <X, Y>, label L, and MBB Status code 1 🎯.

8.4.2. Accepting Elements ✨

okay so an accepting element is basically a specific label value L that got advertised to a neighbor N for an MBB LSP <X, Y>, and it's a candidate for accepting label switched packets 🎀. An LSR can have two accepting elements for one MBB LSP <X, Y>, but only one of them MUST be active. The active one is the element whose label value has already been installed in the label forwarding database 💅. An inactive accepting element gets created after a new upstream LSR is chosen, while the swap into the label forwarding database is still pending. These inactive elements are only temporary, just for while we switch to a new upstream LSR, and once the switch finishes, only one active element is left 🦋.

During network convergence, it's possible for a new inactive accepting element to show up while another inactive one is still pending 🙈. If that happens, the older inactive accepting element MUST be replaced with the newer one. Also, if an accepting element gets removed, a Label Withdraw has to be sent for label L to neighbor N for <X, Y> 💀.

8.4.3. Procedures for Upstream LSR Change

Okay picture this: node Z has an MBB LSP <X, Y> with an active accepting element A(N1, L1). Then a routing change happens, and Z notices a new best path for root X and picks a new upstream LSR N2 👀. Node Z allocates a new local label L2 and creates an inactive accepting element iA(N2, L2). It sends an MBB Label Mapping <X, Y, L2> to N2 and then waits for N2 to reply with an MBB Notification for <X, Y, L2> 🧚. During this transition, there are two accepting elements: the old A(N1, L1), which is still accepting packets from N1 over label L1, and the new inactive iA(N2, L2) ✨.

While Z is waiting for that MBB Notification, another routing change can happen. Say the new upstream LSR is now N3. Then an inactive element iA(N3, L3) gets created, and the old inactive element iA(N2, L2) MUST be removed. A Label Withdraw MUST be sent to N2 for <X, Y, L2>. Any MBB Notification for <X, Y, L2> coming from N2 will get ignored, because that inactive element is already gone 🫶.

It's possible the MBB Notification from the upstream LSR never shows up because of a link or node failure. To avoid waiting forever, a timeout SHOULD be applied. As soon as the timer expires, the procedures in Section 8.4.5 get applied as if an MBB Notification had been received for the inactive element ⏰. And if a downstream LSR notices that the old upstream LSR went down while it was waiting for the MBB Notification from the new upstream LSR, that downstream LSR can immediately move on without waiting for the timer to expire 🔥.

8.4.4. Receiving a Label Mapping with MBB Status Code

Suppose node Z already has state for an MBB LSP <X, Y> and receives an MBB Label Mapping <X, Y, L2> from N2 🍓. A new forwarding state F(N2, L2) gets added to the MP LSP, but only if it didn't already exist. If this MBB LSP has an active accepting element, or if node Z is the root of the MBB LSP, then an MBB notification <X, Y, L2)> gets sent to node N2 🌈. If node Z has an inactive accepting element instead, it marks the Forwarding state as <X, Y, F'(N2, L2)> 💜. Now if the upstream LSR for <X, Y> happens to be N2 already, then Z MUST NOT send an MBB notification to N2 right away. Sending that MBB notification to N2 must be done only after Z's upstream for <X, Y> stops being N2 🙃.

8.4.5. Receiving a Notification with MBB Status Code

Suppose node Z receives an MBB Notification <X, Y, L> from N 📩. If node Z has state for MBB LSP <X, Y> and an inactive accepting element iA(N, L) that matches N and L, then we activate that accepting element and install label L in the label-forwarding database 🎉. If another active accepting element was present, it gets removed from the label-forwarding database 🧹.

If this MBB LSP <X, Y> also has Forwarding states marked for sending MBB Notifications, like <X, Y, F'(N2, L2)>, then MBB Notifications get sent to those downstream LSRs too 💌. And if node Z gets an MBB Notification for an accepting element that either isn't inactive or doesn't match the label value and neighbor address, that MBB notification just gets ignored 🙅‍♀️.

8.4.6. Node Operation for MP2MP LSPs

Everything described above applies to the downstream path of an MP2MP LSP 🦋. The upstream path of the MP2MP gets set up as normal, without including an MBB Status code. If the MBB procedures apply to an MP2MP downstream FEC element, then the upstream path to a node N is only installed in the label-forwarding database if node N is part of the active accepting element. If node N is part of an inactive accepting element instead, the upstream path gets installed once that inactive accepting element is activated ✨.

9. Typed Wildcard for mLDP FEC Element

The format of the mLDP FEC Typed Wildcard FEC is a bit of a layout situation, so here it is exactly as written 👑:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Typed Wcard   |     Type      |   Len = 2     |      AFI      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               |
   +-+-+-+-+-+-+-+-+

Here's what each field means 🧚:

  • Typed Wcard: As specified in [RFC5918]
  • Type: The type of FEC Element Type. This is either the P2MP FEC Element or the MP2MP FEC Element, using the values defined for those FEC Elements when carried in the FEC TLV as defined in this document.
  • Len: Len FEC Type Info, two octets (=0x02).
  • AFI: Address Family, a two-octet quantity containing a value from IANA's "Address Family Numbers" registry.

10. Security Considerations

This one is serious, bestie 😭🔥. The same security considerations apply as those for the base LDP specification, as described in [RFC5036].

The protocol specified in this document does not provide any authorization mechanism for controlling the set of LSRs that may join a given MP LSP 🚨. If that kind of authorization is desirable, then additional mechanisms are needed, and those are outside the scope of this document. Also, authorization policies cannot be implemented and/or configured solely at the root node of the LSP, because the root node does not learn the identities of all the leaf nodes 🙈.

11. IANA Considerations

Per this document, IANA has created 3 new registries 📚.

  1. "LDP MP Opaque Value Element basic type"
    • The range is 0-255, with the following values allocated in this document:
      • 0: Reserved
      • 1: Generic LSP identifier
      • 255: Extended Type field is present in the following two bytes
    • The allocation policy for this space is 'Standards Action with Early Allocation'.
  2. "LDP MP Opaque Value Element extended type"
    • The range is 0-65535, with the following allocation policies:
      • 0-32767: Standards Action with Early Allocation
      • 32768-65535: First Come, First Served
  3. "LDP MP Status Value Element type"
    • The range is 0-255, with the following values allocated in this document:
      • 0: Reserved
      • 1: MBB Status
    • The allocation policy for this space is 'Standards Action with Early Allocation'.

The code point values listed below have been allocated by IANA through early allocation 🎀.

IANA allocated three new code points from the LDP registry "Forwarding Equivalence Class (FEC) Type Name Space". The values are:

  • P2MP FEC type - requested value 0x06
  • MP2MP-up FEC type - requested value 0x07
  • MP2MP-down FEC type - requested value 0x08

IANA assigned three new code points for new Capability Parameter TLVs from the LDP registry "TLV Type Name Space", corresponding to the advertisement of the P2MP, MP2MP, and MBB capabilities. The values are:

  • P2MP Capability Parameter - 0x0508
  • MP2MP Capability Parameter - 0x0509
  • MBB Capability Parameter - 0x050A

IANA assigned an LDP Status Code to indicate that an LDP MP Status TLV is following in the Notification message. The value assigned in the LDP registry "LDP Status Code Name Space" is:

  • LDP MP status - requested value 0x00000040

IANA assigned a new code point for an LDP MP Status TLV. The value assigned in the LDP registry "LDP TLV Type Name Space" is:

  • LDP MP Status TLV Type - requested value 0x096F

12. Acknowledgments

Huge thanks to these people for their review and contributions 🫶✨: Nischal Sheth, Yakov Rekhter, Rahul Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin and Ben Niven-Jenkins 💖.

13. Contributing Authors

Here's the list of contributing authors, in alphabetical order 📇:

Shane Amante
Level 3 Communications, LLC
1025 Eldorado Blvd
Broomfield, CO 80021
US
EMail: Shane.Amante@Level3.com


Luyuan Fang
Cisco Systems
300 Beaver Brook Road
Boxborough, MA 01719
US
EMail: lufang@cisco.com


Hitoshi Fukuda
NTT Communications Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019,
Japan
EMail: hitoshi.fukuda@ntt.com


Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku,
Tokyo 163-1421,
Japan
EMail: y.kamite@ntt.com


Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: kireeti@juniper.net
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
Lannion, Cedex 22307
France
EMail: jeanlouis.leroux@francetelecom.com


Ina Minei
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
US
EMail: ina@juniper.net


Bob Thomas
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA, 01719
EMail: bobthomas@alum.mit.edu


Lei Wang
Telenor
Snaroyveien 30
Fornebu 1331
Norway
EMail: lei.wang@telenor.com


IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
1831 Diegem
Belgium
EMail: ice@cisco.com

14. References

14.1. Normative References

These are the normative references, and they're all listed in full below 📖:

[ITU.V42.1994]
           International Telecommunications Union, "Error-correcting
           Procedures for DCEs Using Asynchronous-to-Synchronous
           Conversion", ITU-T Recommendation V.42, 1994.
           http://www.itu.int/rec/T-REC-V.42-200203-I

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

[RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
           "LDP Specification", RFC 5036, October 2007.

[RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
           Label Assignment and Context-Specific Label Space", RFC
           5331, August 2008.

[RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
           Le Roux, "LDP Capabilities", RFC 5561, July 2009.

[RFC5918]  Asati, R., Minei, I., and B. Thomas, "Label Distribution
           Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
           (FEC)", RFC 5918, August 2010.

[RFC6389]  Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
           Assignment for LDP", RFC 6389, September 2011.

14.2. Informative References ✨

Okay bestie, these are the extra reads 📚 They're informative, so they're there for background and aren't required reading to get the spec 💅

[ISO3309] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure", ISO 3309, 3rd Edition, October 1984. 🧚

[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010. 🦋

[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. 💜

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

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. 🔥

[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. ✨

[RFC6348] Le Roux, J., Ed., and T. Morin, Ed., "Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011. 👑

Authors' Addresses 🎀

Meet the squad who made this happen 🫶

IJsbrand Wijnands (editor)
Cisco Systems, Inc.
De kleetlaan 6a
Diegem  1831
Belgium
EMail: ice@cisco.com


Ina Minei (editor)
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
US
EMail: ina@juniper.net


Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
US
EMail: kireeti@juniper.net


Bob Thomas
300 Beaver Brook Road
Boxborough  01719
US
EMail: bobthomas@alum.mit.edu
📦 where this page comes from