RFC 3353
Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment
RFC 3353 💖 Overview of IP Multicast in MPLS
okay bestie, this one is Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment and it's giving "how do we make one-to-many traffic work on MPLS networks" energy ✨
It's an Informational RFC from the Network Working Group, dated August 2002 🎀 It's not a standard, just info for the Internet community. The authors are D. Ooms (Alcatel), B. Sales (Alcatel), W. Livens (Colt Telecom), A. Acharya (IBM), F. Griffoul (Ulticom), and F. Ansari (Bell Labs). The title block doesn't list any RFCs it obsoletes or updates, so it doesn't touch anything else 🦋
Status of this Memo ✨
this memo is here to give info to the Internet community 💅 it does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🌸
Copyright Notice 🌈
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract 💜
this doc gives a framework for IP multicast deployment in an MPLS environment 🧚 it overviews the issues that show up when MPLS techniques get applied to IP multicast, and it looks at the pros and cons of existing IP multicast routing protocols in the MPLS context. it also covers how those protocols relate to the different trigger methods and label distribution modes, lists the consequences of various layer 2 (L2) technologies, and considers both point-to-point and multi-access networks 🔥
Table of Contents 🍓
1. Introduction ............................................. 3
2. Layer 2 Characteristics .................................. 4
3. Taxonomy of IP Multicast Routing Protocols
in the Context of MPLS ................................... 5
3.1. Aggregation .............................................. 5
3.2. Flood & Prune ............................................ 5
3.3. Source/Shared Trees ...................................... 6
3.4. Co-existence of Source and Shared Trees .................. 7
3.5. Uni/Bi-directional Shared Trees .......................... 10
3.6. Encapsulated Multicast Data .............................. 11
3.7. Loop-free-ness ........................................... 11
3.8. Mapping of Characteristics on Existing Protocols ......... 11
4. Mixed L2/L3 Forwarding in a Single Node .................. 12
5. Taxonomy of IP Multicast LSP Triggers .................... 14
5.1. Request Driven ........................................... 14
5.1.1. General .................................................. 14
5.1.2. Multicast Routing Messages ............................... 15
5.1.3. Resource Reservation Messages ............................ 15
5.2. Topology Driven .......................................... 16
5.3. Traffic Driven ........................................... 16
5.3.1. General .................................................. 16
5.3.2. An Implementation Example ................................ 17
5.4. Combinations of Triggers and Label Distribution Modes .... 18
6. Piggy-backing ............................................ 18
7. Explicit Routing ......................................... 20
8. QoS/CoS .................................................. 20
8.1. DiffServ ................................................. 20
8.2. IntServ and RSVP ......................................... 21
9. Multi-access Networks .................................... 21
10. More Issues .............................................. 22
10.1. TTL Field ................................................ 22
10.2. Independent vs. Ordered Label Distribution Control ....... 23
10.3. Conservative vs. Liberal Label Retention Mode ............ 24
10.4. Downstream vs. Upstream Label Allocation ................. 25
10.5. Explicit vs. Implicit Label Distribution ................. 25
11. Security Considerations .................................. 26
12. Acknowledgements ......................................... 26
Informative References........................................... 27
Authors' Addresses .............................................. 28
Full Copyright Statement ........................................ 30Table of Abbreviations 📚
this is the glossary of acronyms we'll be using, so keep it handy 🫶
ATM Asynchronous Transfer Node
CBT Core Based Tree
CoS Class of Service
DLCI Data Link Connection Identifier
DRrecv Designated Router of the receiver
DRsend Designated Router of the sender
DVMRP Distant Vector Multicast Routing Protocol
FR Frame Relay
IGMP Internet Group Management Protocol
IP Internet Protocol
L2 layer 2 (e.g. ATM, Frame Relay)
L3 layer 3 (e.g. IP)
LSP Label Switched Path
LSR Label Switching Router
LSRd Downstream LSR
LSRu Upstream LSR
MOSPF Multicast OSPF
mp2mp multipoint-to-multipoint
MRT Multicast Routing Table
p2mp point-to-multipoint
PIM-DM Protocol Independent Multicast-Dense Mode
PIM-SM Protocol Independent Multicast-Sparse Mode
QoS Quality of Service
RP Rendezvous Point
RPT-bit RP Tree bit [DEER]
RSVP Resource reSerVation Protocol
SPT-bit Shortest Path Tree [DEER]
SSM Source Specific Multicast
TCP Transmission Control Protocol
UDP User Datagram Protocol
VC Virtual Circuit
VCI Virtual Circuit Identifier
VP Virtual Path
VPI Virtual Path Identifier1. Introduction 🌷
okay so in an MPLS cloud, the routes are set by an L3 routing protocol 💖 those routes can then get mapped onto L2 paths to boost network performance. on top of that, MPLS is a vehicle for enhanced network services like QoS/CoS, traffic engineering, and more ✨
current unicast routing protocols end up with one same (optimal) shortest path in steady state for any given (source, destination) pair 💅 fun fact, though: unicast protocols can behave slightly differently when it comes to equal cost paths 👀
multicast is where it gets spicy 🌶️ the optimal solution (minimum cost to interconnect N nodes) would need a Steiner tree computation. sadly, no multicast routing protocol today can maintain that optimal tree, so different multicast protocols will generally build different trees 😭
this discussion is focused on intra-domain multicast routing protocols. inter-domain routing is out of scope for this doc 🦋
2. Layer 2 Characteristics 🫧
MPLS is multiprotocol at both L3 and L2, but in practice IP is the only L3 protocol being considered 🎀 MPLS can run on top of several L2 technologies, like PPP/Sonet, Ethernet, ATM, FR, and others.
when label switching gets mapped onto L2 switching capabilities (like using VPI/VCI as the label), the main focus is on mapping to ATM [DAVI]. ATM has high switching capacities and QoS awareness, but in an MPLS context it has several limitations, which are described in [DAVI] 💜 Frame Relay gets similar considerations in [CONT]. the limitations boil down to:
- Limited Label Space 🍓 either the standardized or the implemented number of bits available for a label can be small (e.g. VPI/VCI space, DLCI space), which limits how many LSPs can be established.
- Merging 🙈 some L2 technologies, or implementations of them, don't support multipoint-to-point and/or multipoint-to-multipoint 'connections', which blocks LSPs from merging.
- TTL 💀 L2 technologies don't support a 'TTL-decrement' function.
all three limitations can affect how multicast gets implemented in MPLS, as we'll see in this doc 🔥
when native MPLS is deployed, those limitations vanish ✨ also, on PPP and Ethernet links, the same label can be used at the same time for a unicast and a multicast LSP, because different EtherTypes are defined for MPLS unicast and multicast [ROSE] 👑
3. Taxonomy of IP Multicast Routing Protocols in the Context of MPLS 🌈
at the moment there's an abundance of IP multicast routing protocols being proposed and developed 🤯 they all have different characteristics (scalability, computational complexity, latency, control message overhead, tree type, etc...). this doc isn't trying to give a complete taxonomy of IP multicast routing protocols, it only covers the characteristics that matter for MPLS 💅
the following characteristics are considered:
- Aggregation
- Flood & Prune
- Source/Shared trees
- Co-existence of Source and Shared Trees
- Uni/Bi-directional shared trees
- Encapsulated multicast data
- Loop-free-ness
these characteristics won't lead to picking one superior multicast routing protocol 🙅♀️ it's not impossible that different IP multicast routing protocols end up deployed on the Internet, and that's totally fine 🫶
3.1. Aggregation 🦋
in unicast, different destination addresses get aggregated into one routing table entry, which yields one FEC and one LSP ✨
the granularity of multicast streams is (*, G) for a shared tree and (S, G) for a source tree, where S is the source address and G is the multicast group address 💖 aggregating multicast trees with different multicast 'destination' addresses onto one LSP is a subject for further study, so that's still cooking 🧚
3.2. Flood & Prune 🌊
to build a multicast tree, some IP multicast routing protocols (e.g. DVMRP, PIM-DM) flood the network with multicast data 🌊 the branches can then get pruned by nodes that don't want the data for that specific multicast group. this process repeats periodically 🔁
flood & prune protocols have some characteristics that really differ from unicast routing protocols, so let's get into it:
- a) Volatile. 🌪️ because flood & prune is the nature of the protocol, super volatile tree structures get generated. solutions for mapping a dynamic L3 p2mp tree onto a L2 p2mp LSP need to be efficient in terms of signaling overhead and LSP setup time. the volatile L2 LSP eats up a lot of labels throughout the network, which is a real disadvantage when label space is limited 😩
- b) Traffic-driven. 🚦 the router only creates state for a certain group when data arrives for that group. routers also independently decide to remove state when an inactivity timer expires 🕰️
- so LSPs can't be pre-established the way they usually are in unicast 🙃 to minimize the time between traffic arrival and LSP establishment, a fast LSP setup method is favorable ⚡
- since creating and deleting an L3 route at each node is triggered by traffic, it suggests the LSP associated with that route should be set up and torn down in a traffic-driven manner too 💫
- if an LSR doesn't support L3 forwarding, this traffic-driven nature even requires that the upstream LSR takes the initiative to create an LSP (Upstream Unsolicited or Downstream on Demand label advertisement) 👑
(part 1 of 6, more coming next! 🎀)
3.3. Source/Shared Trees 🌊
Okay so IP multicast routing protocols build one of two kinds of tree. Either it's a source tree (S, G), which means one tree for each source (S) and each multicast group (G), or a shared tree (*, G), which is just one tree per group 🌸 Check out Figure 1 below.
R1 R1 R1
S1 / / /
\ / / /
\ / / /
C---R2 S1---R2 S2---R2
/ \ \ \
/ \ \ \
S2 \ \ \
R3 R3 R3
Figure 1. Shared tree and Source treesHere's the tea ☕ When label switching is in play, shared trees are the more efficient ones, because they eat fewer labels. A shared tree needs 1 label per group, while a source tree needs 1 label per source and per group. Iconic for shared trees 💅
BUT (there's always a but 😭) mapping a shared tree end-to-end on L2 means setting up multipoint-to-multipoint (mp2mp) LSPs. Making mp2mp LSPs work basically comes down to the merging problem we already talked about earlier, so it's a whole thing 🙈
Also, in real life, shared trees are mostly used just to find out about new sources of the group. Then everyone switches over to a source tree once the bitrate is super low 🦋
3.4. Co-existence of Source and Shared Trees 🎀
Some protocols support both source and shared trees (PIM-SM is one of them 💜), and a single router can keep both (*, G) and (S, G) state for the same group G. Two state co-existence cases are coming up. Here's the setup: senders are Si and receivers are Ri, RP is the Rendezvous Point, and Ni are LSRs. The numbers are interface numbers, and "Reg" is the Register interface. Every IGMP and PIM Join/Prune message is shown in the figures, and the figures also show whether the RPT-bit is set for the (S, G) state 🧚
- Figure 2 is a switchover from a shared tree to a source tree. Let's say the shortest path from R1 to RP goes through N1-N2-N5. N1 is the Designated Router of receiver R1 (DRrecv), and it decides to start a source tree for source S1. Once data from the source tree shows up at N2, N2 sends a prune to N5 for source S1. This state co-existence happens at the node where the shared and source trees overlap for the first time (N2), and also at the node where S1 doesn't need forwarding on the shared tree anymore (N5) ✨
PJ
IJ PJS PJS
-> 1 2 -> 1 2 -> 1 2
R1-----N1------N2------N3----S1
3| |3 IJ=Igmp Join
||PPS | PJ=Pim Join (*,G)
|vPJ | PJS=Pim Join (S1,G)
IJ PJ | PJ | PPS=Pim Prune (S1,G)
-> -> |3 -> |
R2-----N4------N5------RP----S2
1 2 1 2 1
Figure 2The multicast routing states in the Multicast Routing Table (MRT) end up looking like this:
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):2->1
in N2: (*,G):3->1
(S1,G):2->1
in N3: (S1,G):2->Reg,1
in N4: (*,G):2->1
in N5: (*,G):2->1,3
(S1,G)RPT-bit:2->1- Figure 3 shows that state co-existence can happen even without any switchover 👀 Traffic from a sender creates
(S, G)state in the sender's Designated Router (DRsend). In Figure 3, N3 is the DRsend for S. Every node on a shared tree already has(*, G)state, so an on-tree DRsend ends up with both(*, G)and(S, G)state. If the DRsend is on the tree, it also sends a prune for S toward the RP. That creates(S, G)state in every node until it reaches the first router with a branch (N1 and N2 in Figure 3) 💖
S
PPS PPS |
PJ PJ PJ |2 PJ IJ
1 <- 1 3<- <- | <- <- PJ=Pim Join
RP------N1----N2----N3----N4----R1 IJ=Igmp Join
^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G)
PJ|| IJ
1| <-
N5----R2
2
Figure 3The MRT states created in this case are:
in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1)
in N1: (*,G):1->2,3
(S,G)RPT-bit:1->2
in N2: (*,G):1->2
(S,G)RPT-bit:1->none
in N3: (*,G):1->3
(S,G):2->Reg,3
in N4: (*,G):1->2
in N5: (*,G):1->2Looking at these examples, you can spot two kinds of state co-existence 👑
(S, G)with the RPT-bit not set (N2 in Figure 2, N3 in Figure 3). The(*, G)and(S, G)state have different incoming interfaces, but they share some outgoing interfaces. Traffic from S can arrive on both the(*, G)and(S, G)interfaces. Normally in L3 forwarding, the(S, G)SPT-bit entry stops S's traffic from being forwarded when it arrives on the(*, G)incoming interface. S's traffic can only temporarily show up on both incoming interfaces, lasting until N5 in Figure 2 and N1 in Figure 3 have handled the prune messages. To avoid those temporary duplicate packets, L3 forwarding can be used on this kind of node. If you don't mind temporary duplicates, L2 forwarding works too. In that case, the(*, G)and(S, G)streams have to be merged into the(*, G)LSP on their common outgoing interfaces 🫶(S, G)with the RPT-bit set (N5 in Figure 2, N1 in Figure 3). Now the(*, G)and(S, G)state share the same incoming interface, so the(S, G)traffic has to be pulled out of the(*, G)stream 🔥 In MPLS there are a few ways to handle this co-existence. Four approaches are described:
a) The first method is to terminate the LSPs and forward all of this group's traffic at L3. You can avoid going back to L3, though, if an (S, G) entry with no outgoing interface is added to the MRT (N2 in Figure 3). That entry only gets traffic temporarily. In this case you could also just ignore the (S, G) state and keep the existing (*, G) LSP, with the downside being duplicate traffic for a very short time 🌈
b) The second approach is to assign source-specific labels on the nodes of the shared tree. Multiple labels get tied to one (*, G) entry, with one label per active source. The nodes only find out which sources are active once traffic from them arrives, so the LSPs can't be set up ahead of time, and a fast LSP setup method is the way to go ⭐
c) The third way is to label-switch only the source trees, and always forward traffic on the shared tree at L3. This assumes the shared tree is only there for receivers to discover who the sources are. If you set a low bitrate switchover threshold, receivers will switch over to source trees super quickly 💨
d) In the fourth approach, an LSR that has (S, G) RPT-bit state with a non-null oif advertises a label for (S, G) to its upstream LSR. Each upstream LSR then passes that advertisement along toward the RP. This creates a dedicated LSP for (S, G) traffic from the RP to the LSR holding the (S, G) RPT-bit state. At that LSR, the (S, G) LSP gets merged onto the (*, G) LSP for the right outgoing interfaces. This makes sure (S, G) packets traveling on the shared tree never get past any LSR that has pruned S 🦋
3.5. Uni/Bi-directional Shared Trees 🌷
Bidirectional shared trees (CBT [BALL] is an example) have a downside: they create a lot of merging points (M) in the nodes (N) of the shared tree. Figure 4 shows the merging points that come from two senders, S1 and S2, on a bidirectional tree 😩
S1 S2
|| ||
v| <- <- <- <- |v
<- <- | -> -> -> -> | ->
----N----M----M----M----M----M----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
Figure 4.
Multicast traffic flows from 2 senders on a bidirectional treeFigure 5 shows the same situation with unidirectional shared trees. Here the senders' data is tunneled toward the root node R, which gives you only a single merging point: the root of the shared tree itself 🧠
S1
tunnel || S2
<----- v| tunnel ||
to R<------------------------- v|
-> -> | -> -> -> -> | ->
----N----N----N----N----N----N----N
|| || || || || ||
|v |v |v |v |v |v
| | | | | |
Figure 5.
Multicast traffic flows from 2 senders on a unidirectional tree3.6. Encapsulated Multicast Data 🎁
Sources of unidirectional shared trees, and non-member sources of bidirectional shared trees, encapsulate their data toward the root node. The root node then decapsulates it. Encapsulation and decapsulation of multicast data are both L3 processes 🙃
So with encapsulation/decapsulation, a path can never be mapped onto an end-to-end LSP. The traffic can't be forwarded at L2 on the DRsend's Register interface (that's the encapsulation part), and it can't cross the root at L2 either (that's the decapsulation part) 💀
Remarks:
- If the LSR supports mixed L2/L3 forwarding (section 4), the
(S, G)traffic in the DRsend can still be forwarded at L2 on all outgoing interfaces other than the Register interface ✨ - Encapsulated traffic can also benefit from MPLS by label switching the tunnels 🚇
- If the root node decides to join the source (so there's no encapsulation/decapsulation), an end-to-end
(S, G)LSP can be built 👑
3.7. Loop-free-ness 🔁
Multicast routing protocols that depend on a unicast routing protocol suffer from the same transient loops that unicast protocols do. The effect is way worse for multicast, though. Every time a multicast packet goes around a loop, copies of it can get emitted from the loop if there are branches in it 😱
Right now, loop detection is a configurable option in LDP, and the decision on how to prevent loops has been postponed 🫠
3.8. Mapping of Characteristics on Existing Protocols ✨
Okay so this is the cheat sheet moment 💅 All those characteristics we just went through get summed up in Table 1 for a non-exhaustive list of existing IP multicast routing protocols: DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM [HOLB], SM [PERL]. Non-exhaustive just means there are more out there, bestie 🙈
+------------------+------+------+------+------+------+------+------+
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM |
+------------------+------+------+------+------+------+------+------+
|Aggregation |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+------+------+
|Flood & Prune |yes |no |no |yes |no |no |option|
+------------------+------+------+------+------+------+------+------+
|Tree Type |source|source|shared|source|both |source|shared|
+------------------+------+------+------+------+------+------+------+
|State Co-existence|no |no |no |no |yes |no |no |
+------------------+------+------+------+------+------+------+------+
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi |
+------------------+------+------+------+------+------+------+------+
|Encapsulation |no |no |yes |no |yes |no |yes |
+------------------+------+------+------+------+------+------+------+
|Loop Free |no |no |no |no |no |no |no |
+------------------+------+------+------+------+------+------+------+Table 1. Taxonomy of IP Multicast Routing Protocols 🎀
Now the fun bit 🔥 From Table 1 you can literally work out that DVMRP is going to eat a LOT of labels when its Flood & Prune L3 tree gets mapped onto an L2 tree 💀 But since DVMRP uses source trees, it experiences no merging problem when label switching is applied, so it's not all doom and gloom. The same reading works for the other protocols too, so go ahead and play detective with the table 🕵️♀️✨
4. Mixed L2/L3 Forwarding in a Single Node 🦋
Okay so unicast traffic only has one incoming and one outgoing interface, which means it's either forwarded at L2 OR at L3 (Figure 6). Multicast is a whole different vibe though, because it can go out more than one outgoing interface. So you can totally imagine a case where traffic to some branches goes out on L2 while traffic to other branches goes out on L3 (Figure 7) 😭
+--------+ +--------+
| L3 | | L3 |
| +>>+ | | |
| | | | | |
+--|--|--+ +--------+
| | | | | |
->-----+ +-----> ->------>>----->
| L2 | | L2 |
+--------+ +--------+
Figure 6. Unicast forwarding on resp. L3 or L2 +--------+ +--------+ +--------+
| L3 | | L3 | | L3 |
| +>>++ | | +>>+ | | |
| | || | | | | | | |
+--|--||-+ +--|--|--+ +--------+
| | |+----> | | +-----> | +---->
->-----+ | | | |L2 | ->----->>-+ |
| L2+-----> ->-----+>>------> | L2 +---->
+--------+ +--------+ +--------+
Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2So nodes that support this 'mixed L2/L3 forwarding' feature let you split a multicast tree into branches, where some branches get forwarded at L3 and others get switched at L2 🌈 Super flexible, no cap.
BUT (and this is a big but 🙈) the L3 forwarding has to make sure the traffic does NOT go out on those branches that are already getting their traffic on L2. One way to handle that is by e.g. providing an extra bit in the Multicast Routing Table, which is a very smart little trick ✨
Even though mixed L2/L3 forwarding still needs the traffic to be processed at L3, the load on the L3 forwarding engine is generally less than in a pure L3 node. Honestly iconic 👑
Supporting this 'mixed L2/L3 forwarding' feature comes with the following advantages:
a) Say LSR A (Figure 8) is an MPLS edge node for the branch towards LSR B and an MPLS core node for the branch towards LSR C. Mixed L2/L3 forwarding means the branch towards C isn't disturbed by a return to L3 in LSR A. Main character energy 💅
+-------------+
| MPLS cloud |
| N |
| / \ |
| / \ |
| / \ |
| A N |
|/ \ \ |
| \ \ |
/| \ |
B | C |
| |
+-------------+
Figure 8. Mixed L2/L3 forwarding in node Ab) It also enables the use of the traffic driven trigger with the Downstream Unsolicited or Upstream on Demand label distribution mode, as explained in section 5.3.1 🧚
5. Taxonomy of IP Multicast LSP Triggers 💜
Okay so an LSP for a multicast stream can get created by different events, and those events can be mapped onto the well known categories of 'request driven', 'topology driven' and 'traffic driven'. Think of them as three different ways of saying "hey, build the tunnel now" 🎀
a) Request driven: intercept the sending or receiving of control messages (e.g. multicast routing messages, resource reservation messages).
b) Topology driven: map the L3 tree, which is available in the Multicast Routing Table, to an L2 tree. The mapping is done even if there is no traffic. Yikes, that's a lot of labels 💀
c) Traffic driven: the L3 tree is mapped onto an L2 tree when data arrives on the tree. Much more chill 🫶
5.1. Request Driven ✨
5.1.1. General
Establishing LSPs can be triggered by intercepting either outgoing control messages (which requires that the label is requested by the downstream LSR) or incoming control messages (which requires that the label is requested by the upstream LSR). Figure 9 shows both of these cases 🦋
LSRu LSRd LSRu LSRd
-------+ +--- ---+ +-------
| control | | control |
<---*<-----message------- <-------message-------*----
| | | | | |
trigger| | | | | |trigger
| | bind | | bind | |
+--------or---------> <---------or----------+
| bind-request | | bind-request |
| | | |
| | | |
|----data----->| |-----data---->|
incoming outgoing
Figure 9. Request driven trigger
(interception of resp. incoming and outgoing control messages)So the downstream LSR (LSRd) sends a control message to the upstream LSR (LSRu). If incoming control messages get intercepted and the MPLS module in LSRu decides to set up an LSP, it'll send an LDP bind (Upstream Unsolicited mode) or an LDP bind request (Downstream on Demand mode) to LSRd. Cute and simple 🌸
Right now, for multicast, there are two important types of control messages we can point out: the multicast routing messages and the resource reservation messages 💖
5.1.2. Multicast Routing Messages
In principle, this mechanism can only be used by IP multicast routing protocols that use explicit signaling, like the Join messages in PIM-SM or CBT. Remark that DVMRP and PIM-DM can be adapted to support this type of trigger [FARI], however, that comes at the cost of modifying the IP multicast routing protocol itself! 😬
IP multicast routing messages can create both hard states (e.g. CBT Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent periodically). The latter generates more control traffic for tree maintenance and therefore requires more processing in the MPLS module 🔥
Triggers based on the multicast routing protocol messages have the disadvantage that the 'routing calculations' done by the multicast routing daemon to determine the Multicast Routing Table get repeated by the MPLS module. The former figures out the tree that will be used at L3, while the latter calculates an identical tree to be used by L2. Doing the same task twice is a waste, so it's better to create the multicast LSP based on information pulled straight from the Multicast Routing Table itself (see section 5.2 and 5.3) ✨ Also, the routing calculations get more complex for protocols that support a switch-over from a (*, G) tree to a (S, G) tree, because more messages have to be interpreted 💀
When a host has a point-to-point connection to the first router, you could create 'LSPs up to the end-user' by intercepting not only the multicast routing messages but also the IGMP Join/Prune messages ([FENN]) 🧚
5.1.3. Resource Reservation Messages
Just like with unicast, the RSVP Resv message can be used as a trigger to establish LSPs. A source of a multicast group sends an RSVP Path message down the tree, and the receivers can then reply with an RSVP Resv message. RSVP scales just as well for multicast as it does for unicast, because:
a) RSVP Resv messages can merge.
b) RSVP Resv messages are only sent up to the first branch that made the required reservation.
5.2. Topology Driven 🌈
The Multicast Routing Table (MRT) is maintained by the IP multicast routing protocol daemon. The MPLS module maps this L3 tree topology information onto L2 p2mp LSPs 💜
The MPLS module can poll the MRT to pull out the tree topologies. Alternatively, the multicast daemon can be modified to notify the MPLS module directly of any change to the MRT 🎀
The downside of this method is that labels get consumed even when no traffic exists 😭
5.3. Traffic Driven 🫶
5.3.1. General
A traffic driven trigger method will only construct LSPs for trees that carry traffic. It consumes fewer labels than the topology driven method, because labels only get allocated when there's traffic on the multicast tree 🍓
If the mixed L2/L3 forwarding capability (see section 4) is not supported, the traffic driven trigger requires a label distribution mode in which the label is requested by the LSRu (Downstream on Demand or Upstream Unsolicited mode). In Figure 10, suppose an LSP for a certain group exists to LSRd1 and another LSRd2 wants to join the tree. For LSRd2 to initiate a trigger, it must already receive the traffic from the tree. That can happen at either L2 or L3. The former case is a chicken and egg problem 🐔🥚 The latter case requires a mixed L2/L3 forwarding capability in LSRu to add the L3 branch 👑
+--------+
| LSRd1 |
| |
+--------+ | L3 |
| LSRu | +--------+
| | | |
| L3 | +-------------------------->
+--------+ / | L2 |
| | / +--------+
->-------------+
| L2 | +--------+
+--------+ | LSRd2 |
| |
| L3 |
+--------+
| |
| |
| L2 |
+--------+
Figure 10. The LSRu has to request the label.5.3.2. An Implementation Example 🦋
Okay so, to prove that picking the right trigger makes MPLS multicast independent of whatever multicast routing protocol you're running, here's a real example 💅
Current Unix implementations of IP multicast routing protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The MFC is basically a cached copy of the Multicast Routing Table ✨ When it hits a "cache miss" for an incoming multicast packet, it requests an entry for that certain group. The multicast daemon supplies the missing routing info. If the route changes later (outgoing interfaces get added or removed), the multicast daemon updates the MFC 🌸
The MFC is a common component (part of the kernel), and that's lowkey why this trigger is so iconic: it can be used transparently for any IP multicast routing protocol 👑
MFC entries get removed when no traffic is received for that entry for a certain period of time. Now here's the tea 🙈 When label switching is applied to a certain MFC entry, the L3 won't see any packets arriving anymore 😭 To retain the normal MFC behavior, the L3 counters of the MFC need to be updated by L2 measurements.
5.4. Combinations of Triggers and Label Distribution Modes 🌈
Okay, Table 2 shows the valid combos of label distribution modes and trigger types we've been talking about in the previous sections 🧚 The (X) means the combination is valid when the mixed L2/L3 forwarding feature is supported in the LSR.
+----------------+---------------------------------------------+
| | label requested by |
| | LSRu | LSRd |
| +----------------------+----------------------+
| | upstream |downstream|downstream |upstream |
| |unsolicited|on demand |unsolicited|on demand |
+----------------+-----------+----------+-----------+----------+
|Request Driven | | | | |
|(incoming msg) | X | X | | |
+----------------+-----------+----------+-----------+----------+
|Request Driven | | | | |
|(outgoing msg) | | | X | X |
+----------------+-----------+----------+-----------+----------+
|Topology Driven | X | X | X | X |
+----------------+-----------+----------+-----------+----------+
|Traffic Driven | X | X | (X) | (X) |
+----------------+-----------+----------+-----------+----------+
Table 2. Valid combinations of triggers and label distribution modes6. Piggy-backing 🎀
In Figure 9 (outgoing case) you can see that instead of sending 2 separate messages, the label advertisement can be piggy-backed on the existing control messages 💖 For multicast there are two piggy-back candidates:
- a) Multicast routing messages: protocols such as PIM-SM and CBT have explicit Join messages that could carry the label mappings. This approach is described in [FARI]. When different multicast routing protocols are deployed, an extension to each of these protocols has to be defined.
- b) RSVP Resv messages: a label mapping extension object for RSVP, also applicable to multicast, is proposed in [AWDU].
Now let's talk about the pros and cons of piggy-backing on multicast routing messages 🫶
Piggy-backing has the following advantages:
- a) If the label advertisement is piggy-backed on multicast routing messages, the distribution of routes and the distribution of labels are tightly synchronized 🔥 This eliminates difficult corner cases like "what do I do with a label if I don't (yet) have a routing table entry to attach it to?" 💀 It also minimizes the interval between establishing the multicast route and mapping a label to the route.
- b) The number of control messages needed to support label advertisement beyond those needed for the multicast routing itself is zero ✨
Following disadvantages of piggy-backing can be identified:
- a) In dense-mode protocols there are no messages to piggy-back the label advertisement on. [FARI] proposes adding periodic messages to dense-mode protocols for label advertisement, which is a heavy impact on the multicast routing protocol and eliminates the message-conserving benefit of piggy-backing 😩
- b) The second solution for the state co-existence problem (section 3.4) cannot be applied in combination with piggy-backing.
- c) Piggy-backing requires extending the multicast routing protocol, so it becomes less attractive if label advertisement needs to be supported for multiple multicast routing protocols. This is especially true when not only the label advertisement but also the other two LDP functions (discovery and adjacency) are piggy-backed.
- d) Piggy-backing assumes the Downstream Unsolicited label distribution mode, and this excludes a number of trigger methods (see Table 2) 🙅
- e) LDP normally runs on top of TCP, assuring reliable communication between peer nodes. Piggy-backed label advertisement often replaces that reliable communication with periodic soft-state label advertisements. Because of this periodic label advertisement, the control traffic (in number of bytes) will increase 📈
- f) If a VCID notification mechanism [NAGA] is required, the (in-band) notification can normally be done by sending the LDP bind through the newly established VC, so only one message is required 🦋 This method cannot be combined with piggy-backing, because the routing message is sent before the VC can be established. An extra handshake message is thus required, which diminishes the benefit of piggy-backing.
So whether piggy-backing makes sense really depends on which and how many multicast routing protocols are deployed, whether LDP is already used for unicast, which trigger mechanism is used, ... 🤷♀️ Piggy-backing is just one possible component of an MPLS multicast solution.
7. Explicit Routing 🧭
Explicit routing for unicast means overriding the unicast routing table by using LSPs.
A first way to interpret "multicast explicit routing" is overriding the tree established by the multicast routing protocol with another LSP tree (e.g. a Steiner tree calculated by an off-line tool). In this interpretation, the current 'shortest path' multicast routing protocol becomes obsolete and can be replaced by label advertisement messages that follow an explicit route (e.g. a branch of the Steiner tree) 👑
A second way of interpreting "multicast explicit routing" is that the known multicast routing protocols keep running, but the messages they generate use explicit unicast routes (instead of the IGP shortest path routes) to construct trees 🌸
8. QoS/CoS 💜
8.1. DiffServ 🍓
The Differentiated Services approach can be applied to multicast too 💅 It introduces finer stream granularities (DiffServ Codepoint (DSCP) as an extra differentiator). A sender can construct one or more trees with different DSCPs ✨
These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily onto LSPs when the traffic driven trigger is used. In this case, you can create LSPs with different attributes for the various DSCPs. Note however that these LSPs still use the same route as long as the tree construction mechanism itself does not take the DSCP as an input 🙈
8.2. IntServ and RSVP 🌈
RSVP can be used to set up multicast trees with QoS. An important multicast issue is how to map the 'heterogeneous receivers' paradigm onto L2 (remark that it isn't solved in IP either) 🫠 This subject is tackled in [CRAW]. Pragmatic approaches are the 'Limited Heterogeneity Model', which allows a best effort service and a single alternate QoS (e.g. a QoS proposed by the sender in an RSVP Path message), and the 'Homogeneous Model', which allows only a single QoS 🎀
The first approach constructs full trees for each service class. The sender has to send its traffic twice across the network (e.g. 1 best-effort and 1 QoS tree). Both trees can be label switched 🧚
The second approach constructs one tree, and the best-effort users are connected to the QoS tree. If the branches created for best-effort users are not to be label switched (thus carried by a hop-by-hop default LSP), the QoS multicast traffic has to be merged onto these default LSPs. This function can be provided by the 'mixed L2/L3 forwarding' feature described in section 4. If this is not available, merging is necessary to avoid a return to L3 in the QoS LSP 🔥
The mapping of the IntServ service categories onto L2 for ATM service categories is studied in [GARR] 🦋
9. Multi-access Networks ✨
okay so multicast MPLS on multi-access networks is a whole special problem 😭 an LSR that wants to join a group has to always be ready to accept the label that's already assigned to the group LSP (to another downstream LSR on the link). there are three ways to make that work 💅
- each LSR on the multi-access link memorizes all the advertised labels on the link, even if it hasn't received a join for the associated group. if an LSR gets added to the link, it has to grab this info from another LSR on the link, or if it's doing soft state label advertisement it can wait a certain time before allocating labels itself. if LSRs allocate a label "at the same moment," the LSR with the highest IP address could keep it while the others withdraw it 👑
- each LSR gets its own label range to allocate labels from. a label partitioning mechanism is described in [FARI]. if an LSR is added to the multi-access link, the label ranges have to be negotiated again, and existing LSPs might get torn down and rebuilt with other labels 🥲
- per multi-access link, one LSR could be elected to be responsible for label allocation. when an LSR needs a label, it can request it from this Label Allocation LSR 🫶
unlike the unicast case, a multicast stream can have more than one downstream LSR that all have to use the same label 🌸 two solutions for label advertisement can be thought of:
- [FARI] proposes multicasting the label advertisements to all LSRs on the shared link. multicast isn't reliable, so this needs periodic label advertisements, which means label advertisement duplicates in time ⏰
- another approach is for an LSR to unicast its label advertisements in a reliable way (TCP) to all other (or all interested) LSRs on the shared link. with this one, the hard-state character of LDP can be maintained, but the label advertisement gets duplicated in space 🦋
since LSPs are only rewarding if they have a long lifetime, and since the number of LSRs on a shared link is limited, the second approach seems advantageous 💜
another issue with multicast in multi-access networks is whether to use upstream or downstream label assignment 🤔 for multicast traffic, upstream label allocation is simpler, because there can be only one upstream node per link that belongs to a multicast tree. that (upstream) node can assign a unique label for the FEC. with downstream allocation, there may be multiple downstream nodes for a given tree on a multi-access link, and each node may propose a different label assignment for a FEC. that would need some resolution process to come up with a single label per multicast FEC on the link 🌀
once a label has been assigned, it's possible that the label assigner leaves the tree. with downstream label assignment, this could happen when the label allocator leaves the group. with upstream assignment, this could happen when the upstream LSR changes due to a unicast topology change 🧚
10. More Issues
10.1. TTL Field
the TTL field in the IP header is typically used for loop detection 🔁 in IP multicast, it's also used to limit the scope of the multicast packets by setting an appropriate TTL value 🎀
so in LSRs that don't support a TTL decrement function (e.g. ATM LSR), the scope restriction function is affected 💀 imagine you could work out in advance how many hops an LSP traverses. in a unicast LSP, the TTL value could then be decremented at the ingress or the egress node. but for multicast, all the branches of the tree can have different lengths, so the TTL can only be decremented at the egress node, which could waste bandwidth if the TTL turns out to be zero or negative 😤
10.2. Independent vs. Ordered Label Distribution Control
current Label Distribution terminology is only defined for unicast, so the next sections explore what it might mean in a multicast context 🔍
in Independent Control ([ANDE]), each LSR can take the initiative to do a label mapping. in Ordered Control ([ANDE]), an LSR only maps a label once it has already received a label from its next-hop 🪜
all the previously described trigger methods (section 5) combine with Independent Control. note that if the request driven approach is used with Independent Control, the label distribution still behaves like Ordered Control: the control messages flow from the egress node upstream, imposing the same sequence on the label advertisement 💫
Ordered Control isn't applicable for a traffic driven trigger if the node doesn't support mixed L2/L3 forwarding 🙈 according to Table 2, this case implies that labels are requested by the upstream LSR. suppose in Figure 11 there's an LSP from S to R1 and a new branch needs to be added to R2. B will only accept a label on the A-B link if a label is already assigned on the B-C link. but to establish a label on the B-C link, B must already receive traffic on the A-B link. it's a chicken-and-egg situation and it is NOT giving 🐔🥚
N---N---R1
/
/
S -----A
\
\
B---C---R2
Figure 11.10.3. Conservative vs. Liberal Label Retention Mode
in the Conservative Mode ([ANDE]), only the labels used for forwarding data are allocated and maintained (if the next-hop for the FEC is the LSR that advertised the label). in the Liberal Mode, labels are advertised and maintained to all neighbors. Liberal Mode does not make sense in multicast, and there are two reasons for that 🙅♀️
- all LSRs have a route for each unicast FEC. this is not true for multicast FECs.
- for multicast, an LSR always knows which neighbor to send the label request or the label map messages to. in e.g. unicast Downstream Unsolicited mode (see below), the LSR doesn't know where to send the label mappings, so it has to send the mapping to all its neighbors. in that case, supporting Liberal Mode doesn't generate extra messages (it still requires extra state information and label space), so the threshold to support Liberal Mode could be considered lower 🧠
Table 3 shows the cases where an LSR knows where to send its label requests 📊
+---------+----------------------------------+
| | label requested by |
| | LSRu | LSRd |
+---------+----------------+-----------------|
|unicast | Yes | No |
+---------+----------------+-----------------|
|multicast| Yes | Yes |
+---------+----------------+-----------------+
Table 3. Does an LSR know where to send its label requests ?for a unicast flow, an LSR can work out the next hop LSR, which is the one to send the request to in Upstream Unsolicited or Downstream on Demand mode. the LSR can't find the previous hop, though 😵💫 the previous hop isn't necessarily the next hop towards the source, because the path from A to B isn't necessarily the same as the path from B to A. this can happen because of asymmetric link measures or when multiple equal cost paths exist [PAXS] 🛤️
in the multicast case, an LSR knows both the next hop(s) and the previous hop. multicast trees are built using the reverse shortest path method, so the previous hop is always the next hop towards the source or towards the root of the tree 🌳
10.4. Downstream vs. Upstream Label Allocation
the label can be allocated by either the downstream LSR (Downstream on Demand, Downstream Unsolicited) or the upstream LSR (Upstream on Demand, Upstream Unsolicited, implicit) 🔄 the advantages of downstream label allocation are:
- it's the same mode as unicast LDP, so there's no need to develop upstream label distribution procedures 🙌
- the same label can be kept when the upstream LSR changes due to a route change, which is an advantage on multi-access networks (see section 9) 🌈
- it's compatible with piggy-backing (especially the downstream distribution mode) 🎒
the advantages of upstream label allocation are:
- easier label allocation in multi-access networks (see section 9) 🥰
- the same label can be kept when the downstream LSR (which would have been the label allocator in downstream mode in a multi-access network) leaves the group (see section 9) 🚪
- the upstream and implicit distribution modes allow a faster LSP setup when the LSP is traffic triggered ⚡
whether to use upstream or downstream label distribution is outside the scope of this framework. the relative complexity of the necessary protocol extensions and the resolution mechanism needed, plus the relative operational complexity, will influence which way to go 🧩
10.5. Explicit vs. Implicit Label Distribution
besides the explicit distribution modes (which use a signaling protocol), [ACHA] proposes an implicit label distribution method that uses unknown labels 🕵️♀️ this method has all the advantages of upstream label allocation and is probably the fastest label advertisement method for traffic triggered LSPs 🚀
implicit label distribution isn't applicable if the FEC-to-label binding was advertised before traffic arrived, e.g. explicit routing (i.e. if all the information needed to identify the FEC isn't present in the packet) 🙃
explicit distribution allows pre-establishment (before data arrives) of LSPs with topology or request driven triggers 🗓️
11. Security Considerations
okay this section is important, bestie 🚨 in general, using multicast in an MPLS environment poses no extra security issues beyond the ones that already exist in multicast and MPLS protocols as such 🔐
the protocols described in this document are, however, NOT suited to crossing administrative boundaries 🚧
when the multicast tree is determined by an existing multicast routing protocol (this is the assumption made in this document, except for the Explicit Routing section), clearly no additional security issues are introduced with respect to the shape of the tree (e.g. unauthorized joining, tapping, blackholing, injecting traffic, ...). these security issues should have been addressed in the specifications of the multicast routing protocols 🛡️
in the MPLS context, it's possible that control messages trigger L2 resource allocations (e.g. LSPs). if security flaws were still present in the existing protocols (which possibly aren't too harmful in their original context), the abusive sending of such control messages can yield more severe DoS attacks 😱
in the case of an "explicit routed" tree that's calculated centrally, sufficient authentication must be done on the control messages that set up the tree in the network nodes 🔑
12. Acknowledgements
big thank yous to Eric Rosen, Piet Van Mieghem, Philip Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard Gastaud 🫶🌸 for the fruitful discussions and/or their thorough revision of this document 💖
Informative References ✨
okay bestie, this is the reading list 📚🎀 these are the references the doc leans on. every single one is listed in full, so you can go find the originals if you want to dig deeper 🫶
[ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE Globecom '97.
[ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress.
[ANDE] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
[AWDU] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[CONT] Conta, D., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks", RFC 3034, January 2001.
[CRAW] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M. and J. Krawczyk, "A Framework for Integrated Services and RSVP over ATM", RFC 2382, August 1998.
[DAVI] 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.
[DEER] Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[FARI] D. Farinacci, Y. Rekhter, E. Rosen and T. Qian, "Using PIM to Distribute MPLS Labels for Multicast Routes", Work In Progress.
[FENN] Fenner, W., "Internet Group Management Protocol, IGMP, Version 2", RFC 2236, November 1997.
[GARR] Garrett, M. and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998.
[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress.
[MOY] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[NAGA] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.
[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress.
[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work In Progress.
[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking 5(5), pp. 601-615.
[ROSE] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
Authors' Addresses ✨
and here are the people who wrote it, with where to find them 💖 contact details are kept exactly as they were, no edits 🫶
Dirk Ooms
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerp, Belgium.
Phone : 32 3 2404732
Fax : 32 3 2409879
EMail: Dirk.Ooms@alcatel.be
Bernard Sales
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerp, Belgium.
Phone : 32 3 2409574
EMail: Bernard.Sales@alcatel.be
Wim Livens
Colt Telecom
Zweefvliegtuigstraat 10, 1130 Brussels, Belgium
Phone : 32 2 7901705
Fax : 32 2 7901711
EMail: WLivens@colt-telecom.be
Arup Acharya
IBM TJ Watson Research Center
30 Saw Mill River Road, Hawthorne
NY 10532
Phone : 1 914 784 7481
EMail: arup@us.ibm.com
Frederic Griffoul
Ulticom, Inc.
Les Algorithmes, 2000 Route des Lucioles, BP29
06901 Sophia-Antipolis, FRANCE
EMail: griffoul@ulticom.com
Furquan Ansari
Bell Labs, Lucent Tech.
101 Crawfords Corner Rd., Holmdel, NJ 07733
Phone : 1 732 949 5249
Fax : 1 732 949 4556
EMail: furquan@dnrc.bell-labs.comFull Copyright Statement ✨
the legal bit 🧾 it's copied exactly, word for word, because it has to be 💅
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and 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.
Acknowledgement ✨
last but not least, the thank-you note 🌈 funding for the RFC Editor function is currently provided by the Internet Society. the people who keep the whole RFC system running deserve all the flowers 💐🫶
📦 where this page comes from
- ietf: rfc3353 2002-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms