RFC 2362

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

📅 published June 1998, from ietf

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

bestie, this one is the PIM-SM spec! 🦋 It's from June 1998 and it's an Experimental protocol doc (not a full Internet standard, so no cap, it's a test drive 💅). It obsoletes RFC 2117, and it doesn't say it updates anything else. The author list is a whole squad: 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) 🫶🌈

Status of this Memo 📜

okay so this memo defines an Experimental Protocol for the Internet community 🧪 It is NOT an Internet standard of any kind, and the authors are literally asking for discussion and suggestions for improvement 💖 Distribution of this memo is unlimited 🌸

Copyright Notice ©️

1 Introduction ✨

okay bestie, so this doc describes a protocol for routing efficiently to multicast groups that might span wide-area (and inter-domain) internets 🌍 We call it Protocol Independent Multicast--Sparse Mode (PIM-SM) because it doesn't depend on any particular unicast routing protocol, and because it's built to support sparse groups as defined in [1][2] 🧚 This doc is where the protocol details live. For the motivation behind the design and an architecture description, go check [1][2] 📚

Here's the lay of the land 🗺️ Section 2 gives you a summary of PIM-SM operation from a network perspective, especially how the participating routers team up to create and maintain the multicast distribution tree 🌳 Section 3 is the main body of the spec, and it's told from the POV of a single router implementing the protocol 👑 It's organized by PIM-SM message type, and for each type we cover its contents, how it gets generated, and how it gets processed 💅

Sections 3.8 and 3.9 are the recap sections for the timers and flags that show up all over this doc 🦋 Section 4 has the packet format details 🎀

The big changes since the January '95 version are all about the Rendezvous Point-related mechanisms 🔥 A bunch of things got simplified because of that, and the PIM-DM protocol details were moved out to their own separate doc [3] so this one stays clear 💖

2 PIM-SM Protocol Overview 🌸

in this section we give you the overview of the architectural pieces of PIM-SM 🧩

okay so a router gets explicit Join/Prune messages from its neighbor routers that have downstream group members 🫶 Then it forwards data packets addressed to a multicast group, G, only out of the interfaces where it got explicit joins 🎯 Also, unless it says otherwise, every router mentioned in this doc is assumed to be PIM-SM capable 💜

A Designated Router (DR) sends periodic Join/Prune messages toward a group-specific Rendezvous Point (RP), one for each group where it has active members 🧚 Every router on the path to the RP builds a wildcard (any-source) state for the group and sends Join/Prune messages onward toward the RP 🌈 We use the term route entry for the state a router keeps to represent the distribution tree 📦 A route entry can hold stuff like the source address, the group address, the incoming interface packets are accepted from, the list of outgoing interfaces packets go out on, timers, flag bits, and so on 💅

The wildcard route entry's incoming interface points toward the RP ⬆️ The outgoing interfaces point at the neighboring downstream routers that sent Join/Prune messages toward the RP ⬇️ This state creates a shared, RP-centered distribution tree that reaches all group members 🌳✨

Now, when a data source first sends to a group, its DR unicasts Register messages to the RP, and the source's data packets ride inside them (encapsulated) 🎁 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 travel unencapsulated to the RP 🦋 Either way, whether they arrive encapsulated or natively, the RP forwards the decapsulated data packets down the RP-centered tree toward group members 💖

If the data rate warrants 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, though, neither the RP nor the last-hop routers need to join a source-specific shortest path tree, and the data packets can be delivered over the shared RP-tree 🌸

Here's what the next subsections cover: the control messages and the actions they trigger 💅

2.1 Local hosts joining a group 🎀

okay so 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 here on, we call that host a receiver, R, (or member) of group G 🧚

Heads up: all the figures in this section are just for illustration and aren't meant to be complete. For the full and 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 (e.g., router A in figure 1) gets a membership indication from IGMP for a new group, G, it looks up the associated RP 🔍 The DR creates a wildcard multicast route entry for the group, which we'll call 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 also 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 directly connected members for the group, IGMP tells 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 🌳

Triggered by the (*,G) state, the DR creates a Join/Prune message with the RP address in its join list, and the wildcard bit (WC-bit) and RP-tree bit (RPT-bit) both set to 1 🔥 The WC-bit says any source may match and get forwarded according to this entry if there's no longer 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, it means 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, it means the address is an RP, and the downstream receivers expect to get packets from all sources via this shared tree path 👑 The term RPT-bit is used for both the RPT-bit flags associated with 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 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 its own Join/Prune message, in which the 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 so the RP can distribute them down the RP-tree 🎁 (see figure 2) The sender's DR starts out by encapsulating each data packet in a Register message and unicasting 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 warrants a source-specific shortest path tree (SPT), the RP can build a new multicast route entry specific to the source, which we'll call (S,G) state 🔥 It then sends periodic Join/Prune messages toward the source 🎯 Note that the rules for when to switch can change over time without any global coordination 🌈 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 for as long as) it keeps getting Register-Stop messages from the RP 🛑 The RP triggers Register-Stop messages in response to Registers if it has no downstream receivers for the group (or for that particular source), or if it has already joined the (S,G) tree and is receiving the data packets natively 🙈 Each source's DR keeps a Register-Suppression-timer per (S,G) ⏲️ That timer starts when a Register-Stop message arrives, and 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 bestie, so a router with directly-connected members first joins the shared RP-tree 🌸. Then it can switch over to a source's shortest path tree (SP-tree), but only after it has received packets from that source over the shared RP-tree 👀. The recommended policy is to start the switch after a significant number of data packets arrive from one particular source within 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 that entry once the data rate goes past the configured threshold 💅. As you can see in figure 3, router `A' sets up an (S,G) state 🦋.

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

Once an (S,G) entry is activated (and it keeps happening 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 looks like Multicast-Address=G, Join=S, Prune=NULL. When the (S,G) entry gets created, its outgoing interface list is copied from (,G), so all the local shared tree branches get replicated into the new shortest path tree 🌈. That means when a data packet from S shows up and matches this entry, every receiver keeps 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.) Also, the (S,G) state has to be maintained in each last-hop router that's responsible for starting and keeping up an SP-tree 🧚. Even when (,G) and (S,G) overlap, you still need both states to trigger the source-specific Join/Prune messages 😭.

The (S,G) state stays alive because data packets keep arriving from that source 💜. There's a timer called Entry-timer set for each (S,G) entry, and it gets restarted whenever data packets for (S,G) go out on at least one oif, or whenever Registers are sent ⏰. When Entry-timer runs out, the state gets deleted 💀. The last-hop router is the one that actually delivers the packets to their final end-system destination 🎀. It's the router that keeps watch on whether there's group membership, and it joins or prunes the right distribution trees based on that 👑. Usually the last-hop router is the Designated Router (DR) for the LAN. However, under various conditions described later, a parallel router connected to the same LAN may take over as the last-hop router in place of the DR 🙈.

Only the RP and routers with local members can start switching to the SP-tree, and intermediate routers can't 🚫. So last-hop routers create (S,G) state in response to data packets from the source, S, while 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 basically means the shortest path tree branch from S isn't fully set up yet 🌸. Until then, the router can still accept packets from S that arrive on the incoming interface (iif) of the (*,G) entry 💅. Every PIM multicast entry has an associated incoming interface where packets are expected to arrive 🦋.

Now here's the moment 👀. 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 🔥. It also sends a Join/Prune message toward the RP, saying it no longer wants to receive packets from S over the shared RP-tree 🚫. That Join/Prune message includes S in the prune list with the RPT-bit set, which tells the RP that 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 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 with the RPT-bit flag set to 1 an (S,G)RPT-bit entry 🎀. This little notation helps point out the different actions taken for (S,G) entries depending on how the RPT-bit flag is set 💜. 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 for this contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit 🫶.

A brand new receiver might join an existing RP-tree that already has source-specific prune state on it (for example, because downstream receivers switched to SP-trees) 🌸. In that case, the prune state has to be eradicated upstream of the new receiver so that all sources' data packets come down to the new receiver 😤. So when a (,G) Join arrives at a router that has any (Si,G)RPT-bit entries (meaning entries that cause the router to send source-specific prunes toward the RP), those entries must be updated upstream of the router so that all sources' packets get brought down to the new member 🦋. To make that happen, 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 🚀. And if the arriving (,G) join has some sources included in its prune list, then the matching (S,G)RPT-bit entries stay unchanged, meaning the RPT-bit remains set and no oif gets added 🙅‍♀️.

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

Here's how things stay healthy long-term 🫶. In the steady state, each router sends periodic Join/Prune messages for each active PIM route entry 💖. These go to the neighbor indicated in the corresponding entry ✨. The periodic messages are how routers keep up with state, topology, and membership changes 🌸. A Join/Prune message also gets sent on an event-triggered basis each time a new route entry is established for some new source 🔥. Quick note: some damping function may be applied, like a short delay so new Join information can merge together nicely 🧚. Join/Prune messages don't get any kind of explicit acknowledgment 🙈. Instead, routers recover from lost packets using the periodic refresh mechanism 💜. Honestly so chill ngl 😌.

2.6. Obtaining RP information

So how do routers actually figure out who the RPs are? 🤔 All routers within a PIM domain collect Bootstrap messages 🌈. These get 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 also 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), distributed in Bootstrap messages, to get the proper Group to RP mapping 💅. The following paragraphs summarize the mechanism, and if you want the details, check out Sections 3.6 and Appendix 6.2 📖. A (small) set of routers within a domain is configured as candidate BSRs, and through a simple election mechanism, a single BSR gets selected for that domain 👑. Another set of routers within a domain is configured as candidate RPs (C-RPs), and typically these are 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 show the group prefix(es) the candidacy is advertised for 🌸. Then the BSR puts together a set of these Candidate-RPs (the RP-Set), along with the corresponding group prefixes, into the Bootstrap messages it originates periodically ✨. Those Bootstrap messages get distributed hop-by-hop throughout the domain 🫶.

Routers receive and store the Bootstrap messages originated by the BSR 💜. When a DR gets a membership indication from IGMP (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 that group (see Section 3.7) 🧚. Then the DR sends a Join/Prune message toward that RP, or unicasts Registers to it 🦋.

The Bootstrap message also shows the liveness of the RPs included in it 🌈. If an RP is included in the message, it gets tagged as up at the routers 💅. Any RPs not included in the message get removed from the list of RPs the hash algorithm works over 💀. Each router keeps using the contents of the most recently received Bootstrap message until it receives a new one 🙌.

Now, what if a PIM domain partitions? 😱 Each area separated from the old BSR will elect its own BSR, which will distribute an RP-Set containing the RPs reachable within that partition 🌗. When the partition heals, another election happens automatically, and only one of the BSRs keeps sending out Bootstrap messages ✨. As you'd expect around a partition or healing, there may be some disruption in packet delivery 🥺. This disruption 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 bestie, so to play nicely with networks running dense-mode, broadcast-and-prune protocols like DVMRP 🦋, every packet generated inside a PIM-SM region has to get pulled out to that region's PIM Multicast Border Routers (PMBRs) and then injected (aka broadcast) into the DVMRP network. A PMBR is a router sitting on the edge of a PIM-SM domain that talks to other kinds of multicast routers, like the DVMRP ones. Usually a PMBR speaks both protocols and handles interop stuff that regular PIM routers don't have to deal with 💅. To make this work, a special entry type written as (*,*,RP) must be supported by all PIM routers. That's why we include the (*,*,RP) entry details in this general PIM spec 🎀.

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 basically, a (*,*,RP) entry is an aggregate of all the groups that hash to that RP 🧚. 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 every data packet 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. To do that, PMBRs first encapsulate externally originated packets (the ones received on DVMRP interfaces) in Register messages and unicast them to the corresponding RP within the PIM domain. The Register message has a bit that says it was originated by a border router, and the RP caches the originating PMBR's address in the route entry. That way, duplicate Registers from other PMBRs can be declined with a Register-Stop message 🙈.

All PIM routers must be capable of supporting (*,*,RP) state and interpreting the associated Join/Prune messages 🫶. We describe the handling of (*,*,RP) entries and messages throughout this document. The detailed PIM Multicast Border Router (PMBR) functions, though, get specified in a separate interoperability document (see directory, http://catarina.usc.edu/pim/interop/).

2.8 Multicast data packet processing 🔥

Data packets get processed in a way that's pretty similar to other multicast schemes 💖. A router first does a longest match on the source and group address in the data packet. An (S,G) entry gets matched first if one exists, and a (*,G) entry gets matched otherwise. If neither state exists, then a (*,*,RP) entry match is attempted like this: the router hashes on G to identify the RP for group G, then looks for a (*,*,RP) entry that has that RP address associated with it. If none of the above exists, the packet is dropped 💀. If a state is matched, the router compares the interface the packet arrived on to the incoming interface field in the matched route entry. If the iif check fails, the packet is dropped. Otherwise, the packet is forwarded to all interfaces listed in the outgoing interface list ✨.

Some special actions are needed to keep delivering packets smoothly while switching from the shared tree to the shortest-path tree 🦋. In particular, when an (S,G) entry is matched, incoming packets are handled as follows:

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.
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 🙈. However, data packets may trigger actions that in turn trigger prunes. For example, when router B in figure 3 decides to switch to the 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 that for (S,G). This triggers the sending of prunes toward the RP 💜.

2.9 Operation over Multi-access Networks 🌈

This section covers a few extra protocol mechanisms needed to operate PIM over multi-access networks: Designated Router election, Assert messages to resolve parallel paths, and the Join/Prune-Suppression-Timer to suppress redundant Joins on multi-access networks 🍓.

Designated router election 👑

When there are multiple routers connected to a multi-access network, one of them must be chosen to operate as the designated router (DR) at any point in time. The DR is responsible for sending triggered Join/Prune and Register messages toward the RP 🫶.

A simple designated router (DR) election mechanism is used for both SM and traditional IP multicast routing. Neighboring routers send Hello messages to each other. The sender with the largest network layer address assumes the role of DR. Each 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 receives a multicast datagram on a multi-access LAN from a source whose corresponding (S,G) outgoing interface list includes the interface to that LAN, the packet must be a duplicate. In this case, a single forwarder must be elected. Using Assert messages addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN, upstream routers can resolve which one will act as the forwarder 💅. Downstream routers listen to the Asserts so they know which one was elected, and therefore where to send subsequent Joins. Typically this is the same as the downstream router's RPF (Reverse Path Forwarding) neighbor, but there are circumstances where this might not be the case, e.g., when using multiple unicast routing protocols on that LAN. The RPF neighbor for a particular source (or RP) is the next-hop router to which packets are forwarded en route to that source (or RP), and therefore is considered a good path via which to accept packets from that source 🧚.

The upstream router elected is the one that has the shortest distance to the source. So, when a packet is received on an outgoing interface, a router sends an Assert message on the multi-access LAN indicating what metric it uses to reach the source of the data packet. The router with the smallest numerical metric (with ties broken by highest address) becomes the forwarder. All other upstream routers delete the interface from their outgoing interface list. Downstream routers also do the comparison, in case the forwarder is different from the RPF neighbor 🌸.

Associated with the metric is a metric preference value. This is provided to deal with the case where the upstream routers may run different unicast routing protocols. The numerically smaller metric preference is always preferred. The metric preference is treated as the high-order part of an assert metric comparison. Therefore, a metric value can be compared with another metric value provided both metric preferences are the same. A metric preference can be assigned per unicast routing protocol and needs to be consistent for all routers on the multi-access network 🎀.

Asserts are also needed for (*,G) entries, since 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 to indicate that this path corresponds to the RP tree, and that the match must be done on (*,G) if it exists. Furthermore, the RPT-bit is always cleared for metric preferences that refer to SP-tree entries. This causes an SP-tree path to always look better than an RP-tree path. When the SP-tree and RP-tree cross the same LAN, this mechanism eliminates the duplicates that would otherwise be carried over the LAN 🦋.

In case the packet, or the Assert message, matches on the oif for a (*,*,RP) entry, a (*,G) entry is created, and asserts take place as if the matching state were (*,G) 💖.

The DR may lose the (*,G) Assert process to another router on the LAN if there are multiple paths to the RP through the 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 reduce duplicate control message overhead. It is not required for correct performance of the protocol 💅. 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 included in the Join/Prune message is greater than the recipient's own [Join/Prune-Holdtime] (with ties resolved in favor of the higher network layer address), then a timer (the Join/Prune-Suppression-timer) in the recipient's route entry may be started to suppress further Join/Prune messages. After this timer expires, the recipient triggers a Join/Prune message and resumes sending periodic Join/Prunes for this entry 🧚. The Join/Prune-Suppression-timer should be restarted each time a Join/Prune message is received with a higher Holdtime ⭐.

2.10 Unicast Routing Changes 🎀

When unicast routing changes, an RPF check is done on all active (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming interfaces are updated 🔥. In particular, if the new incoming interface appears in the outgoing interface list, it is deleted from the outgoing interface list. The previous incoming interface may be added to the outgoing interface list by a subsequent Join/Prune from downstream 🦋. Join/Prune messages received on the current incoming interface are ignored. Join/Prune messages received on new interfaces or existing outgoing interfaces are not ignored 🙈. Other outgoing interfaces are left as is until they are explicitly pruned by downstream routers or are timed out due to lack of appropriate Join/Prune messages. 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), then 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 inform upstream routers that it expects multicast datagrams over the interface 🌸. It may also send a Join/Prune message with S in the Prune list out the old incoming interface, if the link is operational, to inform upstream routers that this part of the distribution tree is going away 🫶.

2.11 PIM-SM for Inter-Domain Multicast ✨

Okay so future documents are gonna cover using PIM-SM as a backbone inter-domain multicast routing protocol 🌍 The big design questions are mostly about how RP information gets distributed and used for wide area, inter-domain groups 🗺️ It's giving "stay tuned" energy 💅

2.12 Security 🔐

Bestie, all PIM control messages may use IPsec [6] to handle security concerns 🛡️ Security mechanisms are likely to be enhanced in the near future, so keep your eyes peeled 👀 This part is lowkey a big deal.

3 Detailed Protocol Description 🎀

This section is the deep dive from the point of view of one individual router implementation 🧠 For each message type, it walks through how the message gets generated and how it gets processed 💖

3.1 Hello 👋

Hello messages exist so neighboring routers can discover each other 🦋

3.1.1 Sending Hellos 📣

Hello messages go out periodically between PIM neighbors, every [Hello-Period] seconds ⏰ This is how routers find out which interfaces have PIM neighbors 🔍 Hellos are multicast to address 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 get sent on all types of communication links 🔗

3.1.2 Receiving Hellos 📥

When a router gets a Hello message, it stores the network layer address for that neighbor 📝 It sets its Neighbor-timer for the Hello sender to the Holdtime included in the Hello ⏳ Then it figures out the Designated Router (DR) for that interface 👑 The highest addressed system is the one elected DR, so no drama, just math 🧮 Every Hello received causes the DR's address to be updated 🔄

When a router that is the active DR receives a Hello from a new neighbor (i.e., from an address that is not yet in the DRs neighbor table), the DR unicasts its most recent RP-set information to the new neighbor 🎁 Main character energy for the DR, honestly 💅

3.1.3 Timing out neighbor entries 🕰️

There's a periodic process that times 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 the new DR is the one with the highest network layer 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 sent to join or prune a branch off of the multicast distribution tree 🌳 A single message contains both a join and a prune list, and either one of them is allowed to be null 🙈 Each list holds a set of source addresses, which tell the router which source-specific trees or shared tree it wants to join or prune 💜

3.2.1 Sending Join/Prune Messages ✨

Okay bestie, so Join/Prune messages get merged 🫶. A message going to one upstream neighbor, N, carries all the current joined and pruned sources that are reached through N. According to unicast routing, these messages get multicast to every router on a multi-access network, with the target address set to the next hop router toward S or RP 🦋. They go out every [Join/Prune-Period] seconds ⏰. We're planning to add ways to rate-limit this control traffic on each hop so small links don't get buried in overhead 🐢. Certain events also trigger extra Join/Prune messages right away 💥.

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:

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 the following 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.
A particular source address, S, is included in the join list with the RPT and WC bits cleared under the following 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.
A particular source address, S, is included in the prune list with the RPT and WC bits cleared under the following 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.
A particular source address, S, is included in the prune list with the RPT-bit set and the WC bit cleared under the following 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.
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).

Triggered Join/Prune Messages:

In addition to periodic messages, the following events will trigger Join/Prune messages 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 described above.

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).
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 an (*,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.
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 in the prune list and the RPT-bit set.
Receipt of a packet at the DR from a directly connected source S, on the subnet containing the address S, triggers a Join/Prune message towards the RP with S in the prune list and the RPT-bit set under the following conditions: a) there is no matching (S,G) state, and b) there exists a (*,G) or (*,*,RP) for which the DR is not the RP.
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.)
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.
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.
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 ✨.

Fragmentation: It is possible that a Join/Prune message constructed according to the preceding rules could exceed the MTU of a network. In this case, the message can undergo semantic fragmentation, whereby information corresponding to different groups can be sent in different messages. However, if a Join/Prune message must 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 such semantic fragmentation is not possible, IP fragmentation should be used between the two neighboring hops 💜.

3.2.2. Receiving Join/Prune Messages ✨

okay so bestie, here's what a router does the moment a Join/Prune message lands on its doorstep 💅 When a router receives a Join/Prune message, it processes it like this 🎀

The receiver of the Join/Prune notes the interface the PIM message arrived on, and we'll call that interface I 👀 Then it checks whether the Join/Prune was addressed to the receiving router itself, meaning the router's address shows up in the Unicast Upstream Neighbor Router field of the message. (If the router is connected to 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 happen next 🫶

For each group address G in the Join/Prune message, the associated join list gets processed. We call each address in the join list Sj, and Sj refers to the RP if the RPT-bit and WC-bit are both set 💜 Then, for each Sj in the join list of the Join/Prune message:

If an address, Sj, in the join list has the RPT-bit and WC-bit set, then Sj is the RP address the downstream router(s) are using, and these actions happen 🔥
1. If Sj is not the same as the receiving router's RP mapping for G, the receiving router may ignore the Join/Prune message with respect to that group entry. If the router doesn't have any RP-Set information, it may use the address Sj from the Join/Prune message as the RP for the group 🌸
2. If Sj is the same as the receiving router's RP mapping for G, the receiving router adds I to the outgoing interface list of the (*,G) route entry. (If there's no (*,G) entry, the router creates one first ✨) It sets the Oif-timer for that interface to the Holdtime from the Join/Prune message. The Oif-Deletion-Delay for that interface gets set to 1/3rd the Holdtime from the Join/Prune message too. If a (*,*,RP) entry exists for the RP associated with G, then the oif list of the newly created (*,G) entry is copied from that (*,*,RP) entry 🧚
3. For each (Si,G) entry associated with group G: i) if Si is not included in the prune list, ii) if I is not on the same subnet as the address Si, and iii) if I is not 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 included in the Join/Prune message. And if that Oif-timer gets increased, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime from the Join/Prune message 🦋

If the group address in the Join/Prune message is *, then every (*,G) and (S,G) entry whose group address hashes to the RP indicated in the (*,*,RP) Join/Prune message gets updated accordingly. A * in the group field of the Join/Prune is represented by the group address 224.0.0.0 and a group mask length of 4, which means a (*,*,RP) Join 👑

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 💀
The incoming interface is set to the interface used to send unicast packets to the RP in the (*,G) route entry. In other words, it's the RPF interface toward the RP 🌈

For each address, Sj, in the join list whose RPT-bit and WC-bit are not set, and for which there is no existing (Sj,G) route entry, the router starts one. The router creates a (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 is copied from the (*,G) entry. And if there's no (*,G) entry either, the oif list is copied from the (*,*,RP) entry, if it 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, this is an error (or a unicast routing change), and the Join/Prune must not be processed 🙅‍♀️
For each address, Sj, in the join list of the Join/Prune message, for which there is an existing (Sj,G) route entry:
1. If the RPT-bit is not set for Sj in the Join/Prune message, but the RPT-bit flag is set on the existing (Sj,G) entry, the router clears the RPT-bit flag on the (Sj,G) entry. It sets the incoming interface to point toward Sj for that (Sj,G) entry, and sends a Join/Prune message corresponding to that entry through the new incoming interface 🦋
2. If I is not 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 included in the Join/Prune message. And if that Oif-timer gets increased, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime from the Join/Prune message ⭐
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 Join/Prune message, the associated prune list gets processed like this. We call each address in the prune list Sp, and Sp refers to the RP if the RPT-bit and WC-bit are both set. For each Sp in the prune list of the Join/Prune message:

For each address, Sp, in the prune list whose RPT-bit and WC-bit are 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. This lets other downstream routers on a multi-access LAN 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 🧚
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. Other downstream routers on a multi-access LAN can still override the prune this way 💜 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 is not deleted. The Entry-timer gets restarted, even if its outgoing interface list is null ✨
3. If (*,G), or the corresponding (*,*,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 was received) deleted. 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 gets restarted 🌈
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. That gives other downstream routers on a multi-access LAN a chance to override the prune 👑 On point-to-point links, the Oif-timer expires immediately 😭
2. If the corresponding (*,*,RP) state exists but there's no (*,G) entry, a (*,G) entry gets created. Its outgoing interface list is copied from the (*,*,RP) entry, with the interface I (where the prune was received) deleted 🍓

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

If the entry has a Join/Prune-Suppression timer associated with it, and the received Join/Prune doesn't name the router as its target, then the receiving router checks the join and prune lists. It looks for any addresses that completely-match existing (S,G), (*,G), or (*,*,RP) state for which the receiving router is currently scheduling Join/Prune messages 🔥 An element on the join or prune list completely-matches a route entry only if both the addresses and the RPT-bit flag are the same 💅 If the incoming Join/Prune completely matches an existing (S,G), (*,G), or (*,*,RP) entry, and the Join/Prune arrived on the iif for that entry, then the router compares the Holdtime in the Join/Prune 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] is equal, the tie is settled in favor of the Join/Prune message originator with the higher network layer address 🏆 When the Join/Prune timer expires, the router triggers a Join/Prune message for the matching entry or entries ✨

3.3. Register and Register-Stop 🎀

okay this one's the sweetest 🥹 When a source first starts sending to a group, its packets get encapsulated in Register messages and sent to the RP. If the data rate calls for 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 this is how Register messages get sent 💅

okay bestie, first up: when a DR catches a packet from a directly connected source, S, on the subnet that holds the address S 🦋
1. if there's no corresponding (S,G) entry, the router has RP-Set information, and the DR is not the RP for G, the DR makes an (S,G) entry 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 gets copied from any existing (*,G) or (*,*,RP) entries, if they exist. the iif of the (S,G) entry is always excluded from the oif list. if a (*,G) or (*,*,RP) entry exists, the DR sends a Join/Prune message towards the RP with S in the prune list and the RPT-bit set 💖
2. if an (S,G) entry is already there, the DR just restarts the Entry-timer on it ⏰

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 came from a directly connected source. a separate document will cover the details of interoperability 🌈

if the new or previously existing (S,G) entry's Register-Suppression-timer isn't running, the data packet gets wrapped in a Register message and unicast to the RP for that group. the data packet also gets forwarded according to the DR's (S,G) state if the oif list isn't null, since a receiver may join the SP-tree while the DR is still registering to the RP 🎀
if the (S,G) entry's Register-Suppression-timer is running, the data packet isn't sent in a Register message. it just gets forwarded according to the (S,G) oif list 🙈

when the DR gets a Register-Stop message, it restarts the Register-Suppression-timer in the matching (S,G) entry(ies) at [Register-Suppression-Timeout] seconds. if there's data to be registered, the DR may send a null Register (a Register message with a zero-length data portion in the inner packet) to the RP, [Probe-Time] seconds before the Register-Suppression-timer expires, so it doesn't keep blasting occasional bursts of traffic at an RP for no reason 🫶

3.3.2 Receiving Register Messages and Sending Register-Stops 👑

when a router (i.e., the RP) receives a Register message, it does the following 👑

first it decapsulates the data packet and checks for a matching (S,G) entry
1. if an (S,G) entry with a cleared (0) SPT bit exists, and the received Register doesn't 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 stops a high datarate stream from setting off a huge pile of Register-Stop messages between the moment the first packet lands and the moment the source gets the first Register-Stop 🔥
2. if there's no (S,G) entry but there is a (*,G) entry, and the received Register doesn't have the Null-Register-Bit set to 1, the packet is forwarded according to the (*,G) entry 🌸
3. if there's a (*,*,RP) entry but no (*,G) entry, and the Register received doesn't 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 into the new entry. the packet is forwarded according to the created entry 🧚
4. if there's no G or (*,*,RP) entry for G, the packet is dropped and a Register-Stop is triggered 💀
5. a "Border bit" bit is added to the Register message to help with 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's no matching (S,G) state, but there's a (*,G) or (*,*,RP) entry, the RP makes a (S,G) entry with a PMBR field. this field holds the source of the Register (i.e. the outer network layer 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 isn't a null Register, the packet is forwarded according to the created state. Else,
  2. if the PMBR field for the matching (S,G) entry matches the source of the Register packet, and the received Register isn't a null Register, the decapsulated packet is forwarded to the oif list of that entry. Else,
  3. if the PMBR field for the matching (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 gets restarted by Registers arriving from that source to that group ⏰

if the matching (S,G) or (*,G) state has 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 inside the Register-Stop message is set to the wildcard value (all 0's). this message isn't processed by intermediate routers, so no (S,G) state gets built between the RP and the source 🙅‍♀️
if the Register message arrival rate warrants it and there's no existing (S,G) entry, the RP sets up a (S,G) route entry. its outgoing interface list, excluding iif(S,G), is copied from the (*,G) outgoing interface list, and its SPT-bit is initialized to 0. if there's no (*,G) entry but there is a (*,*,RP) entry with the RP corresponding to G, the oif list for (S,G) is copied (excluding the iif) from that (*,*,RP) entry 💅

an Entry-timer is set for the (S,G) entry, and this timer gets restarted whenever data packets for (S,G) arrive. the (S,G) entry makes the RP 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 won't be sent towards the source, S 🥺

3.4 Multicast Data Packet Forwarding ✨

processing a multicast data packet goes through these steps, periodt 🍓

look up route state using a longest match on the source address and an exact match on 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 doesn't need an exact match on the destination group address. in summary, the longest match happens in this order: (1) (S,G), (2) (*,G). if neither one matches, a lookup is done on (*,*,RP) entries 🔍
if the packet arrived on the interface found in the matching entry's iif field, and the oif list isn't null 🌊
1. forward the packet to the oif list for that entry, excluding the subnet containing S, and restart the Entry-timer if the matching entry is (S,G). optionally, the (S,G) Entry-timer may be restarted by periodically checking the matching packet count 💖
2. if the entry is an (S,G) entry with a cleared SPT-bit, and a (*,G) or associated (*,*,RP) also exists whose incoming interface is different from the one 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 isn't running, 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 catches packets arriving on the SP-tree and triggers their pruning from the RP-tree. if it's the DR for the source, it sends data packets encapsulated in Registers to the RPs 👑

if the packet matches an entry but didn't 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, look up 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 where a data packet matches an (S,G) entry whose SP-tree hasn't been fully built upstream yet 🧚
if the packet doesn't 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 find the RP for the destination group, G. the DR makes an (S,G) entry with the Register-Suppression-timer not running, encapsulates the data packet in a Register message, and unicasts it to the RP 🌈
if the packet doesn't match any entry, and it isn't from a local host or the router isn't the DR, drop the packet 🥀

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

okay so there are different ways to decide when to ditch the RP-based shared tree and switch over to source-specific shortest path trees 🌸 it's not one-size-fits-all, bestie 💅

one idea that's been floated is going off data rate 🔥 here's how it goes: when a (*,G), or the matching (*,*,RP), entry gets created, a data rate counter may be started at the last-hop routers. that counter goes up with every data packet received for directly connected members of an SM group, but only if the longest match is (*,G) or (*,*,RP) 👀

if and when the data rate for the group goes over a configured threshold (t1), the router starts up source-specific data rate counters for the packets that come next. then each source gets its own counter, which goes up when packets matching (*,G), or (*,*,RP), come in from that source 🦋 if the data rate from one particular source goes over a configured threshold (t2), an (S,G) entry gets created and a Join/Prune message gets sent towards the source ✨

and here's the sneaky bit 🙈 if the RPF interface for (S,G) is not the same as the one for (*,G) -or (*,*,RP), then the SPT-bit gets cleared in the (S,G) entry. main character energy for sure 👑

other configured rules can also be enforced to either cause or stop the (S,G) state from being set up 🧚

3.5 Assert

asserts are how routers figure out which one of the parallel routers hooked up to a multi-access LAN is the one in charge of forwarding packets onto that LAN 🎀 it's giving teamwork, but make it a fight for the title 😭

3.5.1 Sending Asserts

these Assert rules kick in when a multicast packet shows up on an outgoing multi-access interface I of an existing active (S,G), (*,G) or (*,*,RP) entry 💖

do a unicast routing table lookup on the source address from the data packet, and send an assert on interface I for the source address in the data packet. include the metric preference of the routing protocol and the metric from the routing table lookup 🌈
if no route is found, use a metric preference of 0x7fffffff and a metric of 0xffffffff 💀

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

asserts should be rate-limited in an implementation-specific way ✨

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 💅 but only active entries, the ones that have packet forwarding state, get matched 🔥 the router also checks the first bit of the metric preference (the RPT-bit) 🌸

if the RPT-bit is set, the router first tries to match (*,G), or (*,*,RP), entries. if no matching entry is found, it ignores the Assert 🙈
if the RPT-bit is not set in the Assert, the router first tries to match (S,G) entries. if no matching entry is found, the router matches (*,G) or (*,*,RP) entries 🦋

Receiving Asserts on an entry's outgoing interface:

if the interface that received the Assert message is in the oif list of the matched entry, then the router processes this Assert like this 💜

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 in response to the Assert 🎀
the router then compares the metric values received in the Assert with the metric values associated with the matched entry. the RPT-bit and metric preference (in that order) are treated as the high-order part of an Assert metric comparison. if the value in the Assert is less than the router's value (with ties broken by the IP address, where higher network layer address wins), delete the interface from the entry. when the 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 ⏰
if the router has won the election, the router keeps the interface in its outgoing interface list. it acts as the forwarder for the LAN 👑

the winning router sends an Assert message with its own metric to that outgoing interface. this makes the other routers on the LAN prune that interface from their route entries 🫶 the winning router sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit entry was matched 🌈

Receiving Asserts on an entry's incoming interface

if the Assert arrived on the incoming interface of an existing (S,G), (*,G), or (*,*,RP) entry, the Assert gets processed as follows 🔥 if the Assert message doesn't match the entry exactly, it's ignored. no longest-match in this case, bestie 🙅 if the Assert message does match exactly, then:

downstream routers select the upstream router with the smallest metric preference and metric as their RPF neighbor. if two metrics are the same, the highest network layer address is chosen to break the tie. this is important so that downstream routers send subsequent Joins/Prunes (in SM) to the correct neighbor 🧚 an Assert-timer gets initiated when the RPF neighbor changes to the Assert winner. when that timer expires, the router resets its RPF neighbor according to its unicast routing tables, to capture network dynamics and router failures ⏳
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

okay this section is about how the RP info gets spread around the whole domain 🦋 two main characters: the Candidate-RP-Advertisements (C-RP-Advs) and the Bootstrap messages 💅

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

Bootstrap messages are periodic PIM messages started by the Bootstrap router (BSR) inside a domain. they get forwarded hop-by-hop so the current RP-set can reach every router in that domain 🎀

the Bootstrap messages also have a simple mechanism for electing the BSR: the Candidate BSR (C-BSR) with the highest BSR-priority and address (called the preferred BSR) becomes the BSR for the domain 👑 we recommend that each router configured as a C-RP also be configured as a C-BSR 🫶 Sections 3.6.2 and 3.6.3 describe how Bootstrap messages do double duty as both the vehicle 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 that domain 💜 how often they send these is up to local configuration at the C-RP ⏰

C-RP-Advs carry group address and group mask fields 🌈 this lets the advertising router limit the advertisement to certain prefixes or scopes of groups 🍓 the advertising router may enforce this scope acceptance when it receives Registers or Join/Prune messages 🙈 C-RPs should send C-RP-Adv messages with the Priority field set to 0 🔥

3.6.2 Receiving C-RP-Advs and Originating Bootstrap

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

if the router is not the elected BSR, it ignores the message. else, 🌸
the BSR adds the RP address to its local pool of candidate RPs, according to the associated group prefix(es) in the C-RP-Adv message 🎀 the Holdtime in the C-RP-Adv message is also stored with the corresponding RP, to be included later in the Bootstrap message ⏳ the BSR may apply a local policy to limit the number of Candidate RPs included in the Bootstrap message 👑 the BSR may override the prefix indicated in a C-RP-Adv unless the Priority field is not zero 🫶

the BSR keeps an RP-timer for each RP in its local RP-set 🦋 the RP-timer is initialized to the Holdtime in the RP's C-RP-Adv. when the timer expires, that RP gets removed from the RP-set 💀 the RP-timer is restarted by the C-RP-Advs from the corresponding RP ✨

the BSR also uses its Bootstrap-timer to periodically send Bootstrap messages 🧚 specifically, when the Bootstrap-timer expires, the BSR originates a Bootstrap message on each of its PIM interfaces 💖 to reduce the bootstrap message overhead during partition healing, the BSR should set a random time (as a function of the priority and address) after which the Bootstrap message is originated only if no other preferred Bootstrap message is received 🌈 for details, see appendix 6.2 🙈 the message is sent with a TTL of 1 to the ALL-PIM-ROUTERS' group 💜 in steady state, the BSR originates Bootstrap messages periodically 🔥 at startup, the Bootstrap-timer is initialized to [Bootstrap-Timeout], so the first Bootstrap message only gets originated when and if that timer expires ⏰ for timer details, see Section 3.6.3 🍓 a DR unicasts a Bootstrap message to each new PIM neighbor, i.e., after the DR receives the neighbor's Hello message (it does so 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 corresponding Holdtime goes in the RP-Holdtime field 🌸 the format of the Bootstrap message allows semantic fragmentation if the length of the original Bootstrap message goes over the packet maximum boundaries (see Section 4) 😭 but we recommend against configuring a large number of routers as C-RPs, so there's less semantic fragmentation needed ✨

3.6.3 Receiving and Forwarding Bootstrap ✨

okay bestie, every router keeps a Bootstrap-timer ⏰ that gets set to [Bootstrap-Timeout] when it starts up 🌸

when a router gets a Bootstrap message sent to ALL-PIM-ROUTERS' group, it does this, no cap 💅

If the message was not sent by the RPF neighbor towards the BSR address included, the message is dropped. Else
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 BSR address and priority found in the message, and restarts the timer by setting it to [Bootstrap-Timeout]. The Bootstrap message is then forwarded out all PIM interfaces, excluding the one over which the message arrived, to ALL-PIM-ROUTERS' group, with a TTL of 1. 🦋
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, excluding the one over which the message arrived, to ALL-PIM-ROUTERS' group, with a TTL of 1.

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 obtains the RP-Set and BSR address from its DR. 🧚

the way that a new RP-Set gets handled is so iconic 👑 when a router receives a new RP-Set, it checks if each of the RPs referred to by existing state (i.e., by (,G), (,*,RP), or (S,G)RPT-bit entries) is in the new RP-Set. if an RP is not in the new RP-set, that RP is considered unreachable and the hash algorithm (see below) is re-performed for each group with locally active state that previously hashed to that RP. this will cause those groups to be distributed among the remaining RPs. when the new RP-Set contains a new RP, the value of the new RP is calculated for each group covered by that C-RP's Group-prefix. any group for which the new RP's value is greater than the previously active RP's value is switched over to the new RP. 🌈

3.7 Hash Function 🔮

the hash function is used by all routers within a domain to map a group to one of the C-RPs from the RP-Set. for a particular group, G, the hash function uses only those C-RPs whose Group-prefix covers G. the algorithm takes as input the group address and the addresses of the Candidate RPs, and gives as output one RP address to be used.

the protocol requires that all routers hash to the same RP within a domain (except for transients). the following hash function must be used in each router:

For RP addresses in the RP-Set, whose Group-prefix covers G, select the RPs with the highest priority (i.e. lowest `Priority' value), and compute a value:

Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31

where C_i is the RP address and M is a hash-mask included in Bootstrap messages. The hash-mask allows a small number of consecutive groups (e.g., 4) to 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.

For address families other than IPv4, a 32-bit digest to be used as C_i must first be derived from the actual RP address. Such a digest method must be used consistently throughout the PIM domain. For IPv6 addresses, we recommend using the equivalent IPv4 address for an IPv4-compatible address, and the CRC-32 checksum [7] of all other IPv6 addresses. 💜

From the RPs with the highest priority (i.e. lowest `Priority' value), 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 RPs having the same hash value and priority 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 ⏱️

in this subsection, we enumerate all timers that have been discussed or implied. since some critical timer events are not associated with the receipt or sending of messages, they are not fully covered by 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, DRs 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 network layer 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)

(*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G)
(*,G)  oif-timer  value  | (*,G) oif-timer restarted    | (S,G)

Okay so when the oif-timer expires 💀, the oif gets removed from the oiflist, unless there are directly-connected members hanging around (they stay!) 🫶 And when an oif is deleted, it's also removed from any associated (S,G) or (*,G) entries. Lowkey important stuff.

[Entry-Timer (kept per route entry)] Every route entry gets its own Entry-Timer ⏰, and that's what times the entry out. The tables below show what it's set to when an oif first joins the entry's oiflist, and when it should get restarted (unless it's already higher, because we don't go backwards 💅).

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
oif-timer value       | any oif-timer restarted  | (S,G)RPT-bit (*,G)
                      |                          | (*,*,RP)
[Assert-Timeout]      | assert received          | (S,G)RPT-bit (*,G)
                      |                          | w/null oif

When this timer expires, the whole route entry gets deleted 🗑️. If it's a (,G) or (,*,RP) entry, all the associated (S,G)RPT-bit entries get deleted too. Bye bye, bestie 😭

[Register-Suppression-Timer (kept per (S,G) route entry)] Each (S,G) route entry has its own Register-Suppression-Timer 🛑, and its whole job is to stop registers when the RP is already getting data natively. When a Register-Stop for the entry comes in from the RP, the timer gets set to a random value somewhere between 0.5 * [Register-Suppression-Timeout] and 1.5 * [Register-Suppression-Timeout]. While it's running, Registers for that entry are suppressed 🙈 If null registers are used, a null register gets sent [Probe-Time] seconds before the timer expires.
[Assert-Timer (per (S,G) or (*,G) route entry)] The Assert-Timer is for timing out the Asserts you've received 🎀 When an Assert comes in and the RPF neighbor changes to the Assert winner, the Assert-Timer is set to [Assert-Timeout]. Then it gets restarted to that same value every time another Assert for the entry shows up on its incoming interface. When the timer expires, the router resets its RPF neighbor using its unicast routing table. Reset era 🔄
[Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)] This one exists so downstream routers on a LAN don't all do the same thing at the same time when their RPF neighbor changes 🧚 When that happens, the timer gets set to a random value between 0 and [Random-Delay-Join-Timeout] seconds. When it 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 how Hello messages get sent periodically 👋 To keep routers that boot up at the same time from syncing up, it starts at a random value between 1 and [Hello-Period]. When it expires, it's immediately restarted to [Hello-Period], and then a Hello message goes out each interface. This timer should not be restarted by other events. Keep your hands off it 🫶
[Neighbor-Timer (kept per neighbor)] Every neighbor gets a Neighbor-Timer, and that's what times out the neighbor state ✨ When a Hello message comes in from a new neighbor, the timer is initially set to the Holdtime included in that Hello (which is equal to the neighbor's value of [Hello-Holdtime]). Every time a later Hello comes in 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)] Routers that are configured as candidate RP's use this timer to send C-RP-Adv messages periodically 🦋 Same deal as the Hello-Timer: to avoid synchronization among routers booting at the same time, it's initially set to a random value between 1 and [C-RP-Adv-Period]. When it expires, it's immediately restarted to [C-RP-Adv-Period], and then a C-RP-Adv message is 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 tell if that 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 the C-RP's value of [RP-Holdtime]). Every time a later C-RP-Adv comes in from that RP, its timer is restarted to the Holdtime in the C-RP-Adv. When the timer expires, the RP is removed from the RP-Set that goes out in Bootstrap messages 🚪
[Bootstrap-Timer] This timer is used by the BSR to originate Bootstrap messages periodically, and by other routers to time out the BSR (see 3.6.3). It's initially set to [Bootstrap-Timeout]. A C-BSR restarts this timer to [Bootstrap-Timeout] when it receives 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 this timer to [Bootstrap-Timeout] when they receive a Bootstrap message from the elected BSR or a more preferred one, and they ignore Bootstrap messages from non-preferred C-BSRs while it's running 🥹

3.8.4 Default timer values

Heads up, this section is where the numbers live 🔢

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 gets included in the Holdtime field of the Hellos. To improve convergence, though, the default timeout value for information related to RP liveness and Bootstrap messages is 2.5 times the refresh period 🏃‍♀️

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 on 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 things like the configured bandwidth and the expected average number of multicast route entries for the attached network or link. For example, the period would be longer for lower-speed links, or for routers in the center of the network that expect a larger number of entries. A router could also modify this value (and the corresponding Join/Prune-Holdtime value) if the number of route entries changes significantly, like by an order of magnitude. Say the number of route entries with a particular iif goes 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, and if the number of entries drops back to N, the Join/Prune-Period (and Join/Prune-Holdtime) could go back down to its previous value. If the Join/Prune-Period is modified, these changes should be made relatively infrequently, and the router should keep refreshing at its previous Join/Prune-Period for at least Join/Prune-Holdtime so the upstream router has time to adapt 🫶
[Join-Prune Holdtime] This is the Holdtime specified in Join/Prune messages, and it's used to time out oifs. It 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 network layer address) and allowing duplicate Join/Prunes to be sent again. It 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 gets 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 the RP, while a higher value means longer join latency for new receivers. Default: 60 seconds. (Fun fact: if null Registers are sent [Probe-Time] seconds before the timeout, register bursts are prevented, and [Register-Suppression-Timeout] can 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's restarted by receiving a Register-Stop. So a null Register would be 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. It 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. It 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. It should be set to 2 * [Bootstrap-Period] + 10'. Default: 130 seconds 💖

3.9 Summary of flags used ✨

Okay bestie, here's the cheat sheet of every flag in our scheme 🫶 Some of these show up in more than one place, so I've kept them exactly as the table has them.

Bit           | Used in     | Definition

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 🔒

Security time, and it's giving serious. 🔐 All PIM control messages may use IPsec [6] to address security concerns.

4 Packet Formats 📦

This section is where we get into the nitty-gritty packet formats for PIM control messages 💅

All PIM control messages have protocol number 103 🎀

Basically, PIM messages are either unicast (like Registers and Register-Stop) or multicast hop-by-hop to the ALL-PIM-ROUTERS group 224.0.0.13 (like 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  | Reserved      |           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

Reserved: set to zero. Ignored upon receipt. 🧚
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 these are the three little address "boxes" that show up everywhere. Super iconic, honestly. ✨

1. Encoded-Unicast-address: Takes the following format:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type |     Unicast Address           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++

Addr Family: The address family of the Unicast Address field of this address.

Here are the address family numbers assigned by IANA 📋

 Number    Description
 --------  ---------------------------------------------------------
      0    Reserved
      1    IP (IP version 4)
      2    IP6 (IP version 6)
      3    NSAP
      4    HDLC (8-bit multidrop)
      5    BBN 1822
      6    802 (includes all 802 media plus Ethernet "canonical format")
      7    E.163
      8    E.164 (SMDS, Frame Relay, ATM)
      9    F.69 (Telex)
     10    X.121 (X.25, Frame Relay)
     11    IPX
     12    Appletalk
     13    Decnet IV
     14    Banyan Vines
     15    E.164 with NSAP format subaddress

Encoding Type: The type of encoding used within a specific Address Family. The value 0 is reserved for this field, and represents the native encoding of the Address Family. 🍓
Unicast Address: The unicast address as represented by the given Address Family and Encoding Type.

2. Encoded-Group-Address: Takes the following format:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type |   Reserved    |  Mask Len     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Group multicast Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Addr Family: described above.
Encoding Type: described above.
Reserved: Transmitted as zero. Ignored upon receipt.
Mask Len: The Mask length is 8 bits. The value is the number of contiguous bits left justified used as a mask which describes the address. It is less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group then the Mask length must equal the address length in bits for the given Address Family and Encoding Type. (e.g. 32 for IPv4 native encoding and 128 for IPv6 native encoding). 💜
Group multicast Address: contains the group address.

3. Encoded-Source-Address: Takes the following format:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type | Rsrvd   |S|W|R|  Mask Len     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Source Address                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Addr Family: described above.
Encoding Type: described above.
Reserved: Transmitted as zero, ignored on receipt.
S,W,R: See Section 4.5 for details.
Mask Length: Mask length is 8 bits. The value is the number of contiguous bits left justified used as a mask which describes the address. The mask length must be less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group then the Mask length must equal the address length in bits for the given Address Family and Encoding Type. In version 2 of PIM, it is strongly recommended that this field be set to 32 for IPv4 native encoding. 🙈
Source Address: The source address.

4.2 Hello Message 👋

It is sent periodically by routers on all interfaces. 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  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OptionType              |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          OptionValue                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OptionType              |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          OptionValue                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++

PIM Version, Type, Reserved, Checksum: Described above.
OptionType: The type of the option given in the following OptionValue field.
OptionLength: The length of the OptionValue field in bytes.
OptionValue: A variable length field, carrying the value of the option.

The Option fields may contain the following values:

OptionType = 1; OptionLength = 2; OptionValue = Holdtime; where Holdtime is the amount of time a receiver must keep the neighbor reachable, in seconds. If the Holdtime is set to 0xffff, the receiver of this message never times out the neighbor. This may be used with ISDN lines, to avoid keeping the link up with periodic Hello messages. Furthermore, if the Holdtime is set to 0, the information is timed 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

4.3 Register Message 💌

A Register message is sent by the DR or a PMBR to the RP when a multicast packet needs to be transmitted on the RP-tree. Source address is set to the address of the DR, destination address is to the RP's address. Main character energy, honestly 👑

     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  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |B|N|                       Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
                          Multicast data packet
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Type, Reserved, Checksum: Described above. Note that the checksum for Registers is done only on the PIM header, excluding the data packet portion. 🧾
B: The Border bit. If the router is a DR for a source that it is directly connected to, it sets the B bit to 0. If the router is a PMBR for a source in a directly connected cloud, it sets the B bit to 1.
N: The Null-Register bit. Set to 1 by a DR that is probing the RP before expiring its local Register-Suppression timer. Set to 0 otherwise.
Multicast data packet: The original packet sent by the source.

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

4.4 Register-Stop Message ✨

okay so the Register-Stop is the RP's little "stop sending me that" message 🛑💅. It's unicast from the RP back to whoever sent the Register, so no flooding, just one-to-one bestie energy 🫶. The source address is the address the register was aimed at, and the destination address is the source address of that 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  | Reserved      |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Encoded-Group Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Encoded-Unicast-Source Address             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Type, Reserved, Checksum 🧩 Described above.

Encoded-Group Address 🎯 Format described above. Heads up, though: for Register-Stops the Mask Len field holds the full address length * 8 (so 32 for IPv4 native encoding) if the message is sent for a single group. 👀

Encoded-Unicast-Source Address 🌟 This is the host address of the source from the multicast data packet in the register. The format is the Encoded-Unicast-Address from 4.1. There's also a special wild card value, 0s, that can be used to mean "any source" 🌈.

4.5 Join/Prune Message 🦋

okay this one is the main event 🎀. A Join/Prune message is sent by routers towards upstream sources and RPs. Joins build shared trees (RP trees) or source trees (SPT) 🌳, and Prunes take 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  | Reserved      |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Encoded-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, Reserved, Checksum 🧩 Described above.

Encoded-Unicast Upstream Neighbor Address 🧭 This is the address of the RPF or upstream neighbor. The format is the Encoded-Unicast-Address from 4.1.

Reserved 🫧 Transmitted as zero, ignored on receipt.

Holdtime ⏰ This is how long, in seconds, a receiver must keep the Join/Prune state alive. If the Holdtime is 0xffff, the receiver never times out the oif 🙈. That's handy with ISDN lines, since it avoids keeping the link up with periodic Join/Prune messages 📞. And if the Holdtime is 0, the info times out immediately 💀.

Number of Groups 🔢 The number of multicast group sets in the message.

Encoded-Multicast Group Address 🎀 For the format, see Section 4.1. A wild card group in the (,,RP) join is shown as 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 💜.

Number of Joined Sources 📥 The number of join source addresses listed for a given group.

Join Source Address-1 .. n 💖 This list has the sources the sending router will forward multicast datagrams for, if they're received on the interface this message is sent on. For the format, see Section 4.1. Here's the breakdown of the Encoded-Source-Address format 💅:

Reserved 🫧 Described above.

S ✨ The Sparse bit is a 1-bit value, set to 1 for PIM-SM. It's there for PIM v.1 compatibility 🕰️.

W 🔥 The WC bit is a 1-bit value. If it's 1, the join or prune applies to the (,G) or (,*,RP) entry. If it's 0, it applies to the (S,G) entry, where S is the Source Address. Joins and prunes sent towards the RP must have this bit set 👑.

R 🌈 The RPT-bit is a 1-bit value. If it's 1, the info about (S,G) is sent towards the RP. If it's 0, the info must be sent toward S, where S is the Source Address 🧚.

Mask Length, Source Address 🍓 Described above.

It's represented in the form of:

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

Some examples, because I know you love a visual 🥹:

A source address can be a host IPv4 native encoding address:

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

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

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

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

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

A source address can be a general aggregate:

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

Number of Pruned Sources ✂️ The number of prune source addresses listed for a group.

Prune Source Address-1 .. n 🙅‍♀️ This list has the sources the sending router does not want to forward multicast datagrams for, when they're received on the interface this message is sent on. Also, if the Join/Prune message boundary goes over the maximum packet size, the join and prune lists for the same group must be included in the same packet 📦🫶.

4.6. Bootstrap Message ✨

okay bestie, Bootstrap messages get multicast to the `ALL-PIM-ROUTERS' group 🌸, and they go out every interface that has PIM neighbors (except the one it came in on, obviously 💅). They're sent with TTL value of 1 🫶. They start at the BSR and get forwarded by intermediate routers.

If a Bootstrap message is bigger than the maximum packet size, it gets split up into `semantic fragments' 🧩.

Here's the layout of a single `fragment' 👀:

     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  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Fragment Tag          | Hash Mask len | BSR-priority  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-BSR-Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-1               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RP-Count-1    | Frag RP-Cnt-1 |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP1-Holdtime         | RP1-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP2-Holdtime         | RP2-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-m                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RPm-Holdtime         | RPm-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-2               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RP-Count-n    | Frag RP-Cnt-n |          Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP1-Holdtime         | RP1-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP2-Holdtime         | RP2-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-m                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RPm-Holdtime         | RPm-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Type, Reserved, Checksum 📦 Described above.

Fragment Tag 🏷️ A randomly generated number that tells apart the fragments from different Bootstrap messages. Fragments that belong to the same Bootstrap message carry the same `Fragment Tag'. 🎀

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

BSR-priority 👑 Contains the BSR priority value of the included BSR. This field is considered as a high order byte when comparing BSR addresses. Main character energy 😤✨

Encoded-Unicast-BSR-Address 📍 The address of the bootstrap router for the domain. The format for this address is given in the Encoded-Unicast-Address in 4.1.

Encoded-Group Address-1..n 🌈 The group prefix (address and mask) that the Candidate RPs are associated with. Format previously described.

RP-Count-1..n 🔢 The number of Candidate RP addresses included in the whole Bootstrap message for the corresponding group prefix. A router does not replace its old RP-Set for a given group prefix until/unless it receives `RP-Count' addresses for that prefix. The addresses could be carried over several fragments. If only part of the RP-Set for a given group prefix was received, the router discards it, without updating that specific group prefix's RP-Set. Not gonna lie, this one is a whole mood 🙈

Frag RP-Cnt-1..m 🧮 The number of Candidate RP addresses included in this fragment of the Bootstrap message, for the corresponding group prefix. The `Frag RP-Cnt' field makes it easier to parse the RP-Set for a given group prefix when it's carried over more than one fragment. 🦋

Encoded-Unicast-RP-address-1..m 🎯 The address of the Candidate RPs, for the corresponding group prefix. The format for this address is given in the Encoded-Unicast-Address in 4.1.

RP1..m-Holdtime ⏳ The Holdtime for the corresponding RP. This field is copied from the `Holdtime' field of the associated RP stored at the BSR.

RP1..m-Priority 🥇 The Priority' of the corresponding RP and Encoded-Group Address. This field is copied from the Priority' field stored at the BSR when receiving a Candidate-RP-Advertisement. The highest priority is 0' (i.e. the lower the value of the Priority' field, the higher). Note that the priority is per RP per Encoded-Group Address. Lower number = higher vibes 🌟

4.7. Assert Message 🎭

The Assert message gets sent when a multicast data packet is received on an outgoing interface that corresponds to the (S,G) or (*,G) associated with the source. Drama alert 🚨

     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  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Encoded-Group Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Encoded-Unicast-Source Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|                        Metric Preference                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Metric                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Type, Reserved, Checksum 📦 Described above.

Encoded-Group Address 🌸 The group address that the data packet was addressed to, and which triggered the Assert. Format previously described.

Encoded-Unicast-Source Address 🫧 Source address from the multicast datagram that triggered the Assert packet to be sent. The format for this address is given in the Encoded-Unicast-Address in 4.1.

R 🔁 The RPT-bit is a 1 bit value. If the multicast datagram that triggered the Assert packet is routed down the RP tree, then the RPT-bit is 1. If the multicast datagram is routed down the SPT, it is 0. 🌳

Metric Preference 💅 Preference value assigned to the unicast routing protocol that provided the route to Host address.

Metric 📏 The unicast routing table metric. The metric is in units applicable to the unicast routing protocol used.

4.8. Graft Message 🌿

Used in dense-mode. Refer to PIM dense mode specification. 🫶

4.9. Graft-Ack Message ✅

Used in dense-mode. Refer to PIM dense mode specification. 💜

4.10. Candidate-RP-Advertisement 🎀

okay so Candidate-RP-Advertisements are periodically unicast from the C-RPs to the BSR 💌 (bestie, the C-RPs are the ones volunteering to be RPs, and they keep reminding the BSR they exist 🙈)

     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  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Prefix-Cnt    |   Priority    |             Holdtime          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-1               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Type, Reserved, Checksum ✨ Described above.
Prefix-Cnt 🍓 The number of encoded group addresses included in the message, indicating the 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, i.e. all multicast groups. If the C-RP is not configured with Group-prefix information, the C-RP puts a default value of 0 in this field.
Priority 👑 The Priority of the included RP, for the corresponding Encoded-Group Address (if any). Highest priority is 0 (i.e. the lower the value of the Priority field, the higher the priority). This field is stored at the BSR upon receipt along with the RP address and corresponding Encoded-Group Address.
Holdtime ⏳ The amount of time the advertisement is valid. This field allows advertisements to be aged out, so nothing gets stuck around forever 💅
Encoded-Unicast-RP-Address 🦋 The address of the interface to advertise as a Candidate RP. The format for this address is given in the Encoded-Unicast-Address in 4.1.
Encoded-Group Address-1..n 🌈 The group prefixes for which the C-RP is advertising. Format previously described.

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 provided detailed comments on previous drafts. The authors of CBT [8] and membership of the IDMR WG provided many of the motivating ideas for this work and useful feedback on design details. Major thank-yous to all of them 💖

This work was supported by the National Science Foundation, ARPA, cisco Systems and Sun Microsystems ✨

6. Appendices 🧚

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

This appendix populates the major changes in the specification document as compared to draft-ietf-idmr-pim-spec-01.ps,txt. It's the glow-up log 💅

Major Changes

List of changes since March '96 IETF:

(,,RP) Joins state and data forwarding check; replaces (,G-Prefix) Joins state for interoperability. (,G) negative cache introduced for the (,,RP) state supporting mechanisms.
Semantic fragmentation for the Bootstrap message.
Refinement of Assert details.
Addition and refinement of Join/Prune suppression and Register suppression (introduction of null Registers).
Editorial changes and clarifications to the timers section.
Addition of Appendix II (BSR Election and RP-Set Distribution), and Appendix III (Glossary of Terms).
Addition of table of contents.

List of changes incurred since version 1 of the spec.:

Proposal and refinement of bootstrap router (BSR) election mechanisms
Introduction of hash functions for Group to RP mapping
New RP-liveness indication mechanisms based upon the the Bootstrap Router (BSR) and the Bootstrap messages.
Removal of reachability messages, RP reports and multiple RPs per group.

Packet Format Changes

Packet Format incurred updates to accommodate different address lengths, and address aggregation.

The Addr Family and Encoding Type fields were added to the packet formats.
The Encoded source and group address formats were introduced, with the use of a Mask length field to allow aggregation, section 4.1.
Packet formats are no longer IGMP messages; rather PIM messages.

PIM message types and formats were also modified:

[Note: most changes were made to the May 95 version, unless otherwise specified].

Obsolete messages:
- Register-Ack [Feb. 96]
- Poll and Poll Response [Feb. 96]
- RP-Reachability [Feb. 96]
- RPlist-Mapping [Feb. 96]
New messages:
- Candidate-RP-Advertisement [change made in October 95]
- RP-Set [Feb. 96]
Modified messages:
- Join/Prune [Feb. 96]
- Register [Feb. 96]
- Register-Stop [Feb. 96]
- Hello (addition of OptionTypes) [Aug 96]
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 🗳️

For simplicity, the bootstrap message is used in both the BSR election and the RP-Set distribution mechanisms. These mechanisms are described by the following state machine, illustrated in figure 4. The protocol transitions for a Candidate-BSR are given in state diagram (a). For routers not configured as Candidate-BSRs, the protocol transitions are given in state diagram (b).

[Figures are present only in the postscript version] Fig. 4 State Diagram for the BSR election and RP-Set distribution

Each PIM router keeps a bootstrap-timer, initialized to [Bootstrap-Timeout], in addition to a local BSR field LclBSR (initialized to a local address if Candidate-BSR, or to 0 otherwise), and a local RP-Set LclRP-Set (initially empty). The main stimuli to the state machine are timer events and arrival of bootstrap messages:

Initial States and Timer Events ⏰

(blank)
If the router is a Candidate-BSR:
1. (blank)
2. The router operates initially in the `CandBSR' state, where it does not originate any bootstrap messages.
3. If the bootstrap-timer expires, and the current state is CandBSR', the router originates a bootstrap message carrying the local RP-Set and its own BSR priority and address, restarts the bootstrap-timer at [Bootstrap-Period] seconds, and transits into the ElectedBSR' state. Note that the actual sending of the bootstrap message may be delayed by a random value to reduce transient control overhead. To obtain best results, the random value is set such that the preferred BSR is the first to originate a bootstrap message. We propose the following as an efficient implementation of the random value delay (in seconds):

Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) + AddrDelay

where myPriority is the Candidate-BSR's configured priority, and bestPriority equals:

bestPriority = Max(storedPriority, myPriority)

and AddrDelay is given by the following:

if ( bestPriority equals myPriority) then
    AddrDelay = log_2(bestAddr - myAddr) / 16
else
    AddrDelay = 2 - (myAddr / 2^31)

where myAddr is the Candidate-BSR's address, and bestAddr is the stored BSR's address.

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

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

In this case, if an elected BSR becomes unreachable, the routers start accepting bootstrap messages from another Candidate-BSR after the bootstrap-timer expires. All PIM routers within a domain converge on the preferred reachable Candidate-BSR 🌸

Receiving Bootstrap Message 📬

To avoid loops, an RPF check is performed on the included BSR address. Upon receiving a bootstrap message from the RPF neighbor toward the included BSR, the following actions are taken:

If the router is not a Candidate-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.
If the router is a Candidate-BSR, and the bootstrap message is preferred, the message is accepted. Further, if this happens when the current state is Elected BSR, the router transits into the CandBSR state.

When a bootstrap message is accepted, the router restarts the bootstrap-timer at [Bootstrap-Timeout], stores the received BSR priority and address in LclBSR, and the received RP-Set in LclRP-Set, and 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 alphabetical, so you can just scroll and find what you need 💅

Bootstrap router (BSR). 👑 A BSR is a router that gets dynamically elected inside a PIM domain. It builds the RP-Set and sends out Bootstrap messages. main character energy, fr fr 🎀
Candidate-BSR (C-BSR). 🦋 A C-BSR is a router that's set up to take part in the BSR election and become a BSR if it wins 💖
Candidate RP (C-RP). 🌸 A C-RP is a router that's configured to keep sending Candidate-RP-Advertisement messages to the BSR. When it gets Join/Prune or Register messages for the group prefix it advertised, it acts as an RP 🧚
Designated Router (DR). 💅 The DR sets up multicast route entries and sends the matching Join/Prune and Register messages for the directly-connected receivers and sources, respectively. It might or might not be the same router as the IGMP Querier. It might or might not be the long-term, last-hop router for the group. If a router on the LAN has a route to the data source, or to the group's RP, with a lower metric, that router can take over sending the Join/Prune messages 🔥
Incoming interface (iif). 🌈 The iif of a multicast route entry is the interface that multicast data packets get accepted from for forwarding. It gets set when the entry is created ✨
Join list. 🍓 The Join list is one of the two address lists included in a Join/Prune message. Each address points to a source or an RP. It shows which sources or RPs the downstream receivers want to join 💜
Last-hop router. 🙈 The last-hop router is the final router that multicast data packets pass through before they reach directly-connected member hosts. Usually that's the DR for the LAN. But in some situations this document describes, a parallel router on the same LAN can take over as the last-hop router instead of the DR 💀
Outgoing interface (oif) list. 🦋 Every multicast route entry has an oif list. It holds the outgoing interfaces that multicast packets should get forwarded out of 🫶
Prune list. 🌸 The Prune list is the second address list inside a Join/Prune message. It shows the sources or RPs that the downstream receivers want to prune from 🍓
PIM Multicast Border Router (PMBR). 🌈 A PMBR connects a PIM domain to other multicast routing domains 👑
Rendezvous Point (RP). 🧚 Every multicast group has a shared tree. Receivers hear about new sources through it, 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 gets. It gets distributed to every PIM router in the BSR's 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 address X is the next-hop router that gets used to forward packets toward X. The RPF interface is the interface that leads to that RPF neighbor. Usually that's the next hop the unicast routing protocol uses to send unicast packets toward X. But when unicast and multicast routes aren't congruent, it can be different 🔥
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. A route entry can be different from the forwarding entry, which is what actually forwards data packets in real time. A forwarding entry usually 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 when all the shortest paths connecting receivers to the source get merged together. Those shortest paths are determined by unicast routing 💜
Sparse Mode (SM). 🍓 SM is one operating mode of a multicast protocol. PIM SM uses explicit Join/Prune messages and Rendezvous Points in place of the broadcast-and-prune mechanism that Dense Mode PIM and DVMRP use 🧚
Wildcard (WC) multicast route entry. ✨ Wildcard multicast route entries are the entries that can be used to forward packets from any source sending to the specified group. Wildcard bots in the Join list of a Join/Prune message stand for either a (*,G) or a (*,*,RP) join. In the Prune list, they stand for a (*,G) prune 🫶
(S,G) route entry. 🌈 An (S,G) entry is a source-specific route entry. It can get created because of data packets, Join/Prune messages, or Asserts. (S,G) state in routers creates a source-rooted distribution tree, either shortest path or reverse shortest path. (S,G)RPT bit entries are source-specific entries on the shared RP-Tree. They're used to prune particular sources off the 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. 🔥 A (*,*,RP) entry refers to any source and any multicast group that maps to the RP in the entry. The routers along the shortest path branches between a domain's RP(s) and its PMBRs keep (*,*,RP) state. If data packets arrive that don't have a longer match, they use that state to figure out how to deliver packets toward the PMBRs. The wildcard group in a (*,*,RP) route entry is shown as the group address 224.0.0.0 with a mask length of 4 bits 👑

References

Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast (pim): Motivation and Architecture", Work in Progress. 📖
S. Deering, 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. 📖
Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast-dense Mode (pim-dm): Protocol Specification", Work in Progress. 📖
Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. 📖
Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. 📖
Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. 📖
Mark R. Nelson. File verification using CRC. Dr. Dobb's Journal, May 1992. 📖
A.J. Ballardie, P.F. Francis, and J. Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993. 📖

Authors' Addresses

NOTE: The author list has been reordered to reflect the involvement in detailed editorial work on this specification document. The first four authors are the primary editors and are listed alphabetically. The rest of the authors, also listed alphabetically, participated in all aspects of the architectural and detailed design but managed to get away without hacking the latex! 💅🫶

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

EMail: estrin@usc.edu


Dino Farinacci
Cisco Systems Inc.
170 West Tasman Drive,
San Jose, CA 95134

EMail: dino@cisco.com


Ahmed Helmy
Computer Science Dept.
University of Southern Calif.
Los Angeles, CA 90089

EMail: ahelmy@catarina.usc.edu


David Thaler
EECS Department
University of Michigan
Ann Arbor, MI 48109

EMail: thalerd@eecs.umich.edu
Stephen Deering
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94304

EMail: deering@parc.xerox.com

Mark Handley
Department of Computer Science
University College London
Gower Street
London, WC1E 6BT
UK

EMail: m.handley@cs.ucl.ac.uk


Van Jacobson
Lawrence Berkeley Laboratory
1 Cyclotron Road
Berkeley, CA 94720

EMail: van@ee.lbl.gov


Ching-gung  Liu
Computer Science Dept.
University of Southern Calif.
Los Angeles, CA 90089

EMail: charley@catarina.usc.edu


Puneet Sharma
Computer Science Dept.
University of Southern Calif.
Los Angeles, CA 90089

EMail: puneet@catarina.usc.edu


Liming Wei
Cisco Systems Inc.
170 West Tasman Drive,
San Jose, CA 95134

EMail: lwei@cisco.com

Full Copyright Statement

This document and translations of it can be copied and shared with others. Derivative works that comment on or explain it, or help with implementing it, can be made, copied, published, and distributed, in whole or in part, with no restriction at all. The one condition is that the above copyright notice and this paragraph get included on all of those copies and derivative works. 💖 However, this document itself can't be modified in any way, such as by removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's needed to translate it into languages other than English 🌈

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns. ✨

This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫶

📦 where this page comes from

ietf: rfc2362 1998-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms