RFC 2117

Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification

📅 published June 1997, from ietf

Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification 🎀

Okay bestie, let's get into it! 💖 This is RFC 2117, published in June 1997 as an Experimental doc from the Network Working Group. It was written by D. Estrin (USC), D. Farinacci (CISCO), A. Helmy (USC), D. Thaler (UMICH), S. Deering (XEROX), M. Handley (UCL), V. Jacobson (LBL), C. Liu (USC), P. Sharma (USC), and L. Wei (CISCO). 🧚 The header doesn't list anything it obsoletes or updates, so there's nothing to report there. 💅

Status of This Memo

This memo defines an Experimental Protocol for the Internet community. 🧪 It does not specify an Internet standard of any kind. 🙈 The authors are asking for discussion and suggestions for improvement, and the memo can be distributed without limit. 🦋

Acknowledgements

The author list got reordered to show who did the heavy editorial lifting on this spec. ✨ The first four authors are the primary editors, listed alphabetically. The rest also listed alphabetically, but they were involved in all the architecture and detailed design, and they somehow got away without touching LaTeX! 😭💀

1 Introduction 🌸

Okay so this doc describes a protocol for routing to multicast groups efficiently, even when those groups stretch across wide-area and inter-domain internets. 🌍 It's called Protocol Independent Multicast-Sparse Mode (PIM-SM) because it doesn't depend on any particular unicast routing protocol, and because it's designed for sparse groups, as defined in [1][2]. This doc covers the protocol details. For the why behind the design and the architecture, check out [1][2]. 🧠

Section 2 gives an overview of how PIM-SM works from the network's point of view, especially how the participating routers team up to build and maintain the multicast distribution tree. 🤝 Section 3 is the real meat. It looks at PIM-SM from the perspective of one router running the protocol, and it's the main body of the spec. It's organized by PIM-SM message type, and for each type it explains the contents, how the message gets generated, and how it gets processed. 📦

Sections 3.8 and 3.9 recap the timers and flags you'll keep seeing throughout the doc. ⏱️ Section 4 has the packet format details. 🧩

The biggest functional changes since the January '95 version are all about the Rendezvous Point-related mechanisms, a bunch of simplifications to the protocol, and moving the PIM-DM protocol details into their own separate document, [3], for clarity. 👑

2 PIM-SM Protocol Overview 🦋

In this section we give you the overview of PIM-SM's architectural pieces. 💅

A router gets explicit Join/Prune messages from neighboring routers that have downstream group members. 🙌 Then it forwards data packets addressed to a multicast group, G, only out the interfaces where explicit joins came in. Heads up: every router mentioned in this document is assumed to be PIM-SM capable, unless the text says otherwise. ✨

A Designated Router (DR) sends periodic Join/Prune messages toward a group-specific Rendezvous Point (RP), one for each group it has active members for. 📡 Every router along the path toward the RP builds a wildcard (any-source) state for the group and sends its own Join/Prune messages on toward the RP. 🌊 The term route entry refers to the state a router keeps to represent the distribution tree. 🗂️ A route entry can include things like the source address, the group address, the incoming interface packets are accepted on, the list of outgoing interfaces packets get sent to, timers, flag bits, and so on. 🧾

For the wildcard route entry, the incoming interface points toward the RP, and the outgoing interfaces point at the neighboring downstream routers that sent Join/Prune messages toward the RP. 🫶 Together, this state creates a shared, RP-centered distribution tree that reaches every group member. 🌳

Here's the flow when a data source first sends to a group: its DR unicasts Register messages to the RP, with the source's data packets encapsulated inside. 📮 If the data rate is high, the RP can send source-specific Join/Prune messages back toward the source. Then the source's data packets follow that forwarding state and arrive at the RP unencapsulated. 🚀 Whether they show up encapsulated or native, the RP forwards the decapsulated data packets down the RP-centered distribution tree to the group members. 💖

If the data rate justifies it, routers with local receivers can join a source-specific, shortest path distribution tree and prune that source's packets off the shared RP-centered tree. ✂️ For low data rate sources, neither the RP nor the last-hop routers need to join a source-specific shortest path tree. The data packets can just be delivered over the shared RP-tree. 🐢

The next subsections go deeper into SM operation, specifically the control messages and the actions they set off. 🔍

2.1 Local hosts joining a group 🎟️

To join a multicast group G, a host shares its membership info through the Internet Group Management Protocol (IGMP), as specified in [4][5] (see figure 1). From this point on, we call that host a receiver, R (or member), of group G. 🙋‍♀️

Heads up: all the figures in this section are for illustration only, and they aren't meant to be complete. For the complete, detailed protocol action, see Section 3. 📝

   [Figures are present only in the postscript version]
   Fig. 1  Example: how a receiver joins, and sets up shared tree

When a DR (for example, router A in figure 1) gets a membership indication from IGMP for a new group G, the DR looks up the associated RP. 🔎 Then it creates a wildcard multicast route entry for the group, which we're calling a (*,G) entry. If there's no more specific match for a particular source, the packet gets forwarded according to this entry. 🎯

The RP address goes in a special field in the route entry, and it's included in the periodic upstream Join/Prune messages. 📬 The outgoing interface is set to the one included in the IGMP membership indication for the new member. ✅ The incoming interface is set to the interface used to send unicast packets to the RP. 🛣️

When there are no longer any directly connected members for the group, IGMP notifies the DR. 🔔 If the DR has neither local members nor downstream receivers, the (*,G) state gets deleted. 🗑️

2.2 Establishing the RP-rooted shared tree 🌲

Once the (*,G) state exists, the DR creates a Join/Prune message with the RP address in its join list. It sets the wildcard bit (WC-bit) and the RP-tree bit (RPT-bit) to 1. 💫 The WC-bit says any source may match and be forwarded according to this entry if there's no more specific match. The RPT-bit says this join is being sent up the shared RP-tree. 🌿 The prune list is left empty. 🫧

When the RPT-bit is set to 1, the join is associated with the shared RP-tree, so the Join/Prune message gets propagated along the RP-tree. 🧵 When the WC-bit is set to 1, the address is an RP, and downstream receivers expect to get packets from all sources through this shared tree path. 🥰 The term RPT-bit refers to both the RPT-bit flags on route entries and the RPT-bit included in each encoded address in a Join/Prune message. 🔁

Each upstream router creates or updates its multicast route entry for (*,G) when it receives a Join/Prune with the RPT-bit and WC-bit both set. 🙌 The interface the Join/Prune arrived on gets added to the list of outgoing interfaces (oifs) for (*,G). Based on that entry, each upstream router between the receiver and the RP sends a Join/Prune message whose join list includes the RP. 🪜 The packet payload contains:

Multicast-Address=G, Join=RP,WC-bit,RPT-bit, Prune=NULL

2.3 Hosts sending to a group 📣

When a host starts sending multicast data packets to a group, its DR has to deliver each packet to the RP first, so the RP can distribute it down the RP-tree. 🎁 The sender's DR encapsulates each data packet in a Register message at the start, then unicasts it to the RP for that group. 📨 The RP decapsulates each Register message and forwards the enclosed data packet natively to downstream members on the shared RP-tree. 💌

   [Figures are present only in the postscript version]
   Fig. 2  Example: a host sending to a group

If the source's data rate calls for a source-specific shortest path tree (SPT), the RP can build a new multicast route entry specific to that source. We call that (S,G) state, and the RP then sends periodic Join/Prune messages toward the source. 🌟 Over time, the rules for when to switch can change without any global coordination, which is very iconic. 🦋 When and if the RP does switch to the SPT, the routers between the source and the RP build and maintain (S,G) state in response to these messages, and they send (S,G) messages upstream toward the source. 🧗‍♀️

The source's DR has to stop encapsulating data packets in Registers when, and as long as, it receives Register-Stop messages from the RP. 🛑 The RP triggers Register-Stop messages in response to Registers in two situations: if the RP has no downstream receivers for the group (or for that particular source), or if the RP has already joined the (S,G) tree and is receiving the data packets natively. 😌 Each source's DR keeps a Register-Suppression-timer for every (S,G) pair. 🧁 The Register-Suppression-timer starts when a Register-Stop message arrives. When it expires, the source's DR goes back to sending data packets to the RP, encapsulated in Register messages. ⏰✨

2.4 Switching from shared tree (RP-tree) to shortest path tree (SP-tree) 🌈

okay so 💅 a router with directly-connected members always joins the shared RP-tree first. then it can switch over to a source's shortest path tree (SP-tree), but only after it's been getting packets from that source over the shared RP-tree. 🦋 The recommended policy is to start the switch once the router has received a significant number of data packets from a particular source during a specified time interval. to make that happen, the router can keep an eye on data packets from sources it has no source-specific multicast route entry for, and create one when the data rate goes over the configured threshold. as shown in figure 3, router `A' initiates a (S,G) state. ✨

   [Figures are present only in the postscript version]
   Fig. 3  Example: Switching from shared tree to shortest path tree

when a (S,G) entry gets activated (and again periodically for as long as the state exists), a Join/Prune message goes upstream toward the source, S, with S in the join list. 🎀 the payload contains Multicast-Address=G, Join=S, Prune=NULL. when the (S,G) entry is created, its outgoing interface list is copied from (,G), so all the local shared tree branches get replicated in the new shortest path tree. 🌸 that way, when a data packet from S shows up and matches this entry, all the receivers keep getting the source's packets along this path. (in more complicated scenarios, other entries in the router have to be considered too, as described in Section 3.) 🙈 note that (S,G) state must be maintained in each last-hop router that is responsible for initiating and maintaining an SP-tree. even when (,G) and (S,G) overlap, both states are needed to trigger the source-specific Join/Prune messages. 💜 (S,G) state is kept alive by data packets arriving from that source. there's a timer called Entry-timer set for the (S,G) entry, and it gets restarted whenever data packets for (S,G) are forwarded out at least one oif, or Registers are sent. when Entry-timer expires, the state is deleted. 🫶 the last-hop router is the router that delivers the packets to their ultimate end-system destination. it's the one that watches whether there's group membership and joins or prunes the right distribution trees in response. in general the last-hop router is the Designated Router (DR) for the LAN, but under various conditions described later, a parallel router connected to the same LAN may take over as the last-hop router instead of the DR. 👑

only the RP and routers with local members can start switching to the SP-tree; intermediate routers can't. so last-hop routers create (S,G) state in response to data packets from the source, S, whereas intermediate routers only create (S,G) state in response to Join/Prune messages from downstream that have S in the Join list. 🧚

the (S,G) entry starts out with the SPT-bit cleared, which means the shortest path tree branch from S isn't fully set up yet, and the router can still accept packets from S that arrive on the incoming interface (iif) of the (*,G) entry. 💖 each PIM multicast entry has an associated incoming interface where packets are expected to arrive. ⭐

now here's the fun part 😭 when a router with a (S,G) entry and a cleared SPT-bit starts receiving packets from the new source S on the iif for the (S,G) entry, and that iif is different from the (,G) entry's iif, the router sets the SPT-bit and sends a Join/Prune message toward the RP. this says the router no longer wants to get packets from S over the shared RP-tree. the Join/Prune message sent toward the RP includes S in the prune list, with the RPT-bit set, meaning S's packets must not be forwarded down this branch of the shared tree. 🔥 if the router receiving that message already has (S,G) state (with or without the route entry's RPT-bit flag set), it deletes the arriving interface from the (S,G) oif list. if it only has (,G) state, it creates an entry with the RPT-bit flag set to 1. 🌈 for brevity, we call an (S,G) entry whose RPT-bit flag is set to 1 an (S,G)RPT-bit entry. this little notational distinction helps point out the different actions taken for (S,G) entries depending on the RPT-bit flag. 💅 also, a router can have no more than one active (S,G) entry for any particular S and G at any particular time, whether the RPT-bit flag is set or not. in other words, a router never has both an (S,G) and an (S,G)RPT-bit entry for the same S and G at the same time. the Join/Prune message payload contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit. 🦋

a new receiver may join an existing RP-tree where source-specific prune state has already been established (for example, because downstream receivers have switched to SP-trees). in that case the prune state must be eradicated upstream of the new receiver so that all sources' data packets come down to it. 😭 so when a (,G) Join arrives at a router that has any (Si,G)RPT-bit entries (meaning entries that make the router send source-specific prunes toward the RP), those entries must be updated upstream of the router so all sources' packets reach the new member. to do this, each router that receives a (,G) Join/Prune message updates all of its existing (S,G)RPT-bit entries. 🍓 the router may also trigger a (,G) Join/Prune message upstream to cause the same RPT-bit updating further up and pull down all active sources' packets. if the arriving (,G) join has some sources included in its prune list, then the corresponding (S,G)RPT-bit entries are left unchanged (the RPT-bit stays set and no oif is added). 💀

2.5 Steady state maintenance of distribution tree (i.e., router state) 🍓

in the steady state, every router sends periodic Join/Prune messages for each active PIM route entry, and those messages go to the neighbor listed in that entry. 💜 they keep getting sent so that state, topology, and membership changes stay up to date. a Join/Prune message is also sent on an event-triggered basis each time a new route entry gets established for some new source. (note that some damping function may be applied, e.g., a short delay so new Join information can get merged. 🌸) Join/Prune messages don't get any kind of explicit acknowledgment, and routers recover from lost packets using the periodic refresh mechanism. 🫶

2.6 Obtaining RP information ✨

so to get the RP information, all routers within a PIM domain collect Bootstrap messages. 🎀 Bootstrap messages are sent hop-by-hop within the domain, and the domain's bootstrap router (BSR) is the one responsible for originating them. Bootstrap messages are used to carry out a dynamic BSR election when one is needed, and to distribute RP information in steady state. 👑

a domain, in this context, is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the rest of the internet. 🧚

routers use a set of available RPs (called the {RP-Set}) that's distributed in Bootstrap messages to get the proper Group to RP mapping. ⭐ the following paragraphs summarize the mechanism, and details can be found in Sections 3.6 and Appendix 6.2. a (small) set of routers within a domain are configured as candidate BSRs, and a single BSR is selected for the domain through a simple election mechanism. 🦋 a set of routers within a domain are also configured as candidate RPs (C-RPs), and these will typically be the same routers that are configured as C-BSRs. 💖 candidate RPs periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that domain. C-RP-Advs include the address of the advertising C-RP, plus an optional group address and a mask length field that indicate the group prefix(es) the candidacy is advertised for. 🌈 the BSR then includes a set of these Candidate-RPs (the RP-Set), along with the corresponding group prefixes, in the Bootstrap messages it periodically originates. Bootstrap messages are distributed hop-by-hop throughout the domain. 🍓

routers receive and store Bootstrap messages originated by the BSR. 💅 when a DR gets a membership indication from IGMP for (or a data packet from) a directly connected host, for a group it has no entry for, the DR uses a hash function to map the group address to one of the C-RPs whose Group-prefix includes the group (see Section 3.7). 😭 the DR then sends a Join/Prune message toward (or unicasts Registers to) that RP. 🎀

the Bootstrap message indicates the liveness of the RPs included in it. if an RP is included in the message, it's tagged as `up' at the routers, while RPs not included in the message are removed from the list of RPs the hash algorithm acts over. 👑 each router keeps using the contents of the most recently received Bootstrap message until it receives a new one. 🫶

if a PIM domain partitions, each area separated from the old BSR will elect its own BSR, which will distribute an RP-Set containing RPs that are reachable within that partition. 💀 when the partition heals, another election happens automatically, and only one of the BSRs keeps sending out Bootstrap messages. 🔥 as is expected at the time of a partition or healing, some disruption in packet delivery may occur. this time will be on the order of the region's round-trip time and the bootstrap router timeout value. ⭐

2.7. Interoperation with dense mode protocols such as DVMRP ✨

okay so if you wanna talk to networks running dense-mode, {broadcast and prune}, protocols like DVMRP, then every packet made inside a PIM-SM region must be pulled out to that region's PIM Multicast Border Routers (PMBRs) and injected (aka broadcast) into the DVMRP network 🌸 A PMBR is the router sitting right at the edge of a PIM-SM domain, and it talks to other kinds of multicast routers, like the ones running DVMRP. Generally a PMBR would speak both protocols and handle interoperability jobs that regular PIM routers don't have to do 💅 To make this work, there's a special entry type called (,,RP) that must be supported by all PIM routers. That's why the (,,RP) entry handling lives in this general PIM spec, not somewhere else 🫶

A data packet matches a (,,RP) entry if there's no more specific entry (like (S,G) or (,G)) and the destination group address in the packet maps to the RP listed in that (,,RP) entry. So a (,,RP) entry is basically one big aggregate for every group that hashes to that RP, which is so clean 🦋 PMBRs set up (,,RP) state for each RP in the domain's RPset. That state makes the PMBRs send (,*,RP) Join/Prune messages toward each of the active RPs in the domain. The result is distribution trees that carry all the data packets originated inside the PIM domain (and sent to the RPs) down to the PMBRs 🎀

PMBRs also deliver externally-generated packets to routers inside the PIM domain, and this part is giving main character energy 👑 At first, PMBRs wrap externally-originated packets (the ones received on DVMRP interfaces) in Register messages and unicast them to the corresponding RP inside the PIM domain. The Register message has a bit that says a border router originated it. The RP caches the originating PMBR's address in the route entry, so duplicate Registers from other PMBRs can get declined with a Register-Stop message. Bestie, that is so organized 😭

All PIM routers must be able to support (,,RP) state and interpret the associated Join/Prune messages. We describe how (,,RP) entries and messages are handled throughout this document. Detailed PIM Multicast Border Router (PMBR) functions, though, get their own separate interoperability document (see directory, http://catarina.usc.edu/pim/interop/) 🧚

2.8. Multicast data packet processing 🔥

Data packets get processed pretty much like other multicast schemes, so you'll recognize the vibe 💖 First the router does a longest match on the source and group address in the data packet. An (S,G) entry gets matched first if one exists. Otherwise it goes for a (,G) entry. If neither state exists, it tries a (,,RP) entry match like this: the router hashes on G to find the RP for group G, then looks for a (,*,RP) entry that has that RP address attached. If none of that exists, the packet gets dropped 💀 If a state does match, the router compares the interface the packet arrived on with the incoming interface field in the matched route entry. If the iif check fails, the packet gets dropped. If it passes, the packet is forwarded to every interface on the outgoing interface list ✨

Some special moves are needed so packets keep flowing smoothly while switching from the shared tree to the shortest-path tree. Specifically, when an (S,G) entry is matched, incoming packets get handled like this:

  1. If the SPT-bit is set, then:
    1. if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G).
    2. if the incoming interface is different than a matching (S,G) iif, the packet is discarded.
  2. If the SPT-bit is cleared, then:
    1. if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G). In addition, the SPT bit is set for that entry if the incoming interface differs from the incoming interface of the (,G) or (,*,RP) entry.
    2. if the incoming interface is different than a matching (S,G) iif, the incoming interface is tested against a matching (,G) or (,*,RP) entry. If the iif is the same as one of those, the packet is forwarded to the oif-list of the matching entry.
    3. Otherwise the iif does not match any entry for G and the packet is discarded.

Data packets never trigger prunes, but they can set off actions that do trigger prunes 🙈 For example, say router B in figure 3 decides to switch to SP-tree at step 3. It creates an (S,G) entry with the SPT-bit set to 0. When data packets from S arrive at interface 2 of B, B sets the SPT-bit to 1, since the iif for (*,G) is different from the one for (S,G). That is what triggers the sending of prunes towards the RP 🦋

2.9. Operation over Multi-access Networks 🌈

This section covers a few extra protocol mechanisms you need to run PIM over multi-access networks: Designated Router election, Assert messages to resolve parallel paths, and the Join/Prune-Suppression-Timer, which suppresses redundant Joins on multi-access networks 💜

Designated router election

When several routers are connected to a multi-access network, exactly one of them has to be picked as the designated router (DR) at any given moment. The DR is the one responsible for sending triggered Join/Prune and Register messages toward the RP 🫶

A simple DR election mechanism is used for both SM and traditional IP multicast routing. Neighboring routers send Hello messages to each other, and the sender with the largest IP address assumes the DR role. Every router connected to the multi-access LAN keeps sending Hellos periodically, so it can adapt to changes in router status 🔥

Parallel paths to a source or the RP--Assert process

If a router gets a multicast datagram on a multi-access LAN from a source whose (S,G) outgoing interface list includes the interface to that LAN, the packet must be a duplicate. In that case one single forwarder has to get elected ✨ Using Assert messages addressed to 224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN, the upstream routers can figure out which one will act as the forwarder. Downstream routers listen to the Asserts so they know which one won, and therefore where to send subsequent Joins 👑 That is typically the same as the downstream router's RPF (Reverse Path Forwarding) neighbor, but there are situations where it might not be, e.g., when multiple unicast routing protocols are running on that LAN 💅 The RPF neighbor for a particular source (or RP) is the next-hop router that packets get forwarded through on their way to that source (or RP). It's therefore considered a good path to accept packets from that source 🦋

The upstream router that gets elected is the one with the shortest distance to the source. So when a router receives a packet on an outgoing interface, it sends an Assert message on the multi-access LAN saying which metric it uses to reach the source of the data packet. The router with the smallest numerical metric wins, with ties broken by highest address, and becomes the forwarder. Every other upstream router deletes that interface from its outgoing interface list. Downstream routers do the same comparison too, just in case the forwarder is different from the RPF neighbor 🎀

The metric also comes with a metric preference value. This exists for when the upstream routers might run different unicast routing protocols 🧚 The numerically smaller metric preference always wins. The metric preference is treated as the high-order part of an assert metric comparison, so a metric value can only be compared with another metric value when both metric preferences are the same. A metric preference can be assigned per unicast routing protocol, and it needs to be consistent for all routers on the multi-access network ⭐

Asserts matter for (,G) entries too, because an RP-Tree and an SP-Tree for the same group may both cross the same multi-access network. When an assert is sent for a (,G) entry, the first bit in the metric preference (RPT-bit) is always set to 1. That says this path corresponds to the RP tree, and that the match must be done on (*,G) if it exists. The RPT-bit is always cleared for metric preferences that refer to SP-tree entries, which means an SP-tree path always looks better than an RP-tree path. When the SP-tree and RP-tree cross the same LAN, this mechanism gets rid of the duplicates that would otherwise travel over the LAN 🌸

If the packet, or the Assert message, matches on the oif for a (,,RP) entry, a (,G) entry gets created, and asserts happen as if the matching state were (,G) 💖

The DR might lose the (,G) Assert process to another router on the LAN if there are multiple paths to the RP through that LAN. From then on, the DR is no longer the last-hop router for local receivers, and it removes the LAN from its (,G) oif list. The winning router becomes the last-hop router and is responsible for sending (*,G) join messages to the RP 😭

Join/Prune suppression

Join/Prune suppression may be used on multi-access LANs to cut down on duplicate control message overhead, but it is not required for the protocol to perform correctly 🙈 If a Join/Prune message arrives and matches on the incoming interface for an existing (S,G), (,G), or (,*,RP) route entry, and the Holdtime in that message is greater than the recipient's own [Join/Prune-Holdtime] (with ties resolved in favor of the higher IP address), a timer called the Join/Prune-Suppression-Timer may be started in the recipient's route entry. That timer suppresses further Join/Prune messages. Once it expires, the recipient triggers a Join/Prune message and goes back to sending periodic Join/Prunes for that entry. The Join/Prune-Suppression-Timer should be restarted each time a Join/Prune message arrives with a higher Holdtime 🍓

2.10. Unicast Routing Changes 🧚

When unicast routing changes, an RPF check runs on all active (S,G), (,G), and (,,RP) entries, and every affected expected incoming interface gets updated 💅 In particular, if the new incoming interface shows up in the outgoing interface list, it gets deleted from that list. The previous incoming interface may get added back to the outgoing interface list by a later Join/Prune from downstream. Join/Prune messages received on the current incoming interface are ignored, but Join/Prune messages received on new interfaces or existing outgoing interfaces are not ignored 🌈 Other outgoing interfaces stay as they are until downstream routers explicitly prune them, or until they time out because the appropriate Join/Prune messages stop arriving ⏳ If the router has an (S,G) entry with the SPT-bit set, and the updated iif(S,G) does not differ from iif(,G) or iif(,,RP), the router resets the SPT-bit 🔥

The router must send a Join/Prune message with S in the Join list out any new incoming interfaces, to tell upstream routers that it expects multicast datagrams over that interface 🫶 It may also send a Join/Prune message with S in the Prune list out the old incoming interface, if that link is operational, to tell upstream routers that this part of the distribution tree is going away 🦋

2.11 PIM-SM for Inter-Domain Multicast 🌍

okay so future docs are gonna cover using PIM-SM as a backbone inter-domain multicast routing protocol. The big design questions mostly revolve around how RP information gets distributed and used for wide area, inter-domain groups. it's giving "to be continued" energy 💅

2.12 Security 🔐

bestie, all PIM control messages may use IPsec [6] to address security concerns. Security mechanisms are likely to get a glow-up in the near future ✨🛡️

3 Detailed Protocol Description 📚

this section walks through the protocol operations from the POV of one individual router implementation 🧠 For each message type, we explain how it gets generated and how it gets processed. main character router behavior 💁‍♀️

3.1 Hello 👋

Hello messages are how neighboring routers find each other 🫶

3.1.1 Sending Hellos 📣

Hellos go out periodically between PIM neighbors, every [Hello-Period] seconds. This tells routers which interfaces have PIM neighbors. Hello messages are multicast to 224.0.0.13 (the ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to [Hello-Holdtime], so neighbors know how long to keep the info valid. Hellos are sent on all types of communication links 🔗

3.1.2 Receiving Hellos 📥

When a router receives a Hello, it stores the IP address for that neighbor, sets its Neighbor-timer for the Hello sender to the Holdtime included in the Hello, and figures out the Designated Router (DR) for that interface. The highest IP addressed system gets elected DR 👑 Each Hello received updates the DR's address.

When a router that is the active DR gets a Hello from a new neighbor (aka from an IP address that isn't in the DR's neighbor table yet), the DR unicasts its most recent RP-set info to that new neighbor 💌

3.1.3 Timing out neighbor entries ⏱️

A periodic process runs to time out PIM neighbors that haven't sent Hellos. If the DR has gone down, a new DR gets chosen by scanning all neighbors on the interface and selecting the one with the highest IP address. If an interface has gone down, the router may optionally time out all PIM neighbors associated with that interface 🙈

3.2 Join/Prune 🌳

Join/Prune messages are how you join or prune a branch off the multicast distribution tree. A single message contains both a join and a prune list, and either one of them can be null. Each list holds a set of source addresses, showing the source-specific trees or shared tree the router wants to join or prune 🎯

3.2.1 Sending Join/Prune Messages 🚀

Join/Prune messages get merged, so a message sent to a particular upstream neighbor, N, includes all of the current joined and pruned sources that are reached via N. According to unicast routing, Join/Prune messages are multicast to all routers on multi-access networks, with the target address set to the next hop router toward S or RP. They're sent every [Join/Prune-Period] seconds. Later on we'll add mechanisms to rate-limit this control traffic hop by hop, so it doesn't cause excess overhead on small links. Certain events also trigger Join/Prune messages to go out right away ⚡

3.2.1.1 Periodic Join/Prune Messages ⏰

A router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor. A periodic Join/Prune message sent to a particular RPF neighbor gets built like this 🧩

  1. Each router determines the RP for a (*,G) entry by using the hash function described. The RP address (with RPT and WC bits set) is included in the join list of a periodic Join/Prune message under these conditions:
    1. The Join/Prune message is being sent to the RPF neighbor toward the RP for an active (*,G) or (*,*,RP) entry, and
    2. The outgoing interface list in the (*,G) or (*,*,RP) entry is non-NULL, or the router is the DR on the same interface as the RPF neighbor.
  2. A particular source address, S, is included in the join list with the RPT and WC bits cleared under these conditions:
    1. The Join/Prune message is being sent to the RPF neighbor toward S, and
    2. There exists an active (S,G) entry with the RPT-bit flag cleared, and
    3. The oif list in the (S,G) entry is not null.
  3. A particular source address, S, is included in the prune list with the RPT and WC bits cleared under these conditions:
    1. The Join/Prune message is being sent to the RPF neighbor toward S, and
    2. There exists an active (S,G) entry with the RPT-bit flag cleared, and
    3. The oif list in the (S,G) entry is null.
  4. A particular source address, S, is included in the prune list with the RPT-bit set and the WC bit cleared under these conditions:
    1. The Join/Prune message is being sent to the RPF neighbor toward the RP and there exists a (S,G) entry with the RPT-bit flag set and null oif list, or
    2. The Join/Prune message is being sent to the RPF neighbor toward the RP, there exists a (S,G) entry with the RPT-bit flag cleared and SPT-bit set, and the incoming interface toward S is different than the incoming interface toward the RP, or
    3. The Join/Prune message is being sent to the RPF neighbor toward the RP, and there exists a (*,G) entry and (S,G) entry for a directly connected source.
  5. The RP address (with RPT and WC bits set) is included in the prune list if:
    1. The Join/Prune message is being sent to the RPF neighbor toward the RP and there exists a (*,G) entry with a null oif list (see Section 3.5.2).

3.2.1.2 Triggered Join/Prune Messages ✨

Okay so besides the periodic messages 💖, these events will trigger Join/Prune messages, but only if, as a result, a) a new entry is created, or b) the oif list changes from null to non-null or non-null to null. The contents of triggered messages are the same as the periodic ones we just covered 🎀

  1. Receipt of an indication from IGMP that the state of directly-connected membership has changed (i.e., new members have just joined membership indication or all members have left), for a group G, may cause the last-hop router to build or modify corresponding (*,G) state. When IGMP indicates that there are no longer directly connected members, the oif is removed from the oif list if the oif timer is not running. A Join/Prune message is triggered if and only if a) a new entry is created, or b) the oif list changes from null to non-null or non-null to null, as follows:
    1. If the receiving router does not have a route entry for G, the router creates a (*,G) entry, copies the oif list from the corresponding (*,*,RP) entry (if it exists), and includes the interface included in the IGMP membership indication in the oif list. As always, the router never includes the entry's iif in the oif list. The router sends a Join/Prune message towards the RP with the RP address and RPT-bit and WC-bits set in the join list. Or,
    2. If a (S,G) RPT-bit or (*,G) entry already exists, the interface included in the IGMP membership indication is added to the oif list (if it was not included already).
  2. Receipt of a Join/Prune message for (S,G), (*,G) or (*,*,RP) will cause building or modifying corresponding state, and subsequent triggering of upstream Join/Prune messages, in the following cases:
    1. When there is no current route entry, the RP address included in the Join/Prune message is checked against the local RP-Set information. If it matches, an entry will be created and the new entry will in turn trigger an upstream Join/Prune message. If the router has no RP-Set information, it may discard the message, or optionally use the RP address included in the message.
    2. When the outgoing interface list of an (S,G) RPT-bit entry becomes null, the triggered Join/Prune message will contain S in the prune list.
    3. When there exists a (S,G) RPT-bit with null oif list, and an (*,G) Join/Prune message is received, the arriving interface is added to the oif list and a (*,G) Join/Prune message is triggered upstream.
    4. When there exists a (*,G) with null oif list, and a (*,*,RP) Join/Prune message is received, the receiving interface is added to the oif list and a (*,*,RP) Join/Prune message is triggered upstream.
  3. Receipt of a packet that matches on a (S,G) entry whose SPT-bit is cleared triggers the following if the packet arrived on the correct incoming interface and there is a (*,G) or (*,*,RP) entry with a different incoming interface: a) the router sets the SPT-bit on the (S,G) entry, and b) the router sends a Join/Prune message towards the RP with S and a set RPT-bit in the prune list.
  4. When a Join/Prune message is received for a group G, the prune list is checked. If the prune list contains a source or RP for which the receiving router has a corresponding active (S,G), (*,G) or (*,*,RP) entry, and whose iif is that on which the Join/Prune was received, then a join for (S,G), (*,G) or (*,*,RP) is triggered to override the prune, respectively. (This is necessary in the case of parallel downstream routers connected to a multi-access network.)
  5. When the RP fails, the RP will not be included in the Bootstrap messages sent to all routers in that domain. This triggers the DRs to send (*,G) Join/Prune messages towards the new RP for the group, as determined by the RP-Set and the hash function. As described earlier, PMBRs trigger (*,*,RP) joins towards each RP in the RP-Set.
  6. When an entry's Join/Prune-Suppression timer expires, a Join/Prune message is triggered upstream corresponding to that entry, even if the outgoing interface has not transitioned between null and non-null states.
  7. When the RPF neighbor changes (whether due to an Assert or changes in unicast routing), the router sets a random delay timer (the Random-Delay-Join-Timer) whose expiration triggers sending of a Join/Prune message for the asserted route entry to the Assert winner (if the Join/Prune Suppression timer has expired).
We do not trigger prunes onto interfaces based on data packets. Data packets that arrive on the wrong incoming interface are silently dropped. However, on point-to-point interfaces, triggered prunes may be sent as an optimization. 🙈

3.2.1.3 Fragmentation 💜

Okay, this one's a little spicy 🌶️ It's possible that a Join/Prune message built using the rules above could exceed the MTU of a network. In that case, the message can undergo semantic fragmentation, where information about different groups can be sent in different messages. However, if a Join/Prune message has to be fragmented, the complete prune list corresponding to a group G must be included in the same Join/Prune message as the associated RP-tree Join for G. If that kind of semantic fragmentation isn't possible, IP fragmentation should be used between the two neighboring hops. Bestie, that's the whole fragmentation story 🦋

3.2.2 Receiving Join/Prune Messages ✨

okay so here's what happens when a router gets a Join/Prune message 💅

The router first notes the interface the PIM message arrived on, and we'll call that I. Then it checks whether the message was actually meant for it, which means its own address shows up in the Unicast Upstream Neighbor Router field 👀 (if the router is on a multiaccess LAN, the message could be meant for a different router, so this check matters). If the Join/Prune is for this router, these actions are taken.

For each group address G in the message, the join list gets processed like this. Each address in the join list is called Sj, and Sj means the RP when both the RPT-bit and WC-bit are set. For each Sj in the join list:

  1. If an address, Sj, in the join list has the RPT-bit and WC-bit set, then Sj is the RP address the downstream routers are using, and these steps happen:
    1. If Sj isn't the same as this router's RP mapping for G, the router may ignore the Join/Prune for that group entry. If the router has no RP-Set information at all, it may use the address Sj from the message as the RP for the group.
    2. If Sj is the same as this router's RP mapping for G, the router adds I to the outgoing interface list of the (*,G) route entry (and if there's no (*,G) entry yet, it creates one first). It then sets the Oif-timer for that interface to the Holdtime from the message, and the Oif-Deletion-Delay for that interface gets set to 1/3rd of that Holdtime 🌸

If a (*,*,RP) entry exists for the RP tied to G, then the oif list of the newly created (*,G) entry is copied from that (*,*,RP) entry.

  1. For each (Si,G) entry tied to group G, if Si isn't in the prune list and I isn't the iif, then interface I gets added to the oif list. The Oif-timer for that interface in each affected entry is increased (never decreased) to the Holdtime from the message, and if that timer went up, the Oif-Deletion-Delay is set to 1/3rd of the Holdtime.

If the group address in the message is *, then every (*,G) and (S,G) entry whose group address hashes to the RP named in the (*,*,RP) Join/Prune message gets updated to match. A * in the group field is represented by group address 224.0.0.0 with a group mask length of 4, which is how you know it's a (*,*,RP) Join 🧚

  1. If the (Si,G) entry has its RPT-bit flag set to 1 and its oif list is the same as the (*,G) oif list, then the (Si,G)RPT-bit entry gets deleted 🗑️
  2. The incoming interface is set to the interface used to send unicast packets to the RP in the (*,G) route entry, which is the RPF interface toward the RP.
  1. For each address, Sj, in the join list whose RPT-bit and WC-bit are not set, and for which there's no existing (Sj,G) route entry, the router starts one. It creates an (S,G) entry and copies all outgoing interfaces from the (S,G)RPT-bit entry if it exists. If there's no (S,G) entry, the oif list gets copied from the (*,G) entry. And if there's no (*,G) entry either, the oif list is copied from the (*,*,RP) entry, if one exists. In every case, the iif of the (S,G) entry is always left out of the oif list 🙅‍♀️
    1. The outgoing interface for (Sj,G) is set to I. The incoming interface for (Sj,G) is set to the interface used to send unicast packets to Sj (aka the RPF neighbor).
    2. If the interface used to reach Sj is the same as I, that's an error (or a unicast routing change), and the Join/Prune must not be processed.
  2. For each address, Sj, in the join list, for which there's already an existing (Sj,G) route entry:
    1. If the RPT-bit isn't set for Sj in the message but the RPT-bit flag is set on the existing (Sj,G) entry, the router clears the RPT-bit flag on that entry, sets the incoming interface to point toward Sj, and sends a Join/Prune matching that entry out through the new incoming interface. And
    2. If I isn't the same as the existing incoming interface, the router adds I to the list of outgoing interfaces.
    3. The Oif-timer for I is increased (never decreased) to the Holdtime from the message. If that timer went up, the Oif-Deletion-Delay for that interface is set to 1/3rd of the Holdtime.
    4. The (Sj,G) entry's SPT bit gets cleared until data comes down the shortest path tree 🌳

For each group address G in the message, the prune list gets processed too. Each address in the prune list is called Sp, and Sp means the RP when both the RPT-bit and WC-bit are set. For each Sp in the prune list:

  1. For each address, Sp, in the prune list whose RPT-bit and WC-bit are both cleared:
    1. If there's an existing (Sp,G) route entry, the router lowers the Oif-timer for I to its Oif-Deletion-Delay. That gives other downstream routers on a multi-access LAN a chance to override the prune 🫶 On point-to-point links, though, the oif-timer expires immediately.
    2. If the router has a current (*,G) or (*,*,RP) route entry, and the existing (Sp,G) entry has its RPT-bit flag set to 1, then this (Sp,G)RPT-bit entry is kept (not deleted), even if its outgoing interface list is null.
  2. For each address, Sp, in the prune list whose RPT-bit is set and whose WC-bit is cleared:
    1. If there's an existing (Sp,G) route entry, the router lowers that entry's Oif-timer for I to its Oif-Deletion-Delay, so other downstream routers on a multi-access LAN can still override the prune. On point-to-point links, the oif-timer expires immediately.
    2. If the router has a current (*,G) or (*,*,RP) route entry, and the existing (Sp,G) entry has its RPT-bit flag set to 1, then this (Sp,G)RPT-bit entry isn't deleted, and its Entry-timer is restarted, even if its outgoing interface list is null.
    3. If (*,G), or the matching (*,*,RP), state exists but there's no (Sp,G) entry, an (Sp,G)RPT-bit entry gets created. Its outgoing interface list is copied from the (*,G) or (*,*,RP) entry, with the interface I (where the prune came in) removed. Packets from the pruned source Sp match this state and aren't forwarded toward the pruned receivers 🚫
    4. If there's an (Sp,G) entry, with or without the RPT-bit set, the oif-timer for I expires and the Entry-timer is restarted.
  3. For each address, Sp, in the prune list whose RPT-bit and WC-bit are both set:
    1. If there's an existing (*,G) entry with Sp as the RP for G, the router lowers that entry's Oif-timer for I to its Oif-Deletion-Delay, letting other downstream routers on a multi-access LAN override the prune. On point-to-point links, the oif-timer expires immediately.
    2. If the matching (*,*,RP) state exists but there's no (*,G) entry, a (*,G) entry is created. Its outgoing interface list is copied from the (*,*,RP) entry, with the interface I (where the prune arrived) removed.

For any new (S,G), (*,G) or (*,*,RP) entry created by an incoming Join/Prune message, the SPT-bit gets cleared (and if a Join/Prune-Suppression timer is used, it's left off) 🧹

If the entry has a Join/Prune-Suppression timer attached, and the received Join/Prune doesn't name this router as its target, then the receiving router looks at the join and prune lists to see if any addresses in them completely- match existing (S,G), (*,G), or (*,*,RP) state that the router is currently scheduling Join/Prune messages for. An element on the join or prune list completely-matches a route entry only if both the IP addresses and the RPT-bit flag are the same 🎀 If the incoming message completely matches an existing (S,G), (*,G), or (*,*,RP) entry, and it arrived on the iif for that entry, then the router compares the Holdtime in the message to its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime] is lower, the Join/Prune-Suppression-Timer starts at the [Join/Prune-Suppression-Timeout]. If the [Join/Prune-Holdtime] values are equal, the tie goes to whichever Join/Prune Message originator has the higher IP address. When the Join/Prune timer expires, the router triggers a Join/Prune message for the matching entry(ies) 💜

3.3 Register and Register-Stop 🌈

okay so when a source first starts sending to a group, its packets get wrapped up in Register messages and sent to the RP 📦 If the data rate justifies source-specific paths, the RP sets up source-specific state and starts sending (S,G) Join/Prune messages toward the source, with S in the join list 🦋

3.3.1 Sending Registers and Receiving Register-Stops ✨

okay so here's how Register messages get sent 💅

  1. When a DR receives a packet from a directly connected source, S
    1. If there is no corresponding (S,G) entry, and the router has RP-Set information, the DR creates one with the Register-Suppression-timer turned off and the RP address set according to the hash function mapping for the corresponding group. The oif list is copied from existing (*,G) or (*,*,RP) entries, if they exist. The iif of the (S,G) entry is always excluded from the oif list.
    2. If there is a (S,G) entry in existence, the DR simply restarts the corresponding Entry-timer.

When a PMBR (e.g., a router that connects the PIM-SM region to a dense mode region running DVMRP or PIM-DM) receives a packet from a source in the dense mode region, the router treats the packet as if it were from a directly connected source. A separate document will describe the details of interoperability. 🌈

  1. If the new or previously-existing (S,G) entry's Register-Suppression-timer is not running, the data packet is encapsulated in a Register message and unicast to the RP for that group. The data packet is also forwarded according to (S,G) state in the DR if the oif list is not null, since a receiver may join the SP-tree while the DR is still registering to the RP. 🦋
  2. If the (S,G) entry's Register-Suppression-timer is running, the data packet is not sent in a Register message. It is just forwarded according to the (S,G) oif list. 🌸

When the DR receives a Register-Stop message, it restarts the Register-Suppression-timer in the corresponding (S,G) entry(ies) at [Register-Suppression-Timeout] seconds. If there is data to be registered, the DR may send a null Register (a Register message with a zero-length data portion in the inner IP packet) to the RP, [Probe-Time] seconds before the Register-Suppression-timer expires, to avoid sending occasional bursts of traffic to an RP unnecessarily. 🫶

3.3.2 Receiving Register Messages and Sending Register-Stops 🎀

When a router (i.e., the RP) receives a Register message, the router does the following:

  1. Decapsulates the data packet, and checks for a corresponding (S,G) entry.
    1. If a (S,G) entry with cleared (0) SPT bit exists, and the received Register does not have the Null-Register-Bit set to 1, the packet is forwarded, and the SPT bit is left cleared (0). If the SPT bit is 1, the packet is dropped, and Register-Stop messages are triggered. Register-Stops should be rate-limited (in an implementation-specific manner) so that no more than a few are sent per round trip time. This prevents a high datarate stream of packets from triggering a large number of Register-Stop messages between the time that the first packet is received and the time when the source receives the first Register-Stop. 🔥
    2. If there is no (S,G) entry, but there is a (*,G) entry, and the received Register does not have the Null-Register-Bit set to 1, the packet is forwarded according to the (*,G) entry.
    3. If there is a (*,*,RP) entry but no (*,G) entry, and the Register received does not have the Null-Register-Bit set to 1, a (*,G) or (S,G) entry is created, and the oif list is copied from the (*,*,RP) entry to the new entry. The packet is forwarded according to the created entry.
    4. If there is no G or (*,*,RP) entry corresponding to G, the packet is dropped, and a Register-Stop is triggered.
    5. A "Border bit" bit is added to the Register message, to facilitate interoperability mechanisms. PMBRs set this bit when registering for external sources (see Section 2.7). If the "Border bit" is set in the Register, the RP does the following:
      1. If there is no matching (S,G) state, but there exists a (*,G) or (*,*,RP) entry, the RP creates a (S,G) entry, with a PMBR field. This field holds the source of the Register (i.e., the outer IP address of the register packet). The RP triggers a (S,G) join towards the source of the data packet, and clears the SPT bit for the (S,G) entry. If the received Register is not a null Register, the packet is forwarded according to the created state. Else,
      2. If the PMBR field for the corresponding (S,G) entry matches the source of the Register packet, and the received Register is not a null Register, the decapsulated packet is forwarded to the oif list of that entry. Else,
      3. If the PMBR field for the corresponding (S,G) entry matches the source of the Register packet, the decapsulated packet is forwarded to the oif list of that entry, else
      4. The packet is dropped, and a Register-stop is triggered towards the source of the Register.

The (S,G) Entry-timer is restarted by Registers arriving from that source to that group. ⏰

  1. If the matching (S,G) or (*,G) state contains a null oif list, the RP unicasts a Register-Stop message to the source of the Register message. In the latter case, the source-address field, within the Register-Stop message, is set to the wildcard value (all 0's). This message is not processed by intermediate routers, hence no (S,G) state is constructed between the RP and the source. 🙈
  2. If the Register message arrival rate warrants it and there is no existing (S,G) entry, the RP sets up a (S,G) route entry with the outgoing interface list, excluding iif(S,G), copied from the (*,G) outgoing interface list. Its SPT-bit is initialized to 0. If a (*,G) entry does not exist, but there exists a (*,*,RP) entry with the RP corresponding to G, the oif list for (S,G) is copied (excluding the iif) from that (*,*,RP) entry.

A timer (Entry-timer) is set for the (S,G) entry, and this timer is restarted by receipt of data packets for (S,G). The (S,G) entry causes the RP to send a Join/Prune message for the indicated group towards the source of the Register message.

If the (S,G) oif list becomes null, Join/Prune messages will not be sent towards the source, S. 💜

3.4 Multicast Data Packet Forwarding 🧚

Processing a multicast data packet involves the following steps:

  1. Lookup route state based on a longest match of the source address, and an exact match of the destination address in the data packet. If neither S nor G finds a longest match entry, and the RP for the packet's destination group address has a corresponding (*,*,RP) entry, then the longest match does not require an exact match on the destination group address. In summary, the longest match is performed in the following order: (1) (S,G), (2) (*,G). If neither is matched, then a lookup is performed on (*,*,RP) entries.
  2. If the packet arrived on the interface found in the matching entry's iif field, and the oif list is not null:
    1. Forward the packet to the oif list for that entry, and restart the Entry-timer if the matching entry is (S,G). Optionally, the (S,G) Entry-timer may be restarted by periodic checking of the matching packet count.
    2. If the entry is a (S,G) entry with a cleared SPT-bit, and a (*,G) or associated (*,*,RP) also exists whose incoming interface is different than that for (S,G), set the SPT-bit for the (S,G) entry and trigger an (S,G) RPT-bit prune towards the RP.
    3. If the source of the packet is a directly-connected host and the router is the DR on the receiving interface, check the Register-Suppression-timer associated with the (S,G) entry. If it is not running, then the router encapsulates the data packet in a Register message and sends it to the RP.

This covers the common case of a packet arriving on the RPF interface to the source or RP and being forwarded to all joined branches. It also detects when packets arrive on the SP-tree, and triggers their pruning from the RP-tree. If it is the DR for the source, it sends data packets encapsulated in Registers to the RPs. 🔥

  1. If the packet matches an entry but did not arrive on the interface found in the entry's iif field, check the SPT-bit of the entry. If the SPT-bit is set, drop the packet. If the SPT-bit is cleared, then lookup the (*,G) or (*,*,RP) entry for G. If the packet arrived on the iif found in (*,G), or the corresponding (*,*,RP), forward the packet to the oif list of the matching entry. This covers the case when a data packet matches on an (S,G) entry for which the SP-tree has not yet been completely established upstream. 🌈
  2. If the packet does not match any entry, but the source of the data packet is a local, directly-connected host, and the router is the DR on a multi-access LAN and has RP-Set information, the DR uses the hash function to determine the RP associated with the destination group, G. The DR creates a (S,G) entry, with the Register-Suppression-timer not running, encapsulates the data packet in a Register message, and unicasts it to the RP. 💖
  3. If the packet does not match any entry, and it is not a local host or the router is not the DR, drop the packet. 💀

3.4.1 Data triggered switch to shortest path tree (SP-tree) 🦋

Different criteria can be applied to trigger switching over from the RP-based shared tree to source-specific, shortest path trees.

One proposed example is to do so based on data rate. For example, when a (*,G), or corresponding (*,*,RP), entry is created, a data rate counter may be initiated at the last-hop routers. The counter is incremented with every data packet received for directly connected members of an SM group, if the longest match is (*,G) or (*,*,RP). If and when the data rate for the group exceeds a certain configured threshold (t1), the router initiates source-specific data rate counters for the following data packets. Then, each counter for a source is incremented when packets matching on (*,G), or (*,*,RP), are received from that source. If the data rate from the particular source exceeds a configured threshold (t2), a (S,G) entry is created and a Join/Prune message is sent towards the source. If the RPF interface for (S,G) is not the same as that for (*,G) or (*,*,RP), then the SPT-bit is cleared in the (S,G) entry. 🍓

Other configured rules may be enforced to cause or prevent establishment of (S,G) state.

3.5 Assert 🌸

Asserts are used to resolve which of the parallel routers connected to a multi-access LAN is responsible for forwarding packets onto the LAN. 👑

3.5.1 Sending Asserts ✨

okay so this is when asserts actually get sent 💅 these rules kick in when a multicast packet shows up on an outgoing multi-access interface "I" of an existing (S,G) entry 👀

  1. Run a unicast routing table lookup on the source IP address from the data packet, then send an assert on interface "I" for that source IP address 🎯 Include the metric preference of the routing protocol and the metric from that routing table lookup 💖
  2. If no route is found, use the metric preference 0x7fffffff and the metric 0xffffffff 🙈

When an assert gets sent for a (*,G) entry, the first bit of the metric preference (aka the RPT-bit) gets set to 1, which tells everyone the data packet is routed down the RP-tree 🌳

Asserts should be rate-limited, and how you do that is up to the implementation 🚦

3.5.2 Receiving Asserts 🔍

when an Assert comes in, the router does a longest match on the source and group address in the Assert message ✨ then it checks the first bit of the metric preference, the RPT-bit 👀

  1. If the RPT-bit is set, the router tries to match (*,G) or (*,*,RP) entries first. If nothing matches, it ignores the Assert 🙅‍♀️
  2. If the RPT-bit is not set in the Assert, the router tries to match (S,G) entries first. If nothing matches, the router goes for (*,G) or (*,*,RP) entries 💫

3.5.2.1 Receiving Asserts on an entry's outgoing interface 💁‍♀️

if the interface that received the Assert is in the oif list of the matched entry, this router handles the Assert like this:

  1. If the Assert's RPT-bit is set and the matching entry is (*,*,RP), the router creates a (*,G) entry. If the Assert's RPT-bit is cleared and the matching entry is (*,G) or (*,*,RP), the router creates an (S,G)RPT-bit entry. Otherwise, no new entry gets created because of the Assert 🙌
  2. Next, the router compares the metric values in the Assert with the metric values on the matched entry. The RPT-bit and metric preference (in that order) act as the high-order part of the Assert metric comparison. If the Assert's value is less than the router's value (ties go to the higher IP address), delete the interface from the entry. When that deletion happens for a (*,G) or (*,*,RP) entry, the interface also gets deleted from any associated (S,G)RPT-bit or (*,G) entries, respectively. The Entry-timer for the affected entries gets restarted ⏰
  3. If the router won the election, it keeps the interface in its outgoing interface list and acts as the forwarder for the LAN 🏆

The winner sends an Assert message with its own metric out that interface 📣 That makes other routers on the LAN prune that interface from their route entries 🧹 The winner sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit entry was matched.

3.5.2.2 Receiving Asserts on an entry's incoming interface 🧐

if the Assert arrives on the incoming interface of an existing (S,G), (*,G), or (*,*,RP) entry, it gets processed like this. If the Assert message does not match the entry exactly, it gets ignored (i.e, longest-match is not used in this case, bestie 🙃). If it does match exactly, then:

  1. Downstream routers will pick the upstream router with the smallest metric preference and metric as their RPF neighbor. If the metrics tie, the highest IP address breaks it. This matters because downstream routers send their subsequent Joins/Prunes (in SM) to the correct neighbor 🎯 An Assert-timer starts when the RPF neighbor changes to the Assert winner. When that timer expires, the router resets its RPF neighbor using its unicast routing tables, so it can keep up with network dynamics and router failures 🔄
  2. If the downstream routers have downstream members, and the Assert caused the RPF neighbor to change, the downstream routers must trigger a Join/Prune message to tell the upstream router that packets are to be forwarded on the multi-access network 📨

3.6. Candidate-RP-Advertisements and Bootstrap messages 🎀

Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM messages unicast to the BSR by routers configured as Candidate-RPs (C-RPs) 📬

Bootstrap messages are periodic PIM messages from the Bootstrap router (BSR) in a domain, forwarded hop-by-hop to spread the current RP-set to every router in that domain 🥾

Bootstrap messages also give us a simple way to elect the BSR for the domain 👑 The Candidate BSR (C-BSR) with the highest BSR-priority and IP address (the preferred BSR) wins. We recommend that every router configured as a C-RP also be configured as a C-BSR. Sections 3.6.2 and 3.6.3 explain how Bootstrap messages do double duty for BSR election and RP-Set distribution 🧠

There's a Finite State Machine description of the BSR election and RP-Set distribution mechanisms in Appendix II 🗺️

3.6.1 Sending Candidate-RP-Advertisements 💌

C-RPs periodically unicast C-RP-Advs to the BSR for their domain. How often they send these is up to local configuration at the C-RP ⏱️

Candidate-RP-Advertisements carry group address and group mask fields 🎭 That lets the advertising router limit its advertisement to certain prefixes or scopes of groups. The advertising router may enforce that scope when it receives Registers or Join/Prune messages. C-RPs should send C-RP-Adv messages with the Authoritative bit cleared 🚫

3.6.2 Receiving C-RP-Advs and Originating Bootstrap 📥

when a router gets a C-RP-Adv, it does the following:

  1. If the router is not the elected BSR, it ignores the message, else
  2. The BSR adds the RP address to its local pool of candidate RPs, based on the associated group prefix(es) in the C-RP-Adv message. The Holdtime from the C-RP-Adv gets stored with that RP too, to be included later in the Bootstrap message. The BSR may apply a local policy to limit how many Candidate RPs go in the Bootstrap message. The BSR may override the prefix in a C-RP-Adv unless the Authoritative bit in that C-RP-Adv is set 💅

The BSR keeps an RP-timer for each RP in its local RP-set ⏲️ The RP-timer starts at the Holdtime from that RP's C-RP-Adv. When the timer runs out, that RP gets removed from the RP-set. Fresh C-RP-Advs from that RP restart the RP-timer 🔁

The BSR also uses its Bootstrap-timer to send Bootstrap messages on a schedule 📅 When the Bootstrap-timer expires, the BSR originates an Bootstrap message on each of its PIM interfaces. The message goes out with a TTL of 1 to the `ALL-PIM-ROUTERS' group. In steady state, the BSR keeps originating Bootstrap messages periodically. At startup, the Bootstrap-timer is set to [Bootstrap-Timeout], so the first Bootstrap message only gets originated when and if that timer expires. For timer details, check Section 3.6.3 🕰️ A DR unicasts a Bootstrap message to each new PIM neighbor, i.e., after the DR receives that neighbor's Hello message (it does this even if the new neighbor becomes the DR) 💌

The Bootstrap message is split into sets of {group-prefix,RP-Count,RP-addresses} 🧩 For each RP-address, the matching Holdtime goes in the RP-Holdtime field. The format lets the Bootstrap message do semantic fragmentation if its length goes past the packet maximum boundaries (see Section 4). Still, we recommend against configuring a large number of routers as C-RPs, so there's less semantic fragmentation to deal with 🙏

3.6.3 Receiving and Forwarding Bootstrap 🎬

Each router keeps a Bootstrap-timer, set to [Bootstrap-Timeout] at startup ⏰

When a router receives a Bootstrap message sent to the `ALL-PIM-ROUTERS' group, it does the following:

  1. If the message was not sent by the RPF neighbor toward the BSR address included, the message is dropped. Else
  2. If the included BSR is not preferred over, and not equal to, the currently active BSR:
    1. If the Bootstrap-timer has not yet expired, or if the receiving router is a C-BSR, then the Bootstrap message is dropped. Else
    2. If the Bootstrap-timer has expired and the receiving router is not a C-BSR, the receiving router stores the RP-Set and the BSR address and priority from the message, and restarts the timer by setting it to [Bootstrap-Timeout]. The Bootstrap message is then forwarded out all PIM interfaces, except the one it arrived on, to the `ALL-PIM-ROUTERS' group, with a TTL of 1.
    3. If the Bootstrap message includes a BSR address that is preferred over, or equal to, the currently active BSR, the router restarts its Bootstrap-timer at [Bootstrap-Timeout] seconds. and stores the BSR address and RP-Set information. The Bootstrap message is then forwarded out all PIM interfaces, except the one it arrived on, to the `ALL-PIM-ROUTERS' group, with a TTL of 1.
    4. If the receiving router has no current RP set information and the Bootstrap was unicast to it from a directly connected neighbor, the router stores the information as its new RP-set. This covers the startup condition when a newly booted router gets the RP-Set and BSR address from its DR 🚀

When a router gets a new RP-Set, it checks whether each RP referenced by existing state (i.e., by (*,G), (*,*,RP), or (S,G)RPT-bit entries) is in the new RP-Set 🔍 If an RP isn't in the new RP-set, that RP is considered unreachable 💀 and the hash algorithm (see below) is re-run for each group with locally active state that previously hashed to that RP. That spreads those groups across the remaining RPs 🌈 When the new RP-Set includes a new RP, the new RP's value is calculated for each group covered by that C-RP's Group-prefix. Any group where the new RP's value is greater than the previously active RP's value gets switched over to the new RP 🔀

3.7 Hash Function 🎀

okay so the hash function is how every router in a domain agrees on the SAME RP for a group, like a group chat picking one bestie 💖. It maps a group to one of the C-RPs in the RP-Set, but only the C-RPs whose Group- prefix covers G even get a look-in ✨. It takes the group address plus the Candidate RP addresses and spits out one RP address.

The protocol needs every router to hash to the same RP within a domain (except for transients 👀). The following hash function must be used in each router:

  1. For each RP address C(i) in the RP-Set, whose Group-prefix covers G, compute a value:
Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31

where M is a hash-mask included in Bootstrap messages. This hash-mask lets a small number of consecutive groups (e.g., 4) always hash to the same RP 🧚. For instance, hierarchically-encoded data can be sent on consecutive group addresses to get the same delay and fate-sharing characteristics 🌸.

  1. The candidate with the highest resulting value is then chosen as the RP for that group, and its identity and hash value are stored with the entry created 💅.

Ties between C-RPs having the same hash value, are broken in advantage of the highest address.

The hash function algorithm is invoked by a DR, upon reception of a packet, or IGMP membership indication, for a group, for which the DR has no entry. It is invoked by any router that has (*,*,RP) state when a packet is received for which there is no corresponding (S,G) or (*,G) entry. Furthermore, the hash function is invoked by all routers upon receiving a (*,G) or (*,*,RP) Join/Prune message 🫶.

3.8 Processing Timer Events ⏰

okay bestie, this is where we list every timer that was discussed or implied 📋. Some critical timer events aren't tied to sending or receiving messages, so they aren't fully covered by the earlier subsections 🙈.

Timers are implemented in an implementation-specific manner. For example, a timer may count up or down, or may simply expire at a specific time. Setting a timer to a value T means that it will expire after T seconds ⏳.

Each (S,G), (*,G), and (*,*,RP) route entry has multiple timers associated with it: one for each interface in the outgoing interface list, one for the multicast routing entry itself, and one optional Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has an Assert-timer and a Random-Delay-Join-Timer for use with Asserts. In addition, DR's have a Register- Suppression-timer for each (S,G) entry and every router has a single Join/Prune-timer. (A router may optionally keep separate Join/Prune-timers for different interfaces or route entries if different Join/Prune periods are desired.) 💜

  • [Join/Prune-Timer] This timer is used for periodically sending aggregate Join/Prune messages. To avoid synchronization among routers booting simultaneously, it is initially set to a random value between 1 and [Join/Prune-Period]. When it expires, the timer is immediately restarted to [Join/Prune-Period]. A Join/Prune message is then sent out each interface. This timer should not be restarted by other events 🕰️.
  • [Join/Prune-Suppression-Timer (kept per route entry)] A route entry's (optional) Join/Prune-Suppression-Timer may be used to suppress duplicate joins from multiple downstream routers on the same LAN. When a Join message is received from a neighbor on the entry's incoming interface in which the included Holdtime is higher than the router's own [Join/Prune-Holdtime] (with ties broken by higher IP address), the timer is set to [Join/Prune-Suppression-Timeout], with some random jitter introduced to avoid synchronization of triggered Join/Prune messages on expiration. (The random timeout value must be < 1.5 * [Join/Prune-Period] to prevent losing data after 2 dropped Join/Prunes.) The timer is restarted every time a subsequent Join/Prune message (with higher Holdtime/IP address) for the entry is received on its incoming interface. While the timer is running, Join/Prune messages for the entry are not sent. This timer is idle (not running) for point-to-point links 🤓.
  • [Oif-Timer (kept per oif for each route entry)] A timer for each oif of a route entry is used to time out that oif. Because some of the outgoing interfaces in an (S,G) entry are copied from the (*,G) outgoing interface list, they may not have explicit (S,G) join messages from some of the downstream routers (i.e., where members are joining to the (*,G) tree only). Thus, when an Oif-timer is restarted in a (*,G) entry, the Oif-timer is restarted for that interface in each existing (S,G) entry whose oif list contains that interface. The same rule applies to (*,G) and (S,G) entries when restarting an Oif-timer on a (*,*,RP) entry 🦋.

The following table shows its usage when first adding the oif to the entry's oiflist, when it should be restarted (unless it is already higher), and when it should be decreased (unless it is already lower).

Set to                   | When                         | Applies  to
-------------------------|------------------------------|------------
included Holdtime        | adding oif off Join/Prune    | (S,G) (*,G)
                         |                              | (*,*,RP)



Increased (only) to      | When                         |  Applies to
-------------------------|------------------------------|------------
included  Holdtime       | received Join/Prune          | (S,G) (*,G)
                         |                              | (*,*,RP)
                         |                              |
Value of (*,*,RP)        | (*,*,RP) oif-timer restarted | (S,G) (*,G)
   oif-timer             |                              |
                         |                              |
Value of (*,G)           | (*,G) oif-timer restarted    | (S,G)
   oif-timer             |                              |


Decreased (only) to      |  When                        | Applies  to
-------------------------|------------------------------|------------
Oif-Deletion-Delay       | prune received               | (S,G) (*,G)

When the timer expires, the oif is removed from the oiflist if there are no directly-connected members. When deleted, the oif is also removed in any associated (S,G) or (*,G) entries.

  • [Entry-Timer (kept per route entry)] A timer for each route entry is used to time out that entry. The following table summarizes its usage when first adding the oif to the entry's oiflist, and when it should be restarted (unless it is already higher).
Set to                |  When                    | Applies to
----------------------|--------------------------|------------
[Data- Timeout]       | created off data packet  | (S,G)
                      |                          |
included Holdtime     | created off Join/Prune   | (S,G) (*,G)
(*,*,RP)


Increased  (only)  to |  When                    | Applies to
----------------------|--------------------------|------------
[Data-Timeout]        | receiving  data  packets | (S,G)no RPT-bit
                      |                          |
Value of oif-timer    | any oif-timer restarted  | (S,G)RPT-bit (*,G)
                      |                          | (*,*,RP)
                      |                          |
[Assert-Timeout]      | assert received          | (S,G)RPT-bit
                      |                          | (*,G)w/null oif

When the timer expires, the route entry is deleted; if the entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT-bit entries are also deleted 💀.

  • [Register-Suppression-Timer (kept per (S,G) route entry)] An (S,G) route entry's Register-Suppression-Timer is used to suppress registers when the RP is receiving data packets natively. When a Register-Stop message for the entry is received from the RP, the timer is set to a random value in the range 0.5 * [Register-Suppression-Timeout] to 1.5 * [Register-Suppression-Timeout]. While the timer is running, Registers for that entry will be suppressed. If null registers are used, a null register is sent [Probe-Time] seconds before the timer expires 🧁.
  • [Assert-Timer (per (S,G) or (*,G) route entry)] The Assert-Timer for an (S,G) or (*,G) route entry is used for timing out Asserts received. When an Assert is received and the RPF neighbor is changed to the Assert winner, the Assert-Timer is set to [Assert-Timeout], and is restarted to this value every time a subsequent Assert for the entry is received on its incoming interface. When the timer expires, the router resets its RPF neighbor according to its unicast routing table 🗺️.
  • [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)] The Random-Delay-Join-Timer for an (S,G) or (*,G) route entry is used to prevent synchronization among downstream routers on a LAN when their RPF neighbor changes. When the RPF neighbor changes, this timer is set to a random value between 0 and [Random-Delay-Join-Timeout] seconds. When the timer expires, a triggered Join/Prune message is sent for the entry unless its Join/Prune-Suppression-Timer is running 🎲.

3.8.2 Timers relating to neighbor discovery 👋

  • [Hello-Timer] This timer is used to periodically send Hello messages. To avoid synchronization among routers booting simultaneously, it is initially set to a random value between 1 and [Hello-Period]. When it expires, the timer is immediately restarted to [Hello-Period]. A Hello message is then sent out each interface. This timer should not be restarted by other events 💖.
  • [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer for each neighbor is used to time out the neighbor state. When a Hello message is received from a new neighbor, the timer is initially set to the Holdtime included in the Hello message (which is equal to the neighbor's value of [Hello-Holdtime]). Every time a subsequent Hello is received from that neighbor, the timer is restarted to the Holdtime in the Hello. When the timer expires, the neighbor state is removed 🥹.

3.8.3. Timers relating to RP information ✨

  • [C-RP-Adv-Timer (C-RP's only)] Okay so, routers set up as candidate RP's use this timer to send C-RP-Adv messages on a regular schedule 💌. To avoid synchronization among routers that boot at the same time (nobody wants that drama 🙈), the timer starts at a random value between 1 and [C-RP-Adv-Period]. When it expires, it restarts immediately at [C-RP-Adv-Period], and then a C-RP-Adv message gets sent to the elected BSR. This timer SHOULD NOT be restarted by other events.
  • [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR keeps a timer for each RP in the RP-Set so it can check that every RP is still alive 💖. When a C-RP gets added to the RP-Set, its timer is set to the Holdtime included in that C-RP's C-RP-Adv message, which is equal to that C-RP's [RP-Holdtime] value. Every time a later C-RP-Adv comes in from that RP, the timer restarts to the Holdtime in the C-RP-Adv. When the timer expires, the RP gets removed from the RP-Set included in Bootstrap messages.
  • [Bootstrap-Timer] This timer is used by the BSR to originate Bootstrap messages on a schedule, and by other routers to time out the BSR (see 3.6.3) 🧚. It starts at [Bootstrap-Timeout]. A C-BSR restarts it to [Bootstrap-Timeout] when it gets a Bootstrap message from a preferred router. When it expires, the C-BSR originates a Bootstrap message and restarts the timer to [Bootstrap-Period]. Routers that aren't configured as C-BSR's restart it to [Bootstrap-Timeout] when they get a Bootstrap message from the elected or a more preferred BSR. While it's running, they ignore Bootstrap messages from non-preferred C-BSRs. 🫶

3.8.4. Default timer values 🎀

Most of the default timeout values for state information are 3.5 times the refresh period. For example, Hellos refresh Neighbor state and the default Hello-timer period is 30 seconds, so a default Neighbor-timer duration of 105 seconds is included in the Holdtime field of the Hellos. In order to improve convergence, however, the default timeout value for information related to RP liveness and Bootstrap messages is 2.5 times the refresh period. This part is giving tight planning 📅

In this version of the spec, we suggest particular numerical timer settings. A future version of the specification will specify a mechanism for timer values to be scaled based upon observed network parameters. ⭐

  • [Join/Prune-Period] This is the interval between sending Join/Prune messages. {Default: 60 seconds.} This value MAY be set to take into account such things as the configured bandwidth and expected average number of multicast route entries for the attached network or link (e.g., the period would be longer for lower-speed links, or for routers in the center of the network that expect to have a larger number of entries ). In addition, a router could modify this value (and corresponding Join/Prune-Holdtime value) if the number of route entries changes significantly (e.g., by an order of magnitude). For example, given a default minimum Join/Prune-Period value, if the number of route entries with a particular iif increases from N to N*100, the router could increase its Join/Prune-Period (and Join/Prune-Holdtime), for that interface, by a factor of 10. If/when the number of entries decreases back to N, the Join/Prune-Period (and Join/Prune-Holdtime) could be decreased to its previous value. If the Join/Prune-Period is modified, these changes SHOULD be made relatively infrequently, and the router SHOULD continue to refresh at its previous Join/Prune-Period for at least Join/Prune-Holdtime, in order to allow the upstream router to adapt. 🔥
  • [Join-Prune Holdtime] This is the Holdtime specified in Join/Prune messages, and it's used to time out oifs. This SHOULD be set to 3.5 * [Join/Prune-Period]. {Default: 210 seconds.} 🍓
  • [Join/Prune-Suppression-Timeout] This is the mean interval between receiving a Join/Prune with a higher Holdtime (with ties broken by higher IP addres) and allowing duplicate Join/Prunes to be sent again. This SHOULD be set to approximately 1.25 * [Join/Prune-Period]. {Default: 75 seconds. } 💜
  • [Data-Timeout] This is the time after which (S,G) state for a silent source will be deleted. {Default: 210 seconds.} 🙈
  • [Register-Suppression-Timeout] This is the mean interval between receiving a Register-Stop and allowing Registers to be sent again. A lower value means more frequent register bursts at RP, while a higher value means longer join latency for new receivers. {Default: 60 seconds.} (Note that if null Registers are sent [Probe-Time] seconds before the timeout, register bursts are prevents, and [Register-Suppression-Timeout] MAY be lowered to decrease join latency.) 🦋
  • [Probe-Time] When null Registers are used, this is the time between sending a null Register and the Register-Suppression-Timer expiring, unless it gets restarted by receiving a Register-Stop. So a null Register gets sent when the Register-Suppression-Timer reaches this value. {Default: 5 seconds.} 🌸
  • [Assert-Timeout] This is the interval between the last time an Assert is received and the time at which the assert is timed out. {Default: 180 seconds.} 💅
  • [Random-Delay-Join-Timeout] This is the maximum interval between the time when the RPF neighbor changes and the time at which a triggered Join/Prune message is sent. {Default: 4.5 seconds.} 🌈
  • [Hello-Period] This is the interval between sending Hello messages. {Default: 30 seconds.} 👑
  • [Hello-Holdtime] This is the Holdtime specified in Hello messages, after which neighbors time out their neighbor entries for the router. This SHOULD be set to 3.5 * [Hello-Period]. {Default: 105 seconds.} ✨
  • [C-RP-Adv-Period] For C-RPs, this is the interval between sending C-RP-Adv messages. {Default: 60 seconds.} 🎀
  • [RP-Holdtime] For C-RPs, this is the Holdtime specified in C-RP-Adv messages, and it's used by the BSR to time out RPs. This SHOULD be set to 2.5 * [C-RP-Adv-Period]. {Default: 150 seconds.} 🫶
  • [Bootstrap-Period] At the elected BSR, this is the interval between originating Bootstrap messages, and it SHOULD be equal to 60 seconds. 🧚
  • [Bootstrap-Timeout] This is the time after which the elected BSR is assumed unreachable when Bootstrap messages are not received from it. This SHOULD be set to 2.5 * [Bootstrap-Period]. {Default: 150 seconds.} 💖

3.9. Summary of flags used 🦋

Following is a summary of all the flags used in our scheme. 🌸

Bit           |  Used in    |  Definition

Authoritative | C-RP-Adv    | Group-prefix information should not be
                              over-ridden by BSR
Border        | Register    | Register for external sources is coming
                              from PIM multicast border router
Null          | Register    | Register sent as Probe of RP, the
                              encapsulated IP data packet should not
                              be forwarded
RPT           | Route entry | Entry represents state on the RP-tree
RPT           | Join/Prune  | Join is associated with the shared tree
                              and therefore the Join/Prune message is
                              propagated along the RP-tree (source
                              encoded is an RP address)
RPT           | Assert      | The data packet was routed down the shared
                              tree; thus, the path indicated corresponds
                              to the RP tree
SPT           | (S,G) entry | Packets have arrived on the iif towards S,
                              and the iif is different from the (*,G)
                              iif
WC            |Join         | The receiver expects to receive packets
                              from all sources via this (shared tree)
                              path. Thus, the Join/Prune applies to a
                              (*,G) entry
WC            | Route entry | Wildcard entry; if there is no more
                              specific match for a particular source,
                              packets will be forwarded according to
                              this entry

3.10. Security 🔐

All PIM control messages MAY use IPSec [6] to address security concerns. Lock it down, bestie 🔐✨

4. Packet Formats 💅

This section describes the details of the packet formats for PIM control messages. 🎀

All PIM control messages have protocol number 103. 🫶

Basically, PIM messages are either unicast (e.g. Registers and Register-Stop), or multicast hop-by-hop to the group ALL-PIM-ROUTERS (224.0.0.13) (e.g. Join/Prune, Asserts, etc.). 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • PIM Ver: PIM Version number is 2. 💖
  • Type: Types for specific PIM messages. PIM Types are: 🌈
0 = Hello
1 = Register
2 = Register-Stop
3 = Join/Prune
4 = Bootstrap
5 = Assert
6 = Graft (used in PIM-DM only)
7 = Graft-Ack (used in PIM-DM only)
8 = Candidate-RP-Advertisement
  • Addr length: Address length in bytes. Throughout this section, this would indicate the number of bytes in the Address field of an address, including unicast and group addresses. 👑
  • Checksum: The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message (excluding the data portion in the Register message). For computing the checksum, the checksum field is zeroed. 🧚

4.1 Encoded Source and Group Address formats 💖

okay so first up, the address formats 🎀 these show up everywhere in the packets below, so get comfy with them bestie 🧚

  1. Unicast address: only the address gets included 🌸 how long it is in bytes comes from the Addr length field in the header.
  2. Encoded-Group-Address: the format is:
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reserved  |  Mask Len     | Group multicast Address ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...Group multicast Address ...|
   +-+-+-+-+-+-+-+-+-+-+~+~+~+~+~+~+
  • Reserved 🫶 transmitted as zero, and ignored when received.
  • Mask Length 🔥 this is 8 bits. The value is the number of contiguous bits, left justified, used as a mask that describes the address. It's less than or equal to Addr length * 8. If the message is for a single group, the Mask length MUST equal Addr length * 8 (so 32 for IPv4 and 128 for IPv6) 👑
  • Group multicast Address 💜 holds the group address, and it's as many bytes long as the Addr length field says.
  1. Encoded-Source-Address: the format is:
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsrvd   |S|W|R|  Mask Len     | Source Address ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ...  Source Address          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+-+
  • Reserved 🌈 transmitted as zero, and ignored on receipt.
  • S,W,R 🦋 see Section 4.5 for the details.
  • Mask Length 💅 this is 8 bits. The value is the number of contiguous bits, left justified, used as a mask that describes the address. The mask length MUST be less than or equal to Addr Length * 8. If the message is for a single source, the Mask length MUST equal Addr length * 8. In version 2 of PIM, it is strongly recommended that this field be set to 32 for IPv4 🙈
  • Source Address ✨ the address length comes from the Addr length field at the start of the header. For IPv4, that's 4 octets.

4.2 Hello Message 🦋

okay this one's sent periodically by routers on all interfaces, so it's basically the "hi, I'm still here" message 💖

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OptionType              |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OptionType              |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+

PIM Version, Type, Addr length, Checksum 💜 these were covered above, so no need to repeat the drama.

  • OptionType ✨ the type of the option in the OptionValue field that follows.
  • OptionLength 🌸 the length of the OptionValue field, in bytes.
  • OptionValue 🧚 a variable-length field that carries the value of the option.

The Option fields can hold these values:

  • OptionType = 1; OptionLength = 2; OptionValue = Holdtime; 🔥 where Holdtime is how long a receiver has to keep the neighbor reachable, in seconds. If the Holdtime is 0xffff, the receiver never times the neighbor out 🫶 this can be used with ISDN lines, so the link doesn't stay up just because of periodic Hello messages 🙈 And if the Holdtime is 0, the info times out immediately 💀
  • OptionType 2 to 16: reserved 🎀
  • the rest of the OptionTypes are defined in another document 📚

In general, options MAY be ignored 🌈 but a router MUST NOT ignore the Holdtime OptionType 👑

4.3 Register Message 🌈

okay so a Register message gets sent by the DR or a PMBR to the RP when a multicast packet needs to go out on the RP-tree 🚀 The source IP address is set to the DR's address, and the destination IP address is the RP's address 💖

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B|N|                       Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Multicast data packet                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • PIM Version, Type, Addr length, Checksum 🌸 described above. Note that the checksum for Registers is only done on the PIM header, and it excludes the data packet portion 🧚
  • B 💅 the Border bit. If the router is a DR for a source it's directly connected to, it sets B to 0. If the router is a PMBR for a source in a directly connected cloud, it sets B to 1.
  • N 🦋 the Null-Register bit. A DR sets this to 1 when it's probing the RP before its local Register-Suppression timer expires. Otherwise it's set to 0.
  • Multicast data packet ✨ the original packet sent by the source.

For (S,G) null Registers, the Multicast data packet portion only contains a dummy IP header, with S as the source address, G as the destination address, and a data length of zero 🙈

4.4 Register-Stop Message 💜

so a Register-Stop is unicast from the RP to the sender of the Register message 🫶 The source IP address is the address the register was sent to, and the destination IP address is the source address of the register message 🔥

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Encoded-Group Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Unicast-Source Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • PIM Version, Type, Addr length, Checksum 🎀 described above.
  • Encoded-Group Address 🌈 the format is described above. For Register-Stops, if the message is for a single group, the Mask Len field contains Addr length * 8 (32 for IPv4) 👑
  • Unicast-Source Address 💖 the IP host address of the source from the multicast data packet in the register. The length of this field in bytes is given by the Addr length field. A special wildcard value (0.0.0.0) can be used to mean any source 🧚

4.5. Join/Prune Message 🦋

okay so the Join/Prune message is how routers say "hey, I want in" or "bye, I'm out" 💅 routers send these toward upstream sources and RPs. Joins build shared trees (RP trees) or source trees (SPT) 🌳 and prunes shut down source trees when members leave groups, plus sources that don't use the shared tree 🙅‍♀️

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Unicast-Upstream Neighbor Address                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved     | Num groups    |          Holdtime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Encoded-Multicast Group Address-1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined  Sources   |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           .                                   |
   |                           .                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Encoded-Multicast Group Address-n              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined  Sources   |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Type, Addr length, Checksum — Described above.

Upstream Neighbor Address — the IP address of the RPF or upstream neighbor 📍

Reserved — transmitted as zero, ignored on receipt 🫧

Holdtime — the amount of time a receiver must keep the Join/Prune state alive, in seconds ⏳ If the Holdtime is set to 0xffff', the receiver of this message never times out the oif. This may be used with ISDN lines, to avoid keeping the link up with periodical Join/Prune messages. Furthermore, if the Holdtime is set to 0', the information is timed out immediately 💀

Number of Groups — the number of multicast group sets contained in the message 🧺

Encoded-Multicast group address — for the format description, see Section 4.1. A wild card group in the (*,*,RP) join is represented by a 224.0.0.0 in the group address field and 4' in the mask length field. A (*,*,RP) join also has the WC-bit and the RPT-bit set. the wildcard era is so iconic 🌈

Number of Joined Sources — number of join source addresses listed for a given group 🌸

Join Source Address-1 .. n — this list contains the sources that the sending router will forward multicast datagrams for if received on the interface this message is sent on. See format section 4.1. The fields explanation for the Encoded-Source-Address format follows:

  • Reserved — described above.
  • S — the Sparse bit is a 1 bit value, set to 1 for PIM-SM. It is used for PIM v.1 compatibility 🎀
  • W — the WC bit is a 1 bit value. If 1, the join or prune applies to the (*,G) or (*,*,RP) entry. If 0, the join or prune applies to the (S,G) entry where S is Source Address. Joins and prunes sent towards the RP must have this bit set 👑
  • R — the RPT-bit is a 1 bit value. If 1, the information about (S,G) is sent towards the RP. If 0, the information must be sent toward S, where S is the Source Address 🦋
  • Mask Length, Source Address — described above.

Represented in the form of:

< WC-bit >< RPT-bit > < Mask length
><Source address>:

A source address could be a host IP address :

 < 0 >< 0 >< 32 >< 192.1.1.17 >

A source address could be the RP's IP address :

 < 1 >< 1 >< 32 >< 131.108.13.111 >

A source address could be a subnet address to prune from the RP-tree :

 < 0 >< 1 >< 28 >< 192.1.1.16 >

A source address could be a general aggregate :

 < 0 >< 0 >< 16 >< 192.1.0.0 >

Number of Pruned Sources — number of prune source addresses listed for a group 🙅‍♀️

Prune Source Address-1 .. n — this list contains the sources that the sending router does not want to forward multicast datagrams for when received on the interface this message is sent on. If the Join/Prune message boundary exceeds the maximum packet size, then the join and prune lists for the same group must be included in the same packet. this part is so important, keep your join and prune lists together bestie 🫶

the join and prune lists are literally a package deal 💖

4.6 Bootstrap Message ✨

okay bestie, so Bootstrap messages get multicast to the `ALL-PIM-ROUTERS' group 📣 and sent out every interface that has PIM neighbors, except the one it came in on 🙅‍♀️. They go out with a TTL value of 1 💅. The BSR is where they start, and intermediate routers forward them along 🧚

if the whole Bootstrap message is too big for one packet, it gets chopped up into "semantic fragments" 🧩 each fragment has the layout below 👇

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Fragment Tag          | Hash Mask len | BSR-priority  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-BSR-Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RP-Count-1    | Frag RP-Cnt-1 |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RP1-Holdtime         |           Unicast- . . .      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | . . . RP-Address-2            |       RP2-Holdtime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-m                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RPm-Holdtime         |            Encoded- . . .     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | . . . Group Address-2         . . .                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-n               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RP-Count-m    | Frag RP-Cnt-m |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RP1-Holdtime         |           Unicast- . . .      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | . . . RP-Address-2            |       RP2-Holdtime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-m                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RPm-Holdtime         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   PIM Version, Type, Addr length, Checksum
         Described above.

PIM Version, Type, Addr length, Checksum are the same as we covered up top, so nothing new to see there 🙈

Fragment Tag 🏷️ is a randomly generated number. Its whole job is to tell apart the fragments from different Bootstrap messages. Every fragment that belongs to the same Bootstrap message carries the same Fragment Tag.

Hash Mask len is the length (in bits) of the mask used in the hash function 🔢. For IPv4 we recommend a value of 30. For IPv6 we recommend a value of 126.

BSR-priority holds the BSR priority value of the BSR that's included. When routers compare BSR addresses, this field gets treated as the high order byte, so it's a big deal 👑

Unicast-BSR-Address is the IP address of the bootstrap router for the domain. How long this field is (in bytes) gets specified by Addr length.

Encoded-Group Address-1..n is the group prefix (address and mask) that the Candidate RPs are associated with. The format was described earlier.

RP-Count-1..n is the number of Candidate RP addresses included in the entire Bootstrap message for that group prefix 🧮 A router doesn't replace its old RP-Set for a given group prefix until (unless) it gets RP-Count addresses for that prefix. Those addresses could be spread across several fragments. If only part of the RP-Set for a group prefix shows up, the router throws that part away and doesn't update that group prefix's RP-Set. no half-baked RP-Sets allowed 🙅‍♀️

Frag RP-Cnt-1..m is the number of Candidate RP addresses included in this particular fragment, for that group prefix. This field makes it easier to parse an RP-Set when it's carried across more than one fragment 🧩

Unicast-RP-address-1..m is the address of a Candidate RP for the group prefix. How long it is (in bytes) gets specified by Addr length.

RP1..m-Holdtime is the Holdtime for that RP. It gets copied from the Holdtime field of the matching RP stored at the BSR ⏰

4.7 Assert Message

okay so the Assert message gets sent when a multicast data packet shows up on an outgoing interface that matches the (S,G) or (*,G) tied to the source 👀 it's giving "hey, I see this too!" energy 📣

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded-Group Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Unicast-Source Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                        Metric Preference                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Metric                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PIM Version, Type, Addr length, Checksum
         Described above.

PIM Version, Type, Addr length, Checksum are described above, so we're good 🫶

Encoded-Group Address is the group address the data packet was sent to, the one that set off the Assert. Its format was described earlier.

Unicast-Source Address is the source IP address from the IP multicast datagram that made the Assert packet get sent. How long it is (in bytes) gets specified by Addr length.

R is the RPT-bit, a 1-bit value 🦋 If the IP multicast datagram that triggered the Assert gets routed down the RP tree, the RPT-bit is 1. If it's routed down the SPT, it's 0.

Metric Preference is the preference value given to the unicast routing protocol that provided the route to the Host address 💅

Metric is the unicast routing table metric. It's measured in whatever units the unicast routing protocol being used expects 📏

4.8 Graft Message

ngl this one is only for dense-mode 🌊 for the details, you go read the PIM dense mode specification.

4.9 Graft-Ack Message

same deal here, this is dense-mode only 🌊 and the PIM dense mode specification has the full story.

4.10 Candidate-RP-Advertisement

okay so Candidate-RP-Advertisements get unicast periodically from the C-RPs to the BSR 📬 literally the C-RPs keeping the BSR updated 💖

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix-Cnt    |A| Reserved    |             Holdtime          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-n               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Type, Addr length, Checksum are described above, same as always 🩷

Prefix-Cnt is the number of encoded group addresses in the message 🔢 It tells the BSR which group prefixes the C-RP is advertising for. A Prefix-Cnt of 0 implies a prefix of 224.0.0.0 with mask length of 4, which means all multicast groups 🌈 If the C-RP isn't configured with any Group-prefix information, it puts a default value of 0 in this field.

A is the Authoritative bit ✋ it says the BSR shouldn't override the group-prefix information in the C-RP Advertisement. In most cases, C-RPs set this bit to 0.

Holdtime is how long the advertisement stays valid ⏳ this field is what lets advertisements age out.

Unicast-RP-Address is the address of the interface to advertise as a Candidate RP. How long it is (in bytes) gets specified by Addr length.

Encoded-Group Address-1..n are the group prefixes the C-RP is advertising for. The format was described earlier.

5 Acknowledgments 🎀

Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang and Girish Chandranmenon gave super detailed comments on earlier drafts 🫶 The authors of CBT [7] and the IDMR WG members gave a bunch of the motivating ideas for this work, plus really useful feedback on design details. iconic behaviour 👑

This work was supported by the National Science Foundation, ARPA, cisco Systems and Sun Microsystems. thank you, legends 💜

6 Appendices 🌸

6.1. Appendix I: Major Changes and Updates to the Spec 📜

okay bestie, this appendix is the big "what changed" recap 💅 It lists the major changes in the spec compared to draft-ietf-idmr-pim-spec-01.ps,txt ✨

Major Changes

Here's what changed since the March '96 IETF meeting 🌸

The (*,*,RP) Joins state and data forwarding check now replaces the (*,G-Prefix) Joins state, for interoperability 🔥 A (*,G) negative cache was also introduced, to support the mechanisms for the (*,*,RP) state 🧚

Bootstrap messages got semantic fragmentation 🎀

Assert details got refined 💖

Join/Prune suppression and Register suppression got added and refined, and null Registers were introduced 🦋

The timers section got editorial changes and clarifications 🌈

Appendix II (BSR Election and RP-Set Distribution) and Appendix III (Glossary of Terms) were added 📚

A table of contents was added too 💜

Here's what changed since version 1 of the spec 👑

  • Bootstrap router (BSR) election mechanisms got proposed and refined 🗳️
  • Hash functions for Group to RP mapping were introduced ✨
  • New RP-liveness indication mechanisms, based on the Bootstrap Router (BSR) and the Bootstrap messages, showed up 🫶
  • Reachability messages, RP reports and multiple RPs per group got removed 💀

Packet Format Changes

The packet format got updates so it can handle different address lengths and address aggregation 🍓

  1. The `Addr length' field was added to the PIM fixed header to specify the address length in bytes of the underlying protocol. See section 4 for more 💅
  2. The Encoded source and group address formats were introduced, with a `Mask length' field so aggregation is possible. See section 4.1 🌸
  3. Packet formats are no longer IGMP messages. They're PIM messages now 🦋

PIM message types and formats got modified too 🎀

[Note: most changes were made to the May 95 version, unless otherwise specified].
  1. Obsolete messages:
    • Register-Ack [Feb. 96]
    • Poll and Poll Response [Feb. 96]
    • RP-Reachability [Feb. 96]
    • RPlist-Mapping [Feb. 96]
  2. New messages:
    • Candidate-RP-Advertisement [change made in October 95]
    • RP-Set [Feb. 96]
  3. Modified messages:
    • Join/Prune [Feb. 96]
    • Register [Feb. 96]
    • Register-Stop [Feb. 96]
    • Hello (addition of OptionTypes) [Aug 96]
  4. Renamed messages:
    • Query messages are renamed as Hello messages [Aug. 96]
    • RP-Set messages are renamed as Bootstrap messages [Aug. 96]

6.2. Appendix II: BSR Election and RP-Set Distribution 🗳️

okay so, for simplicity, the Bootstrap message gets used for both the BSR election AND the RP-Set distribution 🥹

Both of those mechanisms (the BSR election and the RP-Set distribution) are powered by the following state machine, shown in figure 4 💖

[Figures are present only in the postscript version]

Fig. 4 State Diagram for the BSR election and RP-Set distribution mechanisms

The protocol transitions for a C-BSR are in state diagram (a). For routers that aren't configured as C-BSRs, the transitions are in state diagram (b) ✨

Each PIM router keeps a Bootstrap-timer, initialized to [Bootstrap-Timeout]. It also keeps a local BSR field called LclBSR, which is initialized to a local address if it's a C-BSR, or to 0 otherwise. And it keeps a local RP-Set called LclRP-Set, which starts out empty 🧚 The two main stimuli for the state machine are timer events and receiving a Bootstrap message 🔥

Initial States and Timer Events

  1. If the router is a C-BSR:
    1. The router operates initially in the CandBSR state, where it does not originate any Bootstrap messages 🙈
    2. If the Bootstrap-timer expires and the current state is CandBSR, the router originates a Bootstrap message. That message carries the local RP-Set, plus its own BSR priority and address. The router also restarts the Bootstrap-timer at [Bootstrap-Period] seconds and transits into the ElectedBSR state 👑
    3. If the Bootstrap-timer expires and the current state is ElectedBSR, the router originates a Bootstrap message and restarts the RP-Set timer at [Bootstrap-Period]. No state transition is incurred 🌈

This way, the elected BSR originates periodic Bootstrap messages every [Bootstrap-Period] 🫶

  1. If a router is not a C-BSR:
    1. The router operates initially in the AxptAny state. In that state, a router accepts the first Bootstrap message from the RPF neighbor toward the included BSR. The Reverse Path Forwarding (RPF) neighbor in this case is the next hop router en route to the included BSR 🦋
    2. If the Bootstrap-timer expires and the current state is AxptPref (where the router accepts only preferred Bootstrap messages from the RPF neighbor toward the included BSR), the router transits into the AxptAny state. Preferred Bootstrap messages are those that carry a BSR priority and address higher than, or equal to, LclBSR 💅

In this case, if an elected BSR becomes unreachable, the routers start accepting Bootstrap messages from another C-BSR after the Bootstrap-timer expires. All PIM routers within a domain converge on the preferred (with highest priority and address) reachable C-BSR 🔥

Receiving Bootstrap Message

To avoid loops, an RPF check is performed on the included BSR address 🔁 When a Bootstrap message comes in from the RPF neighbor toward the included BSR, these actions happen:

  1. If the router is not a C-BSR:
    1. If the current state is AxptAny, the router accepts the Bootstrap message and transits into the AxptPref state 💖
    2. If the current state is AxptPref and the Bootstrap message is preferred, the message is accepted. No state transition is incurred ✨
  2. If the router is a C-BSR, and the Bootstrap message is preferred, the message is accepted. Further, if this happens when the current state is

When a Bootstrap message is accepted, the router restarts the Bootstrap-timer at [Bootstrap-Timeout]. It stores the received BSR priority and address in LclBSR, and the received RP-Set in LclRP-Set. Then it forwards the Bootstrap message out all interfaces except the receiving interface 🧚

If a Bootstrap message is rejected, no state transitions are triggered 🌸

6.3. Appendix III: Glossary of Terms ✨

Okay bestie, here's the glossary 📖 It's alphabetized, and every term in it is something the whole spec leans on, so bookmark it 🔖

  • Bootstrap router (BSR). So a BSR is a router that gets dynamically elected inside a PIM domain 👑 It's in charge of building the RP-Set and sending out Bootstrap messages.
  • Candidate-BSR (C-BSR). A C-BSR is a router that's configured to join the BSR election, and it becomes a BSR if it wins 🗳️
  • Candidate RP (C-RP). A C-RP is a router that's configured to send Candidate-RP-Advertisement messages to the BSR on a regular schedule. It acts as an RP once it gets Join/Prune or Register messages for the group prefix it advertised 🎯
  • Designated Router (DR). The DR sets up multicast route entries, and it sends Join/Prune and Register messages for directly-connected receivers and sources, respectively 🫶 The DR might or might not be the same router as the IGMP Querier. It also might or might not be the long-term, last-hop router for the group, because a router on the same LAN that has a lower metric route to the data source, or to the group's RP, can take over sending Join/Prune messages. Plot twist 🙈
  • Incoming interface (iif). The iif of a multicast route entry is the interface that multicast data packets are accepted from for forwarding. It gets set when the entry is created 🚪
  • Join list. The Join list is one of the two lists of addresses in a Join/Prune message. Each address is a source or an RP, and the list says which sources or RPs the downstream receivers want to join 💖
  • Last-hop router. The last-hop router is the last router that gets multicast data packets before they're delivered to directly-connected member hosts 🏁 Usually that's the DR for the LAN. But under some conditions this document describes, a parallel router on the same LAN can step in and become the last-hop router instead of the DR 💅
  • Outgoing interface (oif) list. Every multicast route entry has an oif list, which holds the outgoing interfaces that multicast packets should be forwarded out of 📤
  • Prune list. The Prune list is the second list of addresses in a Join/Prune message. It says which sources or RPs the downstream receivers want to prune from 🌸
  • PIM Multicast Border Router (PMBR). A PMBR connects a PIM domain to other multicast routing domain(s) 🌉
  • Rendezvous Point (RP). Every multicast group has a shared-tree that receivers use to hear about new sources, and new receivers hear about all the sources through it. The RP is the root of this per-group shared tree, which is called the RP-Tree 🌳
  • RP-Set. The RP-Set is a set of RP addresses that the BSR builds from the Candidate-RP advertisements it receives. The BSR sends the RP-Set information out to all the PIM routers in its PIM domain 📣
  • Reverse Path Forwarding (RPF). RPF is how you pick the right incoming interface for a multicast route entry 🧭 The RPF neighbor for an IP address X is the next-hop router that's used to forward packets toward X. The RPF interface is the interface that leads to that RPF neighbor. In the common case, that's the next hop the unicast routing protocol uses for sending unicast packets toward X. But when unicast and multicast routes aren't congruent, it can be different, so don't assume it's always the same 🙃
  • Route entry. A multicast route entry is state a router keeps along the distribution tree. It gets created and updated based on incoming control messages 📝 It can be different from the forwarding entry, which is what's used to forward data packets in real time. Usually a forwarding entry doesn't get created until data packets show up. Its iif and oif list get copied from the route entry, and it can be flushed and recreated whenever 🔄
  • Shortest path tree (SPT). The SPT is the multicast distribution tree you get by merging all the shortest paths that connect receivers to the source, where the shortest paths are determined by unicast routing 🛤️
  • Sparse Mode (SM). SM is one mode a multicast protocol can run in. PIM SM uses explicit Join/Prune messages and Rendezvous Points, where Dense Mode PIM and DVMRP use broadcast and prune instead 🦋
  • Wildcard (WC) multicast route entry. Wildcard multicast route entries are the ones that can forward packets for any source sending to the specified group 🌈 In the join list of a Join/Prune message, wildcard bits represent either a (*,G) or (*,*,RP) join. In the prune list, they represent a (*,G) prune.
  • (S,G) route entry. (S,G) is a source-specific route entry. It can get created because of data packets, Join/Prune messages, or Asserts. The (S,G) state in routers builds a source-rooted, shortest path (or reverse shortest path) distribution tree 🌲 (S,G)RPT bit entries are source-specific entries on the shared RP-Tree, and they're used to prune particular sources off of that shared tree ✂️
  • (*,G) route entry. Group members join the shared RP-Tree for a particular group. That tree is represented by (*,G) multicast route entries along the shortest path branches between the RP and the group members 🫂
  • (*,*,RP) route entry. (*,*,RP) refers to any source and any multicast group that maps to the RP included in the entry 🧚 The routers along the shortest path branches between a domain's RP(s) and its PMBRs keep (*,*,RP) state. They use it to figure out how to deliver packets toward the PMBRs when data packets arrive that don't have a longer match. The wildcard group in a (*,*,RP) route entry is represented by a group address of 224.0.0.0 and a mask length of 4 bits 💜

References 📚

  1. Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast (pim) : Motivation and architecture. Work in Progress.
  2. Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei. The pim architecture for wide-area multicast routing. ACM Transactions on Networks, April 1996.
  3. Estrin, D., D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast-dense mode (pim-dm) : Protocol specification. Work in Progress.
  4. Deering, S. Host extensions for ip multicasting, Aug 1989. RFC1112.
  5. Fenner, W. Internet group management protocol, version 2. Work in Progress.
  6. Atkinson, R. Security architecture for the internet protocol, August 1995. RFC-1825.
  7. Ballardie, A.J., P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993.

Addresses of Authors 🏡

Deborah Estrin
Computer Science Dept/ISI
University of Southern Calif.
Los Angeles, CA 90089
estrin@usc.edu

Dino Farinacci
Cisco Systems Inc.
170 West Tasman Drive,
San Jose, CA 95134
dino@cisco.com

Ahmed Helmy
Computer Science Dept.
University of Southern Calif.
Los Angeles, CA 90089
ahelmy@catarina.usc.edu

David Thaler
EECS Department
University of Michigan
Ann Arbor, MI 48109
thalerd@eecs.umich.edu

Stephen Deering
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94304
deering@parc.xerox.com
Mark Handley
Department of Computer Science
University College London
Gower Street
London, WC1E 6BT
UK
m.handley@cs.ucl.ac.uk

Van Jacobson
Lawrence Berkeley Laboratory
1 Cyclotron Road
Berkeley, CA 94720
van@ee.lbl.gov

Ching-gung  Liu
Computer Science Dept.
University of Southern Calif.
Los Angeles, CA 90089
charley@catarina.usc.edu

Puneet Sharma
Computer Science Dept.
University of Southern Calif.
Los Angeles, CA 90089
puneet@catarina.usc.edu

Liming Wei
Cisco Systems Inc.
170 West Tasman Drive,
San Jose, CA 95134
lwei@cisco.com
📦 where this page comes from