RFC 3031
Multiprotocol Label Switching Architecture
📜 Multiprotocol Label Switching Architecture 🦋
RFC 3031, "Multiprotocol Label Switching Architecture" 🎀 Authors: E. Rosen (Cisco Systems, Inc.), A. Viswanathan (Force10 Networks, Inc.), and R. Callon (Juniper Networks, Inc.) 💜 Category: Standards Track ✨ Date: January 2001 🌸 Obsoletes / Updates: nothing is listed in the header, so this one doesn't obsolete or update any other RFC 🙌 Network Working Group is the group that published it 🧚
Status of this Memo
okay so this document is an Internet standards track protocol spec for the Internet community 💅 It's open for discussion, and people are literally encouraged to send suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And the good news is distribution of this memo is unlimited 🌈
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒✨
Abstract
this doc is the architecture for Multiprotocol Label Switching (MPLS) 🦋 That's the whole pitch, bestie 💖
Table of Contents
1 Specification ...................................... 3
2 Introduction to MPLS ............................... 3
2.1 Overview ........................................... 4
2.2 Terminology ........................................ 6
2.3 Acronyms and Abbreviations ......................... 9
2.4 Acknowledgments .................................... 9
3 MPLS Basics ........................................ 9
3.1 Labels ............................................. 9
3.2 Upstream and Downstream LSRs ....................... 10
3.3 Labeled Packet ..................................... 11
3.4 Label Assignment and Distribution .................. 11
3.5 Attributes of a Label Binding ...................... 11
3.6 Label Distribution Protocols ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Label Retention Mode ............................... 12
3.9 The Label Stack .................................... 13
3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
3.11 Incoming Label Map (ILM) ........................... 14
3.12 FEC-to-NHLFE Map (FTN) ............................. 14
3.13 Label Swapping ..................................... 15
3.14 Scope and Uniqueness of Labels ..................... 15
3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ....................................... 20
3.18 Invalid Incoming Labels ............................ 20
3.19 LSP Control: Ordered versus Independent ............ 20
3.20 Aggregation ........................................ 21
3.21 Route Selection .................................... 23
3.22 Lack of Outgoing Label ............................. 24
3.23 Time-to-Live (TTL) ................................. 24
3.24 Loop Control ....................................... 25
3.25 Label Encodings .................................... 26
3.25.1 MPLS-specific Hardware and/or Software ............. 26
3.25.2 ATM Switches as LSRs ............................... 26
3.25.3 Interoperability among Encoding Techniques ......... 28
3.26 Label Merging ...................................... 28
3.26.1 Non-merging LSRs ................................... 29
3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
3.26.3 Merge over ATM ..................................... 31
3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
3.27 Tunnels and Hierarchy .............................. 32
3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
3.27.2 Explicitly Routed Tunnel ........................... 33
3.27.3 LSP Tunnels ........................................ 33
3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
3.27.5 Label Distribution Peering and Hierarchy ........... 34
3.28 Label Distribution Protocol Transport .............. 35
3.29 Why More than one Label Distribution Protocol? ..... 36
3.29.1 BGP and LDP ........................................ 36
3.29.2 Labels for RSVP Flowspecs .......................... 36
3.29.3 Labels for Explicitly Routed LSPs .................. 36
3.30 Multicast .......................................... 37
4 Some Applications of MPLS .......................... 37
4.1 MPLS and Hop by Hop Routed Traffic ................. 37
4.1.1 Labels for Address Prefixes ........................ 37
4.1.2 Distributing Labels for Address Prefixes ........... 37
4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
4.1.2.2 Distributing Labels ................................ 38
4.1.3 Using the Hop by Hop path as the LSP ............... 39
4.1.4 LSP Egress and LSP Proxy Egress .................... 39
4.1.5 The Implicit NULL Label ............................ 40
4.1.6 Option: Egress-Targeted Label Assignment ........... 40
4.2 MPLS and Explicitly Routed LSPs .................... 42
4.2.1 Explicitly Routed LSP Tunnels ...................... 42
4.3 Label Stacks and Implicit Peering .................. 43
4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 58
7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 59
9 References ......................................... 59
10 Full Copyright Statement ........................... 611. Specification ✨
okay so 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 💅 That's the decoder ring for every requirement in here, so keep it handy 🔑
2. Introduction to MPLS 🌸
this document is all about the architecture for Multiprotocol Label Switching (MPLS) 🦋
heads up though: using MPLS for multicast is left for further study 👀 So don't go looking for that part yet, bestie 💜
more parts are coming, so stay tuned 🧚💖
2.1. Overview ✨
okay bestie, picture a packet from a connectionless network layer protocol hopping from one router to the next 🦋. at every single router, that packet gets its own independent forwarding decision 💅. each router reads the packet's header AND runs a network layer routing algorithm, then independently picks a next hop based on what the header says plus what the routing algorithm came up with.
ngl, packet headers carry way more info than you actually need just to pick a next hop 😭. so choosing a next hop is lowkey two functions stacked on top of each other. function one partitions the entire set of possible packets into a set of "Forwarding Equivalence Classes (FECs)" 🎀. function two maps each FEC to a next hop 👑. as far as the forwarding decision is concerned, packets that land in the same FEC are totally indistinguishable 🙈. every packet in a particular FEC that travels from a particular node follows the same path (or, if certain kinds of multi-path routing are in use, they all follow one of a set of paths tied to that FEC) 🌈.
in conventional IP forwarding, a router will typically treat two packets as being in the same FEC if there's some address prefix X in its routing tables that is the "longest match" for each packet's destination address 🧚. and as the packet travels through the network, every hop in turn re-examines the packet and assigns it to a FEC all over again 😩.
in MPLS, the FEC assignment happens just once, as the packet enters the network ✨. the FEC is encoded as a short, fixed-length value called a "label" 💖. when the packet gets forwarded to its next hop, the label goes along with it. that's the whole "labeled" part: the packets get labeled BEFORE they're forwarded 🎀.
at subsequent hops there's no further analysis of the network layer header, periodt 💅. instead, the label is used as an index into a table that specifies the next hop AND a new label. the old label gets swapped for the new one, and the packet heads off to its next hop 🦋.
so in the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further header analysis is done by subsequent routers. all forwarding is driven by the labels 🌸. this gives it a bunch of advantages over conventional network layer forwarding, and I'm obsessed with every one of them 😭🫶:
- MPLS forwarding can be done by switches that are capable of label lookup and replacement, but that either aren't capable of analyzing network layer headers at all, or aren't capable of doing it at adequate speed 🚀.
- since a packet gets assigned to a FEC when it enters the network, the ingress router can use ANY information it has about the packet to make that call, even if that info can't be gleaned from the network layer header 👑. for example, packets arriving on different ports can be assigned to different FECs. conventional forwarding, on the other hand, can only consider info that travels with the packet in its header 🙈.
- a packet entering the network at one particular router can be labeled differently than the same packet entering at a different router. so forwarding decisions that depend on the ingress router are super easy to make 💜. this can't be done with conventional forwarding, because the identity of a packet's ingress router doesn't travel with the packet 💀.
- the considerations that decide how a packet gets assigned to a FEC can get more and more complicated, and it has zero impact on the routers that just forward labeled packets 🌈. iconic separation of concerns, no cap 🍓.
- sometimes you want to force a packet to follow a particular route, explicitly chosen at or before the moment it enters the network, instead of letting the normal dynamic routing algorithm pick the path as it travels through 🧚. this might be done as a matter of policy, or to support traffic engineering ✨. in conventional forwarding, this means the packet has to carry an encoding of its route along with it ("source routing") 😩. in MPLS, a label can represent the route instead, so the identity of the explicit route doesn't need to ride along with the packet 🦋.
some routers look at a packet's network layer header not just to pick the next hop, but also to figure out its "precedence" or "class of service" 👑. they might then apply different discard thresholds or scheduling disciplines to different packets 💅. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label ✨. when that happens, you can say the label represents the combination of a FEC AND a precedence or class of service 🫶.
fun fact: MPLS stands for "Multiprotocol" Label Switching 🌈. it's multiprotocol because its techniques are applicable to ANY network layer protocol, not just one 💖. in this document, though, we're focusing on IP as the network layer protocol 🎀.
and finally, a router that supports MPLS is known as a "Label Switching Router", or LSR 👑💜.
2.2. Terminology
Okay bestie, this is the vocab section 📚✨ Some of these terms get a more precise definition later in the doc, so this is the vibe check version 💅
- DLCI: a label used in Frame Relay networks to identify frame relay circuits 🎀
- forwarding equivalence class: a group of IP packets that get forwarded the same way (e.g., over the same path, with the same forwarding treatment) 🦋
- frame merge: label merging, when it's applied to operation over frame based media, so the potential problem of cell interleave is not an issue 🫶
- label: a short, fixed length, physically contiguous identifier used to identify a FEC, usually of local significance 🏷️
- label merging: swapping out multiple incoming labels for a particular FEC with one single outgoing label 🌸
- label swap: the basic forwarding move. You look up an incoming label to find the outgoing label, plus encapsulation, port, and other data handling info 🔁
- label swapping: a forwarding paradigm that lets data move super streamlined by using labels to group packets into classes that get treated the same way when forwarded 💜
- label switched hop: the hop between two MPLS nodes where forwarding is done using labels 🍓
- label switched path: the path through one or more LSRs at one level of the hierarchy that a packet in a particular FEC follows 🧚
- label switching router: an MPLS node that can forward native L3 packets 👑
- layer 2: the protocol layer under layer 3 (so it offers the services layer 3 uses). Forwarding done by swapping short fixed length labels happens at layer 2, no matter if the label being checked is an ATM VPI/VCI, a frame relay DLCI, or an MPLS label 🌈
- layer 3: the protocol layer where IP and its routing protocols operate. link layer is synonymous with layer 2 🌐
- loop detection: a way of handling loops where loops are allowed to be set up and data may go over the loop, but the loop gets detected later on 🔍
- loop prevention: a way of handling loops where data never gets sent over a loop 🙅♀️
- label stack: an ordered set of labels 📚
- merge point: a node where label merging gets done 🔀
- MPLS domain: a contiguous set of nodes that run MPLS routing and forwarding and are also in one Routing or Administrative Domain 🏰
- MPLS edge node: an MPLS node that connects an MPLS domain with a node outside the domain, either because that node doesn't run MPLS, and/or because it's in a different domain. Note that if an LSR has a neighboring host that isn't running MPLS, then that LSR is an MPLS edge node 🚪
- MPLS egress node: an MPLS edge node in its role of handling traffic as it leaves an MPLS domain 👋
- MPLS ingress node: an MPLS edge node in its role of handling traffic as it enters an MPLS domain 🫴
- MPLS label: a label carried in a packet header that represents the packet's FEC 🎟️
- MPLS node: a node that's running MPLS. An MPLS node is aware of MPLS control protocols, runs one or more L3 routing protocols, and can forward packets based on labels. An MPLS node may optionally also be able to forward native L3 packets ⭐
- MultiProtocol Label Switching: an IETF working group and the effort associated with that working group 🎀
- network layer: synonymous with layer 3 🧠
- stack: synonymous with label stack 🥞
- switched path: synonymous with label switched path 🛤️
- virtual circuit: a circuit used by a connection-oriented layer 2 technology such as ATM or Frame Relay, which requires keeping state information in layer 2 switches 🌀
- VC merge: label merging where the MPLS label is carried in the ATM VCI field (or the combined VPI/VCI field), so multiple VCs can merge into one single VC 🧩
- VP merge: label merging where the MPLS label is carried in the ATM VPI field, so multiple VPs can be merged into one single VP. In this case two cells would have the same VCI value only if they came from the same node. This lets cells from different sources be told apart by the VCI 🦄
- VPI/VCI: a label used in ATM networks to identify circuits ⚡
2.3. Acronyms and Abbreviations
Here's the acronym cheat sheet 📝 (copied exactly as the original has it, quirks and all)
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
DLCI Data Link Circuit Identifier
FEC Forwarding Equivalence Class
FTN FEC to NHLFE Map
IGP Interior Gateway Protocol
ILM Incoming Label Map
IP Internet Protocol
LDP Label Distribution Protocol
L2 Layer 2 L3 Layer 3
LSP Label Switched Path
LSR Label Switching Router
MPLS MultiProtocol Label Switching
NHLFE Next Hop Label Forwarding Entry
SVC Switched Virtual Circuit
SVP Switched Virtual Path
TTL Time-To-Live
VC Virtual Circuit
VCI Virtual Circuit Identifier
VP Virtual Path
VPI Virtual Path Identifier2.4. Acknowledgments
Shoutout to everyone who helped make this doc happen 🫶 The ideas and text were pulled together from a bunch of sources and comments. Big thanks to Rick Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and George Swallow for their inputs and ideas 💖
3. MPLS Basics ✨
Now we get to the good stuff 🦋 This section introduces some of the basic MPLS concepts and the general approach we're going to use.
3.1. Labels
A label is a short, fixed length, locally significant identifier used to identify a FEC. The label that goes on a particular packet represents the Forwarding Equivalence Class that packet has been assigned to 🏷️
Most commonly, a packet gets assigned to a FEC based (completely or partially) on its network layer destination address. However, the label is never an encoding of that address 🙅♀️
Okay, here's the binding part 🤝 If Ru and Rd are LSRs, they may agree that when Ru transmits a packet to Rd, Ru will label the packet with label value L if and only if the packet is a member of a particular FEC F. That means they can agree on a "binding" between label L and FEC F for packets moving from Ru to Rd. Because of that agreement, L becomes Ru's "outgoing label" representing FEC F, and L becomes Rd's "incoming label" representing FEC F 💜
Note that L doesn't necessarily represent FEC F for any packets other than the ones being sent from Ru to Rd. L is an arbitrary value, and its binding to F is local to Ru and Rd 🎀
When we say packets are "being sent" from Ru to Rd above, we're NOT implying that the packet started at Ru or that its destination is Rd. We mean to include packets that are "transit packets" at one or both of the LSRs 🚌
Sometimes it's hard or even impossible for Rd to tell, from an arriving packet carrying label L, that Ru is the one who put label L on it instead of some other LSR. (This is typically the case when Ru and Rd aren't direct neighbors.) In those cases, Rd MUST NOT agree with Ru1 to bind L to FEC F1 while also agreeing with some other LSR Ru2 to bind L to a different FEC F2, unless Rd can always tell, when it receives a packet with incoming label L, whether Ru1 or Ru2 put the label on the packet. So Rd really has to keep its bindings one-to-one 😤🔒
Last but not least, each LSR is responsible for making sure it can uniquely interpret its incoming labels 🧐
3.2. Upstream and Downstream LSRs
Let's say Ru and Rd have agreed to bind label L to FEC F for packets sent from Ru to Rd. With respect to this binding, Ru is the "upstream LSR" and Rd is the "downstream LSR" ⬆️⬇️
Saying one node is upstream and another is downstream for a given binding only means that a particular label represents a particular FEC in packets traveling from the upstream node to the downstream node. This is NOT meant to imply that packets in that FEC would actually be routed from the upstream node to the downstream node 🙈
3.3. Labeled Packet
A "labeled packet" is a packet that has a label encoded into it 📦 Sometimes the label lives in an encapsulation header that exists specifically for this purpose. Other times the label can sit in an existing data link or network layer header, as long as there's a field free for that purpose 🧃 Either way, the particular encoding technique has to be agreed on by both the entity that encodes the label and the entity that decodes it 🫶
3.4. Label Assignment and Distribution ✨
okay so here's the big question: who actually decides which label goes with which FEC? 👀 In MPLS, the LSR that's DOWNSTREAM for that binding makes the call. Then it tells its UPSTREAM buddy about the binding. So labels are "downstream-assigned," and the bindings travel "downstream to upstream." It's giving reverse-direction energy, and I'm obsessed 💜
Also, if an LSR can only look up labels inside a certain number range, it just has to make sure it only binds labels from that range. Simple, bestie 🧚
3.5. Attributes of a Label Binding 🎀
So a binding of label L to FEC F that gets distributed from Rd to Ru can come with "attributes." Here's the twist: if Ru is acting as a downstream LSR and also hands out a binding for a label to FEC F, then under certain conditions it might have to pass along the matching attribute it got from Rd. Chain reaction, but make it neat 🦋
3.6. Label Distribution Protocols 🌸
A label distribution protocol is just a set of procedures where one LSR tells another about the label/FEC bindings it has made. Two LSRs that use one of these protocols to swap binding info are called "label distribution peers" for that info. If two LSRs are label distribution peers, we say there's a "label distribution adjacency" between them.
N.B.: two LSRs can be label distribution peers for some set of bindings but not for some other set. Context matters, babe 💅
The protocol also covers any negotiation the peers need to do so they can find out each other's MPLS capabilities. Lowkey essential 😭
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. There are a bunch being standardized, and it's giving variety 🌈 Some existing protocols got extended so label distribution can be piggybacked on them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Other protocols were built specifically to distribute labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].
In this document, we try to use the acronym "LDP" to mean the protocol defined in [MPLS-LDP]. When we're talking about label distribution protocols in general, we try to avoid the acronym. Clean and iconic 💖
3.7. Unsolicited Downstream vs. Downstream-on-Demand 🦋
The MPLS architecture lets an LSR explicitly ask its next hop for a particular FEC for a label binding. That's called "downstream-on-demand" label distribution. Basically the LSR says "hey, can I get one?" 🙈
The architecture also lets an LSR push bindings out to LSRs that never asked. That's "unsolicited downstream" label distribution. Surprise delivery, no cap 🎁
Some MPLS implementations will offer only downstream-on-demand, some will offer only unsolicited downstream, and some will do both. What's available might depend on the characteristics of the interfaces that a given implementation supports. Still, both techniques can run in the same network at the same time 🔥 On any single label distribution adjacency, though, the upstream LSR and the downstream LSR must agree on which technique they're using. No vibes-only agreements here 💅
3.8. Label Retention Mode 🌷
An LSR Ru might receive (or might have received) a label binding for a particular FEC from an LSR Rd, even though Rd is not Ru's next hop (or is no longer Ru's next hop) for that FEC. Not me getting bindings from the wrong person 💀
Ru then gets to choose: keep track of those bindings, or throw them away. If Ru keeps them, it can start using the binding again right away if Rd eventually becomes its next hop for that FEC. If Ru tosses them, then when Rd becomes the next hop later, the binding has to be reacquired. Annoying, bestie 😤
If an LSR supports "Liberal Label Retention Mode," it keeps the bindings between a label and a FEC that it gets from LSRs which are not its next hop for that FEC. If an LSR supports "Conservative Label Retention Mode," it discards those bindings.
Liberal label retention mode lets an LSR adapt faster to routing changes. Conservative label retention mode, though, means the LSR has to maintain many fewer labels. Trade-offs are giving main character energy either way ✨
3.9. The Label Stack 🧚
Up to now, we've talked like a labeled packet only carries one label. But it's actually more iconic to have a more general model, where a labeled packet carries a bunch of labels organized as a last-in, first-out stack. We call this a "label stack." LIFO queue, but make it fashion 👑
As we'll see, MPLS supports a hierarchy, but processing a labeled packet doesn't depend on how deep the hierarchy goes. Processing is always based on the top label. It doesn't matter if other labels were "above it" in the past, or if other labels are below it right now. Focus on the top, periodt 💅
An unlabeled packet can be thought of as a packet whose label stack is empty (i.e., whose label stack has depth 0). Zero labels, zero drama 🌸
If a packet's label stack has depth m, the label at the bottom of the stack is the level 1 label. The label above it (if one exists) is the level 2 label. And the label at the top of the stack is the level m label. Numbering is giving organized 🎀
The usefulness of the label stack will make more sense once we introduce the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27). Stay tuned, bestie 🫶
3.10. The Next Hop Label Forwarding Entry (NHLFE) 🍓
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding a labeled packet. It contains the following information:
- the packet's next hop
- the operation to perform on the packet's label stack; this is one of the following operations:
- a) replace the label at the top of the label stack with a specified new label
- b) pop the label stack
- c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack.
It may also contain:
- d) the data link encapsulation to use when transmitting the packet
- e) the way to encode the label stack when transmitting the packet
- f) any other information needed in order to properly dispose of the packet.
Note that at a given LSR, the packet's "next hop" might be that LSR itself. In that case, the LSR would need to pop the top level label, and then "forward" the resulting packet to itself. It would then make another forwarding decision, based on what remains after the label stack is popped. The result might still be a labeled packet, or it might be the native IP packet. Forwarding to yourself, the ultimate self-care 🙈
This implies that in some cases the LSR may need to operate on the IP header in order to forward the packet. Heads up, the IP header is involved sometimes 👀
If the packet's "next hop" is the current LSR, then the label stack operation MUST be to "pop the stack". Non-negotiable, bestie 💅
3.11. Incoming Label Map (ILM) 💜
The "Incoming Label Map" (ILM) maps each incoming label to a set of NHLFEs. It's used when forwarding packets that arrive as labeled packets. Incoming labels in, NHLFEs out 🦋
If the ILM maps a particular label to a set of NHLFEs with more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing that element are beyond the scope of this document. Having the ILM map a label to a set with more than one NHLFE may be useful if, for example, you want to do load balancing over multiple equal-cost paths. Spreading the love across paths, iconic 🌈
3.12. FEC-to-NHLFE Map (FTN) 🌸
The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It's used when forwarding packets that arrive unlabeled but are supposed to be labeled before they get forwarded. Unlabeled in, labeled glow-up 🧚
If the FTN maps a particular label to a set of NHLFEs with more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing that element are beyond the scope of this document. Having the FTN map a label to a set with more than one NHLFE may be useful if, for example, you want to do load balancing over multiple equal-cost paths. Same energy as the ILM, just on the FTN side 💖
3.13. Label Swapping ✨
Label swapping is the use of the following procedures to forward a packet.
To forward a labeled packet, an LSR examines the label at the top of the label stack. It uses the ILM to map this label to an NHLFE. Using the information in the NHLFE, it works out where to forward the packet and performs an operation on the packet's label stack. Then it encodes the new label stack into the packet and forwards the result. Swap, pop, forward, slay 🔥
To forward an unlabeled packet, an LSR analyzes the network layer header to determine the packet's FEC. It then uses the FTN to map this to an NHLFE. Using the information in the NHLFE, it works out where to forward the packet and performs an operation on the packet's label stack. (Popping the label stack would, of course, be illegal in this case.) Then it encodes the new label stack into the packet and forwards the result. Sorry, nothing to pop when there's nothing there 🙈
IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE. This is the part to remember, bestie. The NHLFE decides the next hop, not plain IP routing. Mind blown 🤯💜
3.14. Scope and Uniqueness of Labels 🎀
Okay so picture this: an LSR called Rd binds label L1 to FEC F and tells its label distribution peer Ru1 about it. Rd also binds label L2 to FEC F and tells Ru2. Whether L1 == L2 isn't decided by the architecture, bestie. That's a local matter 💅
Now say Rd binds label L to FEC F1 and sends that to Ru1, then binds the same L to FEC F2 and sends that to Ru2. IF (AND ONLY IF) Rd can tell, when a packet shows up with L on top, whether Ru1 or Ru2 put it there, then the architecture does not require F1 == F2. In that case we can say Rd is using a different "label space" for the labels it gives Ru1 than for the ones it gives Ru2 🦋
Rd can only tell whether Ru1 or Ru2 put the label value L on top of the stack if these conditions hold:
- Ru1 and Ru2 are the only label distribution peers to which Rd distributed a binding of label value L, and
- Ru1 and Ru2 are each directly connected to Rd via a point-to-point interface.
When both of those are true, an LSR can use labels with "per interface" scope, meaning they're only unique per interface. That's a "per-interface label space" ✨. When they aren't true, the labels have to be unique over the LSR that assigned them, and that's a "per-platform label space" 🌸
Here's a plot twist 🙈 If Rd is attached to Ru over two point-to-point interfaces, Rd can give Ru a binding of label L to FEC F1 and a binding of label L to FEC F2 (with F1 != F2), but only if each binding is valid only for packets that Ru sends to Rd over one particular interface. In every other case, Rd MUST NOT distribute bindings of the same label value to two different FECs to Ru. No exceptions, periodt 💅
This prohibition still holds even when the bindings are at different "levels of hierarchy". In MPLS there's no such thing as a different label space for each level of the hierarchy. When you interpret a label, the level of the label doesn't matter at all 🧚
Now, can an LSR use multiple per-platform label spaces, or multiple per-interface label spaces on the same interface? The architecture doesn't prohibit it. But then the LSR has to have some means, which the architecture doesn't specify, of figuring out which label space a particular incoming label belongs to. For example, [MPLS-SHIM] says unicast packets use a different label space than multicast packets, and it uses a data link layer codepoint to tell the two label spaces apart 🫶
3.15. Label Switched Path (LSP), LSP Ingress, LSP Egress 🌈
A "Label Switched Path (LSP) of level m" for a particular packet P is a sequence of routers, like this:
<R1, ..., Rn>and it has these properties ⭐
- R1, the "LSP Ingress", is an LSR that pushes a label onto P's label stack, so the label stack ends up with a depth of m.
- For all i,
1<i<n, P has a label stack of depth m when LSR Ri receives it. - At no time during P's transit from R1 to R[n-1] does its label stack ever have a depth less than m.
- For all i,
1<i<n: Ri transmits P to R[i+1] by means of MPLS, i.e., by using the label at the top of the label stack (the level m label) as an index into an ILM. - For all i,
1<i<n: if a system S receives and forwards P after P is transmitted by Ri but before P is received by R[i+1] (e.g., Ri and R[i+1] might be connected via a switched data link subnetwork, and S might be one of the data link switches), then S's forwarding decision is not based on the level m label, or on the network layer header. This may be because:- a) the decision is not based on the label stack or the network layer header at all;
- b) the decision is based on a label stack on which additional labels have been pushed (i.e., on a level m+k label, where k>0).
So in other words, we can talk about the level m LSP for packet P as the sequence of routers that:
- begins with an LSR (an "LSP Ingress") that pushes on a level m label,
- has all of its intermediate LSRs make their forwarding decision by label Switching on a level m label,
- ends (at an "LSP Egress") when a forwarding decision is made by label Switching on a level m-k label, where k>0, or when a forwarding decision is made by "ordinary", non-MPLS forwarding procedures.
Here's the consequence (or maybe the presupposition) 👑 Whenever an LSR pushes a label onto a packet that's already labeled, it needs to make sure the new label corresponds to a FEC whose LSP Egress is the LSR that assigned the label now second in the stack.
We'll call a sequence of LSRs the "LSP for a particular FEC F" if it's an LSP of level m for a particular packet P, where P's level m label corresponds to FEC F 💜
Now think about all the nodes that could be LSP ingress nodes for FEC F. There's an LSP for FEC F starting at each of them. If a bunch of those LSPs share the same LSP egress, you can treat that set of LSPs as a tree whose root is the LSP egress. (Data travels toward the root, so this can be called a multipoint-to-point tree.) That's how we get the "LSP tree" for a particular FEC F 🌳
3.16. Penultimate Hop Popping 💅
Check it: according to the definitions in section 3.15, if <R1, ..., Rn> is a level m LSP for packet P, then P can be transmitted from R[n-1] to Rn with a label stack of depth m-1. So the label stack can be popped at the penultimate LSR of the LSP, instead of at the LSP Egress 🍓
From an architectural point of view, this is totally appropriate. The whole job of the level m label is to get the packet to Rn. Once R[n-1] has decided to send the packet to Rn, that label has no function left, so it doesn't need to keep riding along.
There's also a practical perk ✨ Without this, when the LSP egress receives a packet, it has to look up the top label first and figure out that it really is the LSP egress. Then it has to pop the stack and examine what's left. If there's another label, the egress looks that one up and forwards based on it. (In that case, the egress for the packet's level m LSP is also an intermediate node for its level m-1 LSP.) If there's no other label, the packet is forwarded according to its network layer destination address. Notice that this means the egress has to do TWO lookups: either two label lookups, or a label lookup followed by an address lookup 😭
With penultimate hop popping, when the penultimate hop looks up the label, it figures out:
- that it's the penultimate hop, and
- who the next hop is.
The penultimate node pops the stack and forwards the packet based on what it learned by looking up the label that used to be on top. When the LSP egress gets the packet, the label now on top is the one it needs to look up to make its own forwarding decision. Or, if the packet was only carrying one label, the LSP egress just sees the network layer packet, which is exactly what it needs to make its decision 🦋
So the egress does a single lookup, and the penultimate node only needs a single lookup too. Lowkey genius 🧠
Building the forwarding "fastpath" in a label switching product gets a lot easier if you know only a single lookup is ever needed:
- the code can be simpler if it can assume only a single lookup is ever needed
- the code can be based on a "time budget" that assumes only a single lookup is ever needed
Actually, when penultimate hop popping is done, the LSP Egress doesn't even have to be an LSR 🙈
Heads up: some hardware switching engines may not be able to pop the label stack, so this can't be a universal requirement. There may also be situations where penultimate hop popping isn't desirable. So the penultimate node pops the label stack only if the egress node specifically asks for it, OR if the next node in the LSP doesn't support MPLS. (If the next node in the LSP does support MPLS but doesn't make such a request, the penultimate node has no way of knowing it actually is the penultimate node.)
An LSR that's capable of popping the label stack at all MUST do penultimate hop popping when its downstream label distribution peer requests it 🎀
Initial label distribution protocol negotiations MUST let each LSR figure out whether its neighboring LSRs can pop the label stack. An LSR MUST NOT ask a label distribution peer to pop the label stack unless it's capable of doing so 🫶
Someone might ask whether the egress node can always interpret the top label of a received packet properly when penultimate hop popping is used. As long as the uniqueness and scoping rules of section 3.14 are followed, the top label of a received packet can always be interpreted unambiguously ✨
3.17. LSP Next Hop 🌸
The LSP Next Hop for a particular labeled packet in a particular LSR is the LSR that's the next hop, as selected by the NHLFE entry used to forward that packet.
The LSP Next Hop for a particular FEC is the next hop selected by the NHLFE entry indexed by a label that corresponds to that FEC.
Here's the thing: the LSP Next Hop may be different from the next hop the network layer routing algorithm would pick. When we talk about that one, we'll use the term "L3 next hop" 🧚
3.18. Invalid Incoming Labels 💀
So what should an LSR do if it gets a labeled packet with a particular incoming label, but it has no binding for that label? It's tempting to think you can just strip the labels and forward the packet as an unlabeled IP packet. But in some cases, that could cause a loop 😱 If the upstream LSR thinks the label is bound to an explicit route, and the downstream LSR doesn't think the label is bound to anything, and the hop by hop routing of the unlabeled IP packet brings it back to the upstream LSR, then yep, you've got a loop.
It's also possible that the label was meant to represent a route that can't be inferred from the IP header.
So, when a labeled packet is received with an invalid incoming label, it MUST be discarded, unless it's determined by some means (not within the scope of the current document) that forwarding it unlabeled can't cause any harm 🔥
3.19. LSP Control: Ordered versus Independent ✨
Okay so some FECs 🎀 line up with address prefixes that get passed around by a dynamic routing algorithm 🗺️. There are two ways to set up the LSPs for those FECs: Independent LSP Control or Ordered LSP Control. 💖
In Independent LSP Control, each LSR that recognizes a particular FEC makes its own call to bind a label to that FEC, then distributes that binding to its label distribution peers. 🦋 This is basically how regular IP datagram routing already works. Every node decides how to treat each packet on its own, and it's counting on the routing algorithm to converge fast enough that every datagram still gets delivered correctly. 🫶
In Ordered LSP Control, an LSR only binds a label to a particular FEC if it's the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next hop for that FEC. 👑 (The "next hop for that FEC" part is the rule, bestie, not a vibe.)
Here's the big deal 😭. If you want traffic in a FEC to take a path with certain properties, like not traversing any node twice, having a specified amount of resources available, or following an explicitly specified path, then ordered control must be used. 💅 With independent control, some LSRs can start label switching that traffic before the LSP is completely set up, so some of it might take a path that doesn't have those properties. Ordered control also needs to be used if recognizing the FEC is a consequence of setting up the corresponding LSP. 🌸
Ordered LSP setup can be initiated by either the ingress or the egress. 🧚
Ordered and independent control are fully interoperable 🤝. Still, unless all LSRs in an LSP are using ordered control, the overall effect on network behavior is mostly like independent control, because you can't be sure an LSP isn't being used until it's fully set up. 💀
This architecture lets the choice between independent and ordered control be a local matter. Since the two methods interwork, a given LSR only needs to support one or the other. ✨ Generally speaking, picking independent versus ordered doesn't seem to affect which label distribution mechanisms need to be defined. 🌈
3.20. Aggregation 🧩
One way to split traffic into FECs is to make a separate FEC for each address prefix in the routing table 📚. But within a particular MPLS domain, that can end up with a bunch of FECs where all the traffic follows the same route. 🤔 For example, a few distinct address prefixes might all have the same egress node, and label swapping might only be used to get the traffic to that egress node. In that case, within the MPLS domain, the union of those FECs is itself a FEC. 🎀 So now there's a choice: should a distinct label be bound to each component FEC, or should a single label be bound to the union and applied to all traffic in the union? 💅
The procedure of binding a single label to a union of FECs that is itself a FEC (within some domain), and applying that label to all traffic in the union, is known as "aggregation". ✨ The MPLS architecture allows aggregation. It can reduce the number of labels needed to handle a particular set of packets, and it may also reduce the amount of label distribution control traffic needed. 🌸
Given a set of FECs that are "aggregatable" into a single FEC, you can (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. 🔍 So we can talk about the "granularity" of aggregation, with (a) being the "coarsest granularity" and (c) being the "finest granularity". 💖
When ordered control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs. 🦋
When independent control is used, it's possible that there will be two adjacent LSRs, Ru and Rd, that aggregate some set of FECs differently. 🙈
If Ru has finer granularity than Rd, no problem 🙌. Ru distributes more labels for that set of FECs than Rd does. That means when Ru needs to forward labeled packets in those FECs to Rd, it may need to map n labels into m labels, where n > m. As an option, Ru may withdraw the set of n labels it has distributed, then distribute a set of m labels that matches Rd's granularity. This isn't necessary for correct operation, but it does reduce the number of labels Ru distributes, and Ru doesn't gain any particular advantage from distributing the larger number. Whether to do this is a local matter. 🫶
If Ru has coarser granularity than Rd (meaning Rd has distributed n labels for the set of FECs, while Ru has distributed m, where n > m), Ru has two choices:
- It may adopt Rd's finer level of granularity. This would mean withdrawing the m labels it has distributed and distributing n labels. This is the preferred option. ⭐
- It may simply map its m labels into a subset of Rd's n labels, if it can determine that this will produce the same routing. For example, suppose Ru applies a single label to all traffic that needs to pass through a certain egress LSR, whereas Rd binds a number of different labels to that traffic depending on the individual destination addresses of the packets. If Ru knows the address of the egress router, and Rd has bound a label to the FEC identified by that address, then Ru can simply apply that label. 🧚
In any event, every LSR needs to know (by configuration) what granularity to use for the labels it assigns. With ordered control, each node only needs to know the granularity for FECs that leave the MPLS network at that node. With independent control, the best results may be obtained by making sure all LSRs are consistently configured to know the granularity for each FEC. However, in many cases you can do this with a single level of granularity that applies to all FECs, like "one label per IP prefix in the forwarding table" or "one label per egress node". 🎀
3.21. Route Selection 🗺️
Route selection refers to the method used for selecting the LSP for a particular FEC. The proposed MPLS protocol architecture supports two options for Route Selection: (1) hop by hop routing, and (2) explicit routing. 💅
Hop by hop routing allows each node to independently choose the next hop for each FEC. This is the usual mode in existing IP networks today 🌸. A "hop by hop routed LSP" is an LSP whose route is selected using hop by hop routing.
With an explicitly routed LSP, each LSR doesn't independently choose the next hop. Instead, a single LSR, generally the LSP ingress or the LSP egress, specifies several (or all) of the LSRs in the LSP. 👑 If a single LSR specifies the entire LSP, the LSP is "strictly" explicitly routed. If a single LSR specifies only some of the LSP, the LSP is "loosely" explicitly routed. 🦋
The sequence of LSRs followed by an explicitly routed LSP may be chosen by configuration, or it may be selected dynamically by a single node. For example, the egress node may use topological information learned from a link state database to compute the entire path for the tree ending at that egress node. 🧠
Explicit routing can be useful for a number of purposes, such as policy routing or traffic engineering 💖. In MPLS, the explicit route needs to be specified at the time labels are assigned, but it doesn't have to be specified with each IP packet. That makes MPLS explicit routing much more efficient than the alternative of IP source routing. ✨
The procedures for making use of explicit routes, either strict or loose, are beyond the scope of this document. 🙈
3.22. Lack of Outgoing Label 😬
When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR where the ILM doesn't map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. 💀 This can happen due to transient conditions, or due to an error at the LSR that should be the packet's next hop.
It's tempting in cases like this to strip off the label stack and try to forward the packet further via conventional forwarding, based on its network layer header 🤷♀️. However, in general that isn't a safe procedure:
- If the packet has been following an explicitly routed LSP, this could result in a loop. 🔁
- The packet's network header may not contain enough information to let this particular LSR forward it correctly. 😵
Unless it can be determined (through some means outside the scope of this document) that neither of these situations applies, the only safe procedure is to discard the packet. 🫠
3.23. Time-to-Live (TTL) ⏳
Okay so in regular IP forwarding, every packet carries a "Time To Live" (TTL) value in its header. 💖 Each time the packet passes through a router, its TTL gets knocked down by 1. If the TTL hits 0 before the packet reaches its destination, the packet gets discarded. 🗑️
This is lowkey a lifesaver because it protects against forwarding loops, which can happen thanks to misconfigurations, or when the routing algorithm fails or converges slowly. 🌀 TTL also does other jobs, like multicast scoping and powering the "traceroute" command. 🔍 So MPLS has to deal with two TTL-related issues: (i) TTL as a way to suppress loops, and (ii) TTL as a way to accomplish other functions, such as limiting the scope of a packet. Main character energy, honestly. ✨
When a packet travels along an LSP, it SHOULD emerge with the same TTL value it would have had if it had crossed the same sequence of routers without being label switched. 🦋 If the packet goes through a hierarchy of LSPs, the total number of LSR-hops it traversed SHOULD be reflected in its TTL value when it comes out of that hierarchy. 🌈
How TTL gets handled depends on where the MPLS label values live. They could be carried in an MPLS-specific "shim" header [MPLS-SHIM], or in an L2 header, like an ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY]. 🎀
If the label values are encoded in a "shim" that sits between the data link and network layer headers, then this shim MUST have a TTL field. That field SHOULD be initially loaded from the network layer header TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be copied into the network layer header TTL field when the packet emerges from its LSP. 💅
Now, if the label values are encoded in a data link layer header (for example, the VPI/VCI field in ATM's AAL5 header), and an L2 switch (like an ATM switch) forwards the labeled packets, and that data link layer doesn't have its own TTL field, then there's no way to decrement the packet's TTL at each LSR-hop. 😭 An LSP segment made of LSRs that can't decrement a packet's TTL gets called a "non-TTL LSP segment". 🫠
When a packet emerges from a non-TTL LSP segment, it SHOULD however be given a TTL that reflects the number of LSR-hops it traversed. For unicast, this can be done by propagating a meaningful LSP length to ingress nodes, so the ingress can decrement the TTL value before forwarding packets into a non-TTL LSP segment. 🧠✨
Sometimes, upon entering a non-TTL LSP segment, it can be determined that a particular packet's TTL will expire before the packet reaches the egress of that segment. In that case, the LSR at the ingress to the non-TTL LSP segment must not label switch the packet. 🙅♀️ That means special procedures have to be developed to support traceroute functionality. For example, traceroute packets may be forwarded using conventional hop by hop forwarding. 🗺️
3.24. Loop Control 🔁
On a non-TTL LSP segment, by definition, TTL can't be used to protect against forwarding loops. 🙈 How much loop control matters depends on the particular hardware providing the LSR functions along that segment.
Let's say ATM switching hardware is providing the MPLS switching functions, with the label carried in the VPI/VCI field. Since ATM switching hardware can't decrement TTL, there's no protection against loops. 🌪️ If the ATM hardware can provide fair access to the buffer pool for incoming cells carrying different VPI/VCI values, the looping may not hurt other traffic at all. But if the hardware can't do fair buffer access like that, even transient loops may seriously degrade the LSR's total performance. 💀
Even when fair buffer access is available, it's still worth having some way to detect loops that last "longer than possible". 👀 Also, even where TTL and/or per-VC fair queuing lets you survive loops, it may still be desirable, where practical, to avoid setting up LSPs that loop in the first place. 🚫🔁 So all LSRs that may attach to non-TTL LSP segments will be required to support a common technique for loop detection. Using that loop detection technique is optional, though. The loop detection technique is specified in [MPLS-ATM] and [MPLS-LDP]. 📜
3.25. Label Encodings 🎀
To send a label stack along with the packet it belongs to, you need a concrete encoding of that label stack. The architecture supports several different encoding techniques, and the one you pick depends on the kind of device forwarding the labeled packets. 🧁
3.25.1. MPLS-specific Hardware and/or Software 🛠️
If you're using MPLS-specific hardware and/or software to forward labeled packets, the most obvious way to encode the label stack is to define a new protocol to use as a "shim" between the data link layer and network layer headers. 💖 This shim would basically just be an encapsulation of the network layer packet. It would be "protocol-independent", meaning it could encapsulate any network layer, so we'll call it the "generic MPLS encapsulation". 🌈
The generic MPLS encapsulation would then be encapsulated in a data link layer protocol. 📦
The MPLS generic encapsulation is specified in [MPLS-SHIM]. 📄
3.25.2. ATM Switches as LSRs 🦋
Notice that MPLS forwarding procedures are super similar to those of legacy "label swapping" switches, like ATM switches. ✨ ATM switches use the input port and the incoming VPI/VCI value as the index into a "cross-connect" table, which gives them an output port and an outgoing VPI/VCI value. So if one or more labels can be encoded directly into the fields those legacy switches already access, then the legacy switches can, with suitable software upgrades, be used as LSRs. We'll call these devices "ATM-LSRs". 👑
There are three obvious ways to encode labels in the ATM cell header (assuming AAL5 is used):
- SVC Encoding 📞
Use the VPI/VCI field to encode the label at the top of the label stack. This technique can be used in any network. With this encoding, each LSP is realized as an ATM SVC, and the label distribution protocol becomes the ATM "signaling" protocol. ATM-LSRs can't do "push" or "pop" operations on the label stack with this one, though. 🙃
- SVP Encoding 🛣️
Use the VPI field to encode the label at the top of the label stack, and the VCI field to encode the second label on the stack, if there is one. This technique has some advantages over the previous one, since it lets you use ATM "VP-switching". The LSPs are realized as ATM SVPs, with the label distribution protocol serving as the ATM signaling protocol. 🔥
It can't always be used, though. If the network includes an ATM Virtual Path through a non-MPLS ATM network, the VPI field isn't necessarily available for MPLS to use. 😬
When this encoding is used, the ATM-LSR at the egress of the VP effectively does a "pop" operation. 🎬
- SVP Multipoint Encoding 🌸
Use the VPI field to encode the label at the top of the label stack. Use part of the VCI field to encode the second label on the stack, if there is one, and use the rest of the VCI field to identify the LSP ingress. If you do this, conventional ATM VP-switching capabilities can provide multipoint-to-point VPs. Cells from different packets will then carry different VCI values. As we shall see in section 3.26, this lets us do label merging without running into any cell interleaving problems, on ATM switches that can provide multipoint-to-point VPs but don't have the VC merge capability. 🧚
This technique depends on being able to assign 16-bit VCI values to each ATM switch so that no single VCI value is assigned to two different switches. (If an adequate number of such values could be assigned to each switch, it would also be possible to treat the VCI value as the second label in the stack.) 🧠
If there are more labels on the stack than the ATM header can hold, the ATM encodings must be combined with the generic encapsulation. 🫶
3.25.3. Interoperability among Encoding Techniques 🤝
If <R1, R2, R3> is a segment of an LSP, R1 might use one encoding of the label stack when transmitting packet P to R2, but R2 might use a different encoding when transmitting packet P to R3. 🌀 In general, the MPLS architecture supports LSPs with different label stack encodings used on different hops, so that's totally allowed. 💜 That's why, when we talk about processing a labeled packet, we speak in abstract terms of operating on the packet's label stack. When a labeled packet is received, the LSR must decode it to find the current value of the label stack, then operate on the label stack to determine the new value, and then encode the new value appropriately before transmitting the labeled packet to its next hop. 🧩
Unfortunately, ATM switches have no capability for translating from one encoding technique to another. ☹️ So the MPLS architecture requires that whenever two ATM switches could be successive LSRs along a level m LSP for some packet, those two ATM switches use the same encoding technique. 🔒
Naturally, there will be MPLS networks that mix ATM switches operating as LSRs with other LSRs that use an MPLS shim header. In these networks, some LSRs will have ATM interfaces as well as "MPLS Shim" interfaces. This is one example of an LSR with different label stack encodings on different hops. Such an LSR may swap off an ATM encoded label stack on an incoming interface and replace it with an MPLS shim header encoded label stack on the outgoing interface. 🌈✨
3.26. Label Merging ✨
Okay so picture this, bestie 🫶. An LSR has bound a bunch of incoming labels to one FEC, and every packet in that FEC should leave with the same outgoing label. It doesn't matter that the packets came in with different incoming labels. The goal is to send them all out with one label. That trick is called "label merging" 💅
Here's the definition. An LSR is capable of label merging if it can take two packets from different incoming interfaces, and/or with different labels, and send both out the same outgoing interface with the same label. Once they've gone out, nothing tells you they came from different places or had different labels. Poof, that info is gone 🌸
An LSR is not capable of label merging if, for any two packets that arrive from different interfaces or with different labels, the packets have to go out different interfaces or leave with different labels. ATM-LSRs using the SVC or SVP Encodings can't do label merging. We'll dig into that in the next section 🙈
So if an LSR can't merge, and two packets in the same FEC show up with different incoming labels, they must go out with different outgoing labels. With merging, the number of outgoing labels per FEC only needs to be 1 ✨ Without merging, it could be as many as the number of nodes in the network 😭
With merging, the number of incoming labels per FEC that an LSR needs is never larger than the number of label distribution adjacencies. Without merging, the LSR needs as many incoming labels as there are upstream nodes forwarding traffic in that FEC to it. Honestly, it's hard for the LSR to even figure out how many it needs for a given FEC 💀
The MPLS architecture handles both merging and non-merging LSRs, and it knows that some LSRs just won't support merging at all. That raises the question of how merging and non-merging LSRs interoperate correctly. The story is a bit different for datagram media than for ATM, so each gets its own discussion 🦋
3.26.1. Non-merging LSRs
Here's the vibe. MPLS forwarding works a lot like ATM and Frame Relay. A unit of data shows up, you look up its label (VPI/VCI or DLCI) in a "cross-connect table", that lookup picks an output port, and then the label value gets rewritten 🧚 Honestly, you can use those technologies for MPLS forwarding, with a label distribution protocol acting as the "signalling protocol" that sets up the cross-connect tables 🎀
The catch is that those technologies don't necessarily support label merging. In ATM, trying to merge can cause cells from different packets to get interleaved. And once cells are interleaved, you can't reassemble the packets anymore 😱 Some Frame Relay switches switch cells across their backplanes, and they might be incapable of merging for the same reason: cells from different packets can get tangled, and then there's no way to put the packets back together 💔
So MPLS is going to tackle this two ways. First, it has procedures that allow the use of non-merging LSRs. Second, it supports procedures that let certain ATM switches act as merging LSRs ✨
Since MPLS supports both merging and non-merging LSRs, it also has procedures to make sure they play nicely together 🫶
3.26.2. Labels for Merging and Non-Merging LSRs
An upstream LSR that supports merging only needs one label per FEC 💖 An upstream neighbor that doesn't support merging needs multiple labels per FEC. The catch is that nobody can know in advance how many it'll need. That depends on how many LSRs sit upstream of it for that FEC 🙈
Here's how the MPLS architecture handles it. If an upstream neighbor doesn't support merging, it doesn't get any labels for a FEC unless it explicitly asks for one. It can ask multiple times, and it gets a new label each time it asks 🍓 When a downstream neighbor gets one of these requests from upstream, and the downstream neighbor doesn't support merging itself, it must in turn ask its own downstream neighbor for another label for that FEC 🔁
There's also a middle ground. Some nodes support merging but can only merge a limited number of incoming labels into one outgoing label. Say a node can merge four incoming labels into a single outgoing label because of a hardware limitation. If six incoming labels show up for one FEC, that node can merge them into two outgoing labels 👑
Whether label merging applies to explicitly routed LSPs is still for further study 🔮
3.26.3. Merge over ATM
3.26.3.1. Methods of Eliminating Cell Interleave
There are several ways to kill the cell interleaving problem in ATM, which lets ATM switches support stream merge 💅
- VP merge, using the SVP Multipoint Encoding
With VP merge, multiple virtual paths get merged into one virtual path. Packets from different sources stay distinguishable because they use different VCIs within the VP 🦋
- VC merge
With VC merge, switches have to buffer cells from one packet until the whole packet has arrived. You can tell when that happens by looking for the AAL5 end of frame indicator 🎀
VP merge has the advantage of being compatible with a higher percentage of existing ATM switch implementations. That makes it more likely to actually work in networks that already exist ✨ Unlike VC merge, VP merge doesn't add any delays at merge points, and it doesn't impose any buffer requirements either 🙌 The downside is that it requires coordinating the VCI space within each VP, and there are a number of ways to do that. Picking one or more of those methods is still for further study 🔮
This trade-off, compatibility with existing equipment versus protocol complexity and scalability, means it's desirable for MPLS to support both VP merge and VC merge 👑 To pull that off, each ATM switch participating in MPLS needs to know whether its immediate ATM neighbors do VP merge, VC merge, or no merge 🧚
3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge
It's easiest to understand how the forms of ATM merging interoperate by starting with VC merge and non-merge 💖
When VC merge and non-merge nodes are connected, forwarding is always based on a VC, which is the VPI and VCI concatenated together 🌸 For each node, if an upstream neighbor does VC merge, that neighbor only needs a single VPI/VCI for a given stream. This is just like needing a single label over frame media 🦋 If the upstream neighbor doesn't merge, it needs a single VPI/VCI per stream for itself, plus enough VPI/VCIs to pass along to its own upstream neighbors. How many it needs depends on letting upstream nodes request extra VPI/VCIs from their downstream neighbors, which is again just like the frame merge method 🔁
VP merge nodes can work in a similar way. Instead of asking its downstream neighbor for a single VPI/VCI or a bunch of them, a VP merge node can ask for a single VP (identified by a VPI) with several VCIs inside it 🧚 Now suppose a non-merge node sits downstream from two different VP merge nodes. That node might need one VPI/VCI for its own traffic, plus two VPs (one per upstream node), each with a specific set of VCIs requested from its upstream node 💅
So to support VP merge, VC merge, and non-merge all together, upstream nodes have to be able to request a mix of zero or more VC identifiers (each a VPI/VCI), plus zero or more VPs (identified by VPIs), each containing a set number of VCs (identified by a set of VCIs, which only matter inside a VP) 🎀 A VP merge node requests one VP. That VP holds a VCI for its own traffic (if that applies) plus a VCI for each VC requested from above, whether or not that VC is part of a containing VP ✨ A VC merge node only requests a single VPI/VCI, since it can merge all upstream traffic into one VC 💜 Non-merge nodes pass along whatever requests they get from above, and also request a VPI/VCI for their own traffic (if that applies) 🫧
3.27. Tunnels and Hierarchy 🌈
Sometimes a router Ru deliberately makes sure a particular packet gets delivered to another router Rd. The catch is that Ru and Rd aren't consecutive routers on the hop-by-hop path for that packet, and Rd isn't the packet's ultimate destination either 🧚 One way to do this is to encapsulate the packet inside a network layer packet whose destination address is Rd's own address. That creates a "tunnel" from Ru to Rd 🦋 We call any packet handled this way a "Tunneled Packet" 💖
3.27.1. Hop-by-Hop Routed Tunnel
If a Tunneled Packet follows the hop-by-hop path from Ru to Rd, it's in a "Hop-by-Hop Routed Tunnel". Its "transmit endpoint" is Ru and its "receive endpoint" is Rd 🌸
3.27.2. Explicitly Routed Tunnel
If a Tunneled Packet travels from Ru to Rd over a path that isn't the hop-by-hop path, it's in an "Explicitly Routed Tunnel". Again, its "transmit endpoint" is Ru and its "receive endpoint" is Rd ✨ For example, you could send a packet through an Explicitly Routed Tunnel by wrapping it in a packet that's source routed 🎀
3.27.3. LSP Tunnels 🎀
okay so, it's possible to build a tunnel as an LSP 🦋 instead of wrapping packets in network layer encapsulation, and you just use label switching to push the packet through the tunnel. The tunnel is an LSP <R1, ..., Rn>, where R1 is the transmit endpoint of the tunnel and Rn is the receive endpoint. This is called an "LSP Tunnel" 💖
The set of packets that get sent through the LSP tunnel is a FEC ✨, and every LSR in the tunnel has to assign a label to that FEC (so basically, it has to assign a label to the tunnel). Deciding which packet goes into an LSP tunnel is a local matter at the tunnel's transmit endpoint 🧚. To put a packet in, the transmit endpoint pushes the tunnel's label onto the label stack and sends the labeled packet to the next hop in the tunnel. Main character energy 👑
If the tunnel's receive endpoint doesn't need to figure out which packets it got through the tunnel (we talked about this earlier 🙈), the label stack can be popped at the penultimate LSR in the tunnel. 🍓
A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that's implemented as a hop-by-hop routed LSP between the transmit endpoint and the receive endpoint 🌸
An "Explicitly Routed LSP Tunnel" is an LSP Tunnel that's also an Explicitly Routed LSP. It's giving precision 💅
3.27.4. Hierarchy: LSP Tunnels within LSPs 🌈
Okay picture this 🫶 an LSP <R1, R2, R3, R4>. R1 gets an unlabeled packet P, pushes on the label stack the label that makes it follow this path, and this is actually the hop-by-hop path. BUT (plot twist 😭) R2 and R3 aren't directly connected. They're "neighbors" only because they're the endpoints of an LSP tunnel. So the real sequence of LSRs P goes through is <R1, R2, R21, R22, R23, R3, R4>. 🦋
When P travels from R1 to R2, its label stack has depth 1. R2 switches on the label and figures out that P has to enter the tunnel. First, R2 swaps the incoming label for one that means something to R3. Then it pushes a new label on top. This level 2 label is meaningful to R21. R21, R22, and R23 all switch on the level 2 label. R23 is the penultimate hop in the R2-R3 tunnel, so it pops the label stack before forwarding P to R3. When R3 sees P, P only has a level 1 label, because it has exited the tunnel now. R3 is the penultimate hop in P's level 1 LSP, so it pops the label stack, and R4 gets P with no label at all. Iconic ✨
The label stack mechanism lets LSP tunneling nest to any depth. Literally endless 💜
3.27.5. Label Distribution Peering and Hierarchy 💅
Say packet P travels along a Level 1 LSP <R1, R2, R3, R4>, and when it goes from R2 to R3, it travels along a Level 2 LSP <R2, R21, R22, R3>. From the Level 2 LSP's point of view, R2's label distribution peer is R21. From the Level 1 LSP's point of view, R2's label distribution peers are R1 and R3. You can have label distribution peers at every layer of the hierarchy 🌸 We'll see some ways to use this hierarchy in sections 4.6 and 4.7. Also, in this example, R2 and R21 have to be IGP neighbors, but R2 and R3 don't need to be 🧚
When two LSRs are IGP neighbors, we call them "local label distribution peers". When two LSRs might be label distribution peers but aren't IGP neighbors, we call them "remote label distribution peers". In the example above, R2 and R21 are local label distribution peers, and R2 and R3 are remote label distribution peers 🎀
The MPLS architecture supports two ways to distribute labels at the different layers of the hierarchy: Explicit Peering and Implicit Peering 🦋
With its local label distribution peer, you distribute labels by sending label distribution protocol messages addressed to that peer. With remote label distribution peers, you can do it in one of two ways:
- Explicit Peering
In explicit peering, you distribute labels to a peer by sending label distribution protocol messages addressed to that peer, exactly like you would for local label distribution peers. This works best when there aren't many remote label distribution peers, when there are lots of higher level label bindings, or when the remote label distribution peers are in different routing areas or domains 💖 Of course, you need to know which labels to send to which peers. That's covered in section 4.1.2 ✨
You can see examples of explicit peering in sections 4.2.1 and 4.6 🫶
- Implicit Peering
In implicit peering, you DON'T send label distribution protocol messages addressed to your peer 🙈 Instead, to get higher level labels to your remote label distribution peers, you encode a higher level label as an attribute of a lower level label. Then you distribute that lower level label, attribute and all, to your local label distribution peers. Those local peers pass the info on to their own local label distribution peers, and this keeps going until the info reaches the remote peer 🌈
This works best when there are lots of remote label distribution peers. Implicit peering doesn't need an n-square peering mesh to get labels to the remote peers, because the info gets piggybacked through the local peering. The catch is that intermediate nodes have to store info they might not even be interested in 😭
You can see an example of implicit peering in section 4.3 💜
3.28. Label Distribution Protocol Transport 🌸
A label distribution protocol is used between nodes in an MPLS network to set up and keep up the label bindings 🧚 For MPLS to work correctly, label distribution info has to be sent reliably, and the label distribution protocol messages for a particular FEC have to be sent in sequence. Flow control is also nice to have, and so is being able to carry multiple label messages in one datagram 💅
One way to get all of that is to use TCP as the underlying transport, which is what [MPLS-LDP] and [MPLS-BGP] do 🎀
3.29. Why More than one Label Distribution Protocol? 🦋
This architecture doesn't set any hard and fast rules for picking which label distribution protocol to use in which situations. Still, there are some things worth considering 💖
3.29.1. BGP and LDP ✨
In lots of scenarios, it's desirable to bind labels to FECs that can be identified with routes to address prefixes (see section 4.1) 🫶 If there's a standard, widely deployed routing algorithm that distributes those routes, you could argue that label distribution is best done by piggybacking it on the distribution of the routes themselves 👑
For example, BGP distributes routes like this. If a BGP speaker also needs to distribute labels to its BGP peers, using BGP to do the label distribution (see [MPLS-BGP]) has a bunch of advantages. Specifically, it lets BGP route reflectors distribute labels too, which is a huge scalability win over using LDP to distribute labels between BGP peers 🌈
3.29.2. Labels for RSVP Flowspecs 🧚
When RSVP is used to set up resource reservations for particular flows, it can be desirable to label the packets in those flows, so the RSVP filterspec doesn't have to be applied at each hop 🍓 You could argue that having RSVP distribute the labels as part of its path/reservation setup process is the most efficient way to distribute labels for this 💜
3.29.3. Labels for Explicitly Routed LSPs 🌸
In some MPLS applications, especially ones related to traffic engineering, it's desirable to set up an explicitly routed path from ingress to egress 🦋 It's also desirable to apply resource reservations along that path ✨
There are two ways you could imagine doing this:
- Start with an existing protocol that's used for setting up resource reservations, and extend it to support explicit routing and label distribution.
- Start with an existing protocol that's used for label distribution, and extend it to support explicit routing and resource reservations.
The first approach gave us the protocol specified in [MPLS-RSVP-TUNNELS], and the second gave us the approach specified in [MPLS-CR-LDP] 🫶
3.30. Multicast 🙈
This section is for further study 🔮
4. Some Applications of MPLS 💖
4.1. MPLS and Hop by Hop Routed Traffic 🌈
A bunch of MPLS uses need packets with a certain label to be forwarded along the same hop-by-hop routed path that would be used to forward a packet with a specified address in its network layer destination address field 🧚
4.1.1. Labels for Address Prefixes 🎀
Generally, router R figures out the next hop for packet P by finding the address prefix X in its routing table that's the longest match for P's destination address. So the packets in a given FEC are just the packets that match a given address prefix in R's routing table. In this case, a FEC can be identified with an address prefix 🦋
Heads up 🙈 a packet P can be assigned to FEC F, and FEC F can be identified with address prefix X, even if P's destination address doesn't match X 💅
4.1.2. Distributing Labels for Address Prefixes 🍓
4.1.2.1. Label Distribution Peers for an Address Prefix 🌸
LSRs R1 and R2 count as label distribution peers for address prefix X if and only if one of the following conditions holds:
- R1's route to X is a route it learned about via a particular instance of a particular IGP, and R2 is a neighbor of R1 in that instance of that IGP
- R1's route to X is a route it learned about via some instance of routing algorithm A1, and that route gets redistributed into an instance of routing algorithm A2, and R2 is a neighbor of R1 in that instance of A2
- R1 is the receive endpoint of an LSP Tunnel that's within another LSP, and R2 is a transmit endpoint of that tunnel, and R1 and R2 are participants in a common instance of an IGP and are in the same IGP area (if the IGP has areas), and R1's route to X was learned via that IGP instance or is redistributed by R1 into that IGP instance
- R1's route to X is a route it learned about via BGP, and R2 is a BGP peer of R1
Overall, these rules mean that if the route to a particular address prefix is distributed via an IGP, the label distribution peers for that prefix are the IGP neighbors 🧚 If the route is distributed via BGP, the label distribution peers for that prefix are the BGP peers 💜 In other LSP tunneling cases, the tunnel endpoints are label distribution peers ✨
4.1.2.2. Distributing Labels 💖
Okay bestie, so if you want MPLS to forward packets along the hop-by-hop route for any address prefix, every LSR MUST do two things:
- bind one or more labels to each address prefix that shows up in its routing table;
- for each such address prefix X, use a label distribution protocol to send the binding of a label to X to each of its label distribution peers for X.
There's also one situation where an LSR has to pass along a label binding for an address prefix even though it's not the one that made the binding. Plot twist! 🙈
- If R1 uses BGP to distribute a route to X, naming some other LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has assigned label L to X, then R1 must distribute the binding between L and X to any BGP peer to which it distributes that route.
These rules make sure labels for prefixes that correspond to BGP routes go out to IGP neighbors if and only if those BGP routes get distributed into the IGP. Otherwise, those labels only go to the other BGP speakers. It's giving tidy routing drama 💜
These rules just tell you which label bindings a given LSR has to send, and to which other LSRs. Nothing more, nothing less. ✨
4.1.3. Using the Hop by Hop path as the LSP 🧚
If the hop-by-hop path that packet P needs to take is <R1, ..., Rn>, then <R1, ..., Rn> can count as an LSP as long as:
- there is a single address prefix X, such that, for all i,
1<=i<n, X is the longest match in Ri's routing table for P's destination address; - for all i,
1<i<n, Ri has assigned a label to X and distributed that label toR[i-1].
Quick note, babe: a packet's LSP can only extend until it hits a router whose forwarding table has a longer best-match prefix for that packet's destination. At that point the LSP has to end and the best match algorithm has to run again. 🛑
Here's an example to make it click. Say packet P, with destination address 10.2.153.178, needs to go from R1 to R2 to R3. R2 advertises the prefix 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. So R2 is basically sending R1 an "aggregated route" 🎀 Packet P can be label Switched all the way to R2, but since R2 did the route aggregation, it has to run the best match algorithm to figure out P's FEC. Aggregation is the plot twist again 🙈
4.1.4. LSP Egress and LSP Proxy Egress 🦋
An LSR R is an "LSP Egress" LSR for address prefix X if and only if one of these conditions holds:
- R has an address Y, such that X is the address prefix in R's routing table that is the longest match for Y, or
- R has one or more address prefixes Y in its routing tables where X is a proper initial substring of Y, but R's "LSP previous hops" for X don't contain any such address prefixes Y. In other words, R is a "deaggregation point" for address prefix X. 💅
An LSR R1 is an "LSP Proxy Egress" LSR for address prefix X if and only if:
- R1's next hop for X is R2, and R1 and R2 are not label distribution peers with respect to X (maybe because R2 doesn't support MPLS), or
- R1 has been configured to act as an LSP Proxy Egress for X.
The LSP definition is flexible enough that the LSP Egress can be a node that doesn't support MPLS. In that case, the penultimate node on the LSP is the Proxy Egress. Iconic behaviour, honestly 👑
4.1.5. The Implicit NULL Label 🌸
Implicit NULL is a label with special semantics that an LSR can bind to an address prefix. If LSR Ru checks its ILM and sees that a labeled packet P has to go next to Rd, but Rd has distributed an Implicit NULL binding for the matching address prefix, then Ru doesn't swap the label on top of the stack. Instead it pops the label stack and forwards the resulting packet to Rd. Pop it, don't swap it 💖
LSR Rd distributes a binding between Implicit NULL and an address prefix X to LSR Ru if and only if:
- the rules of Section 4.1.2 say that Rd distributes a label binding for X to Ru, and
- Rd knows that Ru can support the Implicit NULL label (i.e., that it can pop the label stack), and
- Rd is an LSP Egress (not a proxy egress) for X.
This makes the penultimate LSR on an LSP pop the label stack, and that's honestly so smart 🧠 If the LSP Egress is an MPLS Egress for X and the penultimate LSR didn't pop the stack, the LSP Egress would have to look up the label, pop it, and then look up the next label (or the L3 address, if there are no more labels). By having the penultimate LSR pop the stack, the LSP Egress gets to skip looking up two labels to make its forwarding decision. Efficiency era ✨
Just a heads up, though: if the penultimate LSR is an ATM switch, it might not be able to pop the label stack. So an Implicit NULL binding may only be distributed to LSRs that can support that function. 🙈
If the penultimate LSR on an LSP for address prefix X is an LSP Proxy Egress, it acts exactly as if the LSP Egress had distributed an Implicit NULL binding for X. 🫶
4.1.6. Option: Egress-Targeted Label Assignment 🌈
Sometimes an LSP Ingress, Ri, knows that packets from several different FECs all have to take the same LSP, ending at, say, LSP Egress Re. In that case, routing still works if you use one single label for all those FECs. You don't need a separate label for each FEC. This only works if and only if both of these hold:
- the address of LSR Re is itself in the routing table as a "host route", and
- there's some way for Ri to figure out that Re is the LSP egress for all packets in a particular set of FECs.
If both are true, Ri may bind a single label to all FECS in the set. This is known as "Egress-Targeted Label Assignment." 👑
So how does LSR Ri work out that an LSR Re is the LSP Egress for all packets in a particular FEC? There are a few ways to do it:
- If the network runs a link state routing algorithm and every node in the area supports MPLS, then the routing algorithm gives Ri enough info to know which routers the packets in that FEC have to leave the routing domain or area through.
- If the network runs BGP, Ri might be able to tell that packets in a particular FEC have to leave the network through a specific router, which is the "BGP Next Hop" for that FEC.
- You can use the label distribution protocol to pass along info about which address prefixes are "attached" to which egress LSRs. This one is nice because it doesn't depend on link state routing being around. 🦋
If you use egress-targeted label assignment, the number of labels you need across the network can go way down. That matters a lot if you're doing MPLS on legacy switching hardware that can only handle a limited number of labels. Less label drama, more slay 💅
One option is to set the network up to use egress-targeted label assignment by default, but configure particular LSRs to NOT use it for one or more of the address prefixes they're an LSP egress for. Here's the rule that goes with that:
- If a particular LSR is NOT an LSP Egress for some set of address prefixes, then it should assign labels to those address prefixes the same way its LSP next hop does for them. So say Rd is Ru's LSP next hop for address prefixes X1 and X2. If Rd assigns the same label to X1 and X2, Ru should too. If Rd assigns different labels to X1 and X2, then Ru should as well.
Here's an example. Say you want egress-targeted label assignment as the default, but you want distinct labels for the prefixes that have multiple possible LSP egresses (the multi-homed ones). You can set all LSRs to use egress-targeted label assignment, then configure a handful of LSRs to assign distinct labels to those multi-homed prefixes. For a particular multi-homed prefix X, you'd only need to configure this on the LSRs that are either LSP Egresses or LSP Proxy Egresses for X. 🎀
Also, if Ru and Rd are adjacent LSRs on an LSP for X1 and X2, forwarding still works correctly if Ru assigns distinct labels to X1 and X2 while Rd assigns just one label to both. This just means R1 maps different incoming labels to the same outgoing label, which is totally normal. 🙌
And if Rd assigns distinct labels to X1 and X2, but Ru assigns both of them the label for the address of their LSP Egress or Proxy Egress, forwarding still works. Ru just maps the incoming label to the label Rd assigned to the address of that LSP Egress. Everyone's happy 🌈
4.2. MPLS and Explicitly Routed LSPs 🍓
There are plenty of reasons you might want explicit routing instead of hop-by-hop routing. For example, it lets routes be based on administrative policies, and it lets the routes LSPs take be carefully designed for traffic engineering [MPLS-TRFENG]. Main character energy for your traffic 💜
4.2.1. Explicitly Routed LSP Tunnels ✨
Sometimes network admins want certain classes of traffic to go along specific pre-set paths that are different from the hop-by-hop path the traffic would normally take. This can support policy routing or traffic engineering. The explicit route can be a configured one, or it can be worked out dynamically by some means, e.g., by constraint-based routing. 🦋
MPLS makes this easy with Explicitly Routed LSP Tunnels. All you need is:
- A means of selecting the packets that are to be sent into the Explicitly Routed LSP Tunnel;
- A means of setting up the Explicitly Routed LSP Tunnel;
- A means of ensuring that packets sent into the Tunnel will not loop from the receive endpoint back to the transmit endpoint.
If the transmit endpoint of the tunnel wants to put a labeled packet into the tunnel, it first has to replace the label value at the top of the stack with a label value that the tunnel's receive endpoint distributed to it. Then it pushes on the label that corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. For this to work, the tunnel endpoints should be explicit label distribution peers. The label bindings they swap around aren't any of the LSRs' business along the tunnel. Private group chat energy 🫶🔥
4.3. Label Stacks and Implicit Peering 🧚
okay so picture this 💅 an LSR called Re is an LSP proxy egress for 10 address prefixes, and it reaches each one through a totally different interface.
option one: slap a single label on all 10 address prefixes. then Re is an LSP egress for all 10, which means packets for every one of them definitely get delivered to Re 🎀. BUT Re would then have to look up the network layer address of every single packet just to figure out which interface to send it out of. that's a lot of extra work 😭
option two: give each interface its own label. then Re is an LSP proxy egress for the 10 address prefixes ✨, and Re doesn't need to look up network layer addresses to forward anything. iconic. the catch? it can end up using a lot of labels 💀
option three is the slay one 👑: bind all 10 address prefixes to the same level 1 label (the one that's also bound to the LSR's own address), and then bind each address prefix to its own distinct level 2 label. the level 2 label gets treated as an attribute of the level 1 label binding, and we call that the "Stack Attribute" 🦋. we impose the following rules:
- When LSR Ru initially labels a hitherto unlabeled packet, if the longest match for the packet's destination address is X, and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru a binding of label L1 to X, along with a stack attribute of L2, then
- Ru must push L2 and then L1 onto the packet's label stack, and then forward the packet to Rd;
- When Ru distributes label bindings for X to its label distribution peers, it must include L2 as the stack attribute.
- Whenever the stack attribute changes (possibly as a result of a change in Ru's LSP next hop for X), Ru must distribute the new stack attribute.
ngl the key detail here is that the label value bound to X can be different at each hop along the LSP 🌸, but the stack attribute value gets passed along unchanged, and it's set by the LSP proxy egress.
so the LSP proxy egress for X becomes an "implicit peer" with each other LSR in the routing area or domain 🫶. explicit peering would be way too unwieldy here, because the number of peers would get way too large 🙈.
4.4. MPLS and Multi-Path Routing 🍓
if an LSR supports multiple routes for a particular stream, then it may assign multiple labels to the stream, one for each route 💜. so if a second label binding shows up from a particular neighbor for a particular address prefix, that should be read as meaning either label can be used to represent that address prefix ✨.
if multiple label bindings for a particular address prefix are specified, they may have distinct attributes 🌈.
4.5. LSP Trees as Multipoint-to-Point Entities 🌳
let's look at packets P1 and P2. each one has a destination address whose longest match, throughout a particular routing domain, is address prefix X 👀. say the Hop-by-hop path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4, R2, R3>. R3 binds label L3 to X and distributes that binding to R2. then R2 binds label L2 to X and distributes that binding to both R1 and R4.
when R2 receives P1, its incoming label is L2. R2 overwrites L2 with L3 and sends P1 to R3. when R2 receives P2, its incoming label is also L2. R2 again overwrites L2 with L3 and sends P2 on to R3 💅.
so when P1 and P2 are traveling from R2 to R3, they carry the same label, and as far as MPLS is concerned, they cannot be distinguished 🥹. which means instead of talking about two distinct LSPs, <R1, R2, R3> and <R4, R2, R3>, we can talk about a single "Multipoint-to-Point LSP Tree", which we can denote as <{R1, R4}, R2, R3> 🌲.
this gets tricky when we try to use conventional ATM switches as LSRs 😬. conventional ATM switches don't support multipoint-to-point connections, so there have to be procedures to make sure each LSP is realized as a point-to-point VC. BUT if ATM switches that do support multipoint-to-point VCs are in use, then the LSPs can be most efficiently realized as multipoint-to-point VCs 🔥. and if the SVP Multipoint Encoding (section 3.25.2) can be used, the LSPs can be realized as multipoint-to-point SVPs 🦄.
4.6. LSP Tunneling between BGP Border Routers 🚇
picture an Autonomous System, A, that carries transit traffic between other Autonomous Systems 🌍. A has a number of BGP Border Routers, plus a mesh of BGP connections among them, and BGP routes get distributed over that mesh. in lots of cases, it's desirable to avoid distributing BGP routes to routers that aren't BGP Border Routers 🙌. if that can be avoided, the "route distribution load" on those routers is significantly reduced. but there has to be some way of making sure the transit traffic still gets delivered from Border Router to Border Router by the interior routers 🫠.
LSP Tunnels can do this easily 💖. say BGP routes are distributed only to BGP Border Routers, and NOT to the interior routers along the Hop-by-hop path from Border Router to Border Router. then LSP Tunnels can be used like this:
- Each BGP Border Router distributes, to every other BGP Border Router in the same Autonomous System, a label for each address prefix that it distributes to that router via BGP.
- The IGP for the Autonomous System maintains a host route for each BGP Border Router. Each interior router distributes its labels for these host routes to each of its IGP neighbors.
- Suppose that:
- a) BGP Border Router B1 receives an unlabeled packet P,
- b) address prefix X in B1's routing table is the longest match for the destination address of P,
- c) the route to X is a BGP route,
- d) the BGP Next Hop for X is B2,
- e) B2 has bound label L1 to X, and has distributed this binding to B1,
- f) the IGP next hop for the address of B2 is I1,
- g) the address of B2 is in B1's and I1's IGP routing tables as a host route, and
- h) I1 has bound label L2 to the address of B2, and distributed this binding to B1.
Then before sending packet P to I1, B1 must create a label stack for P, then push on label L1, and then push on label L2.
- Suppose that BGP Border Router B1 receives a labeled Packet P, where the label on the top of the label stack corresponds to an address prefix, X, to which the route is a BGP route, and that conditions 3b, 3c, 3d, and 3e all hold. Then before sending packet P to I1, B1 must replace the label at the top of the label stack with L1, and then push on label L2.
with these procedures in place, a given packet P follows a level 1 LSP whose members are all BGP Border Routers 🗺️. and between each pair of BGP Border Routers in that level 1 LSP, it follows a level 2 LSP ✨.
these procedures effectively create a Hop-by-Hop Routed LSP Tunnel between the BGP Border Routers 🎀.
since the BGP border routers are exchanging label bindings for address prefixes that the IGP routing doesn't even know about, the BGP routers should become explicit label distribution peers with each other 🤝.
sometimes it's also possible to create Hop-by-Hop Routed LSP Tunnels between two BGP Border Routers even if they're NOT in the same Autonomous System 😳. say, for example, that B1 and B2 are in AS 1, B3 is an EBGP neighbor of B2 and is in AS2, and B2 and B3 are on some network that's common to both Autonomous Systems (a "Demilitarized Zone") 🧸. then an LSP tunnel can be set up directly between B1 and B3 like this:
- B3 distributes routes to B2 (using EBGP), optionally assigning labels to address prefixes;
- B2 redistributes those routes to B1 (using IBGP), indicating that the BGP next hop for each such route is B3. If B3 has assigned labels to address prefixes, B2 passes these labels along, unchanged, to B1.
- The IGP of AS1 has a host route for B3.
4.7. Other Uses of Hop-by-Hop Routed LSP Tunnels 🪄
Hop-by-Hop Routed LSP Tunnels aren't restricted to tunnels between BGP Next Hops 🙅♀️. any situation where you'd otherwise have used an encapsulation tunnel is one where it's appropriate to use a Hop-by-Hop Routed LSP Tunnel 💅. instead of encapsulating the packet with a new header whose destination address is the address of the tunnel's receive endpoint, the label corresponding to the address prefix that's the longest match for the address of the tunnel's receive endpoint gets pushed on the packet's label stack ✨. the packet sent into the tunnel may or may not already be labeled.
if the transmit endpoint of the tunnel wants to put a labeled packet into the tunnel, it must first replace the label value at the top of the stack with a label value that was distributed to it by the tunnel's receive endpoint 🔄. then it must push on the label that corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel 🫶. to allow this, the tunnel endpoints should be explicit label distribution peers 🤍. the label bindings they need to exchange are of no interest to the LSRs along the tunnel 🙈.
4.8. MPLS and Multicast 📡
multicast routing works by constructing multicast trees 🌳. the tree a particular multicast packet gets forwarded along depends, in general, on the packet's source address and its destination address 🧭. whenever a particular LSR is a node in a particular multicast tree, it binds a label to that tree, and then distributes that binding to its parent on the multicast tree 💌. (if the node in question is on a LAN and has siblings on that LAN, it must also distribute the binding to its siblings. this lets the parent use a single label value when multicasting to all children on the LAN 🧃.)
when a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label 🎯. if the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children 🥳.
5. Label Distribution Procedures (Hop-by-Hop) 🌈
in this section, we only look at label bindings that are used for traffic that's going to be label switched along its hop-by-hop routed path 🛤️. in these cases, the label in question corresponds to an address prefix in the routing table 📖.
5.1. The Procedures for Advertising and Using labels 💖
there are a bunch of different procedures that can be used to distribute label bindings 🧁. some are executed by the downstream LSR, and some by the upstream LSR 👯.
the downstream LSR must perform:
- The Distribution Procedure, and
- the Withdrawal Procedure.
the upstream LSR must perform:
- The Request Procedure, and
- the NotAvailable Procedure, and
- the Release Procedure, and
- the labelUse Procedure.
the MPLS architecture supports several variants of each procedure ✨. however, it does NOT support all possible combinations of all possible variants 😅. the set of supported combinations gets described in section 5.2, where interoperability between different combinations gets discussed too 🦋.
5.1.1. Downstream LSR: Distribution Procedure ✨
okay bestie, so the Distribution Procedure is how a downstream LSR figures out when it should send out a label binding for an address prefix to its label distribution peers 💅 and the architecture gives you four different ones to pick from 🦋
no matter which procedure you use, if a downstream LSR Rd has already sent a label binding for a prefix to an upstream LSR Ru, and then at any point the attributes (the ones defined above) of that binding change, Rd MUST inform Ru of the new attributes. no skipping this one, it's giving main character energy 😭
and if an LSR is juggling multiple routes to the same address prefix, it's a local matter whether it binds multiple labels to that prefix (one per route), which means it distributes multiple bindings. your call, queen 👑
5.1.1.1. PushUnconditional 🌸
Okay, picture Rd as an LSR, and suppose that:
- X is an address prefix in Rd's routing table
- Ru is a label distribution peer of Rd with respect to X
Whenever these conditions hold, Rd MUST bind a label to X and distribute that binding to Ru. Rd is responsible for keeping track of the bindings it has sent to Ru and making sure Ru always has them 💖
This procedure is for LSRs doing unsolicited downstream label assignment in the Independent LSP Control Mode 🧚
5.1.1.2. PushConditional 🎀
Picture Rd as an LSR again, and suppose that:
- X is an address prefix in Rd's routing table
- Ru is a label distribution peer of Rd with respect to X
- Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rn has bound a label to X and distributed that binding to Rd.
Then, as soon as these conditions all hold, Rd SHOULD bind a label to X and distribute that binding to Ru.
PushUnconditional hands out bindings for every prefix in the routing table, but PushConditional is pickier 🙈 It only distributes bindings for prefixes where it has received a binding from its LSP next hop, or for prefixes where it doesn't have an MPLS-capable L3 next hop.
This procedure is for LSRs doing unsolicited downstream label assignment in the Ordered LSP Control Mode.
5.1.1.3. PulledUnconditional 💜
Okay, picture Rd as an LSR, and suppose that:
- X is an address prefix in Rd's routing table
- Ru is a label distribution peer of Rd with respect to X
- Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru
Then Rd SHOULD bind a label to X and distribute that binding to Ru. Heads up though: if X isn't in Rd's routing table, or if Rd isn't a label distribution peer of Ru with respect to X, then Rd MUST inform Ru that it can't provide a binding right now 🙅♀️
If Rd has already distributed a binding for prefix X to Ru, and then gets a new request from Ru for a binding for X, it'll bind a second label and distribute the new binding to Ru. The first label binding stays in effect 🌈
This procedure is for LSRs doing downstream-on-demand label distribution using the Independent LSP Control Mode.
5.1.1.4. PulledConditional 🍓
Okay, picture Rd as an LSR, and suppose that:
- X is an address prefix in Rd's routing table
- Ru is a label distribution peer of Rd with respect to X
- Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru
- Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rn has bound a label to X and distributed that binding to Rd
Then, as soon as these conditions all hold, Rd SHOULD bind a label to X and distribute that binding to Ru. Note that if X isn't in Rd's routing table and a binding for X can't be obtained via Rd's next hop for X, or if Rd isn't a label distribution peer of Ru with respect to X, then Rd MUST inform Ru that it can't provide a binding at this time.
However, if the only condition that fails is that Rn hasn't given Rd a label yet, then Rd MUST defer any response to Ru until it has received a binding from Rn ⏳
If Rd has distributed a label binding for address prefix X to Ru, and at some later time any attribute of that binding changes, Rd MUST redistribute the label binding to Ru with the new attribute. It MUST do this even though Ru never sends a new Request 😤
This procedure is for LSRs doing downstream-on-demand label allocation in the Ordered LSP Control Mode.
Peek ahead 🔮 In section 5.2, we will discuss how to choose the particular procedure to be used at any given time, and how to make sure LSRs that choose different procedures can still interoperate.
5.1.2. Upstream LSR: Request Procedure 🦋
The Request Procedure is how the upstream LSR for an address prefix decides when to explicitly ask the downstream LSR to bind a label to that prefix and distribute the binding. There are three possible procedures you can use.
5.1.2.1. RequestNever 🙃
Never make a request. This is useful if the downstream LSR uses the PushConditional procedure or the PushUnconditional procedure, but it's not useful if the downstream LSR uses the PulledUnconditional procedure or the PulledConditional procedure.
This procedure would be used by an LSR when unsolicited downstream label distribution and Liberal Label Retention Mode are being used.
5.1.2.2. RequestWhenNeeded 🥰
Make a request whenever the L3 next hop to the address prefix changes, or when a new address prefix is learned, and you don't already have a label binding from that next hop for the given address prefix.
This procedure would be used by an LSR whenever Conservative Label Retention Mode is being used.
5.1.2.3. RequestOnRequest 🔥
Issue a request whenever a request is received, in addition to issuing a request when needed (as described in section 5.1.2.2). If Ru is not capable of being an LSP ingress, it MAY issue a request only when it receives a request from upstream.
If Rd receives such a request from Ru, for an address prefix for which Rd has already distributed Ru a label, Rd SHALL assign a new (distinct) label, bind it to X, and distribute that binding. (Whether Rd can distribute this binding to Ru immediately or not depends on the Distribution Procedure being used.)
This procedure would be used by an LSR doing downstream-on-demand label distribution, but not doing label merging, e.g., an ATM-LSR that isn't capable of VC merge 🧠
5.1.3. Upstream LSR: NotAvailable Procedure 🌷
If Ru and Rd are respectively the upstream and downstream label distribution peers for address prefix X, and Rd is Ru's L3 next hop for X, and Ru requests a binding for X from Rd, but Rd replies that it can't provide a binding at this time because it has no next hop for X, then the NotAvailable procedure decides how Ru responds. There are two possible procedures governing Ru's behavior:
5.1.3.1. RequestRetry 🔁
Ru SHOULD issue the request again at a later time. That is, the requester is responsible for trying again later to get the needed binding. This procedure would be used when downstream-on-demand label distribution is used.
5.1.3.2. RequestNoRetry 🚫
Ru SHOULD never reissue the request, and instead assumes Rd will provide the binding automatically once it's available. This is useful if Rd uses the PushUnconditional procedure or the PushConditional procedure, i.e., if unsolicited downstream label distribution is used.
Note that if Rd replies that it can't provide a binding to Ru because of some error condition, rather than because Rd has no next hop, then Ru's behavior is governed by the error recovery conditions of the label distribution protocol, not by the NotAvailable procedure ⚠️
5.1.4. Upstream LSR: Release Procedure 🫧
Suppose that Rd is an LSR that has bound a label to address prefix X and has distributed that binding to LSR Ru. If Rd isn't Ru's L3 next hop for address prefix X, or has stopped being Ru's L3 next hop for address prefix X, then Ru won't be using the label. The Release Procedure decides how Ru acts in this case. There are two possible procedures governing Ru's behavior:
5.1.4.1. ReleaseOnChange 👋
Ru SHOULD release the binding and inform Rd that it has done so. This procedure would be used to implement Conservative Label Retention Mode.
5.1.4.2. NoReleaseOnChange 🫶
Ru SHOULD maintain the binding, so that it can use it again immediately if Rd later becomes Ru's L3 next hop for X. This procedure would be used to implement Liberal Label Retention Mode.
5.1.5. Upstream LSR: labelUse Procedure 🎀
Suppose Ru is an LSR that has received label binding L for address prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and in fact Rd is Ru's L3 next hop for X.
Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, at the time Ru receives the binding, Rd is NOT Ru's L3 next hop for X, Ru doesn't make any use of the binding at that time. Ru MAY however start using the binding at some later time, if Rd becomes Ru's L3 next hop for X.
The labelUse Procedure decides exactly how Ru makes use of Rd's binding. There are two procedures Ru MAY use:
5.1.5.1. UseImmediate ⚡
Ru MAY put the binding into use immediately. At any time when Ru has a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will also be Ru's LSP next hop for X. This procedure is used when loop detection is not in use.
5.1.5.2. UseIfLoopNotDetected 🔍
This procedure is the same as UseImmediate, unless Ru has detected a loop in the LSP. If a loop has been detected, Ru will stop using label L for forwarding packets to Rd.
This procedure is used when loop detection is in use.
This will continue until the next hop for X changes, or until the loop is no longer detected.
5.1.6. Downstream LSR: Withdraw Procedure 🦋
okay so this one is giving simple, bestie 💅 there's only ONE procedure here, so no decision tree, no drama.
When LSR Rd decides to break the binding between label L and address prefix X, then this unbinding must be distributed to all LSRs to which the binding was distributed. 🫶
It is required that the unbinding of L from X be distributed by Rd to a LSR Ru before Rd distributes to Ru any new binding of L to any other address prefix Y, where X != Y. Why does the order matter?? 😭 If Ru learned about the new binding of L to Y before it heard about the unbinding of L from X, and packets matching both X and Y were forwarded by Ru to Rd, then for a little while, Ru would label BOTH the packets matching X and the packets matching Y with label L. Chaos, literally. 💀
The distribution and withdrawal of label bindings is done via a label distribution protocol. All label distribution protocols require that a label distribution adjacency be established between two label distribution peers (except implicit peers). If LSR R1 has a label distribution adjacency to LSR R2, and has received label bindings from LSR R2 via that adjacency, then if the adjacency is brought down by either peer (whether as a result of failure or as a matter of normal operation), all bindings received over that adjacency must be considered to have been withdrawn. 🌸
As long as the relevant label distribution adjacency remains in place, label bindings that are withdrawn must always be withdrawn explicitly. ✨ If a second label is bound to an address prefix, the result is not to implicitly withdraw the first label, but to bind both labels. This is needed to support multi-path routing. 🧚 If a second address prefix is bound to a label, the result is not to implicitly withdraw the binding of that label to the first address prefix, but to use that label for both address prefixes. no cap, that's iconic. 👑
5.2. MPLS Schemes: Supported Combinations of Procedures 🎀
Consider two LSRs, Ru and Rd, which are label distribution peers with respect to some set of address prefixes, where Ru is the upstream peer and Rd is the downstream peer. 💖
The MPLS scheme which governs the interaction of Ru and Rd can be described as a quintuple of procedures: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. (Since there is only one Withdraw Procedure, it need not be mentioned.) A "*" appearing in one of the positions is a wild-card, meaning that any procedure in that category may be present. An "N/A" appearing in a particular position indicates that no procedure in that category is needed. it's giving organized, periodt 📋
Only the MPLS schemes which are specified below are supported by the MPLS Architecture. Other schemes may be added in the future, if a need for them is shown. 🔮
5.2.1. Schemes for LSRs that Support Label Merging 🌈
If Ru and Rd are label distribution peers, and both support label merging, one of the following schemes must be used:
<PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate>
This is unsolicited downstream label distribution with independent control, liberal label retention mode, and no loop detection. 🍓
<PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>
This is unsolicited downstream label distribution with independent control, liberal label retention, and loop detection. ✨
<PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange, *>
This is unsolicited downstream label distribution with ordered control (from the egress) and conservative label retention mode. Loop detection is optional. 🦋
<PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
This is unsolicited downstream label distribution with ordered control (from the egress) and liberal label retention mode. Loop detection is optional. 💅
<PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>
This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection. 🫶
<PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, without loop detection. 🌸
<PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection. 👑
5.2.2. Schemes for LSRs that do not Support Label Merging 🧚
Suppose that R1, R2, R3, and R4 are ATM switches which do not support label merging, but are being used as LSRs. Suppose further that the L3 hop-by-hop path for address prefix X is <R1, R2, R3, R4>, and that packets destined for X can enter the network at any of these LSRs. Since there is no multipoint-to-point capability, the LSPs must be realized as point-to-point VCs, which means that there needs to be three such VCs for address prefix X: <R1, R2, R3, R4>, <R2, R3, R4>, and <R3, R4>. 🌈
Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is implemented using conventional ATM switching hardware (i.e., no cell interleave suppression), or is otherwise incapable of performing label merging, the MPLS scheme in use between R1 and R2 must be one of the following:
<PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>
This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection.
The use of the RequestOnRequest procedure will cause R4 to distribute three labels for X to R3. R3 will distribute 2 labels for X to R2, and R2 will distribute one label for X to R1. 🍓
<PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, without loop detection. ✨
<PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection. 🦋
5.2.3. Interoperability Considerations 🔥
It is easy to see that certain quintuples do NOT yield viable MPLS schemes. For example:
<PulledUnconditional, RequestNever, *, *, *>and<PulledConditional, RequestNever, *, *, *>
In these MPLS schemes, the downstream LSR Rd distributes label bindings to upstream LSR Ru only upon request from Ru, but Ru never makes any such requests. Obviously, these schemes are not viable, since they will not result in the proper distribution of label bindings. 🙈
<*, RequestNever, *, *, ReleaseOnChange>
In these MPLS schemes, Rd releases bindings when it isn't using them, but it never asks for them again, even if it later has a need for them. These schemes thus do not ensure that label bindings get properly distributed. 💀
In this section, we specify rules to prevent a pair of label distribution peers from adopting procedures which lead to infeasible MPLS Schemes. These rules require either the exchange of information between label distribution peers during the initialization of the label distribution adjacency, or a priori knowledge of the information (obtained through a means outside the scope of this document). 🧠
- Each must state whether it supports label merging.
- If
Rddoes not support label merging,Rdmust choose either the PulledUnconditional procedure or the PulledConditional procedure. IfRdchooses PulledConditional,Ruis forced to use the RequestRetry procedure.
That is, if the downstream LSR does not support label merging, its preferences take priority when the MPLS scheme is chosen. 👑
- If
Rudoes not support label merging, butRddoes,Rumust choose either the RequestRetry or RequestNoRetry procedure. This forcesRdto use the PulledConditional or PulledUnConditional procedure respectively.
That is, if only one of the LSRs doesn't support label merging, its preferences take priority when the MPLS scheme is chosen. 💖
- If both
RuandRdboth support label merging, then the choice between liberal and conservative label retention mode belongs toRu. That is,Rugets to choose either to use RequestWhenNeeded/ReleaseOnChange (conservative), or to use RequestNever/NoReleaseOnChange (liberal). However, the choice of "push" vs. "pull" and "conditional" vs. "unconditional" belongs toRd. IfRuchooses liberal label retention mode,Rdcan choose either PushUnconditional or PushConditional. IfRuchooses conservative label retention mode,Rdcan choose PushConditional, PulledConditional, or PulledUnconditional.
These choices together determine the MPLS scheme in use. 🎀
6. Security Considerations 💀
Some routers may implement security procedures which depend on the network layer header being in a fixed place relative to the data link layer header. The MPLS generic encapsulation inserts a shim between the data link layer header and the network layer header. This may cause any such security procedures to fail. 😱
An MPLS label has its meaning by virtue of an agreement between the LSR that puts the label in the label stack (the "label writer"), and the LSR that interprets that label (the "label reader"). If labeled packets are accepted from untrusted sources, or if a particular incoming label is accepted from an LSR to which that label has not been distributed, then packets may be routed in an illegitimate manner. this part is SERIOUS bestie, guard those labels like your heart 🔐💜
7. Intellectual Property 📜
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
8. Authors' Addresses 🖋️
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
EMail: erosen@cisco.com
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd.
Milpitas, CA 95035-7438
EMail: arun@force10networks.com
Ross Callon
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
EMail: rcallon@juniper.net9. References ✨
Okay bestie, here's the reading list 📚 Every source this doc leans on is listed below, with all its details, so you can go find the originals yourself 🧚
- [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
- [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress.
- [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress.
- [MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
- [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
- [MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress.
- [MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
- [MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
10. Full Copyright Statement 🎀
Copyright (C) The Internet Society (2001). All Rights Reserved. 💖
So, the vibe here is basically "share it all you want, just don't mess with the original" 🫶 You're allowed to copy this document and pass it around, and you can make derivative works that comment on it, explain it, or help people implement it 🌸 You can publish and distribute those too, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work ✨
What you can't do is edit the document itself. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅♀️ The exceptions are if you need it to develop Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or if you're translating it into a language other than English 🌈
These permissions are perpetual, which means they will not be revoked by the Internet Society or its successors or assigns. Forever and ever 💜
Now the disclaimer, which is kind of a big deal 😭 This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. No promises, no guarantees, just vibes 💀
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to the Internet Society for keeping the lights on for the RFC Editor! 🫶✨
📦 where this page comes from
- ietf: rfc3031 2001-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms