RFC 5110
Overview of the Internet Multicast Routing Architecture
RFC 5110 💖 Overview of the Internet Multicast Routing Architecture
okay bestie, let's get into RFC 5110 🦋 It's called Overview of the Internet Multicast Routing Architecture, and it was written by P. Savola from CSC/FUNET. It's from the Network Working Group, it's marked Category: Informational, and it's dated January 2008. The header doesn't list any Obsoletes or Updates, so nothing gets replaced or patched here 🌸
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract 🎀
This document describes the multicast routing architectures that are currently deployed on the Internet. It gives a quick rundown of those protocols and points you to their specifications 📚
It also reclassifies several older RFCs to Historic. These are the ones that describe multicast routing protocols that never really got widely deployed, or that have fallen out of use 💀
Table of Contents 📖
1. Introduction ....................................................3
1.1. Multicast-Related Abbreviations ............................4
2. Multicast Routing ...............................................4
2.1. Setting up Multicast Forwarding State ......................5
2.1.1. PIM-SM ..............................................5
2.1.2. PIM-DM ..............................................5
2.1.3. Bidirectional PIM ...................................6
2.1.4. DVMRP ...............................................6
2.1.5. MOSPF ...............................................7
2.1.6. BGMP ................................................7
2.1.7. CBT .................................................7
2.1.8. Interactions and Summary ............................7
2.2. Distributing Topology Information ..........................8
2.2.1. Multiprotocol BGP ...................................8
2.2.2. OSPF/IS-IS Multi-Topology Extensions ................9
2.2.3. Issue: Overlapping Unicast/Multicast Topology .......9
2.2.4. Summary ............................................10
2.3. Learning (Active) Sources .................................10
2.3.1. SSM ................................................11
2.3.2. MSDP ...............................................11
2.3.3. Embedded-RP ........................................11
2.3.4. Summary ............................................12
2.4. Configuring and Distributing PIM RP Information ...........12
2.4.1. Manual RP Configuration ............................12
2.4.2. Embedded-RP ........................................13
2.4.3. BSR and Auto-RP ....................................13
2.4.4. Summary ............................................14
2.5. Mechanisms for Enhanced Redundancy ........................14
2.5.1. Anycast RP .........................................14
2.5.2. Stateless RP Failover ..............................14
2.5.3. Bidirectional PIM ..................................15
2.5.4. Summary ............................................15
2.6. Interactions with Hosts ...................................15
2.6.1. Hosts Sending Multicast ............................15
2.6.2. Hosts Receiving Multicast ..........................15
2.6.3. Summary ............................................16
2.7. Restricting Multicast Flooding in the Link Layer ..........16
2.7.1. Router-to-Router Flooding Reduction ................16
2.7.2. Host/Router Flooding Reduction .....................17
2.7.3. Summary ............................................18
3. Acknowledgements ...............................................18
4. IANA Considerations ............................................18
5. Security Considerations ........................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Multicast Payload Transport Extensions.................24
A.1. Reliable Multicast.........................................24
A.2. Multicast Group Security...................................241. Introduction 🌈
this doc is a quick overview of the multicast routing architectures that are running on the Internet right now, and how all those protocols fit together ✨ it also covers the multicast routing protocols that never really took off or have fallen into disuse 😭 there's a companion doc, [ADDRARCH], that goes over multicast addressing architectures 🧚
so specifically, this memo is about:
- setting up multicast forwarding state (Section 2.1),
- distributing multicast topology information (Section 2.2),
- learning active sources (Section 2.3),
- configuring and distributing the rendezvous point (RP) information (Section 2.4),
- mechanisms for enhanced redundancy (Section 2.5),
- interacting with hosts (Section 2.6), and
- restricting the multicast flooding in the link layer (Section 2.7).
Section 2 starts with a simplified example of how these classes of mechanisms fit together 🍓 some multicast data transport issues are introduced in Appendix A too 💜
this memo reclassifies the following RFCs to Historic [RFC2026] 👑:
- Border Gateway Multicast Protocol (BGMP) [RFC3913],
- Core Based Trees (CBT) [RFC2189] [RFC2201],
- Multicast OSPF (MOSPF) [RFC1584].
ngl, these protocols have mostly fallen out of use 💀 there might still be legacy deployments of some of them, and this reclassification doesn't affect those. check Section 2.1 for more on each protocol 🫶
for more historical perspective, you can look at [RFC1458], [IMRP-ISSUES], and [IM-GAPS] 📚
1.1. Multicast-Related Abbreviations 🔤
ASM Any Source Multicast
BGMP Border Gateway Multicast Protocol
BSR Bootstrap Router
CBT Core Based Trees
CGMP Cisco Group Management Protocol
DR Designated Router
DVMRP Distance Vector Multicast Routing Protocol
GARP (IEEE 802.1D-2004) Generic Attribute Registration
Protocol
GMRP GARP Multicast Registration Protocol
IGMP Internet Group Management Protocol
MBGP Multiprotocol BGP (*not* "Multicast BGP")
MLD Multicast Listener Discovery
MRP (IEEE 802.1ak) Multiple Registration Protocol
MMRP (IEEE 802.1ak) Multicast Multiple Registration
Protocol
MOSPF Multicast OSPF
MSDP Multicast Source Discovery Protocol
PGM Pragmatic General Multicast
PIM Protocol Independent Multicast
PIM-DM PIM - Dense Mode
PIM-SM PIM - Sparse Mode
PIM-SSM PIM - Source-Specific Multicast
RGMP (Cisco's) Router Group Management Protocol
RP Rendezvous Point
RPF Reverse Path Forwarding
SAFI Subsequent Address Family Identifier
SDP Session Description Protocol
SSM Source-Specific Multicast2. Multicast Routing 🦋
okay so, to give you the simplified version of how all these mechanisms fit together, picture this multicast receiver scenario 💅
a few things have to be set up before multicast routing can work at all 🔥 specifically, when ASM is in use, a router needs to know its RP address(es) (Section 2.4, Section 2.5). with IPv4, RPs have to be connected to other RPs using MSDP, so that info about sources connected to other RPs can get distributed (Section 2.3). also, routers need to know whether or how the multicast topology differs from the unicast topology, and routing protocol extensions can provide that info (Section 2.2) 🧠
so when a host wants to receive a transmission, it first has to find out the multicast group address (and, with SSM, the source address) using various means (e.g., SDP description file [RFC4566] or manually) 🎀 then it signals its interest to its first-hop router using IGMP (IPv4) or MLD (IPv6) (Section 2.6) ✨ the router starts setting up hop-by-hop multicast forwarding state (Section 2.1) toward the source (in SSM) or first through the RP (in ASM) 🌸 routers use an RP to find out all the sources for a group (Section 2.3) 👑 and when the multicast transmission reaches the receiver's LAN, it gets flooded to every Ethernet switch port, unless flooding reduction such as IGMP snooping is in use (Section 2.7) 😭
2.1. Setting up Multicast Forwarding State 🛠️
the most important part of multicast routing is setting up the multicast forwarding state 💖 state maintenance needs periodic messaging, because forwarding state has a timeout ⏰ this section covers the protocols that are commonly used for this job 🫶
2.1.1. PIM-SM 🌟
by far, the most common multicast routing protocol is PIM-SM [RFC4601] 👑 PIM-SM includes both Any Source Multicast (ASM) and Source-Specific Multicast (SSM) functionality ✨ PIM-SSM is a subset of PIM-SM that doesn't use the RPs. instead, receivers have to know the (source,group) pair and signal it explicitly 🧚 most current routing platforms support PIM-SM 💅
PIM routers elect a designated router on each LAN, and the DR handles PIM messaging and source registration on behalf of the hosts 🍓 the DR encapsulates multicast packets sourced from the LAN in a unicast tunnel to the RP 🦋 PIM-SM builds a unidirectional, group-specific distribution tree made up of the interested receivers of a group 💜 at first, the multicast distribution tree is rooted at the RP, but later the DRs have the option of optimizing delivery by building (source,group)-specific trees 🔥
if you want a longer intro to PIM-SM, check Section 3 of [RFC4601] 📚
2.1.2. PIM-DM 🌈
okay here's the thing: PIM-SM was designed to avoid unnecessary flooding of multicast data 🙈 PIM-DM [RFC3973], on the other hand, assumed that almost every subnet at a site had at least one receiver for a group 😭 PIM-DM floods multicast transmissions throughout the network ("flood and prune") unless the leaf parts of the network periodically say they're not interested in that particular group 🌊
PIM-DM might be an acceptable fit in small and/or simple networks, where setting up an RP would be unnecessary 🎀 it could also work where a large percentage of users are expected to want the transmission, so that the amount of state the network has to keep stays minimal ✨
PIM-DM was used as a first step in moving away from DVMRP 🦋 it also became clear that most networks wouldn't have receivers for most groups, and to cut down on bandwidth and state overhead, the flooding paradigm was gradually abandoned 💀 moving from PIM-DM to PIM-SM was easy, since PIM-SM was designed to use compatible packet formats, and dense-mode operation could also be satisfied by a sparse protocol 🫶 PIM-DM is no longer in widespread use 😭
a lot of implementations also support a so-called "sparse-dense" configuration 💅 in that setup, Sparse mode is used by default, but Dense is used only for configured multicast group ranges (such as Auto-RP in Section 2.4.3) 🌸 lately, lots of networks have moved from sparse-dense to sparse mode only 👑
2.1.3. Bidirectional PIM
Okay bestie, Bidirectional PIM [RFC5015] 💖 is a multicast forwarding protocol that sets up one common shared-path for all sources, with a single root 🌳. It can be used as an alternative to PIM-SM inside a single domain ✨. It doesn't have data-driven events or data-encapsulation, so it's giving simple 🦋. As it doesn't keep source-specific state, it may be an appealing approach, especially in sites with a large number of sources 🫶.
As of this writing, there is no inter-domain solution to configure a group range to use bidirectional PIM 🙈.
2.1.4. DVMRP
Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] [DVMRPv3] [DVMRPv3-AS] was the first protocol designed for multicasting 👑. To get around initial deployment hurdles, it also included tunneling capabilities, which were part of its multicast topology functions 🧚.
Currently, DVMRP is used only very rarely in operator networks 💀, having been replaced with PIM-SM. The most typical deployment of DVMRP is at a leaf network, to run from a legacy firewall that only supports DVMRP to the internal network. However, Generic Routing Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP in this functionality, so there is relatively little use for DVMRP except in legacy deployments 😭.
2.1.5. MOSPF
MOSPF [RFC1584] was implemented by several vendors and has seen some deployment in intra-domain networks 🍓. However, since it is based on intra-domain Open Shortest Path First (OSPF), it does not scale to the inter-domain case. Operators have found it is easier to deploy a single protocol for use in both intra-domain and inter-domain networks, so it is no longer being actively deployed 🥀.
2.1.6. BGMP
BGMP [RFC3913] did not get sufficient support within the service provider community to get adopted and moved forward in the IETF standards process 🙃. There were no reported production implementations and no production deployments.
2.1.7. CBT
CBT [RFC2201] [RFC2189] was an academic project that provided the basis for PIM sparse mode shared trees 🎓. Once the shared tree functionality was incorporated into PIM implementations, there was no longer a need for a production CBT implementation. Therefore, CBT never saw production deployment 🫠.
2.1.8. Interactions and Summary
It is worth noting that it is possible to run different protocols with different multicast group ranges 🌈. For example, treat some groups as dense or bidirectional in an otherwise PIM-SM network. This typically requires manual configuration of the groups or a mechanism like BSR (Section 2.4.3) 🎀. It is also possible to interact between different protocols; for example, use DVMRP in the leaf network, but PIM-SM upstream. The basics for interactions among different protocols have been outlined in [RFC2715] 🧩.
The following figure gives a concise summary of the deployment status of different protocols as of this writing 📋.
+--------------+--------------+----------------+
| Inter-domain | Intra-domain | Status |
+------------+--------------+--------------+----------------+
| PIM-SM | Yes | Yes | Active |
| PIM-DM | Not anymore | Not anymore | Little use |
| BIDIR-PIM | No | Yes | Some uptake |
| DVMRP | Not anymore | Stub only | Going out |
| MOSPF | No | Not anymore | Inactive |
| CBT | No | No | Never deployed |
| BGMP | No | No | Never deployed |
+------------+--------------+--------------+----------------+From this table, it is clear that PIM-Sparse Mode is the only multicast routing protocol that is deployed inter-domain and, therefore, is most frequently used within multicast domains as well 👑💅.
2.2. Distributing Topology Information
PIM has become the de-facto multicast forwarding protocol, but as its name implies, it is independent of the underlying unicast routing protocol 🦋. When unicast and multicast topologies are the same ("congruent"), i.e., they use the same routing tables (routing information base, RIB), it has been considered sufficient to just distribute one set of reachability information to be used in conjunction with a protocol that sets up multicast forwarding state (e.g., PIM-SM) ✨.
However, when PIM, which by default built multicast topology based on the unicast topology, gained popularity, it became apparent that it would be necessary to also distribute non-congruent multicast reachability information in the regular unicast protocols 😮. This was previously not an issue, because DVMRP built its own reachability information 🙈.
The topology information is needed to perform efficient distribution of multicast transmissions and to prevent transmission loops by applying it to the Reverse Path Forwarding (RPF) check 🔁.
This subsection introduces these protocols 💖.
2.2.1. Multiprotocol BGP
Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as "MBGP"; however, it is worth noting that "MBGP" does not stand for "Multicast BGP") specifies a mechanism by which BGP can be used to distribute different reachability information for unicast (SAFI=1) and multicast traffic (SAFI=2) 🌸. Multiprotocol BGP has been widely deployed for years, and is also needed to route IPv6 🧁. Note that SAFI=3 was originally specified for "both unicast and multicast" but has since been deprecated 🥲.
These extensions are in widespread use wherever BGP is used to distribute unicast topology information 🌐. Multicast-enabled networks that use BGP should use Multiprotocol BGP to distribute multicast reachability information explicitly, even if the topologies are congruent, to make an explicit statement about multicast reachability 📣. A number of significant multicast transit providers even require this, by doing the RPF lookups solely based on explicitly advertised multicast address family 💅.
2.2.2. OSPF/IS-IS Multi-Topology Extensions
Similar to BGP, some Interior Gateway Protocols (IGPs) also provide the capability for signalling differing topologies, for example IS-IS multi-topology extensions [M-ISIS] 🧩. These can be used for a multicast topology that differs from unicast. Similar but not so widely implemented work exists for OSPF [RFC4915] 🌙.
It is worth noting that inter-domain incongruence and intra-domain incongruence are orthogonal, so one doesn't require the other 🫶. Specifically, inter-domain incongruence is quite common, while intra-domain incongruence isn't, so you see much more deployment of MBGP than MT-ISIS/OSPF 👀. Commonly deployed networks have managed well without protocols handling intra-domain incongruence 🌷. However, the availability of multi-topology mechanisms may in part replace the typically used workarounds, such as tunnels 🎀.
2.2.3. Issue: Overlapping Unicast/Multicast Topology
An interesting case occurs when some routers do not distribute multicast topology information explicitly while others do 🤔. In particular, this happens when some multicast sites in the Internet are using plain BGP while some use MBGP 🕸️.
Different implementations deal with this in different ways 🙃. Sometimes, multicast RPF mechanisms first look up the multicast routing table, or M-RIB ("topology database"), with a longest prefix match algorithm. If they find any entry (including a default route), that is used. If no match is found, the unicast routing table is used instead 🔍.
An alternative approach is to use longest prefix match on the union of multicast and unicast routing tables. An implementation technique here is to copy the whole unicast routing table over to the multicast routing table 📋. The important point to remember here, though, is to not override the multicast-only routes. If the longest prefix match would find both a (copied) unicast route and a multicast-only route, the latter should be treated as preferable 🚨.
Another implemented approach is to just look up the information in the unicast routing table, and provide the user capabilities to change that as appropriate, using, for example, copying functions discussed above 🛠️.
2.2.4. Summary
A congruent topology can be deployed using unicast routing protocols that provide no support for a separate multicast topology. In intra-domain, that approach is often adequate 🏡. However, it is recommended that if inter-domain routing uses BGP, multicast-enabled sites should use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast, even if the topology was congruent, to explicitly signal "yes, we use multicast" 📢.
The following table summarizes the approaches that can be used to distribute multicast topology information 💜.
+----------------+--------------+
| Inter-domain | Intra-domain |
+--------------------- +----------------+--------------+
| MP-BGP SAFI=2 | Yes | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | Not applicable | Yes |
| OSPF multi-topology | Not applicable | Few implem. |
+----------------------+----------------+--------------+"Not applicable" refers to the fact that IGP protocols can't be used in inter-domain routing 🚫. "Doesn't work" means that while MP-BGP SAFI=3 was defined and could apply, that part of the specification has not been implemented and can't be used in practice 😤. "Yes" lists the mechanisms which are generally applicable and known to work ✅. "Few implem." means that the approach could work but is not commonly available 🥺.
2.3. Learning (Active) Sources
To build a multicast distribution tree, the routing protocol needs to find out where the sources for the group are 🌳. In case of SSM, the user specifies the source IP address, or it is otherwise learned out of band 🗝️.
In ASM, the RPs know about all the active sources in a local PIM domain 👑. As a result, when PIM-SM or BIDIR-PIM is used in intra-domain, the sources are learned as a feature of the protocol itself ✨.
Having a single PIM-SM domain for the whole Internet is an insufficient model for many reasons, including scalability, administrative boundaries, and different technical tradeoffs 🙅. Therefore, it is required to be able to split up the multicast routing infrastructures into smaller domains, and there must be a way to share information about active sources using some mechanism if the ASM model is to be supported 🧠.
This section discusses the options of learning active sources that apply in an inter-domain environment 🌍.
2.3.1. SSM
Source-specific Multicast [RFC4607] (sometimes also referred to as "single-source Multicast") does not count on learning active sources in the network 🙌. Recipients need to know the source IP addresses using an out of band mechanism, which are used to subscribe to the (source, group) channel. The multicast routing uses the source address to set up the state, and no further source discovery is needed 🎯.
As of this writing, there are attempts to analyze and/or define out-of-band source discovery functions which would help SSM in particular [DYNSSM-REQ] 🔭.
2.3.2. MSDP ✨
okay so the Multicast Source Discovery Protocol [RFC3618] 💖 was basically invented as a stop-gap 🩹 once it got obvious that multiple PIM-SM domains (and RPs) were needed in the network, and info about the active sources had to get passed between those domains using some other protocol. a band-aid that became iconic 💅
MSDP is also used to share state about sources between multiple RPs in a single domain for, e.g., redundancy purposes [RFC3446]. the same thing can be done with PIM extensions [RFC4610] too 🦋 see Section 2.5 for more info.
there is no intent to define MSDP for IPv6 🙈 instead it's just SSM and Embedded-RP [MCAST-ISSUES]. bye MSDP, you're giving retired 👋
2.3.3. Embedded-RP
okay this one is the main character of IPv6 🧚 Embedded-RP [RFC3956] is an IPv6-only technique that maps the RP's address to the multicast group address. so you can skip MSDP entirely and still have multiple multicast domains (in the traditional sense) ✨
the model works by defining a single RP address for a particular group for the whole Internet, so there's no need to share state about it with any other RPs. 🌸 if you need RP redundancy anyway, Anycast-RP using PIM [RFC4610] can still get you there.
2.3.4. Summary
the little table below recaps the source discovery approaches and their status 📋
+------+------+------------------------------+
| IPv4 | IPv6 | Status |
+----------------------+------+------+------------------------------+
| Bidir single domain | Yes | Yes | OK but for intra-domain only |
| PIM-SM single domain | Yes | Yes | OK |
| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
| SSM | Yes | Yes | No major uptake yet |
+----------------------+------+------+------------------------------+2.4. Configuring and Distributing PIM RP Information
so there are PIM-SM and BIDIR-PIM configuration mechanisms 🔧 used to configure the RP addresses, plus the groups that are supposed to use those RPs, in the routers. this section walks through the approaches, let's gooo 🚀
2.4.1. Manual RP Configuration
honestly? it's often easiest to just manually configure the RP info on the routers when PIM-SM is used 🙌
originally, static RP mapping was considered suboptimal because it needed explicit config changes every time the RP address changed 😩 but with anycast RP addressing now, the RP address is unlikely to ever change. so the admin burden is generally limited to the initial config. there's usually a fair amount of multicast config on all routers anyway (e.g., PIM on all interfaces), so adding the RP address statically isn't really an issue 💁♀️ plus static anycast RP mapping gives you RP load sharing and redundancy (see Section 2.5) without the complexity of dynamic mechanisms like Auto-RP and Bootstrap Router (BSR). no thank you, complexity 🙅♀️
with that design, an anycast RP uses an address configured on a loopback interface of the routers currently acting as RPs, and state is distributed using PIM [RFC4610] or MSDP [RFC3446] 🪞
using this technique, each router might only need to be configured with one portable RP address 🎀
2.4.2. Embedded-RP
Embedded-RP gives you the RP's address inside the group addresses that are delegated to the people using the RP 🧚 so unless no other ASM than Embedded-RP is in use, the network admin only needs to configure the RP routers. so chill 😌
while Embedded-RP is often enough for IPv6, other RP config methods are needed if you want to provide ASM service for group addresses other than Embedded-RP ones. service discovery apps are the big example here 🔍 they might need hard-coded addresses that don't depend on local RP addresses.
because the RP's address is exposed to users and applications, it's very important to make sure it doesn't change often, e.g., by using manual config of an anycast address 🔒
2.4.3. BSR and Auto-RP
BSR [RFC5059] is a mechanism for configuring the RP address for groups 📮 it may not be as widely used with IPv4 as it was earlier, and for IPv6, Embedded-RP will often be enough.
Cisco's Auto-RP is an older, proprietary method for distributing group to RP mappings, similar to BSR 🤖 and honestly it has little use today.
both Auto-RP and BSR need some form of control at the routers so that only valid routers can advertise themselves as RPs 🚨 flooding of BSR and Auto-RP messages must be prevented at PIM borders too. plus routers need monitoring to check they're actually using the RP(s) the admins think they should be using, e.g., in case a router (maybe in a customer's control) is advertising itself inappropriately 👀 all in all, BSR and Auto-RP give you easy config, but also a ton of config and management complexity 😵💫
worth noting: both Auto-RP and BSR were deployed before manually configured anycast-RP addresses became pretty common, and there's actually relatively little need for them today 💅 unless you need to configure different properties (e.g., sparse, dense, bidirectional) in a dynamic way.
2.4.4. Summary
this table sums up the RP discovery mechanisms and their status. the one exception is Embedded-RP, since every other mechanism operates within a PIM domain 🗺️
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Static RP | Yes | Yes | Especially in ISPs |
| Auto-RP | Yes | No | Legacy deployment |
| BSR | Yes | Yes | Some, anycast simpler |
| Embedded-RP | No | Yes | Growing |
+--------------------+------+------+-----------------------+2.5. Mechanisms for Enhanced Redundancy
having only one RP in a PIM-SM domain would be a single point of failure for the whole multicast domain 😱 so a bunch of mechanisms have been developed to either get rid of RP functionality or boost RP redundancy, resilience against failures, and quick recovery from failures 💪 this section summarizes those techniques.
2.5.1. Anycast RP
as mentioned in Section 2.3.2, MSDP is also used to share state about sources between multiple RPs in a single domain, e.g., for redundancy purposes [RFC3446] 🔁 the point of MSDP here is to share the same state info on multiple RPs for the same groups, so the service is more robust 🛡️
recent PIM extensions [RFC4610] also give you this functionality. unlike MSDP, this approach works for both IPv4 and IPv6 🙌
2.5.2. Stateless RP Failover
while Anycast RP shares state between RPs so an RP failure only causes small disturbance, stateless approaches are also possible, just with more limited resiliency 🤏 a traditional move was to use Auto-RP or BSR (see Section 2.4.3) to select another RP when the active one failed. but the same functionality can be had with a shared-unicast RP address ("anycast RP without state sharing") without the complexity of a dynamic mechanism 🧠 plus Anycast RP offers a significantly more extensive failure mitigation strategy, so today there's very little need for stateless failover, especially dynamic ones, for redundancy 💀
2.5.3. Bidirectional PIM
because bidirectional PIM (see Section 2.1.3) does not switch to shortest path tree (SPT), the final multicast tree may get established faster ⚡ on the other hand, PIM-SM or SSM may converge more quickly, especially in scenarios (e.g., a unicast routing change) where bidirectional needs to redo the Designated Forwarder election 🔄
2.5.4. Summary
this table summarizes the techniques for enhanced redundancy 🌈
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Anycast RP w/ MSDP | Yes | No | De-facto approach |
| Anycast RP w/ PIM | Yes | Yes | Newer approach |
| Stateless RP fail. | Yes | Yes | Causes disturbance |
| BIDIR-PIM | Yes | Yes | Deployed at some sites|
+--------------------+------+------------------------------+2.6. Interactions with Hosts
so far we've covered the stuff routers need to do multicast routing 🖥️ but obviously the real users of multicast are the hosts, either sending or receiving it 🎉 this section describes the required interactions with hosts.
2.6.1. Hosts Sending Multicast
after picking a multicast group through a variety of means, hosts just send packets to the link-layer multicast address 📤 the designated router receives all the multicast packets and starts forwarding them as appropriate. a host doesn't need to be a member of the group to send to it [RFC1112] 🤯
in intra-domain or Embedded-RP scenarios, ASM senders can move to a new IP address without significant impact on delivery of their transmission 🏃♀️ SSM senders, on the other hand, cannot change the IP address unless receivers join the new channel, or the sender uses an IP mobility technique that's transparent to the receivers 🙃
2.6.2. Hosts Receiving Multicast
hosts signal their interest in receiving a multicast group or channel using IGMP [RFC3376] and MLD [RFC3810] 📣 IGMPv2 and MLDv1 are still commonplace, but they're also often used in new deployments. some vendors also support SSM mapping for receivers that use an older IGMP/MLD version, where the router maps the join request to an SSM channel based on various, usually complex, config means 🗂️
2.6.3. Summary
this table summarizes the techniques for host interaction 📊
+-------+------+----------------------------+
| IPv4 | IPv6 | Notes |
+--------------------+-------+------+----------------------------+
| Host sending | Yes | Yes | No support needed |
| Host receiving ASM | IGMP | MLD | Any IGMP/MLD version |
| Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping |
+--------------------+-------+------+----------------------------+2.7. Restricting Multicast Flooding in the Link Layer
multicast transmission in the link layer, like on Ethernet, typically includes some form of flooding the packets through a LAN 🌊 this causes unnecessary bandwidth usage, plus discarding unwanted frames on the nodes that didn't want the multicast transmission in the first place 😤
so a number of techniques have been developed for use in Ethernet switches between routers, or between routers and hosts, to limit the flooding 🛑
some mechanisms work with IP addresses, others with MAC addresses 🔍 if filtering is done based on MAC addresses, hosts may receive unnecessary multicast traffic (filtered out in the hosts' IP layer) when more than one IP multicast group address maps into the same MAC address, or when IGMPv3/MLDv2 source filters are used. filtering based on IP destination addresses, or on destination and source addresses, will help avoid these, but it requires parsing the Ethernet frame payload 🧐
these options are discussed in this section 💜
2.7.1. Router-to-Router Flooding Reduction 🎀
okay so Cisco's proprietary RGMP [RFC3488] was built to cut down on flooding between routers in a switched network 💅 This is typically only considered a problem at some Ethernet-based Internet Exchange points or VPNs.
There have also been proposals to observe and possibly react to ("snoop") PIM messages [PIM-SNOOP] 🦋
2.7.2. Host/Router Flooding Reduction 🌸
There are a bunch of techniques that help cut down on flooding from a router to hosts, and from a host to the routers (and other hosts) ✨
Cisco's CGMP [CGMP] is their proprietary fix, where routers notify the switches. It also lets switches snoop IGMP packets, so hosts that no longer want a group get noticed faster 🙈 Implementations of CGMP do not support fast leave behaviour with IGMPv3, which is a little sad 😭 Thanks to IGMP report suppression in IGMPv1 and IGMPv2, multicast is still flooded to ports that were once members of a group, as long as there is at least one receiver on the link. Flooding restrictions are done based on multicast MAC addresses. And implementations of CGMP do not support IPv6 🥲
Next up is GMRP. The IEEE 802.1D-2004 specification describes Generic Attribute Registration Protocol (GARP), and GARP Multicast Registration Protocol (GMRP) [GMRP] is a link-layer multicast group application of GARP that tells switches about MAC multicast group memberships 🧚 If GMRP is used with IP multicast, the GMRP registration function would get tied to an IGMP "join". BUT this GMRP-IGMP association is beyond the scope of GMRP, so it's not defined there. GMRP needs support at the host stack, and it has not been widely implemented 💀 IEEE 802.1 also considers GARP and GMRP obsolete, since they're being replaced by Multiple Registration Protocol (MRP) and Multicast Multiple Registration Protocol (MMRP), which are being specified in IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between bridges. You can find more GARP/GMRP info in Appendix B of [RFC3488] 📚
IGMP snooping [RFC4541] seems to be the most widely implemented technique, and it's giving main character energy 👑 But it asks switches to do a lot of IP-level packet inspection. That appears to be really hard to get right, and upgrades are often a challenge too 🫠 Snooping support is common for IGMPv1 and IGMPv2, but fewer switches support IGMPv3 or MLD snooping (any version). In the worst case, turning on IGMP snooping on a switch that doesn't support IGMPv3 snooping breaks multicast for nodes using IGMPv3. Yikes 😱
Snooping switches also need to figure out which ports have routers on them, so they know where to flood packets. That can be done with the Multicast Router Discovery protocol [RFC4286], by looking at certain IGMP queries [RFC4541], by looking at PIM Hello and possibly other messages, or by manual configuration. One problem with PIM snooping on LANs is that PIM messages can't be turned off or encrypted, which leads to security issues [PIM-THREATS] 🔐
IGMP proxying [RFC4605] is sometimes used either as a replacement for a multicast routing protocol on a small router, or to aggregate IGMP/MLD reports when it's used with IGMP snooping 🌷
2.7.3. Summary 🧚
The table below sums up the techniques for reducing multicast flooding inside a single link, for router-to-router and last-hop LANs. Look at how neatly it's organised 😍
+--------+-----+----------------------------+
| R-to-R | LAN | Notes |
+-----------------------+--------+-----+----------------------------+
| Cisco's RGMP | Yes | No | Replaced by PIM snooping |
| PIM snooping | Yes | No | Security issues in LANs |
| IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare |
| Multicast Router Disc | No | Yes | Few if any implem. yet |
| IEEE GMRP and MMRP | No | No | No host/router deployment |
| Cisco's CGMP | No | Yes | Replaced by other snooping |
+-----------------------+--------+-----+----------------------------+3. Acknowledgements 💜
Tutoring a couple of multicast-related papers gave the author a major wake-up call. The latest one, by Kaarle Ritvanen [RITVANEN], convinced them that up-to-date multicast routing and address assignment/allocation documentation is necessary 🫶
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, Prashant Jhingran, and Tim Polk provided good comments that helped improve this document 🙌
4. IANA Considerations 🍓
IANA has updated the following registries by adding a reference to this document:
- OSPFv2 Options Registry: MC-bit
- OSPFv2 Link State (LS) Type: Group-membership-LSA
- OSPFv2 Router Properties Registry: W-bit
- OSPFv3 Options Registry: MC-bit
- OSPFv3 LSA Function Code Registry: Group-membership-LSA
- OSPFv3 Prefix Options Registry: MC-bit
5. Security Considerations 🔥
This memo only describes different approaches to multicast routing, and this has no security considerations. The security analysis of the mentioned protocols is out of scope of this memo.
BUT the security stakes are real, bestie. There has been analysis of the security of multicast routing infrastructures [RFC4609], IGMP/MLD [MLD-SEC], and PIM last-hop issues [PIM-THREATS]. Go read those 🚨
6. References 🌈
6.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
6.2. Informative References 📚✨
okay so the informative refs are the extra reading list 🎀 they're not required to implement the spec, but they give you the backstory. here's the full list, kept exact so you can look everything up:
[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol",
<http://www.ieee802.org/1/pages/802.1ak.html>.
[ADDRARCH] Savola, P., "Overview of the Internet Multicast
Addressing Architecture", Work in Progress,
October 2006.
[CGMP] "Cisco Group Management Protocol",
<http://www.javvin.com/protocolCGMP.html>.
[DVMRPv3] Pusateri, T., "Distance Vector Multicast Routing
Protocol", Work in Progress, December 2003.
[DVMRPv3-AS] Pusateri, T., "Distance Vector Multicast Routing
Protocol Applicability Statement", Work in Progress,
May 2004.
[DYNSSM-REQ] Lehtonen, R., Venaas, S., and M. Hoerdt,
"Requirements for discovery of dynamic SSM sources",
Work in Progress, February 2005.
[GMRP] "GARP Multicast Registration Protocol",
<http://www.javvin.com/protocolGMRP.html>.
[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap
Analysis from the MBONED Working Group for the IESG
[Expired]", Work in Progress, July 2002.
[IMRP-ISSUES] Meyer, D., "Some Issues for an Inter-domain Multicast
Routing Protocol", Work in Progress, November 1997.
[M-ISIS] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing
in IS-IS", Work in Progress, November 2007.
[MCAST-ISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work
in Progress, February 2005.
[MLD-SEC] Daley, G. and G. Kurup, "Trust Models and Security in
Multicast Listener Discovery", Work in Progress,
July 2004.
[PIM-SNOOP] Hemige, V., "PIM Snooping over VPLS", Work
in Progress, March 2007.
[PIM-THREATS] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", Work in Progress,
October 2007.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering,
"Distance Vector Multicast Routing Protocol",
RFC 1075, November 1988.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1458] Braudes, B. and S. Zabele, "Requirements for
Multicast Protocols", RFC 1458, May 1993.
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994.
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2)
Multicast Routing -- Protocol Specification --",
RFC 2189, September 1997.
[RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast
Routing Architecture", RFC 2201, September 1997.
[RFC2715] Thaler, D., "Interoperability Rules for Multicast
Routing Protocols", RFC 2715, October 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000.
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci,
D., Lin, S., Leshchiner, D., Luby, M., Montgomery,
T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone,
R., Sumanasekera, R., and L. Vicisano, "PGM Reliable
Transport Protocol Specification", RFC 3208,
December 2001.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
"Anycast Rendevous Point (RP) mechanism using
Protocol Independent Multicast (PIM) and Multicast
Source Discovery Protocol (MSDP)", RFC 3446,
January 2003.
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port
Group Management Protocol (RGMP)", RFC 3488,
February 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group
Security Architecture", RFC 3740, March 2004.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol
(BGMP): Protocol Specification", RFC 3913,
September 2004.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router
Discovery", RFC 4286, December 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management
Protocol (IGMP) and Multicast Listener Discovery
(MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) /
Multicast Listener Discovery (MLD)-Based Multicast
Forwarding ("IGMP/MLD Proxying")", RFC 4605,
August 2006.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM)
Multicast Routing Security Issues and Enhancements",
RFC 4609, October 2006.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol
Independent Multicast (PIM)", RFC 5059, January 2008.
[RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/
papers/>.Appendix A. Multicast Payload Transport Extensions 🧚
okay this appendix is a little side quest 🌸 a couple of mechanisms have been specified to make the data you send over multicast work better 💖
we only talk about the ones that touch the multicast routing infrastructure, like anything that needs routers to help out or get involved somehow. purely end-to-end or host-based protocols are out of scope, so we're skipping those 🙈
A.1. Reliable Multicast 🔁
there's been some work on reliable multicast delivery so apps that really need reliability can use multicast instead of plain unreliable UDP 💅
most of these mechanisms are host-based, which means they're out of scope for this document. the one that matters from the routing side is Pragmatic Generic Multicast (PGM) [RFC3208]. it doesn't need any support from the routers, but PGM-aware routers can act in a router assistance role for the initial delivery and for possible retransmission of missing data ✨
A.2. Multicast Group Security 🔐
the Multicast Security Working Group has been working on ways to make sure data sent to multicast groups has integrity, confidentiality, and authentication, using cryptographic techniques [RFC3740] 🫶
Author's Address 🖋️
Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland
EMail: psavola@funet.fiFull Copyright Statement ©️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🪪
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💜
📦 where this page comes from
- ietf: rfc5110 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms