RFC 4601
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
RFC 4601 Part 1 🎀
okay bestie, this is RFC 4601, and it's giving main character for multicast routing 💅✨ It's the revised spec for Protocol Independent Multicast - Sparse Mode (PIM-SM). It was written by B. Fenner (AT&T Labs - Research), M. Handley (UCL), H. Holbrook (Arastra), and I. Kouvelas (Cisco). It's dated August 2006, it's on the Standards Track 🦋, and it obsoletes RFC 2362. The header doesn't list any updates.
Status of This Memo
This document describes an Internet standards track protocol for the Internet community 🌸 It also asks for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base, or a separate multicast-capable routing information base 🧚 It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it can optionally create shortest-path trees per source.
This document obsoletes RFC 2362, an Experimental version of PIM-SM 💀
Table of Contents
1. Introduction ....................................................5
2. Terminology .....................................................5
2.1. Definitions ................................................5
2.2. Pseudocode Notation ........................................7
3. PIM-SM Protocol Overview ........................................7
3.1. Phase One: RP Tree .........................................8
3.2. Phase Two: Register-Stop ...................................8
3.3. Phase Three: Shortest-Path Tree ............................9
3.4. Source-Specific Joins .....................................10
3.5. Source-Specific Prunes ....................................11
3.6. Multi-Access Transit LANs .................................11
3.7. RP Discovery ..............................................12
4. Protocol Specification .........................................12
4.1. PIM Protocol State ........................................13
4.1.1. General Purpose State ..............................14
4.1.2. (*,*,RP) State .....................................15
4.1.3. (*,G) State ........................................16
4.1.4. (S,G) State ........................................17
4.1.5. (S,G,rpt) State ....................................20
4.1.6. State Summarization Macros .........................21
4.2. Data Packet Forwarding Rules ..............................26
4.2.1. Last-Hop Switchover to the SPT .....................28
4.2.2. Setting and Clearing the (S,G) SPTbit ..............29
4.3. Designated Routers (DR) and Hello Messages ................30
4.3.1. Sending Hello Messages .............................30
4.3.2. DR Election ........................................32
4.3.3. Reducing Prune Propagation Delay on LANs ...........34
4.3.4. Maintaining Secondary Address Lists ................37
4.4. PIM Register Messages .....................................38
4.4.1. Sending Register Messages from the DR ..............38
4.4.2. Receiving Register Messages at the RP ..............43
4.5. PIM Join/Prune Messages ...................................45
4.5.1. Receiving (*,*,RP) Join/Prune Messages .............45
4.5.2. Receiving (*,G) Join/Prune Messages ................49
4.5.3. Receiving (S,G) Join/Prune Messages ................53
4.5.4. Receiving (S,G,rpt) Join/Prune Messages ............56
4.5.5. Sending (*,*,RP) Join/Prune Messages ...............62
4.5.6. Sending (*,G) Join/Prune Messages ..................66
4.5.7. Sending (S,G) Join/Prune Messages ..................71
4.5.8. (S,G,rpt) Periodic Messages ........................76
4.5.9. State Machine for (S,G,rpt) Triggered Messages .....77
4.5.10. Background: (*,*,RP) and (S,G,rpt) Interaction ....82
4.6. PIM Assert Messages .......................................83
4.6.1. (S,G) Assert Message State Machine .................83
4.6.2. (*,G) Assert Message State Machine .................91
4.6.3. Assert Metrics .....................................98
4.6.4. AssertCancel Messages ..............................99
4.6.5. Assert State Macros ...............................100
4.7. PIM Bootstrap and RP Discovery ...........................103
4.7.1. Group-to-RP Mapping ...............................104
4.7.2. Hash Function .....................................105
4.8. Source-Specific Multicast ................................106
4.8.1. Protocol Modifications for SSM Destination
Addresses .........................................106
4.8.2. PIM-SSM-Only Routers ..............................107
4.9. PIM Packet Formats .......................................108
4.9.1. Encoded Source and Group Address Formats ..........110
4.9.2. Hello Message Format ..............................113
4.9.3. Register Message Format ...........................116
4.9.4. Register-Stop Message Format ......................119
4.9.5. Join/Prune Message Format .........................119
4.9.5.1. Group Set Source List Rules ..............122
4.9.5.2. Group Set Fragmentation ..................126
4.9.6. Assert Message Format .............................126
4.10. PIM Timers ..............................................128
4.11. Timer Values ............................................129
5. IANA Considerations ...........................................135
5.1. PIM Address Family .......................................135
5.2. PIM Hello Options ........................................136
6. Security Considerations .......................................136
6.1. Attacks Based on Forged Messages .........................136
6.1.1. Forged Link-Local Messages ........................136
6.1.2. Forged Unicast Messages ...........................137
6.2. Non-Cryptographic Authentication Mechanisms ..............137
6.3. Authentication Using IPsec ...............................138
6.3.1. Protecting Link-Local Multicast Messages ..........138
6.3.2. Protecting Unicast Messages .......................139
6.3.2.1. Register Messages ........................139
6.3.2.2. Register-Stop Messages ...................139
6.4. Denial-of-Service Attacks ................................140
7. Acknowledgements ..............................................140
8. Normative References ..........................................141
9. Informative References ........................................141
Appendix A. PIM Multicast Border Router Behavior .................143
A.1. Sources External to the PIM-SM Domain ....................143
A.2. Sources Internal to the PIM-SM Domain ...................144
Appendix B. Index ................................................146List of Figures
Figure 1. Per-(S,G) register state machine at a DR ................38
Figure 2. Downstream per-interface (*,*,RP) state machine .........46
Figure 3. Downstream per-interface (*,G) state machine ............50
Figure 4. Downstream per-interface (S,G) state machine ............53
Figure 5. Downstream per-interface (S,G,rpt) state machine ........57
Figure 6. Upstream (*,*,RP) state machine .........................62
Figure 7. Upstream (*,G) state machine ............................67
Figure 8. Upstream (S,G) state machine ............................71
Figure 9. Upstream (S,G,rpt) state machine for triggered
messages ................................................77
Figure 10. Per-interface (S,G) Assert State machine ...............84
Figure 11. Per-interface (*,G) Assert State machine ...............921. Introduction ✨
This document specifies a protocol for efficiently routing multicast groups that may span wide-area (and inter-domain) internets 🌈 It's called Protocol Independent Multicast - Sparse Mode (PIM-SM) because, although it may use the underlying unicast routing to provide reverse-path information for multicast tree building, it is not dependent on any particular unicast routing protocol. So it's independent, iykyk 🫶
PIM-SM version 2 was originally specified in RFC 2117, and it was revised in RFC 2362. Both of those are Experimental RFCs 🙈 This document is meant to obsolete RFC 2362, fix a bunch of deficiencies that people found in how PIM-SM was previously specified, and bring PIM-SM onto the IETF Standards Track 👑 As far as possible, this document specifies the same protocol as RFC 2362. It only diverges from the behavior RFC 2362 intended when the previously specified behavior was clearly incorrect. Routers implemented according to this document will be able to interoperate successfully with routers implemented according to RFC 2362 🍓
2. Terminology 💜
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. They indicate requirement levels for compliant PIM-SM implementations, so these words are the ones that really matter here 😭🔥
Part 1 is wrapped, bestie, and more parts are coming. Stay tuned, it gets SO good from here 🦋
2.1. Definitions ✨
okay so these are the key terms for PIM-SM, and you need them all to follow the rest of the spec 💅
- Rendezvous Point (RP): An RP is a router that's been configured to act as the root of the non-source-specific distribution tree for a multicast group 🌸 Join messages from receivers for a group get sent towards the RP, and data from senders gets sent to the RP too, so receivers can figure out who the senders are and start receiving traffic for the group 🫶
- Designated Router (DR): A shared-media LAN like Ethernet can have multiple PIM-SM routers connected to it 🦋 Only one of them, the DR, acts on behalf of directly connected hosts for the PIM-SM protocol 👑 A single DR gets elected per interface (LAN or otherwise) using a simple election process ✨
- MRIB: Multicast Routing Information Base. This is the multicast topology table 🧚 It's typically derived from the unicast routing table, or from routing protocols like Multiprotocol BGP (MBGP) that carry multicast-specific topology information. In PIM-SM, the MRIB decides where Join/Prune messages get sent 💖 It also has a secondary job: providing routing metrics for destination addresses, and those metrics are used when sending and processing Assert messages 🎀
- RPF Neighbor: RPF stands for "Reverse Path Forwarding" 🌈 The RPF Neighbor of a router, for a given address, is the neighbor that the MRIB says should be used to forward packets to that address 💜 For a PIM-SM multicast group, the RPF neighbor is the router that a Join message for that group would be directed to, as long as there's no Assert state modifying that 🙈
- TIB: Tree Information Base. This is the collection of state at a PIM router that's been created by receiving PIM Join/Prune messages, PIM Assert messages, and Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) information from local hosts 🍓 It basically stores the state of all multicast distribution trees at that router 🔥
- MFIB: Multicast Forwarding Information Base. The TIB holds all the state needed to forward multicast packets at a router 💅 However, even though this spec defines forwarding in terms of the TIB, actually forwarding packets straight from the TIB is very inefficient 😭 So a real router implementation will normally build an efficient MFIB from the TIB state to do the forwarding 🦋 How that's done is implementation-specific and isn't discussed in this document 🙈
- Upstream: Towards the root of the tree. The root may be either the source or the RP, depending on the context 🌸
- Downstream: Away from the root of the tree 💜
- GenID: Generation Identifier, used to detect reboots 🔄
- PMBR: PIM Multicast Border Router, joining a PIM domain with another multicast domain 🌉
2.2. Pseudocode Notation ⭐
We use set notation in several places in this specification, so here's the cheat sheet 🎀
A (+) B is the union of two sets, A and B.
A (-) B is the elements of set A that are not in set B.
NULL is the empty set or list.We also use C-like syntax, which you'll totally recognize 💖
= denotes assignment of a variable.
== denotes a comparison for equality.
!= denotes a comparison for inequality.Braces { and } are used for grouping 🧁
3. PIM-SM Protocol Overview ✨
This section gives an overview of PIM-SM behavior 🦋 It's meant as an intro to how PIM-SM works, and it is NOT definitive 🙈 For the definitive spec, see Section 4 💅
PIM relies on an underlying topology-gathering protocol to fill a routing table with routes 🌈 This routing table is called the Multicast Routing Information Base (MRIB) 🧚 The routes in this table may be taken straight from the unicast routing table, or they may be different and come from a separate routing protocol like MBGP [10] 💜 Either way, the MRIB's main job in PIM is to provide the next-hop router along a multicast-capable path to each destination subnet 🫶 The MRIB is used to figure out which next-hop neighbor any PIM Join/Prune message gets sent to 🎀 Data flows along the reverse path of the Join messages 🔄 So, unlike the unicast RIB, which tells you the next hop a data packet would take to reach some subnet, the MRIB gives reverse-path information and shows the path a multicast data packet would take from its origin subnet to the router that has the MRIB 👑
Like all multicast routing protocols that implement the service model from RFC 1112 [3], PIM-SM has to route data packets from sources to receivers without either side knowing in advance that the other exists 🌸 This gets done in three phases, but since senders and receivers can come and go at any time, all three phases might happen at once 🍓
3.1. Phase One: RP Tree 🌳
In phase one, a multicast receiver says it's interested in traffic for a multicast group 💖 Usually it does this with IGMP [2] or MLD [4], though other mechanisms could work too 🦋 One of the receiver's local routers gets elected as the Designated Router (DR) for that subnet 👑 When the DR hears about the receiver's interest, it sends a PIM Join message towards the RP for that group 🫶 This is called a (,G) Join, because it joins group G for all sources sending to that group 🌈 The (,G) Join travels hop-by-hop towards the group's RP, and at each router it passes through, multicast tree state for group G gets created ✨ Eventually the (,G) Join either reaches the RP or hits a router that already has (,G) Join state for that group 🧚 When lots of receivers join, their Join messages converge on the RP and form a distribution tree for group G rooted at the RP 💜 This is the RP Tree (RPT), also called the shared tree, since every source sending to that group shares it 🎀 Join messages get resent periodically as long as the receiver stays in the group 🔄 When all receivers on a leaf-network leave the group, the DR sends a PIM (*,G) Prune message towards the RP for that group 🙈 But if the Prune message isn't sent for any reason, the state will eventually time out ⏳
A multicast data sender just starts sending data for a multicast group 🚀 The sender's local router (the DR) takes those data packets, unicast-encapsulates them, and sends them directly to the RP 🌸 The RP receives these encapsulated packets, decapsulates them, and forwards them onto the shared tree 🌊 The packets then follow the (*,G) multicast tree state in the routers on the RP Tree, getting replicated wherever the RP Tree branches, until they reach all the receivers for that group 💖 The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are known as PIM Register packets 🍓
So at the end of phase one, multicast traffic is flowing encapsulated to the RP, and then natively over the RP tree to the multicast receivers 🥳
3.2. Phase Two: Register-Stop 🛑
Register-encapsulation of data packets is inefficient for two reasons 🙃
- Encapsulation and decapsulation may be relatively expensive operations for a router, depending on whether or not the router has the right hardware for these tasks 🔧
- Traveling all the way to the RP, and then back down the shared tree, may mean the packets travel a really long distance to reach receivers that are close to the sender 😤 For some applications, that extra latency or bandwidth consumption is undesirable 💀
Register-encapsulation may continue indefinitely, but for these reasons the RP will normally choose to switch to native forwarding 💅 To do this, when the RP receives a register-encapsulated data packet from source S on group G, it will normally initiate an (S,G) source-specific Join towards S 🎯 This Join message travels hop-by-hop towards S, creating (S,G) multicast tree state in the routers along the path 🧭 That (S,G) multicast tree state is used only to forward packets for group G if those packets come from source S 🔒 Eventually the Join message reaches S's subnet or a router that already has (S,G) multicast tree state, and then packets from S start flowing along the (S,G) tree state towards the RP 🌊 These data packets may also reach routers with (*,G) state along the path towards the RP; if they do, they can shortcut onto the RP tree at that point ✨
While the RP is busy joining the source-specific tree for S, the data packets keep getting encapsulated to the RP 📦 Once packets from S also start arriving natively at the RP, the RP is getting two copies of each packet 👯 At that point, the RP starts discarding the encapsulated copy, and it sends a Register-Stop message back to S's DR so the DR stops unnecessarily encapsulating the packets 🛑
So at the end of phase two, traffic flows natively from S along a source-specific tree to the RP, and from there along the shared tree to the receivers 🎉 Where the two trees intersect, traffic may switch from the source-specific tree to the RP tree, which avoids a long detour via the RP 🦋
Note that a sender may start sending before or after a receiver joins the group, so phase two may happen before the shared tree to the receiver is built 🤷♀️
3.3. Phase Three: Shortest-Path Tree ✨
Okay so the RP pulling itself back toward the source gets rid of the encapsulation overhead 💅, but the paths still aren't perfect 😭. For a lot of receivers, going through the RP can be a seriously long detour compared to the direct shortest path from the source to them.
For lower latency or better bandwidth use, a router on the receiver's LAN (typically the DR) 🫶 may optionally switch the receiver over from the shared tree to a source-specific shortest-path tree (SPT). To do that, it sends an (S,G) Join towards S. That creates state in the routers along the path to S. Eventually the join either reaches S's subnet or hits a router that already has (S,G) state. Once that happens, data packets from S start flowing along the (S,G) state until they reach the receiver 🦋.
Now the receiver (or a router upstream of it) is getting two copies of the data: one from the SPT and one from the RPT 👀. When the first traffic shows up from the SPT, the DR or upstream router starts dropping the packets for G from S that arrive via the RP tree. It also sends an (S,G) Prune message towards the RP. This is known as an (S,G,rpt) Prune 🌸. The Prune travels hop-by-hop, creating state along the path toward the RP that says traffic from S for G should NOT be forwarded in this direction. The prune keeps going until it reaches the RP or a router that still needs traffic from S for other receivers.
By this point, the receiver is getting traffic from S along the shortest-path tree between itself and S ✨. The RP is still receiving traffic from S too, but that traffic no longer reaches the receiver along the RP tree. From the receiver's point of view, this is the final distribution tree, and it's giving main character energy 👑.
3.4. Source-Specific Joins 🎀
IGMPv3 lets a receiver join a group and say it only wants traffic for that group if the traffic comes from one particular source 🧚. If a receiver does this, and no other receiver on the LAN needs all the traffic for the group, then the DR can skip the (*,G) join that would set up the shared tree and send a source-specific (S,G) join only.
The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is currently set aside for source-specific multicast in IPv4 🍓. For groups in this range, receivers should only issue source-specific IGMPv3 joins. If a PIM router gets a non-source-specific join for a group in this range, it should ignore it, as described in Section 4.8 🙈.
3.5. Source-Specific Prunes 💜
IGMPv3 also lets a receiver join a group and say it only wants traffic for that group if the traffic does NOT come from a specific source or sources. In that case the DR does a (*,G) join as normal, but it can combine that with an (S,G,rpt) prune for each source the receiver doesn't want 💅.
3.6. Multi-Access Transit LANs 🌈
So far the overview has only talked about point-to-point transit links. But using a multi-access LAN like Ethernet for transit is pretty common 😭, and it can cause complications for three reasons:
- Two or more routers on the LAN may issue (*,G) Joins to different upstream routers on the LAN, because they have inconsistent MRIB entries about how to reach the RP. Both paths on the RP tree get set up, so two copies of all the shared tree traffic show up on the LAN 💀.
- Two or more routers on the LAN may issue (S,G) Joins to different upstream routers on the LAN, because they have inconsistent MRIB entries about how to reach source S. Both paths on the source-specific tree get set up, so two copies of all the traffic from S show up on the LAN 🙃.
- A router on the LAN may issue a (,G) Join to one upstream router on the LAN, while another router on the LAN issues an (S,G) Join to a different upstream router on that same LAN. Traffic from S may then reach the LAN over both the RPT and the SPT. If the receiver behind the downstream (,G) router doesn't issue an (S,G,rpt) prune, this condition would persist 🥲.
All of these problems come from having more than one upstream router with join state for the group or source-group pair. PIM doesn't prevent these duplicate joins from happening. Instead, when duplicate data packets show up on the LAN from different routers, those routers notice and then elect a single forwarder 🫶. The election uses PIM Assert messages, which resolve things in favor of the upstream router that has (S,G) state. If neither or both routers have (S,G) state, the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source for source-specific trees.
The downstream routers on the LAN also receive these Assert messages, and that causes their later Join messages to go to the upstream router that won the Assert 🎀.
3.7. RP Discovery 🔍
PIM-SM routers need to know the address of the RP for each group they have (*,G) state for ✨. That address is obtained automatically (for example, via embedded-RP), through a bootstrap mechanism, or through static configuration.
One dynamic way to do this is the Bootstrap Router (BSR) mechanism [11] 🧚. One router in each PIM domain is elected Bootstrap Router through a simple election process. All the routers in the domain that are configured as RP candidates periodically unicast their candidacy to the BSR. From those candidates, the BSR picks an RP-set and periodically announces it in a Bootstrap message. Bootstrap messages are flooded hop-by-hop throughout the domain until every router in the domain knows the RP-Set 🌸.
To map a group to an RP, a router hashes the group address into the RP-set using an order-preserving hash function (one that minimizes changes when the RP-Set changes) 🧮. The resulting RP is the one the router uses for that group. Iykyk 😌.
4. Protocol Specification 📜
The PIM-SM spec is broken into several parts:
- Section 4.1 details the protocol state stored.
- Section 4.2 specifies the data packet forwarding rules.
- Section 4.3 specifies Designated Router (DR) election and the rules for sending and processing Hello messages.
- Section 4.4 specifies the PIM Register generation and processing rules.
- Section 4.5 specifies the PIM Join/Prune generation and processing rules.
- Section 4.6 specifies the PIM Assert generation and processing rules.
- Section 4.7 specifies the RP discovery mechanisms.
- The subset of PIM required to support Source-Specific Multicast, PIM-SSM, is described in Section 4.8.
- PIM packet formats are specified in Section 4.9.
- A summary of PIM-SM timers and their default values is given in Section 4.10.
- Appendix A specifies the PIM Multicast Border Router behavior.
4.1. PIM Protocol State 🗂️
This section specifies all the protocol state a PIM implementation should maintain in order to function correctly 💖. We call this state the Tree Information Base (TIB), since it holds the state of all the multicast distribution trees at this router. In this spec we define PIM mechanisms in terms of the TIB. Only a very simple implementation would actually do packet forwarding directly from this state, though. Most implementations use it to build a multicast forwarding table, which then gets updated whenever the relevant TIB state changes ✨.
Even though we specify the state precisely, an implementation of PIM-SM doesn't have to store it in this form 🦋. This is an abstract state definition, needed to specify the router's behavior. A PIM-SM implementation can hold whatever internal state it needs and still be conformant, as long as it produces the same externally visible protocol behavior as an abstract router holding the state below 🫶.
We split TIB state into four sections:
(*,*,RP)state: State that maintains per-RP trees, for all groups served by a given RP.(*,G)state: State that maintains the RP tree for G.(S,G)state: State that maintains a source-specific tree for source S and group G.(S,G,rpt)state: State that maintains source-specific information about source S on the RP tree for G. For example, if a source is being received on the source-specific tree, it will normally have been pruned off the RP tree. That prune state is(S,G,rpt)state.
The state that should be kept is described below. Implementations only maintain state when it's relevant to forwarding operations. For example, the "NoInfo" state might be assumed from the lack of other state information instead of being held explicitly 🙈.
4.1.1. General Purpose State 🌷
A router holds the following non-group-specific state:
For each interface:
o Effective Override Interval
o Effective Propagation Delay
o Suppression state: One of {"Enable", "Disable"}
Neighbor State:
For each neighbor:
o Information from neighbor's Hello
o Neighbor's GenID.
o Neighbor Liveness Timer (NLT)
Designated Router (DR) State:
o Designated Router's IP Address
o DR's DR PriorityThe Effective Override Interval, the Effective Propagation Delay and the Interface suppression state are described in Section 4.3.3. Designated Router state is described in Section 4.3 💅.
4.1.2. (,,RP) State 🍑
For every RP, a router keeps the following state:
(*,*,RP) state:
For each interface:
PIM (*,*,RP) Join/Prune State:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET)
Not interface specific:
Upstream (*,*,RP) Join/Prune State:
o State: One of {"NotJoined(*,*,RP)",
"Joined(*,*,RP)"}
o Upstream Join/Prune Timer (JT)
o Last RPF Neighbor towards RP that was usedPIM (,,RP) Join/Prune state is the result of receiving PIM (,,RP) Join/Prune messages on this interface, and it's specified in Section 4.5.1 🧠.
The upstream (,,RP) Join/Prune State reflects the state of the upstream (,,RP) state machine described in Section 4.5.5 🔁.
The upstream (,,RP) Join/Prune Timer is used to send out periodic Join(,,RP) messages, and to override Prune(,,RP) messages from peers on an upstream LAN interface ⏰.
The last RPF neighbor towards the RP gets stored because if the MRIB changes, the RPF neighbor towards the RP might change too 😬. If it does, we need to trigger a new Join(,,RP) to the new upstream neighbor and a Prune(,,RP) to the old one. Similarly, if a router notices through a changed GenID in a Hello message that the upstream neighbor towards the RP has rebooted, it should re-instantiate state by sending a Join(,,RP). These mechanisms are specified in Section 4.5.5 🚀.
4.1.3. (*,G) State 💖
okay bestie, for every group G, a router keeps this state 🧚
(*,G) state:
For each interface:
Local Membership:
State: One of {"NoInfo", "Include"}
PIM (*,G) Join/Prune State:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET)
(*,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)}
o Assert Timer (AT)
o Assert winner's IP Address (AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric)
Not interface specific:
Upstream (*,G) Join/Prune State:
o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
o Upstream Join/Prune Timer (JT)
o Last RP Used
o Last RPF Neighbor towards RP that was usedso local membership is basically whatever the local membership mechanism (like IGMP or MLD) is telling you on that interface 📡 you don't need to keep it if you're not the DR on that interface, unless you won a (,G) assert there for this group. implementations are allowed to keep it anyway in case they become the DR or assert winner 🙈 but the spec recommends storing it if possible, because it cuts down the latency to get back to stable operating conditions after a failure that changes the DR. the info gets used by the pim_include(,G) macro in Section 4.1.6 🎀
PIM (,G) Join/Prune state is what you get from receiving PIM (,G) Join/Prune messages on this interface, and it's spelled out in Section 4.5.2. it gets used by the macros that work out the outgoing interface list in Section 4.1.6, plus the JoinDesired(,G) macro (Section 4.5.6), which decides whether a Join(,G) should go upstream 💅
(,G) Assert Winner state comes from sending or receiving (,G) Assert messages on this interface, and it's covered in Section 4.6.2 ✨
the upstream (,G) Join/Prune State just mirrors the upstream (,G) state machine from Section 4.5.6 🦋
the upstream (,G) Join/Prune Timer is what sends out the periodic Join(,G) messages, and it's also how you override Prune(*,G) messages from peers on an upstream LAN interface 🫶
the last RP used has to be stored, because if the RP-Set changes (Section 4.7), state has to be torn down and rebuilt for any groups whose RP changed 😭
the last RPF neighbor towards the RP gets stored too, because if the MRIB changes, the RPF neighbor towards the RP might change. if it does, you need to trigger a new Join(,G) to the new upstream neighbor and a Prune(,G) to the old one. same deal if a router sees a changed GenID in a Hello message and figures out the upstream neighbor towards the RP has rebooted: it should re-instantiate state by sending a Join(*,G) 🔥 all of these mechanisms are specified in Section 4.5.6 👑
4.1.4. (S,G) State 🌸
for every source/group pair (S,G), a router keeps this state 🍓
(S,G) state:
For each interface:
Local Membership:
State: One of {"NoInfo", "Include"}
PIM (S,G) Join/Prune State:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET)
(S,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)}
o Assert Timer (AT)
o Assert winner's IP Address (AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric)
Not interface specific:
Upstream (S,G) Join/Prune State:
o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
o Upstream (S,G) Join/Prune Timer (JT)
o Last RPF Neighbor towards S that was used
o SPTbit (indicates (S,G) state is active)
o (S,G) Keepalive Timer (KAT)
Additional (S,G) state at the DR:
o Register state: One of {"Join" (J), "Prune" (P),
"Join-Pending" (JP), "NoInfo" (NI)}
o Register-Stop timer
Additional (S,G) state at the RP:
o PMBR: the first PMBR to send a Register for this
source with the Border bit set.local membership here is the result of the local source-specific membership mechanism (like IGMP version 3) on that interface, saying this particular source should be included 👀 what's stored is the final answer after any IGMPv3 inconsistencies have been sorted out. same rule as before: you don't need to keep it if you're not the DR on that interface, unless you won a (S,G) assert there for this group. but storing it is recommended if possible, since it speeds up converging after a DR-changing failure 🌈 it's used by the pim_include(S,G) macro in Section 4.1.6 🎀
PIM (S,G) Join/Prune state comes from receiving PIM (S,G) Join/Prune messages on this interface, specified in Section 4.5.2 ✨ the macros that build the outgoing interface list in Section 4.1.6 use it, and so does the JoinDesired(S,G) macro (Section 4.5.7), which decides whether a Join(S,G) goes upstream 💅
(S,G) Assert Winner state is the result of sending or receiving (S,G) Assert messages on this interface, and that's in Section 4.6.1 🦋
the upstream (S,G) Join/Prune State follows the upstream (S,G) state machine in Section 4.5.7 🫶
the upstream (S,G) Join/Prune Timer sends periodic Join(S,G) messages, and it overrides Prune(S,G) messages from peers on an upstream LAN interface 🔥
the last RPF neighbor towards S is stored because if the MRIB changes, the RPF neighbor towards S may change too. if it does, you trigger a new Join(S,G) to the new upstream neighbor and a Prune(S,G) to the old one 😭 and if a router notices a changed GenID in a Hello message showing the upstream neighbor towards S has rebooted, it should re-instantiate state by sending a Join(S,G). all of this is in Section 4.5.7 👑
the SPTbit tells you whether forwarding is happening on the (S,G) Shortest Path Tree (SPT) or on the (,G) tree 🌸 a router can have (S,G) state and still be forwarding on (,G) state while the source-specific tree is being built. when SPTbit is FALSE, only (,G) forwarding state is used to forward packets from S to G. when SPTbit is TRUE, both (,G) and (S,G) forwarding state are used 🧚
the (S,G) Keepalive Timer gets refreshed by data being forwarded with this (S,G) forwarding state, and it keeps (S,G) state alive when there are no explicit (S,G) Joins. this matters for the so-called "turnaround rules" -- where the RP uses (S,G) joins to stop encapsulation, and then (S,G) prunes to stop traffic from needlessly reaching the RP 💀
on a DR, the (S,G) Register State tracks whether data should be encapsulated to the RP on the Register Tunnel, and the (S,G) Register-Stop timer tracks how long until encapsulation starts again for that (S,G) 🍓
on an RP, the PMBR value must be cleared when the Keepalive Timer expires 🙈
4.1.5. (S,G,rpt) State 🦋
for every source/group pair (S,G) that a router also has (*,G) state for, it keeps this extra state too ✨
(S,G,rpt) state:
For each interface:
Local Membership:
State: One of {"NoInfo", "Exclude"}
PIM (S,G,rpt) Join/Prune State:
o State: One of {"NoInfo", "Pruned", "Prune-
Pending"}
o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET)
Not interface specific:
Upstream (S,G,rpt) Join/Prune State:
o State: One of {"RPTNotJoined(G)",
"NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"}
o Override Timer (OT)local membership here is the result of the local source-specific membership mechanism (like IGMPv3) on that interface, saying that even though there's (,G) Include state, this particular source should be excluded 🤭 again, it's the final answer after any IGMPv3 inconsistencies between LAN members are resolved. you don't need to keep it if you're not the DR on that interface, unless you won a (,G) assert there for this group. storing it is still recommended if possible, because it helps convergence after a DR-changing failure 🌈 it's used by the pim_exclude(S,G) macro in Section 4.1.6 🎀
PIM (S,G,rpt) Join/Prune state is what you get from receiving PIM (S,G,rpt) Join/Prune messages on this interface, specified in Section 4.5.4 💅 it's used by the macros that build the outgoing interface list in Section 4.1.6, and by the rules for adding Prune(S,G,rpt) messages to Join(*,G) messages in Section 4.5.8 ✨
the upstream (S,G,rpt) Join/Prune state works together with the Override Timer to send the right override messages when upstream peers on a LAN send Join/Prune messages. that state and behavior are in Section 4.5.9 👑
4.1.6. State Summarization Macros ✨
okay so bestie, this is where we get to define a bunch of "macro" shortcuts 🎀 we'll use all over the state machines and pseudocode coming up. Think of them as nicknames for big messy chunks of state. Let's get into it 💅
The most important macros are the ones that define the outgoing interface list (the "olist") for each piece of state. An olist can be "immediate" 🍓, which means it's built straight from the state of one type. For example, immediate_olist(S,G) is the olist you'd get if the router only had (S,G) state and no (*,G) or (S,G,rpt) state. The "inherited" olist is more of a blend 🦋 because it pulls state from other types too. For example, inherited_olist(S,G) is the olist that matters when forwarding a packet from S to G using both source-specific and group-specific state.
There's no immediate_olist(S,G,rpt), and that's because (S,G,rpt) state is negative state 🙈 It takes interfaces out of the (*,G) olist instead of adding anything. So inherited_olist(S,G,rpt) is the olist used for a packet from S to G that's being forwarded on the RP tree. It's a strict subset of (immediate_olist(*,*,RP) (+) immediate_olist(*,G)), so it's always smaller or equal, never bigger 🧚
Generally speaking, the inherited olists are what get used for actually forwarding packets 🚀, and the immediate olists are what the router uses when it's making decisions about maintaining state 🧠
Here are the immediate olists:
immediate_olist(*,*,RP) =
joins(*,*,RP)
immediate_olist(*,G) =
joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
immediate_olist(S,G) =
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)And here are the inherited ones, which are the real MVPs for forwarding 👑
inherited_olist(S,G,rpt) =
( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)The macros pim_include(*,G) and pim_include(S,G) tell us which interfaces traffic might get forwarded to because of hosts that are local members on that interface 🏠 Normally only the DR (designated router) cares about local membership, but when an assert happens, the assert winner takes over that job and handles forwarding to local members who asked for traffic on a group or a source/group pair 🫶
pim_include(*,G) =
{ all interfaces I such that:
( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me )
AND local_receiver_include(*,G,I) }
pim_include(S,G) =
{ all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
OR AssertWinner(S,G,I) == me )
AND local_receiver_include(S,G,I) }
pim_exclude(S,G) =
{ all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me )
AND local_receiver_exclude(S,G,I) }Now the local receiver clauses 🎧 local_receiver_include(S,G,I) is true if the IGMP/MLD module (or some other local membership mechanism) has figured out that local members on interface I want traffic sent specifically by S to G 💖 local_receiver_include(*,G,I) is true if the same kind of mechanism has determined that local members on interface I want all traffic sent to G, possibly with a few sources excluded 🌈 And local_receiver_exclude(S,G,I) is true if local_receiver_include(*,G,I) is true but none of the local members want traffic from S 🙅♀️
The set joins(*,*,RP) is all the interfaces where the router has received (,,RP) Joins ✨
joins(*,*,RP) =
{ all interfaces I such that
DownstreamJPState(*,*,RP,I) is either Join or
Prune-Pending }DownstreamJPState(*,*,RP,I) is the state of the finite state machine in Section 4.5.1.
The set joins(*,G) is all the interfaces where the router has received (*,G) Joins 🌸
joins(*,G) =
{ all interfaces I such that
DownstreamJPState(*,G,I) is either Join or Prune-Pending }DownstreamJPState(*,G,I) is the state of the finite state machine in Section 4.5.2.
The set joins(S,G) is all the interfaces where the router has received (S,G) Joins 💜
joins(S,G) =
{ all interfaces I such that
DownstreamJPState(S,G,I) is either Join or Prune-Pending }DownstreamJPState(S,G,I) is the state of the finite state machine in Section 4.5.3.
The set prunes(S,G,rpt) is all the interfaces where the router has received (*,G) joins and (S,G,rpt) prunes 🍓
prunes(S,G,rpt) =
{ all interfaces I such that
DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp }DownstreamJPState(S,G,rpt,I) is the state of the finite state machine in Section 4.5.4.
The set lost_assert(*,G) is all the interfaces where the router has received (,G) joins but has lost a (,G) assert 😭 The macro lost_assert(*,G,I) is defined in Section 4.6.5.
lost_assert(*,G) =
{ all interfaces I such that
lost_assert(*,G,I) == TRUE }The set lost_assert(S,G,rpt) is all the interfaces where the router has received (*,G) joins but has lost an (S,G) assert 💀 The macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5.
lost_assert(S,G,rpt) =
{ all interfaces I such that
lost_assert(S,G,rpt,I) == TRUE }The set lost_assert(S,G) is all the interfaces where the router has received (S,G) joins but has lost an (S,G) assert 🥺 The macro lost_assert(S,G,I) is defined in Section 4.6.5.
lost_assert(S,G) =
{ all interfaces I such that
lost_assert(S,G,I) == TRUE }Last batch of macros, and these are the pseudocode ones 🧚♀️ The big idea is that RPF' is the RPF neighbor towards an RP or a source, unless a PIM-Assert has overridden the normal pick ✨
neighbor RPF'(*,G) {
if ( I_Am_Assert_Loser(*, G, RPF_interface(RP(G)) ) ) {
return AssertWinner(*, G, RPF_interface(RP(G)) )
} else {
return NBR( RPF_interface(RP(G)), MRIB.next_hop( RP(G) ) )
}
}
neighbor RPF'(S,G,rpt) {
if( I_Am_Assert_Loser(S, G, RPF_interface(RP(G)) ) ) {
return AssertWinner(S, G, RPF_interface(RP(G)) )
} else {
return RPF'(*,G)
}
}
neighbor RPF'(S,G) {
if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) {
return AssertWinner(S, G, RPF_interface(S) )
} else {
return NBR( RPF_interface(S), MRIB.next_hop( S ) )
}
}RPF'(*,G) and RPF'(S,G) tell us which neighbor data packets should be coming from, and which neighbor joins should be sent to, on the RP tree and the SPT respectively 🌳
RPF'(S,G,rpt) is basically RPF'(*,G) with a twist 🌀 That twist is the result of an Assert(S,G) on RPF_interface(RP(G)). When that happens, packets from S are coming from a different router than RPF'(*,G) points to. So if we only have active (,G) Join state, we need to accept packets from RPF'(S,G,rpt) and add a Prune(S,G,rpt) to the periodic Join(,G) messages we send to RPF'(*,G) (see Section 4.5.8) 💅
The function MRIB.next_hop( S ) gives back the address of the next-hop PIM neighbor toward host S, based on the current MRIB. If S is directly adjacent, MRIB.next_hop( S ) returns NULL. At the RP for G, MRIB.next_hop( RP(G)) also returns NULL 🙈
The function NBR( I, A ) uses info gathered from PIM Hello messages to map the IP address A of a directly connected PIM neighbor router on interface I to the primary IP address of that same router (Section 4.3.4) 🫶 A neighbor's primary IP address is the one it uses as the source of its PIM Hello messages. A neighbor's IP address might not be unique within the PIM neighbor database because of scope issues 🌍 It must, however, be unique among the addresses of all the PIM neighbors on one specific interface, so that's a hard rule 🔒
Last two: I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in Section 4.6.1) for (S,G) on Interface I is in the "I am Assert Loser" state 🥀 And I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in Section 4.6.2) for (*,G) on Interface I is in that same "I am Assert Loser" state 🌷
4.2. Data Packet Forwarding Rules ✨
okay bestie, this is where the packets actually get their glow-up 💅 The PIM-SM forwarding rules are written out below as pseudocode, so you can see exactly what the router checks 🎀
iif is the incoming interface of the packet.
S is the source address of the packet.
G is the destination address of the packet (group address).
RP is the address of the Rendezvous Point for this group.
RPF_interface(S) is the interface the MRIB indicates would be used
to route packets to S.
RPF_interface(RP) is the interface the MRIB indicates would be
used to route packets to RP, except at the RP when it is the
decapsulation interface (the "virtual" interface on which register
packets are received).so the router does four things in order 🦋 First, it restarts (or starts) the Keepalive Timer if the source is on a directly connected subnet. Second, it checks whether the SPTbit should be set, because we've now switched from the RP tree to the SPT 🌸 Next, it decides whether the packet should be accepted, based on TIB state and the interface the packet arrived on 👑
if the packet should be forwarded using (S,G) state, the router builds an outgoing interface list for it. if that list isn't empty, the (S,G) state Keepalive Timer gets restarted 💖 if the packet should be forwarded using (,,RP) or (*,G) state, the router just builds an outgoing interface list. it also checks whether it should start a switch to receiving this source on a shortest path tree ✨
Finally, the incoming interface gets removed from the outgoing interface list, and if what's left isn't empty, the packet goes out of those interfaces 🫶
On receipt of data from S to G on interface iif:
if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
set KeepaliveTimer(S,G) to Keepalive_Period
# Note: a register state transition or UpstreamJPState(S,G)
# transition may happen as a result of restarting
# KeepaliveTimer, and must be dealt with here.
}
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
inherited_olist(S,G) != NULL ) {
set KeepaliveTimer(S,G) to Keepalive_Period
}
Update_SPTbit(S,G,iif)
oiflist = NULL
if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {
oiflist = inherited_olist(S,G)
} else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE) {
oiflist = inherited_olist(S,G,rpt)
CheckSwitchToSpt(S,G)
} else {
# Note: RPF check failed
# A transition in an Assert FSM may cause an Assert(S,G)
# or Assert(*,G) message to be sent out interface iif.
# See section 4.6 for details.
if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif
} else if ( SPTbit(S,G) == FALSE AND
iif is in inherited_olist(S,G,rpt) {
send Assert(*,G) on iif
}
}
oiflist = oiflist (-) iif
forward packet on all interfaces in oiflistthere are a few "macro" definitions in there that you need to know 🧚
DirectlyConnected(S) is TRUE if the source S is on any subnet that is directly connected to this router (or for packets originating on this router) 🍓
inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section 4.1 📖
basically, inherited_olist(S,G) is the outgoing interface list for packets forwarded on (S,G) state, taking into account (,,RP) state, (*,G) state, asserts, etc 💅
inherited_olist(S,G,rpt) is the outgoing interface list for packets forwarded on (,,RP) or (*,G) state, taking into account (S,G,rpt) prune state, asserts, etc 🌈
Update_SPTbit(S,G,iif) is defined in Section 4.2.2 🎀
CheckSwitchToSpt(S,G) is defined in Section 4.2.1 🦋
UpstreamJPState(S,G) is the state of the finite state machine in Section 4.5.7 🌸
Keepalive_Period is defined in Section 4.10 ✨
and one last thing: data-triggered PIM-Assert messages sent from the forwarding code above should be rate-limited in an implementation-dependent manner 🙈
4.2.1. Last-Hop Switchover to the SPT
4.2.1. Last-Hop Switchover to the SPT
ok so in Sparse-Mode PIM, last-hop routers join the shared tree towards the RP 🌳 once traffic from sources to joined groups reaches a last-hop router, it gets to choose whether to switch and receive that traffic on a shortest path tree (SPT) 👑
the decision to switch to the SPT is controlled like this:
void
CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) {
# Note: Restarting the KAT will result in the SPT switch
set KeepaliveTimer(S,G) to Keepalive_Period
}
}SwitchToSptDesired(S,G) is a policy function that's up to the implementation 🫶 an "infinite threshold" policy can be built by making it return false all the time 🙅♀️ a "switch on first packet" policy can be built by making it return true once a single packet has been received for that source and group 🔥
4.2.2. Setting and Clearing the (S,G) SPTbit
4.2.2. Setting and Clearing the (S,G) SPTbit
the (S,G) SPTbit is what tells the router whether to forward on (,,RP)/(,G) state or on (S,G) state 💖 when it switches from the RP tree to the source tree, there's a transition period where data is still arriving because of upstream (,,RP)/(,G) state, while upstream (S,G) state is still being set up. during that time, a router should continue to forward only on (,,RP)/(*,G) state 🥺 this stops temporary black-holes, which would happen if a Prune(S,G,rpt) got sent before the upstream (S,G) state had finished being established 😭
so when a packet arrives, the (S,G) SPTbit gets updated like this:
void
Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) {
Set SPTbit(S,G) to TRUE
}
}a router can also set SPTbit(S,G) to TRUE in other cases too, like when it receives an Assert(S,G) on RPF_interface(S) (see Section 4.6.1) 🌈
JoinDesired(S,G) is defined in Section 4.5.7, and it tells you whether we have the right (S,G) Join state to send a Join(S,G) upstream 🎀
basically, Update_SPTbit sets the SPTbit when we have the right (S,G) join state, the packet arrived on the correct upstream interface for S, and one or more of these conditions applies:
- The source is directly connected, in which case the switch to the SPT is a no-op 🦋
- The RPF interface to S is different from the RPF interface to the RP. The packet arrived on RPF_interface(S), so the SPT must have been completed 🌸
- No one wants the packet on the RP tree ✨
- RPF'(S,G) == RPF'(*,G). In this case, the router will never be able to tell if the SPT has been completed, so it should just switch immediately 🏃♀️
in the case where the RPF interface is the same for the RP and for S, but RPF'(S,G) and RPF'(,G) differ, we wait for an Assert(S,G). that's the upstream router with (S,G) state saying "yep, the SPT is done" 🙌 item (3) above is still needed, though, because there might not be any (,G) state around to trigger an Assert(S,G) 🙈
the SPTbit gets cleared in the (S,G) upstream state machine (see Section 4.5.7) when JoinDesired(S,G) becomes FALSE 🧹
4.3. Designated Routers (DR) and Hello Messages
4.3. Designated Routers (DR) and Hello Messages
ok this one is so iconic 👑 a shared-media LAN like Ethernet can have multiple PIM-SM routers connected to it. just one of them, the DR, acts on behalf of the directly connected hosts when it comes to the PIM-SM protocol 💅 LANs and point-to-point interfaces can be kinda blurry, and routers can also have multicast host functionality, so the PIM-SM specification doesn't distinguish between the two 🦋 that means DR election happens on all interfaces, LAN or otherwise ✨
DR election is done with Hello messages 💖 Hello messages are also how option negotiation happens in PIM, so extra functionality can get switched on or parameters can get tuned 🎀
4.3.1. Sending Hello Messages 📣
Okay bestie, PIM Hello messages go out periodically on every PIM-enabled interface 💖. They're how a router finds its PIM neighbors on each interface ✨. Hellos are also how the DR gets elected and how extra capabilities get negotiated, so they're doing a lot 💅. A router has to record the Hello info from each PIM neighbor 📝.
Hello messages MUST be sent on all active interfaces, including physical point-to-point links, and they get multicast to the 'ALL-PIM-ROUTERS' group address ('224.0.0.13' for IPv4 and 'ff02::d' for IPv6) 🌸.
Heads up, some implementations don't send Hellos on point-to-point interfaces. That's non-compliant behavior 🙅♀️. A compliant PIM router MUST send Hello messages, even on point-to-point interfaces 💅.
Each interface has its own Hello Timer, HT(I), which triggers Hello sending on each active interface ⏰. When PIM gets enabled on an interface or the router first starts up, that timer gets set to a random value between 0 and Triggered_Hello_Delay 🎲. The randomness is the point: it stops Hellos from syncing up if a bunch of routers get powered on at the same time 🙈. After that first randomized interval, Hellos must be sent every Hello_Period seconds. The Hello Timer should not be reset except when it expires ⏳.
Neighbors will not accept Join/Prune or Assert messages from a router until they've heard a Hello from that router first 🙅♀️. So if a router needs to send a Join/Prune or Assert on an interface where it hasn't yet sent a Hello with its currently configured IP address, it MUST immediately send the relevant Hello without waiting for the Hello Timer to expire, then send the Join/Prune or Assert right after ⚡.
The DR_Priority Option lets a network admin give a particular router an edge in DR election by giving it a numerically larger DR Priority 👑. The DR_Priority Option SHOULD be included in every Hello message, even if no DR Priority is explicitly configured on that interface 💁. Why? Because priority-based DR election only switches on when all neighbors on an interface say they can use the DR_Priority Option 🤓. The default priority is 1.
The Generation_Identifier (GenID) Option SHOULD be included in all Hello messages 🧬. It holds a randomly generated 32-bit value that gets regenerated every time PIM forwarding is started or restarted on the interface, including when the router itself restarts 🔄. When a Hello with a new GenID shows up from a neighbor, any old Hello info about that neighbor SHOULD be discarded and superseded by the new Hello 🗑️. This may cause a new DR to be chosen on that interface 👀.
The LAN Prune Delay Option SHOULD be included in all Hello messages sent on multi-access LANs 🏘️. It advertises a router's capability to use values other than the defaults for the Propagation_Delay and Override_Interval, which affect the setting of the Prune-Pending, Upstream Join, and Override Timers (defined in Section 4.10) ⏳.
The Address List Option advertises all the secondary addresses associated with the source interface of the router that sent the message 📇. The option MUST be included in all Hello messages if there are secondary addresses associated with the source interface, and it MAY be omitted if no secondary addresses exist 🤷♀️.
To help new or rebooting routers find PIM neighbors fast 🏃♀️, when a Hello arrives from a new neighbor, or a Hello with a new GenID arrives from an existing neighbor, a new Hello message should be sent on this interface after a randomized delay between 0 and Triggered_Hello_Delay ⚡. This triggered message need not change the timing of the scheduled periodic message 🗓️. If a router needs to send a Join/Prune to the new neighbor, or an Assert in response to an Assert from the new neighbor, before this randomized delay has expired, then it MUST immediately send the relevant Hello without waiting for the Hello Timer to expire, followed by the Join/Prune or Assert 🫶. If it does not do this, the new neighbor will discard the Join/Prune or Assert message 💀.
Before an interface goes down or changes its primary IP address, a Hello with a zero HoldTime should be sent immediately (with the old IP address if the IP address changed) 👋. That makes PIM neighbors remove this neighbor, or its old IP address, right away 🫥. After an interface has changed its IP address, it MUST send a Hello message with its new IP address 🆕. If an interface changes one of its secondary IP addresses, a Hello with an updated Address_List option and a non-zero HoldTime should be sent immediately ✨. That makes PIM neighbors update this neighbor's list of secondary addresses immediately 📇.
4.3.2. DR Election 🗳️
When a PIM Hello message comes in on interface I, the router records this info about the sending neighbor 📒:
neighbor.interface: the interface the Hello message arrived on.neighbor.primary_ip_address: the IP address the PIM neighbor used as the source address of the Hello message.neighbor.genid: the Generation ID of the PIM neighbor.neighbor.dr_priority: the DR Priority field of the PIM neighbor, if it's present in the Hello message.neighbor.dr_priority_present: a flag that says whether the DR Priority field was in the Hello message.neighbor.timeout: a timer value that times out the neighbor state when it goes stale, also known as the Neighbor Liveness Timer.
The Neighbor Liveness Timer (NLT(N,I)) gets reset to Hello_Holdtime (from the Hello Holdtime option) whenever a Hello message arrives containing a Holdtime option. If the Hello message doesn't contain the Holdtime option, it gets reset to Default_Hello_Holdtime instead. Neighbor state gets deleted when the neighbor timeout expires ⏰.
The function for computing the DR on interface I is 🧮:
host
DR(I) {
dr = me
for each neighbor on interface I {
if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
dr = neighbor
}
}
return dr
}The function used for comparing DR "metrics" on interface I is:
bool
dr_is_better(a,b,I) {
if( there is a neighbor n on I for which n.dr_priority_present
is false ) {
return a.primary_ip_address > b.primary_ip_address
} else {
return ( a.dr_priority > b.dr_priority ) OR
( a.dr_priority == b.dr_priority AND
a.primary_ip_address > b.primary_ip_address )
}
}The trivial function I_am_DR(I) is defined to keep things readable 🧠:
bool
I_am_DR(I) {
return DR(I) == me
}The DR Priority is a 32-bit unsigned number, and the numerically larger priority is always preferred 📈. A router's idea of the current DR on an interface can change when a PIM Hello message is received, when a neighbor times out, or when the router's own DR Priority changes 🔀. If the router becomes the DR or stops being the DR, this will normally cause the DR Register state machine to change state 🎰. Subsequent actions are determined by that state machine 🫧.
Heads up, some PIM implementations don't send Hello messages on point-to-point interfaces, so they can't do DR election on those interfaces. That's non-compliant behavior 🙅♀️. DR election MUST be performed on ALL active PIM-SM interfaces 💯.
4.3.3. Reducing Prune Propagation Delay on LANs 🫶
Okay so, on top of everything we record for the DR Election, we also grab this per-neighbor info from the LAN Prune Delay Hello option 🧚:
neighbor.lan_prune_delay_present: a flag that's true if the LAN Prune Delay option was in the Hello message.neighbor.tracking_support: a flag that stores the T bit from the LAN Prune Delay option, if it's there. This tells you if the neighbor can turn off Join message suppression 👀.neighbor.propagation_delay: the Propagation Delay field of the LAN Prune Delay option (if present) in the Hello message.neighbor.override_interval: the Override_Interval field of the LAN Prune Delay option (if present) in the Hello message.
All of this extra state gets deleted along with the DR neighbor state when the neighbor timeout expires. Bye bye 👋
Just like the DR_Priority option, the LAN Prune Delay info doesn't get used unless every neighbor on the link advertises the option. Here's how that check works 💅:
bool
lan_delay_enabled(I) {
for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) {
return false
}
}
return true
}The Propagation Delay a router puts in the LAN Prune Delay option is the expected message propagation delay on the link, and the system administrator should be able to configure it. Upstream routers use it to figure out how long to wait for a Join override message before pruning an interface ⏳.
PIM implementers should enforce a lower bound on the allowed values for this delay, so there's room for scheduling and processing delays inside the router. Those delays can make received messages get processed later, and triggered messages get sent later than intended. 🙈 If the Propagation Delay is set too low, you can get temporary forwarding outages, because a downstream router won't be able to override a neighbor's Prune message before the upstream neighbor stops forwarding. Yikes 😭.
When all routers on a link can negotiate a Propagation Delay that's different from the default, the largest value advertised by any neighbor wins 🏆. Here's the function for Effective_Propagation_Delay of interface I:
time_interval
Effective_Propagation_Delay(I) {
if ( lan_delay_enabled(I) == false ) {
return Propagation_delay_default
}
delay = Propagation_Delay(I)
for each neighbor on interface I {
if ( neighbor.propagation_delay > delay ) {
delay = neighbor.propagation_delay
}
}
return delay
}When multiple downstream routers share a multi-access link, their override messages could all land at the same moment, which is the synchronization problem nobody wants 🙅♀️. So sending those messages gets delayed by a small random amount of time. The randomization period should reflect the size of the PIM router population on the link. Each router tells its neighbors how much randomization it thinks is needed by putting a value in the Override Interval field of the LAN Prune Delay option 🌸.
When all routers on a link can negotiate an Override Interval that's different from the default, the largest value advertised by any neighbor is chosen. Here's the function for Effective Override Interval of interface I:
time_interval
Effective_Override_Interval(I) {
if ( lan_delay_enabled(I) == false ) {
return t_override_default
}
delay = Override_Interval(I)
for each neighbor on interface I {
if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval
}
}
return delay
}The mechanisms aren't specified in this document, but if Join suppression is disabled, upstream routers can explicitly track the join membership of individual downstream routers. A router can say it's willing to disable Join suppression by using the T bit in the LAN Prune Delay Hello option 🦋. Unless every PIM router on the link negotiates this capability, explicit tracking and turning off Join suppression aren't possible. Main character energy only works when everyone's on board 💜. Here's the function that works out the state of Suppression on interface I:
bool
Suppression_Enabled(I) {
if ( lan_delay_enabled(I) == false ) {
return true
}
for each neighbor on interface I {
if ( neighbor.tracking_support == false ) {
return true
}
}
return false
}Note that the setting of Suppression_Enabled(I) affects the value of t_suppressed (see Section 4.10). Keep that connection in mind 🧠✨.
4.3.4. Maintaining Secondary Address Lists 🎀
Routers have to tell their PIM neighbors about their interface secondary addresses. That way, neighbors can map next_hop information from their MRIB to a primary address they can use as the destination for Join/Prune messages 🗺️. The mapping happens through the NBR macro. A PIM neighbor's primary address comes from the source IP address in its PIM Hello messages. Secondary addresses ride along in the Hello message inside an Address List Hello option. Also, the primary address of the router's source interface MUST NOT be listed in the Address List Hello option. Don't do it bestie 🙅♀️.
Along with the DR Election info, we also get this per-neighbor info from the Address List Hello option:
neighbor.secondary_address_list: the list of secondary addresses the PIM neighbor uses on the interface that the Hello message was sent through.
When a received PIM Hello message has an Address List Hello option, that list of secondary addresses completely replaces any secondary addresses previously tied to that neighbor. If a received PIM Hello message doesn't have an Address List Hello option, then all secondary addresses associated with the neighbor must be deleted 🗑️. And if a received PIM Hello message has an Address List Hello option that includes the sending router's primary address in the list of secondary addresses (which isn't expected, tbh), then the addresses in the message, minus the primary address, are used to update that neighbor's secondary addresses 🫠.
All the advertised secondary addresses in received Hello messages must be checked against what every other PIM neighbor on that interface has already advertised. If there's a conflict, and another neighbor already advertised the same secondary address, then only the most recently received mapping MUST be kept. An error message SHOULD be logged for the administrator, and it should be rate-limited 🚨.
Within one Address List Hello option, every address MUST be from the same address family. You can't mix IPv4 and IPv6 addresses in the same message, no cap 🙅♀️. Also, the address family of the fields in the message SHOULD match the IP source and destination addresses in the packet header 💖.
4.4. PIM Register Messages 📬
The Designated Router (DR) on a LAN or point-to-point link wraps up multicast packets from local sources and sends them to the RP for the relevant group 🚀. The only exception is if it recently got a Register-Stop message for that (S,G) or (*,G) from the RP. When the DR gets a Register-Stop message from the RP, it starts a Register-Stop Timer to keep track of that state ⏱️. Right before the Register-Stop Timer runs out, the DR sends a Null-Register Message to the RP. That lets the RP refresh the Register-Stop info at the DR 🔄. If the Register-Stop Timer actually expires, the DR goes back to encapsulating packets from the source to the RP. Back in business 💅.
4.4.1. Sending Register Messages from the DR 🦋
Every PIM-SM router can be a DR, so every router has the ability to do Register stuff 🌈. The state machine below handles Register functionality. For specification purposes, the mechanism that encapsulates packets to the RP is shown as a Register-Tunnel interface. That interface gets added to or removed from the (S,G) olist. Once it's in there, the tunnel interface follows the normal packet forwarding rules from Section 4.2, just like any other interface 🫶.
If register state is kept, it's only kept for directly connected sources, and it's kept per-(S,G). The DR's per-(S,G) Register state machine has four states:
- Join (J): The register tunnel is "joined." The join is actually implicit, but the DR acts like the RP has joined the DR on the tunnel interface.
- Prune (P): The register tunnel is "pruned." This happens when a Register-Stop is received.
- Join-Pending (JP): The register tunnel is pruned, but the DR is thinking about adding it back 🤔.
- NoInfo (NI): No information. This is the starting state, and it's also the state when the router isn't the DR.
On top of that, a Register-Stop Timer (RST) is kept whenever the state machine isn't in the NoInfo state ⏲️.
Figure 1: Per-(S,G) register state machine at a DR in tabular form
+----------++----------------------------------------------------------+
| || Event |
| ++----------+-----------+-----------+-----------+-----------+
|Prev State||Register- | Could | Could | Register- | RP changed|
| ||Stop Timer| Register | Register | Stop | |
| ||expires | ->True | ->False | received | |
+----------++----------+-----------+-----------+-----------+-----------+
|NoInfo ||- | -> J state| - | - | - |
|(NI) || | add reg | | | |
| || | tunnel | | | |
+----------++----------+-----------+-----------+-----------+-----------+
| ||- | - | -> NI | -> P state| -> J state|
| || | | state | | |
| || | | remove reg| remove reg| update reg|
|Join (J) || | | tunnel | tunnel; | tunnel |
| || | | | set | |
| || | | | Register- | |
| || | | | Stop | |
| || | | | Timer(*) | |
+----------++----------+-----------+-----------+-----------+-----------+
| ||-> J state| - | -> NI | -> P state| -> J state|
| || | | state | | |
|Join- ||add reg | | | set | add reg |
|Pending ||tunnel | | | Register- | tunnel; |
|(JP) || | | | Stop | cancel |
| || | | | Timer(*) | Register- |
| || | | | | Stop Timer|| ||-> JP | - | -> NI | - | -> J state|
| ||state | | state | | |
| ||set | | | | add reg |
|Prune (P) ||Register- | | | | tunnel; |
| ||Stop | | | | cancel |
| ||Timer(**);| | | | Register- |
| ||send Null-| | | | Stop Timer|
| ||Register | | | | |
+----------++----------+-----------+-----------+-----------+-----------+Notes: okay the table is done, now the footnotes! 🧚
- (*) The Register-Stop Timer is set to a random value chosen uniformly from the interval
( 0.5 * Register_Suppression_Time, 1.5 * Register_Suppression_Time)minusRegister_Probe_Time. Subtracting offRegister_Probe_Timeis kinda unnecessary because it's really small next toRegister_Suppression_Time, but it was in the old spec and they kept it for compatibility 🥹 - (**) The Register-Stop Timer is set to
Register_Probe_Time. 🎀
There are three actions defined here, so let's go! 💅
Add Register Tunnel
A Register-Tunnel virtual interface, VI, gets created (if it doesn't already exist) with its encapsulation target being RP(G). DownstreamJPState(S,G,VI) gets set to Join state, which causes the tunnel interface to be added to immediate_olist(S,G) and inherited_olist(S,G). ✨
Remove Register Tunnel
VI is the Register-Tunnel virtual interface with encapsulation target of RP(G). DownstreamJPState(S,G,VI) gets set to NoInfo state, which removes the tunnel interface from immediate_olist(S,G) and inherited_olist(S,G). If DownstreamJPState(S,G,VI) is NoInfo for all (S,G), then VI can be deleted. 🗑️
Update Register Tunnel
This action happens when RP(G) changes. 🔄
VI_old is the Register-Tunnel virtual interface with encapsulation target old_RP(G). A Register-Tunnel virtual interface, VI_new, gets created (if it doesn't already exist) with its encapsulation target being new_RP(G). DownstreamJPState(S,G,VI_old) is set to NoInfo state and DownstreamJPState(S,G,VI_new) is set to Join state. If DownstreamJPState(S,G,VI_old) is NoInfo for all (S,G), then VI_old can be deleted.
Note that we cannot simply change the encapsulation target of VI_old, because not every group using that tunnel has moved to the same new RP. Not me making it complicated, it's just how it is 🙈
CouldRegister(S,G)
The macro "CouldRegister" in the state machine is defined as:
bool CouldRegister(S,G) {
return ( I_am_DR( RPF_interface(S) ) AND
KeepaliveTimer(S,G) is running AND
DirectlyConnected(S) == TRUE )
}Here's the tea ☕: when a DR gets a packet from a directly connected source, KeepaliveTimer(S,G) needs to be set by the packet forwarding rules before CouldRegister(S,G) is computed in the register state machine. Otherwise the first packet from a source won't get registered. Major plot hole avoided 😭
Encapsulating Data Packets in the Register Tunnel
Conceptually, the Register Tunnel is an interface with a smaller MTU than the underlying IP interface towards the RP. IP fragmentation on packets forwarded over the Register Tunnel is done based on this smaller MTU. The encapsulating DR may do Path MTU Discovery to the RP to figure out the effective MTU of the tunnel. Fragmentation for the smaller MTU should account for both the outer IP header and the PIM register header overhead. If a multicast packet gets fragmented on the way into the Register Tunnel, each fragment is encapsulated individually, so it has IP, PIM, and inner IP headers. Lots of layers, bestie 🧁
In IPv6, the DR MUST perform Path MTU discovery, and an ICMP Packet Too Big message MUST be sent by the encapsulating DR if it gets a packet that won't fit in the effective MTU of the tunnel. If the MTU between the DR and the RP makes the effective tunnel MTU smaller than 1280 (the IPv6 minimum MTU), the DR MUST send Fragmentation Required messages with an MTU value of 1280, and MUST fragment its PIM register messages as required, using an IPv6 fragmentation header between the outer IPv6 header and the PIM Register header. This part is giving main character energy 👑
The TTL of a forwarded data packet is decremented before it's encapsulated in the Register Tunnel. The encapsulating packet uses the normal TTL that the router would use for any locally-generated IP packet. 🦋
The IP ECN bits should be copied from the original packet to the IP header of the encapsulating packet. They SHOULD NOT be set independently by the encapsulating router. ✨
The Diffserv Code Point (DSCP) should be copied from the original packet to the IP header of the encapsulating packet. It MAY be set independently by the encapsulating router, based on static configuration or traffic classification. See [12] for more discussion on setting the DSCP on tunnels. 🌈
Handling Register-Stop(*,G) Messages at the DR
An old RP might send a Register-Stop message with the source address set to all zeros. This was the normal course of action in RFC 2362 when the Register message matched against (,G) state at the RP, and it was defined as meaning "stop encapsulating all sources for this group". However, the behavior of such a Register-Stop(,G) is ambiguous or incorrect in some circumstances. Ambiguity is not it, bestie 💀
We specify that an RP should not send Register-Stop(*,G) messages, but for compatibility, a DR should be able to accept one if it's received. 🫶
A Register-Stop(,G) should be treated as a Register-Stop(S,G) for all (S,G) Register state machines that are not in the NoInfo state. A router should not apply a Register-Stop(,G) to sources that become active after the Register-Stop(*,G) was received. Timing is everything 💖
4.4.2. Receiving Register Messages at the RP
When an RP receives a Register message, the course of action is decided according to the following pseudocode: 🔥
packet_arrives_on_rp_tunnel( pkt ) {
if( outer.dst is not one of my addresses ) {
drop the packet silently.
# Note: this may be a spoofing attempt
}
if( I_am_RP(G) AND outer.dst == RP(G) ) {
sentRegisterStop = FALSE;
if ( register.borderbit == TRUE ) {
if ( PMBR(S,G) == unknown ) {
PMBR(S,G) = outer.src
} else if ( outer.src != PMBR(S,G) ) {
send Register-Stop(S,G) to outer.src
drop the packet silently.
}
}
if ( SPTbit(S,G) OR
( SwitchToSptDesired(S,G) AND
( inherited_olist(S,G) == NULL ))) {
send Register-Stop(S,G) to outer.src
sentRegisterStop = TRUE;
}
if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
if ( sentRegisterStop == TRUE ) {
set KeepaliveTimer(S,G) to RP_Keepalive_Period;
} else {
set KeepaliveTimer(S,G) to Keepalive_Period;
}
}
if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
decapsulate and forward the inner packet to
inherited_olist(S,G,rpt) # Note (+)
}
} else {
send Register-Stop(S,G) to outer.src
# Note (*)
}
}outer.dst is the IP destination address of the encapsulating header. outer.src is the IP source address of the encapsulating header, i.e., the DR's address. I_am_RP(G) is true if the group-to-RP mapping says this router is the RP for the group. 🌸
Note (): this may block traffic from S for Register_Suppression_Time if the DR learned about a new group-to-RP mapping before the RP did. However, this doesn't matter unless we figure out some way for the RP to also accept (,G) joins when it doesn't yet realize it's about to become the RP for G. It'll all get sorted out once the RP learns the new group-to-RP mapping. We decided to do nothing about this and just accept that PIM may suffer interrupted (*,G) connectivity following an RP change. Some tea is just unavoidable 🍵
Note (+): implementations are advised not to make this a special case, but to arrange for this path to rejoin the normal packet forwarding path. All of the appropriate actions from the "On receipt of data from S to G on interface iif" pseudocode in Section 4.2 should be performed. Keep it consistent, babe 🧚
KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the proper tunnel interface and the RP wants to switch to the SPT, or the SPTbit is already set. This may cause the upstream (S,G) state machine to trigger a join if inherited_olist(S,G) is not NULL. 🦋
An RP should preserve (S,G) state that was created in response to a Register message for at least ( 3 * Register_Suppression_Time ). Otherwise, the RP may stop joining (S,G) before the DR for S has restarted sending registers. Traffic would then be interrupted until the Register-Stop Timer expires at the DR. Nobody wants that, it's giving drama 😭
So, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Register_Suppression_Time + Register_Probe_Time ). ⭐
When forwarding a packet from the Register Tunnel, the TTL of the original data packet is decremented after it's decapsulated. 💅
The IP ECN bits should be copied from the IP header of the Register packet to the decapsulated packet. ✨
The Diffserv Code Point (DSCP) should be copied from the IP header of the Register packet to the decapsulated packet. The RP MAY retain the DSCP of the inner packet or re-classify the packet and apply a different DSCP. Scenarios where each of these might be useful are discussed in [12]. The RP really gets to decide its own vibe here 🌈
4.5. PIM Join/Prune Messages ✨
okay bestie, so a PIM Join/Prune message is basically a little list of groups, and for each group there's a list of sources that are Joined and Pruned 🎀 when you process one, every Joined or Pruned source for a group gets treated on its own, and it can touch one or more of the state machines below. if the Upstream Neighbor Address field is pointing at this router, (,G) Joins and Prunes can affect both the (,G) and (S,G,rpt) downstream state machines, while (,,RP), (S,G), and (S,G,rpt) Joins and Prunes can only touch their own downstream state machine 💅 if the Upstream Neighbor Address field is pointing at some other router, most Join or Prune messages could affect each upstream state machine 🧚
okay now the big vibe check: a Join/Prune should only be accepted for processing if it comes from a known PIM neighbor 👑 routers learn who their neighbors are from PIM Hello messages 🫶 so if a router gets a Join/Prune from some IP source address and it has never seen a Hello from that address, the Join/Prune SHOULD be discarded without further processing 😭 and if the Hello from a neighbor was authenticated using IPsec AH (see Section 6.3), then every Join/Prune from that neighbor MUST also be authenticated using IPsec AH 🔐 no cap, that's a rule you don't break 💀
⚠️ bestie, the thing to remember is that a Hello and the Join/Prune that follows it have to match up on authentication. if the Hello was AH-authenticated, the Joins and Prunes have to be too.
ngl there's also a little historical drama here 🙈 some older PIM implementations quietly fail to send Hello messages on point-to-point interfaces. so we also RECOMMEND that a configuration option be provided to allow interoperation with those older routers, but that this option SHOULD NOT be enabled by default 🌸 it's an escape hatch, not the main event!
4.5.1. Receiving (,,RP) Join/Prune Messages
okay so here's the per-interface state machine for receiving (,,RP) Join/Prune messages 🦋 there are three states:
- NoInfo (NI): the interface has no (,,RP) Join state and no timers running. it's giving empty 🫥
- Join (J): the interface has (,,RP) Join state, which makes the router forward packets for any group handled by RP out of this interface, unless there's also (S,G,rpt) prune info (see Section 4.5.4) or the router lost an assert on this interface 🔥
- Prune-Pending (PP): the router got a Prune(,,RP) on this interface from a downstream neighbor and is waiting to see if another downstream router overrides it 👀 for forwarding, Prune-Pending acts exactly like Join, so it's a whole vibe of "wait and see" 🍓
the state machine also runs two timers ⏰
- ExpiryTimer (ET): restarted when a valid Join(,,RP) comes in. when it expires, the interface drops back to NoInfo for this RP 🕰️
- Prune-Pending Timer (PPT): set when a valid Prune(,,RP) comes in. when it expires, the interface drops back to NoInfo for this RP 🧚
Figure 2: Downstream per-interface (,,RP) state machine in tabular form
+------------++--------------------------------------------------------+
| || Event |
| ++-------------+-------------+--------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(*,*,RP) | Prune | Pending | Expires |
| || | (*,*,RP) | Timer | |
| || | | Expires | |
+------------++-------------+-------------+--------------+-------------+
| ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | |
+------------++-------------+-------------+--------------+-------------+
| ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune-| | |
| ||Expiry Timer | Pending | | |
| || | Timer | | |
+------------++-------------+-------------+--------------+-------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP)||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(*,*,RP) | |
+------------++-------------+-------------+--------------+-------------+okay the transition events "Receive Join(,,RP)" and "Receive Prune(,,RP)" basically mean a Join or Prune aimed at this router's primary IP address, arriving on that interface 🎯 if the upstream neighbor address field is wrong, these transitions in this machine must not occur, though seeing that packet might still poke other state machines 🫣
on unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it picked for the Hello it sent over that interface 🌈 but on point-to-point links we also recommend that, for backwards compatibility, PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted 💜
Transitions from NoInfo State
when you're in NoInfo, this event can trigger a transition 🌱
- Receive Join(,,RP): a Join(,,RP) arrives on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. the (,,RP) downstream state machine on I moves to Join ✨ the Expiry Timer (ET) starts and gets set to the HoldTime from that Join/Prune message.
note that you can receive a Join(,,RP) for an RP you don't have any info saying is an RP. for (,,RP) state, as long as you have a route to the RP, that's not a problem and the transition should still happen 🙌
Transitions from Join State
when you're in Join, these events can trigger a transition 🧁
- Receive Join(,,RP): a Join(,,RP) arrives on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. the (,,RP) downstream state machine on I stays in Join, and the Expiry Timer (ET) gets restarted, set to the maximum of its current value and the HoldTime from that Join/Prune message 🔁
- Receive Prune(,,RP): a Prune(,,RP) arrives on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. the (,,RP) downstream state machine on I moves to Prune-Pending 🕓 the Prune-Pending Timer starts. it's set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface. otherwise it's set to zero, so it expires immediately 💨
- Expiry Timer Expires: the Expiry Timer for the (,,RP) downstream state machine on I expires. the (,,RP) downstream state machine on I moves to NoInfo 👋
Transitions from Prune-Pending State
when you're in Prune-Pending, these events can trigger a transition 🎀
- Receive Join(,,RP): a Join(,,RP) arrives on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. the (,,RP) downstream state machine on I moves to Join 💖 the Prune-Pending Timer gets canceled, and no expiry event gets triggered from it. the Expiry Timer is restarted, set to the maximum of its current value and the HoldTime from that Join/Prune message 🫶
- Expiry Timer Expires: the Expiry Timer for the (,,RP) downstream state machine on I expires. the (,,RP) downstream state machine on I moves to NoInfo 😌
- Prune-Pending Timer Expires: the Prune-Pending Timer for the (,,RP) downstream state machine on I expires. the (,,RP) downstream state machine on I moves to NoInfo, and a PruneEcho(,,RP) gets sent onto the subnet connected to interface I 📣
okay so the action "Send PruneEcho(,,RP)" is triggered when the router stops forwarding on an interface because of a prune 🛑 a PruneEcho(,,RP) is basically a Prune(,,RP) message that the upstream router sends on a LAN with its own address in the Upstream Neighbor Address field 🪞 its whole purpose is extra reliability. if a Prune that should have been overridden by another router gets lost locally on the LAN, the PruneEcho might still get received and make the override happen 🦸♀️ a PruneEcho(,,RP) doesn't need to be sent on an interface that had only a single PIM neighbor while this state machine was in Prune-Pending 💅
4.5.2. Receiving (*,G) Join/Prune Messages
okay, when a router gets a Join(,G), it must first check whether the RP in the message matches RP(G) (the router's idea of who the RP is) 🔍 if the RP doesn't match RP(G), the Join(,G) should be silently dropped 🤫 (note that other source list entries, like (S,G,rpt) or (S,G), in the same Group-Specific Set should still get processed! 🙌) if a router has no RP info at all (like it hasn't recently gotten a BSR message), it may choose to accept Join(,G) and treat the RP in the message as RP(G) 🤷♀️ received Prune(,G) messages get processed even if the RP in the message doesn't match RP(G) ✨
here's the per-interface state machine for receiving (*,G) Join/Prune messages 🌸 three states:
- NoInfo (NI): the interface has no (*,G) Join state and no timers running 🫥
- Join (J): the interface has (*,G) Join state, which makes the router forward packets destined for G out of this interface, unless there's also (S,G,rpt) prune info (see Section 4.5.4) or the router lost an assert on this interface 🔥
- Prune-Pending (PP): the router got a Prune(*,G) on this interface from a downstream neighbor and is waiting to see whether another downstream router overrides it 👀 for forwarding, Prune-Pending acts exactly like Join 🍓
and the state machine runs two timers ⏰
- Expiry Timer (ET): restarted when a valid Join(*,G) comes in. when it expires, the interface drops back to NoInfo for this group 🕰️
- Prune-Pending Timer (PPT): set when a valid Prune(*,G) comes in. when it expires, the interface drops back to NoInfo for this group 🧚
Figure 3: Downstream per-interface (*,G) state machine in tabular form
+------------++--------------------------------------------------------+
| || Event |
| ++-------------+--------------+-------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(*,G) | Prune(*,G) | Pending | Expires |
| || | | Timer | |
| || | | Expires | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | |
| || | Timer | | |
+------------++-------------+--------------+-------------+-------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP)||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(*,G) | |
+------------++-------------+--------------+-------------+-------------+Okay so that table is the whole (*,G) vibe in one glance 👑 Rows are the state you're already in, columns are what just happened, and the cell tells you where you go next. Iconic, honestly 🦋
The Receive Join(*,G) and Receive Prune(*,G) events basically mean a Join or Prune showed up aimed at this router's primary IP address on the interface it came in on. Now here's the tea 🫶 If the upstream neighbor address field isn't right, these transitions in this state machine must not happen. Seeing that packet might still trigger changes in other state machines though, so don't write it off completely 💜
Quick note on unnumbered interfaces on point-to-point links 🌸 The router's address should be the same as the source address it picked for the Hello message it sent over that interface. BUT we also recommend (lowercase, the vibe is chill, not a rule 😌) that for backwards compatibility, PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted. Bestie, that's just being nice to older friends 🧚
Transitions from NoInfo State 🍓
When you're in NoInfo state, this one event can switch things up:
Receive Join(*,G): a Join(,G) comes in on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The (,G) downstream state machine on interface I moves to the Join state. The Expiry Timer (ET) starts, set to the HoldTime from the Join/Prune message that triggered it ✨
Transitions from Join State 💖
When you're in Join state, these events can trigger a transition:
Receive Join(*,G): a Join(*,G) comes in on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The state machine stays in Join state, and the Expiry Timer (ET) gets restarted. It's set to the maximum of its current value and the HoldTime from the triggering Join/Prune message. Main character timer energy 🎀Receive Prune(*,G): a Prune(,G) comes in on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The (,G) downstream state machine on interface I moves to the Prune-Pending state. The Prune-Pending Timer starts, and it's set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface. Otherwise it's set to zero, so it expires immediately 💀Expiry Timer Expires: the Expiry Timer for the (*,G) downstream state machine on interface I expires. The state machine moves to the NoInfo state. Bye bye for now 🌈
Transitions from Prune-Pending State 🌸
When you're in Prune-Pending state, these events can trigger a transition:
Receive Join(*,G): a Join(*,G) comes in on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The state machine moves to the Join state. The Prune-Pending Timer gets canceled, without triggering an expiry event. The Expiry Timer restarts, set to the maximum of its current value and the HoldTime from the triggering Join/Prune message. A glow-up in real time 🦋Expiry Timer Expires: the Expiry Timer for the (*,G) downstream state machine on interface I expires. The state machine moves to the NoInfo state.Prune-Pending Timer Expires: the Prune-Pending Timer for the (,G) downstream state machine on interface I expires. The state machine moves to the NoInfo state, and a PruneEcho(,G) gets sent onto the subnet connected to interface I 📣
The action Send PruneEcho(*,G) gets triggered when the router stops forwarding on an interface because of a prune. A PruneEcho(,G) is basically a Prune(,G) message that the upstream router sends on a LAN, with its own address in the Upstream Neighbor Address field. Why does it exist? Extra reliability, bestie 🫶 If a Prune that another router should've overridden gets lost locally on the LAN, the PruneEcho may still be received and make that override happen. Also, a PruneEcho(*,G) need not be sent on an interface that only has a single PIM neighbor during the time this state machine was in Prune-Pending state. Less drama, same energy 🙈
4.5.3. Receiving (S,G) Join/Prune Messages ✨
The per-interface state machine for receiving (S,G) Join/Prune messages is given below, and it's almost identical to the (*,G) one 👯♀️ There are three states:
- NoInfo (NI): the interface has no (S,G) Join state and no (S,G) timers running. Quiet girl era 😌
- Join (J): the interface has (S,G) Join state. This makes the router forward packets from S destined for G out of this interface if the (S,G) state is active (the SPTbit is set), except if the router lost an assert on this interface. Main character forwarding 💅
- Prune-Pending (PP): the router got a Prune(S,G) on this interface from a downstream neighbor and is waiting to see whether another downstream router will override the prune. For forwarding purposes, Prune-Pending works exactly like Join. Same moves, just on a waiting-list 🧚
There are also two timers in the mix ⏰
- Expiry Timer (ET): this gets set when a valid Join(S,G) is received. When it expires, the state machine goes back to NoInfo state.
- Prune-Pending Timer (PPT): this gets set when a valid Prune(S,G) is received. When it expires, the state machine goes back to NoInfo state.
Figure 4: Downstream per-interface (S,G) state machine in tabular form 🍓
+------------++--------------------------------------------------------+
| || Event |
| ++-------------+--------------+-------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(S,G) | Prune(S,G) | Pending | Expires |
| || | | Timer | |
| || | | Expires | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | |
| || | Timer | | |
+------------++-------------+--------------+-------------+-------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP)||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(S,G) | |The transition events Receive Join(S,G) and Receive Prune(S,G) mean the router got a Join or Prune aimed at its own primary IP address on the interface it came in on 🎀. If the upstream neighbor address field isn't correct, these state transitions in this state machine must not occur 🙅♀️. Seeing such a packet may still cause state transitions in other state machines ✨.
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface 💅. However, on point-to-point links we also recommend that, for backwards compatibility, PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted 🦋.
Transitions from NoInfo State 🌸
When in NoInfo state, the following event may trigger a transition:
- Receive Join(S,G): A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The (S,G) downstream state machine on interface I transitions to the Join state. The Expiry Timer (ET) is started and set to the HoldTime from the triggering Join/Prune message.
Transitions from Join State 💜
When in Join state, the following events may trigger a transition:
- Receive Join(S,G): A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The (S,G) downstream state machine on interface I remains in Join state, and the Expiry Timer (ET) is restarted, set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
- Receive Prune(S,G): A Prune(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The (S,G) downstream state machine on interface I transitions to the Prune-Pending state. The Prune-Pending Timer is started. It is set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface; otherwise, it is set to zero, causing it to expire immediately ⏰.
- Expiry Timer Expires: The Expiry Timer for the (S,G) downstream state machine on interface I expires. The (S,G) downstream state machine on interface I transitions to the NoInfo state.
Transitions from Prune-Pending State 🫶
When in Prune-Pending state, the following events may trigger a transition:
- Receive Join(S,G): A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I. The (S,G) downstream state machine on interface I transitions to the Join state. The Prune-Pending Timer is canceled (without triggering an expiry event). The Expiry Timer is restarted, set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
- Expiry Timer Expires: The Expiry Timer for the (S,G) downstream state machine on interface I expires. The (S,G) downstream state machine on interface I transitions to the NoInfo state.
- Prune-Pending Timer Expires: The Prune-Pending Timer for the (S,G) downstream state machine on interface I expires. The (S,G) downstream state machine on interface I transitions to the NoInfo state. A PruneEcho(S,G) is sent onto the subnet connected to interface I.
The action "Send PruneEcho(S,G)" is triggered when the router stops forwarding on an interface as a result of a prune. A PruneEcho(S,G) is simply a Prune(S,G) message sent by the upstream router on a LAN with its own address in the Upstream Neighbor Address field. Its purpose is to add additional reliability: if a Prune that should have been overridden by another router is lost locally on the LAN, then the PruneEcho may be received and cause the override to happen 🔥. A PruneEcho(S,G) need not be sent on an interface that contained only a single PIM neighbor during the time this state machine was in Prune-Pending state.
4.5.4. Receiving (S,G,rpt) Join/Prune Messages ✨
The per-interface state machine for receiving (S,G,rpt) Join/Prune messages is given below. There are five states:
- NoInfo (NI): The interface has no (S,G,rpt) Prune state and no (S,G,rpt) timers running.
- Prune (P): The interface has (S,G,rpt) Prune state, which will cause the router not to forward packets from S destined for G from this interface, even though the interface has active (*,G) Join state 🚫.
- Prune-Pending (PP): The router has received a Prune(S,G,rpt) on this interface from a downstream neighbor and is waiting to see whether the prune will be overridden by another downstream router 👀. For forwarding purposes, the Prune-Pending state functions exactly like the NoInfo state.
- PruneTmp (P'): This state is a transient state that, for forwarding purposes, behaves exactly like the Prune state. A (,G) Join has been received (which may cancel the (S,G,rpt) Prune). As we parse the Join/Prune message from top to bottom, we first enter this state if the message contains a (,G) Join. Later in the message, we will normally encounter an (S,G,rpt) prune to reinstate the Prune state. However, if we reach the end of the message without encountering such an (S,G,rpt) prune, then we will revert to NoInfo state in this state machine. As no time is spent in this state, no timers can expire ⚡.
- Prune-Pending-Tmp (PP'): This state is a transient state that is identical to P' except that it is associated with the PP state rather than the P state. For forwarding purposes, PP' behaves exactly like PP state.
In addition, there are two timers:
- Expiry Timer (ET): This timer is set when a valid Prune(S,G,rpt) is received. Expiry of the Expiry Timer causes this state machine to revert to NoInfo state.
- Prune-Pending Timer (PPT): This timer is set when a valid Prune(S,G,rpt) is received. Expiry of the Prune-Pending Timer causes this state machine to move on to Prune state.
Figure 5: Downstream per-interface (S,G,rpt) state machine
in tabular form+----------++----------------------------------------------------------+
| || Event |
| ++---------+----------+----------+--------+--------+--------+
|Prev ||Receive | Receive | Receive | End of | Prune- | Expiry |
|State ||Join(*,G)| Join | Prune | Message| Pending| Timer |
| || | (S,G,rpt)| (S,G,rpt)| | Timer | Expires|
| || | | | | Expires| |
+----------++---------+----------+----------+--------+--------+--------+
| ||- | - | -> PP | - | - | - |
| || | | state | | | |
| || | | start | | | |
|NoInfo || | | Prune- | | | |
|(NI) || | | Pending | | | |
| || | | Timer; | | | |
| || | | start | | | |
| || | | Expiry | | | |
| || | | Timer | | | |
+----------++---------+----------+----------+--------+--------+--------+
| ||-> P' | -> NI | -> P | - | - | -> NI |
| ||state | state | state | | | state |
|Prune (P) || | | restart | | | |
| || | | Expiry | | | |
| || | | Timer | | | |
+----------++---------+----------+----------+--------+--------+--------+
|Prune- ||-> PP' | -> NI | - | - | -> P | - |
|Pending ||state | state | | | state | |
|(PP) || | | | | | |
+----------++---------+----------+----------+--------+--------+--------+
| ||- | - | -> P | -> NI | - | - |
|PruneTmp || | | state | state | | |
|(P') || | | restart | | | |
| || | | Expiry | | | |
| || | | Timer | | | |
+----------++---------+----------+----------+--------+--------+--------+
| ||- | - | -> PP | -> NI | - | - |
|Prune- || | | state | state | | |
|Pending- || | | restart | | | |
|Tmp (PP') || | | Expiry | | | |
| || | | Timer | | | |In the Prune-Pending-Tmp and PruneTmp states, the transitions only happen during a compound Join/Prune message, which is why you see the "End of Message" event.
The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)", and "Receive Join(*,G)" basically mean a Join or Prune aimed at this router's primary IP address on the interface it came in on 📬. If the upstream neighbor address field isn't right, these state transitions in this state machine must not occur 🙅♀️. Seeing that kind of packet might still cause state transitions in other state machines though, so it's not totally ignored 👀.
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it picked for the Hello message it sent over that interface 🦋. BUT, on point-to-point links we also recommend accepting PIM Join/Prune messages whose upstream neighbor address field is all zeros 💖.
Transitions from NoInfo State
When in NoInfo (NI) state, the following event may trigger a transition:
Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I 🎀.
The (S,G,rpt) downstream state machine on interface I transitions to the Prune-Pending state. The Expiry Timer (ET) is started and set to the HoldTime from the triggering Join/Prune message ⏳. The Prune-Pending Timer is started too. It's set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface. Otherwise it's set to zero, so it expires immediately ⚡.
Transitions from Prune-Pending State
When in Prune-Pending (PP) state, the following events may trigger a transition:
Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I 🌸.
The (S,G,rpt) downstream state machine on interface I transitions to Prune-Pending-Tmp state whilst the rest of the compound Join/Prune message containing the Join(*,G) is processed 🧚.
Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I 💅.
The (S,G,rpt) downstream state machine on interface I transitions to NoInfo state. ET and PPT are canceled 🙅♀️.
Prune-Pending Timer Expires
The Prune-Pending Timer for the (S,G,rpt) downstream state machine on interface I expires ⏰.
The (S,G,rpt) downstream state machine on interface I transitions to the Prune state.
Transitions from Prune State
When in Prune (P) state, the following events may trigger a transition:
Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I 🍓.
The (S,G,rpt) downstream state machine on interface I transitions to PruneTmp state whilst the rest of the compound Join/Prune message containing the Join(*,G) is processed 🫶.
Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I 🔥.
The (S,G,rpt) downstream state machine on interface I transitions to NoInfo state. ET and PPT are canceled 💜.
Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I 🦄.
The (S,G,rpt) downstream state machine on interface I remains in Prune state. The Expiry Timer (ET) is restarted, set to the maximum of its current value and the HoldTime from the triggering Join/Prune message 🔁.
Expiry Timer Expires
The Expiry Timer for the (S,G,rpt) downstream state machine on interface I expires 🥀.
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state.
Transitions from Prune-Pending-Tmp State
When in Prune-Pending-Tmp (PP') state and processing a compound Join/Prune message, the following events may trigger a transition:
Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt) 📝.
The (S,G,rpt) downstream state machine on interface I transitions back to the Prune-Pending state. The Expiry Timer (ET) is restarted, set to the maximum of its current value and the HoldTime from the triggering Join/Prune message ⏳.
End of Message
The end of the compound Join/Prune message is reached 🏁.
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. ET and PPT are canceled ✨.
Transitions from PruneTmp State
When in PruneTmp (P') state and processing a compound Join/Prune message, the following events may trigger a transition:
Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt) 📝.
The (S,G,rpt) downstream state machine on interface I transitions back to the Prune state. The Expiry Timer (ET) is restarted, set to the maximum of its current value and the HoldTime from the triggering Join/Prune message 🌈.
End of Message
The end of the compound Join/Prune message is reached 🏁.
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. ET is canceled 🫧.
Notes:
Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream state machine 🙅♀️.
Receiving a Join(,,RP) does not affect the (S,G,rpt) downstream state machine either. If a router has originated Join(,,RP) and pruned a source off it using Prune(S,G,rpt), then to receive that source again it should explicitly re-join using Join(S,G,rpt) or Join(,G) 🔄. In some LAN topologies, a router sending a new Join(,,RP) might have to wait as much as a Join/Prune Interval before noticing that it needs to override a neighbor's preexisting Prune(S,G,rpt) ⏳. This is considered acceptable, since (,*,RP) state is intended to be used only in long-lived and persistent scenarios 💖.
4.5.5. Sending (,,RP) Join/Prune Messages ✨
The per-interface state machines for (,,RP) hold join state from downstream PIM routers 🧺. This state then determines whether a router needs to propagate a Join(,,RP) upstream towards the RP 🚀.
If a router wishes to propagate a Join(,,RP) upstream, it must also watch for messages on its upstream interface from other routers on that subnet, and these may modify its behavior 👀. If it sees a Join(,,RP) to the correct upstream neighbor, it should suppress its own Join(,,RP) 🤐. If it sees a Prune(,,RP) to the correct upstream neighbor, it should be prepared to override that prune by sending a Join(,,RP) almost immediately ⚡. Finally, if it sees the Generation ID (see Section 4.3) of the correct upstream neighbor change, it knows that the upstream neighbor has lost state, and it should be prepared to refresh the state by sending a Join(,,RP) almost immediately 🔁.
In addition, if the MRIB changes to indicate that the next hop towards the RP has changed, the router should prune off from the old next hop and join towards the new next hop 🔀.
The upstream (,,RP) state machine contains only two states:
Not Joined
The downstream state machines and local membership information do not indicate that the router needs to join the (,,RP) tree for this RP 💤.
Joined
The downstream state machines and local membership information indicate that the router should join the (,,RP) tree for this RP 💃.
In addition, one timer JT(,,RP) is kept. It's used to trigger the sending of a Join(,,RP) to the upstream next hop towards the RP, NBR(RPF_interface(RP), MRIB.next_hop(RP)) ⏲️.
Figure 6: Upstream (,,RP) state machine in tabular form
+-------------------++-------------------------------------------------+
| || Event |
| Prev State ++-------------------------+-----------------------+
| || JoinDesired | JoinDesired |
| || (*,*,RP) ->True | (*,*,RP) ->False |
+-------------------++-------------------------+-----------------------+
| || -> J state | - |
| NotJoined (NJ) || Send Join(*,*,RP); | |
| || Set Join Timer to | |
| || t_periodic | |
+-------------------++-------------------------+-----------------------+
| Joined (J) || - | -> NJ state |
| || | Send Prune |
| || | (*,*,RP); Cancel |
| || | Join Timer |
+-------------------++-------------------------+-----------------------+In addition, we have the following transitions, which occur within the Joined state 🌟:
+----------------------------------------------------------------------+
| In Joined (J) State |
+-------------------+--------------------+-----------------------------+
| Timer Expires | See | See |
| | Join(*,*,RP) | Prune(*,*,RP) |
| | to MRIB. | to MRIB. |
| | next_hop(RP) | next_hop(RP) |
+-------------------+--------------------+-----------------------------+
| Send | Increase Join | Decrease Join |
| Join(*,*,RP); | Timer to | Timer to |
| Set Join Timer | t_joinsuppress | t_override |
| to t_periodic | | |
+-------------------+--------------------+-----------------------------+
+----------------------------------------------------------------------+
| In Joined (J) State |
+-----------------------------------+----------------------------------+
| NBR(RPF_interface(RP), | MRIB.next_hop(RP) GenID |
| MRIB.next_hop(RP)) | changes |
| changes | |
+-----------------------------------+----------------------------------+
| Send Join(*,*,RP) to new | Decrease Join Timer to |
| next hop; Send | t_override |
| Prune(*,*,RP) to old | |
| next hop; set Join Timer | |
| to t_periodic | |okay so this state machine uses one little macro 🧚
bool JoinDesired(*,*,RP) {
if immediate_olist(*,*,RP) != NULL
return TRUE
else
return FALSE
}JoinDesired(*,*,RP) is true when the router has received (,,RP) Joins from any downstream interface 🫶. ngl, even though it's true, the router's sending of a Join(*,*,RP) message can get suppressed if another router already sent a Join(*,*,RP) onto the upstream interface 🙈
Transitions from NotJoined State 💖
When the upstream (,,RP) state machine is in NotJoined state, this event may trigger a state transition:
JoinDesired(*,*,RP) becomes True🌸- The downstream state for (,,RP) has changed so that at least one interface is in
immediate_olist(*,*,RP), makingJoinDesired(*,*,RP)become True. - The upstream (,,RP) state machine transitions to Joined state. Send
Join(*,*,RP)to the appropriate upstream neighbor, which isNBR(RPF_interface(RP), MRIB.next_hop(RP)). Set the Join Timer (JT) to expire aftert_periodicseconds. ✨
- The downstream state for (,,RP) has changed so that at least one interface is in
Transitions from Joined State 🦋
When the upstream (,,RP) state machine is in Joined state, these events may trigger state transitions:
JoinDesired(*,*,RP) becomes False💅- The downstream state for (,,RP) has changed so no interface is in
immediate_olist(*,*,RP), makingJoinDesired(*,*,RP)become False. - The upstream (,,RP) state machine transitions to NotJoined state. Send
Prune(*,*,RP)to the appropriate upstream neighbor, which isNBR(RPF_interface(RP), MRIB.next_hop(RP)). Cancel the Join Timer (JT). 😭
- The downstream state for (,,RP) has changed so no interface is in
Join Timer Expires⏰- The Join Timer (JT) expires, which means it's time to send a
Join(*,*,RP). - Send
Join(*,*,RP)to the appropriate upstream neighbor, which isNBR(RPF_interface(RP), MRIB.next_hop(RP)). Restart the Join Timer (JT) to expire aftert_periodicseconds. 🔁
- The Join Timer (JT) expires, which means it's time to send a
See Join(*,*,RP) to MRIB.next_hop(RP)👀- This event only matters if
RPF_interface(RP)is a shared medium. This router sees another router onRPF_interface(RP)send aJoin(*,*,RP)toNBR(RPF_interface(RP), MRIB.next_hop(RP)). This causes this router to suppress its own Join. - The upstream (,,RP) state machine remains in Joined state.
- Let
t_joinsuppressbe the minimum oft_suppressedand the HoldTime from the Join/Prune message triggering this event. If the Join Timer is set to expire in less thant_joinsuppressseconds, reset it so that it expires aftert_joinsuppressseconds. If the Join Timer is set to expire in more thant_joinsuppressseconds, leave it unchanged. 🫧
- This event only matters if
See Prune(*,*,RP) to MRIB.next_hop(RP)🥊- This event only matters if
RPF_interface(RP)is a shared medium. This router sees another router onRPF_interface(RP)send aPrune(*,*,RP)toNBR(RPF_interface(RP), MRIB.next_hop(RP)). As this router is in Joined state, it must override the Prune after a short random interval. - The upstream (,,RP) state machine remains in Joined state. If the Join Timer is set to expire in more than
t_overrideseconds, reset it so that it expires aftert_overrideseconds. If the Join Timer is set to expire in less thant_overrideseconds, leave it unchanged. 💪
- This event only matters if
NBR(RPF_interface(RP), MRIB.next_hop(RP)) changes🔀- A change in the MRIB routing base causes the next hop towards the RP to change.
- The upstream (,,RP) state machine remains in Joined state. Send
Join(*,*,RP)to the new upstream neighbor, which is the new value ofNBR(RPF_interface(RP), MRIB.next_hop(RP)). SendPrune(*,*,RP)to the old upstream neighbor, which is the old value ofNBR(RPF_interface(RP), MRIB.next_hop(RP)). Set the Join Timer (JT) to expire aftert_periodicseconds. 🌈
MRIB.next_hop(RP) GenID changes🆔- The Generation ID of the router that is
MRIB.next_hop(RP)changes. This normally means that this neighbor has lost state, so the state has to be refreshed. - The upstream (,,RP) state machine remains in Joined state. If the Join Timer is set to expire in more than
t_overrideseconds, reset it so that it expires aftert_overrideseconds. 🎀
- The Generation ID of the router that is
4.5.6. Sending (*,G) Join/Prune Messages ✨
The per-interface state machines for (*,G) hold join state from downstream PIM routers. This state then determines whether a router needs to propagate a Join(*,G) upstream towards the RP. 🧚
If a router wishes to propagate a Join(*,G) upstream, it must also watch for messages on its upstream interface from other routers on that subnet, and these may modify its behavior. If it sees a Join(*,G) to the correct upstream neighbor, it should suppress its own Join(*,G). If it sees a Prune(*,G) to the correct upstream neighbor, it should be prepared to override that prune by sending a Join(*,G) almost immediately. Finally, if it sees the Generation ID (see Section 4.3) of the correct upstream neighbor change, it knows that the upstream neighbor has lost state, and it should be prepared to refresh the state by sending a Join(*,G) almost immediately. 🫶
If a (*,G) Assert occurs on the upstream interface, and this changes this router's idea of the upstream neighbor, it should be prepared to ensure that the Assert winner is aware of downstream routers by sending a Join(*,G) almost immediately. 👑
In addition, if the MRIB changes to indicate that the next hop towards the RP has changed, and either the upstream interface changes or there is no Assert winner on the upstream interface, the router should prune off from the old next hop and join towards the new next hop. 🔥
The upstream (*,G) state machine only contains two states:
- Not Joined 🥺
- The downstream state machines indicate that the router does not need to join the RP tree for this group.
- Joined 💜
- The downstream state machines indicate that the router should join the RP tree for this group.
In addition, one timer JT(*,G) is kept that is used to trigger the sending of a Join(*,G) to the upstream next hop towards the RP, RPF'(*,G). ⭐
Figure 7: Upstream (*,G) state machine in tabular form 🦋
+-------------------++-------------------------------------------------+
| || Event |
| Prev State ++------------------------+------------------------+
| || JoinDesired(*,G) | JoinDesired(*,G) |
| || ->True | ->False |
+-------------------++------------------------+------------------------+
| || -> J state | - |
| NotJoined (NJ) || Send Join(*,G); | |
| || Set Join Timer to | |
| || t_periodic | |
+-------------------++------------------------+------------------------+
| Joined (J) || - | -> NJ state |
| || | Send Prune(*,G); |
| || | Cancel Join Timer |
+-------------------++------------------------+------------------------+In addition, we have the following transitions, which occur within the Joined state: 🌸
+----------------------------------------------------------------------+
| In Joined (J) State |
+----------------+-----------------+-----------------+-----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) |
| | to RPF'(*,G) | to RPF'(*,G) | changes due to |
| | | | an Assert |
+----------------+-----------------+-----------------+-----------------+
|Send | Increase Join | Decrease Join | Decrease Join |
|Join(*,G); Set | Timer to | Timer to | Timer to |
|Join Timer to | t_joinsuppress | t_override | t_override |
|t_periodic | | | |
+----------------+-----------------+-----------------+-----------------+
+----------------------------------------------------------------------+
| In Joined (J) State |
+----------------------------------+-----------------------------------+
| RPF'(*,G) changes not | RPF'(*,G) GenID changes |
| due to an Assert | |
+----------------------------------+-----------------------------------+
| Send Join(*,G) to new | Decrease Join Timer to |
| next hop; Send | t_override |
| Prune(*,G) to old next | |
| hop; Set Join Timer to | |
| t_periodic | |This macro is basically the bouncer at the door 💅 It decides whether this router even wants to be part of the shared tree for G 🌸
bool JoinDesired(*,G) {
if (immediate_olist(*,G) != NULL OR
(JoinDesired(*,*,RP(G)) AND
AssertWinner(*, G, RPF_interface(RP(G))) != NULL))
return TRUE
else
return FALSE
}okay so JoinDesired(*,G) is TRUE when the router has forwarding state that would make it forward traffic for G over the shared tree 🎀 ngl that's giving main character energy 👑 Even when it's TRUE, though, another router might send a Join(,G) onto the upstream interface first, and then this router's own Join(,G) gets suppressed 🫶
Transitions from NotJoined State 🌈
When the upstream (*,G) state machine is in NotJoined state, this event can kick off a transition:
- JoinDesired(,G) becomes True ✨ The macro
JoinDesired(*,G)flips to True, for example because the downstream state for (,G) changed so that at least one interface is now inimmediate_olist(*,G). The upstream (,G) state machine moves to Joined state. It sends Join(,G) to the right upstream neighbor, which isRPF'(*,G), and sets the Join Timer (JT) to expire aftert_periodicseconds. Iconic 💖
Transitions from Joined State 🦋
When the upstream (*,G) state machine is in Joined state, these events can trigger transitions:
- JoinDesired(,G) becomes False 💀 The macro
JoinDesired(*,G)flips to False, for example because the downstream state for (,G) changed so that no interface is inimmediate_olist(*,G). The upstream (,G) state machine moves to NotJoined state. It sends Prune(,G) toRPF'(*,G)and cancels the Join Timer (JT). Bye bye 👋 - Join Timer Expires ⏰ The Join Timer (JT) has expired, which means it's time to send a Join(,G). The router sends Join(,G) to
RPF'(*,G)and restarts the Join Timer (JT) to expire aftert_periodicseconds. Consistency is everything 🍓 - See Join(,G) to RPF'(,G) 🧚 This one only matters if
RPF_interface(RP(G))is a shared medium. This router sees another router on that interface send a Join(,G) toRPF'(*,G), which makes this router suppress its own Join. The upstream (,G) state machine stays in Joined state. Lett_joinsuppressbe the minimum oft_suppressedand the HoldTime from the Join/Prune message that triggered this event. If the Join Timer is set to expire in less thant_joinsuppressseconds, reset it so it expires aftert_joinsuppressseconds. If it's set to expire in more thant_joinsuppressseconds, leave it alone 🌸 - See Prune(,G) to RPF'(,G) 🙈 Again, this only matters on a shared medium. This router sees another router on
RPF_interface(RP(G))send a Prune(,G) toRPF'(*,G). Since this router is in Joined state, it has to override that Prune after a short random interval. The upstream (,G) state machine stays in Joined state. If the Join Timer is set to expire in more thant_overrideseconds, reset it so it expires aftert_overrideseconds. If it's set to expire in less thant_overrideseconds, leave it unchanged 💜 - RPF'(,G) changes due to an Assert 🔥 The current next hop toward the RP changes because of an Assert(,G) on
RPF_interface(RP(G)). The upstream (*,G) state machine stays in Joined state. If the Join Timer is set to expire in more thant_overrideseconds, reset it so it expires aftert_overrideseconds. If it's set to expire in less thant_overrideseconds, leave it unchanged 🌷 - RPF'(,G) changes not due to an Assert 🦄 Something else happened that changed the next hop toward the RP for G. This could be a change in the MRIB routing database or in the group-to-RP mapping. Note that this transition does not happen if an Assert is active and the upstream interface doesn't change. The upstream (,G) state machine stays in Joined state. It sends Join(,G) to the new upstream neighbor, which is the new value of
RPF'(*,G), and sends Prune(,G) to the old upstream neighbor, which is the old value ofRPF'(*,G). The Prune(*,G) message uses the new value of RP(G), or all zeros if RP(G) becomes unknown. The old value of RP(G) may be used instead to improve behavior in routers implementing older versions of this spec. The Join Timer (JT) is set to expire aftert_periodicseconds ⏳ - RPF'(,G) GenID changes 🪄 The Generation ID of the router that is
RPF'(*,G)changes. This usually means that neighbor has lost state, so the state needs refreshing. The upstream (,G) state machine stays in Joined state. If the Join Timer is set to expire in more thant_overrideseconds, reset it so it expires aftert_overrideseconds 🫧
4.5.7. Sending (S,G) Join/Prune Messages ✨
okay this is the (S,G) version of everything above, but now we're working toward the source instead of the RP 🧚 The per-interface state machines for (S,G) hold join state from downstream PIM routers. That state decides whether a router needs to pass a Join(S,G) upstream toward the source 💖
If a router wants to propagate a Join(S,G) upstream, it also has to watch for messages on its upstream interface from other routers on that subnet, because those messages can change how it behaves 👀 If it sees a Join(S,G) going to the correct upstream neighbor, it should suppress its own Join(S,G). If it sees a Prune(S,G), Prune(S,G,rpt), or Prune(*,G) going to the correct upstream neighbor toward S, it should be ready to override that prune by scheduling a Join(S,G) to go out almost immediately ⚡ Finally, if it sees the Generation ID of its upstream neighbor change, it knows that neighbor has lost state, so it should refresh that state by scheduling a Join(S,G) to go out almost immediately 🌈
If an (S,G) Assert happens on the upstream interface and this changes this router's idea of the upstream neighbor, it should be ready to make sure the Assert winner knows about its downstream routers, by scheduling a Join(S,G) to go out almost immediately 🎀
Also, if MRIB changes cause the next hop toward the source to change, and either the upstream interface changes or there's no Assert winner on the upstream interface, the router should send a prune to the old next hop and a join to the new next hop 🦋
The upstream (S,G) state machine only has two states, and honestly they're pretty simple 🍓
- Not Joined 💀 The downstream state machines and local membership info don't indicate that the router needs to join the shortest-path tree for this (S,G).
- Joined 💅 The downstream state machines and local membership info indicate that the router should join the shortest-path tree for this (S,G).
There's also one timer, JT(S,G), which triggers sending a Join(S,G) to the upstream next hop toward S, which is RPF'(S,G) ⏰
Figure 8: Upstream (S,G) state machine in tabular form 📋
+-------------------+--------------------------------------------------+
| | Event |
| Prev State +-------------------------+------------------------+
| | JoinDesired(S,G) | JoinDesired(S,G) |
| | ->True | ->False |
+-------------------+-------------------------+------------------------+
| NotJoined (NJ) | -> J state | - |
| | Send Join(S,G); | |
| | Set Join Timer to | |
| | t_periodic | |
+-------------------+-------------------------+------------------------+
| Joined (J) | - | -> NJ state |
| | | Send Prune(S,G); |
| | | Set SPTbit(S,G) to |
| | | FALSE; Cancel Join |
| | | Timer |
+-------------------+-------------------------+------------------------+okay and then we have these extra transitions that happen inside the Joined state 🌸 they're a whole vibe 💫
+----------------------------------------------------------------------+
| In Joined (J) State |
+-----------------+-----------------+-----------------+----------------+
| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
| | | | RPF'(S,G) |
+-----------------+-----------------+-----------------+----------------+
| Send | Increase Join | Decrease Join | Decrease Join |
| Join(S,G); Set | Timer to | Timer to | Timer to |
| Join Timer to | t_joinsuppress | t_override | t_override |
| t_periodic | | | |
+-----------------+-----------------+-----------------+----------------++----------------------------------------------------------------------+
| In Joined (J) State |
+-----------------+-----------------+----------------+-----------------+
| See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) |
| to RPF'(S,G) | changes not | GenID changes | changes due to |
| | due to an | | an Assert |
| | Assert | | |
+-----------------+-----------------+----------------+-----------------+
| Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
| Timer to | to new next | Timer to | Timer to |
| t_override | hop; Send | t_override | t_override |
| | Prune(S,G) to | | |
| | old next hop; | | |
| | Set Join Timer | | |
| | to t_periodic | | |Okay so bestie, JoinDesired(S,G) is the big question the router asks itself 💅. Here's the macro:
bool JoinDesired(S,G) {
return( immediate_olist(S,G) != NULL
OR ( KeepaliveTimer(S,G) is running
AND inherited_olist(S,G) != NULL ) )
}JoinDesired(S,G) is true when the router has forwarding state that would make it forward traffic for G using source tree state 🌸. That source tree state can come from either active source-specific join state, or from the (S,G) Keepalive Timer plus active non-source-specific state. Now here's the plot twist 🙈: even when JoinDesired is true, the router might hold back its own Join(S,G) if another router already sent a Join(S,G) onto the upstream interface. Iconic suppression energy 🦋.
Transitions from NotJoined State
When the upstream (S,G) state machine is in NotJoined state, this event can kick off a transition:
- JoinDesired(S,G) becomes True: The macro JoinDesired(S,G) flips to True, e.g., because the downstream state for (S,G) changed so that at least one interface is now in inherited_olist(S,G). ✨ The upstream (S,G) state machine moves to Joined state. Send Join(S,G) to the appropriate upstream neighbor, which is RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic seconds.
Transitions from Joined State
When the upstream (S,G) state machine is in Joined state, these events can trigger transitions 🎀:
- JoinDesired(S,G) becomes False: The macro JoinDesired(S,G) flips to False, e.g., because the downstream state for (S,G) changed so that no interface is in inherited_olist(S,G) anymore 😭. The upstream (S,G) state machine moves to NotJoined state. Send Prune(S,G) to the appropriate upstream neighbor, which is RPF'(S,G). Cancel the Join Timer (JT), and set SPTbit(S,G) to FALSE.
- Join Timer Expires: The Join Timer (JT) expires, which means it's time to send a Join(S,G) 🔥. Send Join(S,G) to the appropriate upstream neighbor, which is RPF'(S,G). Restart the Join Timer (JT) to expire after t_periodic seconds.
- See Join(S,G) to RPF'(S,G): This event only matters if RPF_interface(S) is a shared medium 🌈. This router sees another router on RPF_interface(S) send a Join(S,G) to RPF'(S,G), and that causes this router to suppress its own Join. The upstream (S,G) state machine stays in Joined state. Let t_joinsuppress be the minimum of t_suppressed and the HoldTime from the Join/Prune message that triggered this event. If the Join Timer is set to expire in less than t_joinsuppress seconds, reset it so it expires after t_joinsuppress seconds. If the Join Timer is set to expire in more than t_joinsuppress seconds, leave it unchanged.
- See Prune(S,G) to RPF'(S,G): This event only matters if RPF_interface(S) is a shared medium 👑. This router sees another router on RPF_interface(S) send a Prune(S,G) to RPF'(S,G). Since this router is in Joined state, it must override the Prune after a short random interval. The upstream (S,G) state machine stays in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so it expires after t_override seconds.
- See Prune(S,G,rpt) to RPF'(S,G): This event only matters if RPF_interface(S) is a shared medium 💜. This router sees another router on RPF_interface(S) send a Prune(S,G,rpt) to RPF'(S,G). If the upstream router is an RFC-2362-compliant PIM router, then that Prune(S,G,rpt) will make it stop forwarding. For backwards compatibility, this router should override the prune so forwarding keeps going 🫶. The upstream (S,G) state machine stays in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so it expires after t_override seconds.
- See Prune(,G) to RPF'(S,G): This event only matters if RPF_interface(S) is a shared medium 🧚. This router sees another router on RPF_interface(S) send a Prune(,G) to RPF'(S,G). If the upstream router is an RFC-2362-compliant PIM router, then that Prune(*,G) will make it stop forwarding. For backwards compatibility, this router should override the prune so forwarding keeps going. The upstream (S,G) state machine stays in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so it expires after t_override seconds.
- RPF'(S,G) changes due to an Assert: The current next hop towards S changes because of an Assert(S,G) on the RPF_interface(S) 🍓. The upstream (S,G) state machine stays in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so it expires after t_override seconds. If the Join Timer is set to expire in less than t_override seconds, leave it unchanged.
- RPF'(S,G) changes not due to an Assert: Some event caused the next hop towards S to change. Note that this transition does not happen if an Assert is active and the upstream interface does not change 🙈. The upstream (S,G) state machine stays in Joined state. Send Join(S,G) to the new upstream neighbor, which is the new value of RPF'(S,G). Send Prune(S,G) to the old upstream neighbor, which is the old value of RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic seconds.
- RPF'(S,G) GenID changes: The Generation ID of the router that is RPF'(S,G) changes 🌸. This normally means that neighbor lost its state, so the state has to be refreshed. The upstream (S,G) state machine stays in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so it expires after t_override seconds.
4.5.8. (S,G,rpt) Periodic Messages ✨
(S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP tree with the RPT bit set 🌷. They're used either to modify the results of (,G) Joins, or to override the behavior of other upstream LAN peers. The next section describes the rules for sending triggered messages. This section describes the rules for including a Prune(S,G,rpt) message with a Join(,G).
When a router is going to send a Join(*,G), it should run the following pseudocode for each (S,G) it has state for, to decide whether to include a Prune(S,G,rpt) in the compound Join/Prune message 💖:
if( SPTbit(S,G) == TRUE ) {
# Note: If receiving (S,G) on the SPT, we only prune off the
# shared tree if the RPF neighbors differ.
if( RPF'(*,G) != RPF'(S,G) ) {
add Prune(S,G,rpt) to compound message
}
} else if ( inherited_olist(S,G,rpt) == NULL ) {
# Note: all (*,G) olist interfaces received RPT prunes for (S,G).
add Prune(S,G,rpt) to compound message
} else if ( RPF'(*,G) != RPF'(S,G,rpt) {
# Note: we joined the shared tree, but there was an (S,G) assert
# and the source tree RPF neighbor is different.
add Prune(S,G,rpt) to compound message
}Note that Join(S,G,rpt) is normally not sent as a periodic message 💅. It's sent only as a triggered message.
4.5.9. State Machine for (S,G,rpt) Triggered Messages 🦋
The state machine for (S,G,rpt) triggered messages is required per-(S,G) whenever there is (,G) or (,*,RP) join state at a router, and the router or any of its upstream LAN peers wants to prune S off the RP tree 👑.
There are three states in this machine. One of them is the state where there's neither (,G) nor (,,RP(G)) join state at this router. If there is (,G) or (,,RP(G)) join state at the router, then the state machine must be in one of the other two states. The three states are:
Pruned(S,G,rpt): (,G) or (,*,RP(G)) Joined, but (S,G,rpt) prunedNotPruned(S,G,rpt): (,G) or (,*,RP(G)) Joined, and (S,G,rpt) not prunedRPTNotJoined(G): neither (,G) nor (,*,RP(G)) has been joined
Also there's an (S,G,rpt) Override Timer, OT(S,G,rpt) 🌈. It's used to delay triggered Join(S,G,rpt) messages so they don't implode all at once.
Figure 9: Upstream (S,G,rpt) state machine for triggered messages in tabular form
+------------++--------------------------------------------------------+
| || Event |
| ++--------------+--------------+-------------+------------+
|Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ |
| || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist |
| || ->True | ->False | ->False | (S,G,rpt) |
| || | | | ->non-NULL |
+------------++--------------++--------------+-------------+------------+
|RPTNotJoined|| -> P state | - | - | -> NP state|
|(G) (NJ) || | | | |
+------------++--------------+--------------+-------------+------------+
|Pruned || - | -> NP state | -> NJ state | - |
|(S,G,rpt) || | Send Join | | |
|(P) || | (S,G,rpt) | | |
+------------++--------------+--------------+-------------+------------+
|NotPruned || -> P state | - | -> NJ state | - |
|(S,G,rpt) || Send Prune | | Cancel OT | |
|(NP) || (S,G,rpt); | | | |
| || Cancel OT | | | |
+------------++--------------+--------------+-------------+------------+Additionally, there are the following transitions within the NotPruned(S,G,rpt) state, which are all used for prune override behavior 🎀.
+----------------------------------------------------------------------+
| In NotPruned(S,G,rpt) State |
+----------+--------------+--------------+--------------+--------------+
|Override | See Prune | See Join | See Prune | RPF' |
|Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> |
|expires | RPF' | RPF' | RPF' | RPF' (*,G) |
| | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | |
+----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, |
|(S,G,rpt);| t_override) | | t_override) | t_override) |
|Leave OT | | | | |
|unset | | | | |Note that the min function in the above state machine treats a non-running timer as having an infinite value, so min(not-running, t_override) = t_override. Okay, that's a clean trick 🧠✨
This state machine uses the following macros:
bool RPTJoinDesired(G) {
return (JoinDesired(*,G) OR JoinDesired(*,*,RP(G)))
}RPTJoinDesired(G) is true when the router has forwarding state that would make it forward traffic for G using either (,G) or (,*,RP) shared tree state. 🌳
bool PruneDesired(S,G,rpt) {
return ( RPTJoinDesired(G) AND
( inherited_olist(S,G,rpt) == NULL
OR (SPTbit(S,G)==TRUE
AND (RPF'(*,G) != RPF'(S,G)) )))
}PruneDesired(S,G,rpt) can only be true if RPTJoinDesired(G) is true. 🔒 If RPTJoinDesired(G) is true, then PruneDesired(S,G,rpt) is also true when there are no outgoing interfaces that S would be forwarded on, or when the router has active (S,G) forwarding state but RPF'(*,G) != RPF'(S,G). Two ways to get there, both very valid 💅
The state machine has the following transition events:
See Join(S,G,rpt) to RPF'(S,G,rpt) This event only matters in the "Not Pruned" state. 👀
The router sees a Join(S,G,rpt) from someone else going to RPF'(S,G,rpt), which is the correct upstream neighbor. If we're in the "NotPruned" state and the (S,G,rpt) Override Timer is running, it's because we were triggered to send our own Join(S,G,rpt) to RPF'(S,G,rpt). Someone else beat us to it, so we don't need to send ours. Iconic of them, honestly 🙌
The action is to cancel the Override Timer.
See Prune(S,G,rpt) to RPF'(S,G,rpt) This event only matters in the "NotPruned" state. 🚨
The router sees a Prune(S,G,rpt) from someone else going to RPF'(S,G,rpt), which is the correct upstream neighbor. If we're in the "NotPruned" state, we still want to keep receiving traffic from S destined for G, and RPF'(S,G,rpt) is the one supplying it. So we have to override the Prune. Not me being messy about it, just protecting the feed 💖
The action is to set the (S,G,rpt) Override Timer to the randomized prune-override interval, t_override. If the Override Timer is already running, we only set it when that would make it a lower value. When the interval ends, if noone else has sent a Join, we'll send one ourselves. 🦋
See Prune(S,G) to RPF'(S,G,rpt) This event only matters in the "NotPruned" state. 🌸
This transition and action are the same as the one above, except the Prune doesn't have the RPT bit set. This transition is needed so we play nicely with routers implemented from RFC2362, which don't keep separate (S,G) and (S,G,rpt) state. Compatibility is everything, babe 🫶
The (S,G,rpt) prune Override Timer expires This event only matters in the "NotPruned" state. ⏰
When the Override Timer expires, we need to send a Join(S,G,rpt) to RPF'(S,G,rpt) to override the Prune that started the timer. We only send it if RPF'(S,G,rpt) equals RPF'(,G). If that's not the case, the Join might go to a router that doesn't have (,G) or (,,RP(G)) Join state, and then the behaviour wouldn't be well defined 😭 If RPF'(S,G,rpt) is not the same as RPF'(,G), it may stop forwarding S. But if that happens, the router sends an AssertCancel(S,G), which makes RPF'(S,G,rpt) become equal to RPF'(,G) (see below). Self-correcting, the way I like it 🔁
RPF'(S,G,rpt) changes to become equal to RPF'(*,G) This event only matters in the "NotPruned" state. 🎀
RPF'(S,G,rpt) can only be different from RPF'(,G) if an (S,G) Assert has happened. That means traffic from S is arriving on the SPT, so a Prune(S,G,rpt) was sent to RPF'(,G). When RPF'(S,G,rpt) becomes equal to RPF'(,G), we need to trigger a Join(S,G,rpt) to RPF'(,G) so that router starts forwarding S again. Get back in there, girl 💅
The action is to set the (S,G,rpt) Override Timer to the randomized prune-override interval t_override. If the timer is already running, we only set it when that would make it a lower value. When the interval ends, if noone else has sent a Join, we'll send one. ✨
PruneDesired(S,G,rpt)->TRUE See the macro above. This event matters in the "NotPruned" and "RPTNotJoined(G)" states. 🧚
The router wants to receive traffic for G, but doesn't want to receive traffic from S destined for G. That makes the router transition into the Pruned state. Main character decision, no notes 👑
If the router was previously in the NotPruned state, the action is to send a Prune(S,G,rpt) to RPF'(S,G,rpt) and to cancel the Override Timer. If the router was previously in the RPTNotJoined(G) state, there's nothing to trigger in this state machine, because sending a Prune(S,G,rpt) is handled by the rules for sending Join(,G) or Join(,*,RP). Different department, same vibes 💜
PruneDesired(S,G,rpt)->FALSE See the macro above. This transition only matters in the "Pruned" state. 🍓
If the router is in the Pruned(S,G,rpt) state and PruneDesired(S,G,rpt) changes to FALSE, that could be because the router no longer has RPTJoinDesired(G) true, or because it now wants to receive traffic from S again. If it's the former, this transition shouldn't happen, and the "RPTJoinDesired(G)->FALSE" transition should happen instead. So this transition should be read as "PruneDesired(S,G,rpt)->FALSE AND RPTJoinDesired(G)==TRUE". Read the fine print, bestie 🙈
The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).
RPTJoinDesired(G)->FALSE This event matters in the "Pruned" and "NotPruned" states. 🌈
The router no longer wants to receive any traffic destined for G on the RP Tree. That causes a transition to the RPTNotJoined(G) state, and the Override Timer is canceled if it was running. Anything else is handled by the upstream state machine for (,G) or (,*,RP), as appropriate. Passing the baton 🏃♀️
inherited_olist(S,G,rpt) becomes non-NULL This transition only matters in the RPTNotJoined(G) state. 🦄
The router has joined the RP tree (handled by the (,G) or (,*,RP) upstream state machine, as appropriate) and wants to receive traffic from S. This doesn't trigger any events in this state machine, but it does cause a transition to the NotPruned(S,G,rpt) state. Glow-up complete ✨
4.5.10. Background: (,,RP) and (S,G,rpt) Interaction 🌟
In Sections 4.5.8 and 4.5.9, we covered how periodic and triggered (S,G,rpt) messages get sent. The astute reader will notice that periodic Prune(S,G,rpt) messages are only sent in PIM Join/Prune messages containing a Join(,G), whereas a triggered Prune(S,G,rpt) can be sent when the router has no (,G) join state. This might seem like a contradiction 🙃 but it's actually intentional, and it's a side effect of not optimizing (,,RP) behaviour.
First, receiving a Join(,,RP) by itself doesn't cancel (S,G,rpt) prune state on that interface. Receiving a Join(,G) by itself does cancel it. Similarly, receiving a Prune(,G) on an interface with (,,RP) join state doesn't stop forwarding G using the (,,RP) state, because a Prune(,G) only cancels (,G) join state. Conceptually, (,,RP) state sits "above" the normal (,G) and (S,G) mechanisms, so neither Join(,,RP) nor Prune(,*,RP) messages affect any other state. 🧁
So, to stop forwarding (S,G) on (,,RP) state, a Prune(S,G,rpt) must be used. 🚫
We also note that, for historical reasons, there is no Assert(,,RP) message, so any forwarding contention is resolved using Assert(*,G) messages. 📜
Now let's look at how (,,RP) state and (,G) state interact. If two upstream routers on a LAN need to assert, we have to make sure the right thing happens for every combination of (,,RP) and (,G) forwarding state. Since there's no Assert(,,RP) message, no router can tell whether the assert winner has (,,RP) state or (,G) state. So a downstream router has to treat the two the same and send its periodic Prune(S,G,rpt) messages to RPF'(,G). 🤝
To avoid writing out all the complicated override rules between (,,RP), (,G), and (S,G,rpt), we simply require that a Join(,G) must also be sent in order to prune (S,G) off the (,,RP) tree. Simple is iconic 💖
If a router is receiving on (,,RP) state and hasn't had (,G) state instantiated yet, it may still need to send a triggered Join(S,G,rpt) to override a Prune(S,G,rpt) it sees directed to RPF'(,G) on its upstream interface. So triggered (S,G,rpt) messages may be sent when JoinDesired(,G) is false but JoinDesired(,*,RP) is true. 🎯
Last one: there's an unoptimized case where the upstream router on a LAN already has (,G) join and (S,G,rpt) prune state caused by an existing downstream router. If a new Join(,,RP) comes in from a different downstream router at this point, it won't override that (S,G,rpt) prune state at the upstream router. The override only happens the next time the original downstream router resends its Prune(S,G,rpt). This case wasn't considered worth optimizing, since (,*,RP) state is generally very long lived, so a minor delay in getting traffic to a new PMBR seems unimportant. Honestly, a small wait for a long-lived state is fine 🌸
4.6. PIM Assert Messages 🎀
Where multiple PIM routers peer over a shared LAN, more than one upstream router can have valid forwarding state for a packet. That can lead to packet duplication (see Section 3.6). PIM doesn't try to stop this from happening. Instead, it detects when it has happened and elects a single forwarder among the upstream routers to prevent further duplication. This election uses PIM Assert messages. Downstream routers on the LAN also receive Assert messages, and those cause subsequent Join/Prune messages to be sent to the upstream router that won the Assert. Teamwork makes the dream work 🫶
In general, a PIM Assert message should only be accepted for processing if it comes from a known PIM neighbour. A PIM router learns about its PIM neighbours through PIM Hello messages. If a router receives an Assert message from a particular IP source address and it hasn't seen a PIM Hello message from that source address, the Assert message SHOULD be discarded without further processing. 🚫 Also, if the Hello message from a neighbour was authenticated using the IPsec Authentication Header (AH) (see Section 6.3), then all Assert messages from that neighbour MUST also be authenticated using IPsec AH. Security check, no skipping 🔐
We note that some older PIM implementations incorrectly fail to send Hello messages on point-to-point interfaces. So we also RECOMMEND that a configuration option be provided to allow interoperation with those older routers, but that this configuration option SHOULD NOT be enabled by default. Opt-in only, bestie, not a default 🙅♀️💜
4.6.1. (S,G) Assert Message State Machine ✨
okay so the (S,G) Assert state machine for interface I is shown in Figure 10 💖 and there are three states you need to know about 🦋
- NoInfo (NI): this router has no (S,G) assert state on interface I. Totally blank slate, no drama yet 🌸
- I am Assert Winner (W): this router has won an (S,G) assert on interface I. It is now in charge of forwarding traffic from S destined for G out of interface I 👑 Like, it's the main character now. Even if it's not the DR for I, while it's the assert winner it's also responsible for forwarding traffic onto I for local hosts on I that made membership requests specifically referring to S (and G). Iconic behavior, honestly 💅
- I am Assert Loser (L): this router lost an (S,G) assert on interface I, and it's giving "stepped back." It must not forward packets from S destined for G onto interface I 🙈 If it's the DR on I, it's also no longer responsible for forwarding traffic onto I to satisfy local hosts with membership requests that specifically refer to S and G. Not me giving up the spotlight though 😭
There's also an Assert Timer (AT) that handles two jobs: timing out asserts on the assert losers, and resending asserts on the assert winner ⭐ Timers are lowkey the real backbone of this whole thing 🧚
Figure 10: Per-interface (S,G) Assert State machine in tabular form
+----------------------------------------------------------------------+
| In NoInfo (NI) State |
+---------------+-------------------+------------------+---------------+
| Receive | Receive Assert | Data arrives | Receive |
| Inferior | with RPTbit | from S to G on | Acceptable |
| Assert with | set and | I and | Assert with |
| RPTbit clear | CouldAssert | CouldAssert | RPTbit clear |
| and | (S,G,I) | (S,G,I) | and AssTrDes |
| CouldAssert | | | (S,G,I) |
| (S,G,I) | | | |
+---------------+-------------------+------------------+---------------+
| -> W state | -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] |
+---------------+-------------------+------------------+---------------+
+----------------------------------------------------------------------+
| In I Am Assert Winner (W) State |
+----------------+------------------+-----------------+----------------+
| Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (S,G,I) -> |
| | Assert | Assert | FALSE |
+----------------+------------------+-----------------+----------------+
| -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
+----------------+------------------+-----------------+----------------+
+---------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+-------------+-------------+-------------+-------------+-------------+
|Receive |Receive |Receive |Assert Timer |Current |
|Preferred |Acceptable |Inferior |Expires |Winner's |
|Assert |Assert with |Assert or | |GenID |
| |RPTbit clear |Assert | |Changes or |
| |from Current |Cancel from | |NLT Expires |
| |Winner |Current | | |
| | |Winner | | |
+-------------+-------------+-------------+-------------+-------------+
|-> L state |-> L state |-> NI state |-> NI state |-> NI state |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------+
+----------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+----------------+-----------------+------------------+----------------+
| AssTrDes | my_metric -> | RPF_interface | Receive |
| (S,G,I) -> | better than | (S) stops | Join(S,G) on |
| FALSE | winner's | being I | interface I |
| | metric | | |
+----------------+-----------------+------------------+----------------+
| -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
+----------------+-----------------+------------------+----------------+Quick heads up, bestie 🎀 the table uses a shorthand for convenience: "AssTrDes(S,G,I)" is just a compact way of writing AssertTrackingDesired(S,G,I) 🧠 Very on brand for keeping things tidy 💜
Now the terminology, which is super important so pay attention 👀
- A "preferred assert" is one with a better metric than the current winner 🏆
- An "acceptable assert" is one that has a better metric than my_assert_metric(S,G,I). An assert is never considered acceptable if its metric is infinite 🚫♾️ (no cap, infinity is never acceptable lol)
- An "inferior assert" is one with a worse metric than my_assert_metric(S,G,I). An assert is never considered inferior if my_assert_metric(S,G,I) is infinite 🫶
The state machine uses the following macros:
CouldAssert(S,G,I) is the big check for this part, so here it is verbatim 💅
CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) )Okay so CouldAssert(S,G,I) comes out TRUE for downstream interfaces that would already be in the inherited_olist(S,G) if we pretended the (S,G) assert info didn't exist 🦋 It's like asking "would this interface be forwarding if the assert drama never happened?" 🙈
AssertTrackingDesired(S,G,I) =
(I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) ) )
OR (local_receiver_include(S,G,I) == TRUE
AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me)))
OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE))
OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE)
AND (SPTbit(S,G) == FALSE))AssertTrackingDesired(S,G,I) is TRUE on any interface where an (S,G) assert could change how we behave ✨ It's the "should I even care about asserts on this interface?" check, and it's giving thorough.
Here's how the lines break down, bestie:
- The first three lines cover the (*,G) join and local membership info that came in on
Iand might make us care about asserts onI🌸 - The 4th line covers the (S,G) join info that came in on
Iand could make us care about asserts onI💜 - The 5th and 6th lines cover (S,G) local membership on
I. We can't use thepim_include(S,G)macro here, ngl, because it leans onlost_assert(S,G,I). That would make the router forget it lost an assert just because it was interested for local membership reasons 😭 - The
AssertWinner(S,G,I) == mecheck is what keeps an assert winner in charge of forwarding for as long as local receivers are around. Take that check out, and the winner would stop forwarding the moment the thing that made it forward disappeared, and forwarding for local receivers would fall back to the DR 🫶 - The last three lines exist because a router has to track assert info on upstream interfaces so it can send its joins and prunes to the right neighbor 🌈
Transitions from NoInfo State
When we're in NoInfo state, these events can kick off transitions:
Receive Inferior Assert with RPTbit cleared AND CouldAssert(S,G,I)==TRUE We get an (S,G) assert with the RPT bit cleared that's worse than our own assert metric. A cleared RPT bit means the sender had (S,G) forwarding state on this interface 👑 If the assert is worse than ours, we must also have (S,G) forwarding state (so CouldAssert(S,G,I)==TRUE), because (S,G) asserts beat (*,G) asserts. That means we should be the assert winner, so we move to the "I am Assert Winner" state and do Actions A1 (below) 💖
Receive Assert with RPTbit set AND CouldAssert(S,G,I)==TRUE We get an (S,G) assert on I with the RPT bit set, which makes it a (*,G) assert. CouldAssert(S,G,I) is only TRUE if we have (S,G) forwarding state on this interface, so we should be the assert winner. We move to the "I am Assert Winner" state and do Actions A1 (below) 🍓
An (S,G) data packet arrives on interface I, AND CouldAssert(S,G,I)==TRUE An (S,G) data packet shows up on a downstream interface that's in our (S,G) outgoing interface list. We optimistically assume we'll win the assert for this (S,G), so we move to the "I am Assert Winner" state and do Actions A1 (below), which kicks off the assert negotiation for (S,G) 🔥
Receive Acceptable Assert with RPT bit clear AND AssertTrackingDesired(S,G,I)==TRUE We care about (S,G) asserts, either because I is a downstream interface where we have (S,G) or (*,G) forwarding state, or because I is the upstream interface for S and we have (S,G) forwarding state. The assert we got has a better metric than ours, so we don't win. We move to "I am Assert Loser" and do Actions A6 (below) 🦋
Transitions from "I am Assert Winner" State
Once we're in "I am Assert Winner" state, these events trigger transitions:
Assert Timer Expires The (S,G) Assert Timer ran out. Since we're the Winner, we must still have (S,G) forwarding state that's actively being kept alive. So we resend the (S,G) Assert and restart the Assert Timer (Actions A3 below) ⏰ Heads up: the assert winner's Assert Timer is set to go off shortly before the timers on the assert losers. That stops the forwarder from thrashing and stops duplicate packets from flooding in periodically 🧚
Receive Inferior Assert We get an (S,G) assert or (*,G) assert that mentions S and has a worse metric than ours. Whoever sent it is wrong, so we resend an (S,G) Assert and restart the Assert Timer (Actions A3 below) 🙄
Receive Preferred Assert We get an (S,G) assert with a better metric than ours. We move to "I am Assert Loser" and do Actions A2 (below). This might change the value of JoinDesired(S,G) and PruneDesired(S,G,rpt), which could set off transitions in the upstream (S,G) or (S,G,rpt) state machines 💅
CouldAssert(S,G,I) -> FALSE Our (S,G) forwarding state or RPF interface changed in a way that makes CouldAssert(S,G,I) FALSE. We can't do the assert winner's job anymore, so we move to NoInfo state and do Actions A4 (below). That includes sending a "canceling assert" with an infinite metric 🚫
Transitions from "I am Assert Loser" State
When we're in "I am Assert Loser" state, these transitions can happen:
Receive Preferred Assert We get an assert that's better than the current assert winner's. We stay in Loser state and do Actions A2 (below) 🌟
Receive Acceptable Assert with RPTbit clear from Current Winner We get an assert from the current assert winner that's better than our own metric for this (S,G). The metric might be worse than the winner's previous one, though. We stay in Loser state and do Actions A2 (below) 🫧
Receive Inferior Assert or Assert Cancel from Current Winner We get an assert from the current assert winner that's worse than our own metric for this group. This usually happens because the winner's metric got worse, or because it's an assert cancel. We move to NoInfo state, delete the (S,G) assert info, and let the normal PIM Join/Prune mechanisms take over. Usually we'll eventually re-assert and win once data packets from S start flowing again 🌊
Assert Timer Expires The (S,G) Assert Timer expires. We move to NoInfo state and delete the (S,G) assert info (Actions A5 below) ⌛
Current Winner's GenID Changes or NLT Expires The Neighbor Liveness Timer for the current winner expires, or we get a Hello message from the current winner with a different GenID than the one it reported before. That means the current winner's interface or router went down, and maybe came back up, so we have to assume it doesn't know it's the winner anymore 🥺 We move to NoInfo state and delete this (S,G) assert info (Actions A5 below) 💀
AssertTrackingDesired(S,G,I)->FALSE AssertTrackingDesired(S,G,I) flips to FALSE. Our forwarding state changed so that (S,G) asserts on interface I aren't interesting to us anymore. We move to NoInfo state and delete the (S,G) assert info 🍃
My metric becomes better than the assert winner's metric my_assert_metric(S,G,I) changed so that our assert metric for (S,G) now beats the metric we stored for the current assert winner. This can happen when the underlying routing metric changes, or when CouldAssert(S,G,I) becomes true, like when SPTbit(S,G) becomes true 🏆 We move to NoInfo state, delete this (S,G) assert state (Actions A5 below), and let the normal PIM Join/Prune mechanisms run. Usually we'll eventually re-assert and win once data packets from S start flowing again ✨
RPF_interface(S) stops being interface I Interface I used to be the RPF interface for S, and now it isn't. We move to NoInfo state and delete this (S,G) assert state (Actions A5 below) 🧭
Receive Join(S,G) on Interface I We get a Join(S,G) whose Upstream Neighbor Address field is set to our primary IP address on interface I. We move to NoInfo state, delete this (S,G) assert state (Actions A5 below), and let the normal PIM Join/Prune mechanisms take over. If whoever sent the Join messed up, the normal assert mechanism will eventually reapply, and we'll lose the assert again. But whoever sent the assert might know the previous winner died, so we could end up as the new forwarder 🌸
(S,G) Assert State machine Actions
A1: Send Assert(S,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval). Store ourselves as AssertWinner(S,G,I). Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I). 💖
A2: Store new assert winner as AssertWinner(S,G,I) and assert winner metric as AssertWinnerMetric(S,G,I). Set Assert Timer to Assert_Time. 🎀
A3: Send Assert(S,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval). 📣
A4: Send AssertCancel(S,G). Delete assert info (AssertWinner(S,G,I) and AssertWinnerMetric(S,G,I) will then return their default values). 🚫
A5: Delete assert info (AssertWinner(S,G,I) and AssertWinnerMetric(S,G,I) will then return their default values). 🧹
A6: Store new assert winner as AssertWinner(S,G,I) and assert winner metric as AssertWinnerMetric(S,G,I). Set Assert Timer to Assert_Time. If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == true) set SPTbit(S,G) to TRUE. 🌈
Note that some of these actions can change the value of JoinDesired(S,G), PruneDesired(S,G,rpt), or RPF'(S,G), which can set off more transitions in other state machines. That's the whole assert web, and it's all connected 🕸️💜
4.6.2. (*,G) Assert Message State Machine ✨
okay bestie, the (*,G) Assert state machine for interface I is shown in Figure 11 🦋 and it has three states 💅
- NoInfo (NI): this router has no (*,G) assert state on interface I. Totally clean slate 🧚
- I am Assert Winner (W): this router has won an (*,G) assert on interface I 👑. It's now responsible for forwarding traffic destined for G onto interface I, except for traffic where it has (S,G) "I am Assert Loser" state. Even if it isn't the DR for I, it's also responsible for handling the membership requests for G from local hosts on I. Main character energy, fr fr 🎀
- I am Assert Loser (L): this router has lost an (*,G) assert on interface I 💀. It must not forward packets for G onto interface I, except for traffic from sources where it has (S,G) "I am Assert Winner" state. If it's the DR, it's no longer responsible for handling the membership requests for group G from local hosts on I.
There's also an Assert Timer (AT) 🌸 that's used to time out asserts on the assert losers and to resend asserts on the assert winner. It's giving timekeeping ⏰
When an Assert message comes in with a source address other than zero, a PIM implementation has to match it against the possible events in the (S,G) assert state machine first 🫶 and process any transitions and actions. Only then does it check whether the Assert message matches the (*,G) assert state machine. Order matters, periodt 💅
Now this is the big one, so pay attention 😭 NO TRANSITION CAN OCCUR in the (,G) state machine because of a received Assert message, unless the (S,G) assert state machine for the relevant S and G is in the "NoInfo" state after the (S,G) state machine has processed the message. Also, NO TRANSITION CAN OCCUR in the (,G) state machine because of a received assert message if that message triggers any change of state in the (S,G) state machine. And obviously, when the source address in the received message is set to zero, there's no (S,G) state machine for that S and G, so it can be assumed to be in the "NoInfo" state 🙈
Let me show you with examples, because iykyk 🍓
Example one: if both the (S,G) and (,G) assert state machines are in the NoInfo state when an Assert message arrives, and the message causes the (S,G) state machine to transition to either "W" or "L" state, then the assert will not be processed by the (,G) assert state machine. (S,G) got there first, bestie 👑
Example two: if the (S,G) assert state machine is in "L" state when an assert message is received, and the assert metric in the message is worse than my_assert_metric(S,G,I), then the (S,G) assert state machine transitions to NoInfo state. In that case, you might think the (*,G) assert state machine, if it were in NoInfo state, would transition to "W" state. But nope 🙅♀️ it doesn't, because this message already triggered a transition in the (S,G) assert state machine. Not me thinking I was right 😭
Figure 11: Per-interface (*,G) Assert State machine in tabular form 🌈
+----------------------------------------------------------------------+
| In NoInfo (NI) State |
+-----------------------+-----------------------+----------------------+
| Receive Inferior | Data arrives for G | Receive Acceptable |
| Assert with RPTbit | on I and | Assert with RPTbit |
| set and | CouldAssert | set and AssTrDes |
| CouldAssert(*,G,I) | (*,G,I) | (*,G,I) |
+-----------------------+-----------------------+----------------------+
| -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A2] |
+-----------------------+-----------------------+----------------------++---------------------------------------------------------------------+
| In I Am Assert Winner (W) State |
+----------------+-----------------+-----------------+----------------+
| Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (*,G,I) -> |
| | Assert | Assert | FALSE |
+----------------+-----------------+-----------------+----------------+
| -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
+----------------+-----------------+-----------------+----------------++---------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+-------------+-------------+-------------+-------------+-------------+
|Receive |Receive |Receive |Assert Timer |Current |
|Preferred |Acceptable |Inferior |Expires |Winner's |
|Assert with |Assert from |Assert or | |GenID |
|RPTbit set |Current |Assert | |Changes or |
| |Winner with |Cancel from | |NLT Expires |
| |RPTbit set |Current | | |
| | |Winner | | |
+-------------+-------------+-------------+-------------+-------------+
|-> L state |-> L state |-> NI state |-> NI state |-> NI state |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------++----------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+----------------+----------------+-----------------+------------------+
| AssTrDes | my_metric -> | RPF_interface | Receive |
| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or |
| FALSE | Winner's | being I | Join |
| | metric | | (*,*,RP(G)) on |
| | | | Interface I |
+----------------+----------------+-----------------+------------------+
| -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |The state machine runs on a handful of macros, so let's set them up first 💅
CouldAssert(*,G,I) =
( I in ( joins(*,*,RP(G)) (+) joins(*,G)
(+) pim_include(*,G)) )
AND (RPF_interface(RP(G)) != I)CouldAssert(*,G,I) is true on downstream interfaces where we have (*,*,RP(G)) or (*,G) join state, or where local members asked for any traffic destined for G. It's giving "we're in charge of this group" 👑
AssertTrackingDesired(*,G,I) =
CouldAssert(*,G,I)
OR (local_receiver_include(*,G,I)==TRUE
AND (I_am_DR(I) OR AssertWinner(*,G,I) == me))
OR (RPF_interface(RP(G)) == I AND RPTJoinDesired(G))AssertTrackingDesired(*,G,I) is true on any interface where a (*,G) assert could change how we act. To keep things short, the state machine table calls it AssTrDes(*,G,I) 🧚
Some terms you'll see a lot:
- A preferred assert has a better metric than the current winner 🌟
- An acceptable assert has a better metric than
my_assert_metric(*,G,I). An assert is never acceptable if its metric is infinite 🙅♀️ - An inferior assert has a worse metric than
my_assert_metric(*,G,I). An assert is never inferior ifmy_assert_metric(*,G,I)is infinite 💀
Transitions from NoInfo State
When we're in NoInfo state, these events cause transitions, but only if the (S,G) assert state machine is in NoInfo state both before and after the message gets considered 👀
Receive Inferior Assert with RPTbit set AND CouldAssert(*,G,I)==TRUE An inferior (*,G) assert arrives for G on interface I. If CouldAssert(*,G,I) is TRUE, then I is our downstream interface and we have (*,G) forwarding state there, so we should be the assert winner. We move to the "I am Assert Winner" state and do Actions A1 (below) 🏆
A data packet destined for G arrives on interface I, AND CouldAssert(*,G,I)==TRUE A data packet for G shows up on a downstream interface that's in our (*,G) outgoing interface list. So we believe we should be the forwarder for this (*,G), and we move to the "I am Assert Winner" state and do Actions A1 (below) 🦋
Receive Acceptable Assert with RPT bit set AND AssertTrackingDesired(*,G,I)==TRUE We care about (*,G) asserts, either because I is a downstream interface where we have (*,G) forwarding state, or because I is the upstream interface for RP(G) and we have (*,G) forwarding state. A (*,G) assert with a better metric than ours arrives, so we don't win. We move to "I am Assert Loser" and do Actions A2 (below) 🥲
Transitions from "I am Assert Winner" State
When we're in "I am Assert Winner" state, these events cause transitions, but only if the (S,G) assert state machine is in NoInfo state both before and after the message gets considered 💖
Receive Inferior Assert We get a (*,G) assert with a worse metric than ours. Whoever sent it lost, so we resend a (*,G) Assert and restart the Assert Timer (Actions A3 below) 😤
Receive Preferred Assert We get a (*,G) assert with a better metric than ours. We move to "I am Assert Loser" and do Actions A2 (below) 🫠
When we're in "I am Assert Winner" state, these events also cause transitions 🌈
Assert Timer Expires The (*,G) Assert Timer expires. Since we're in the Winner state, we must still have (*,G) forwarding state that's actively being kept alive. To stop the forwarder from thrashing and to avoid periodic flooding of duplicate packets, we resend the (*,G) Assert and restart the Assert Timer (Actions A3 below) 🔁
CouldAssert(*,G,I) -> FALSE Our (*,G) forwarding state or RPF interface changed in a way that makes CouldAssert(*,G,I) false. We can't act as the assert winner anymore, so we move to NoInfo state and do Actions A4 (below) 😭
Transitions from "I am Assert Loser" State
When we're in "I am Assert Loser" state, these events cause transitions, but only if the (S,G) assert state machine is in NoInfo state both before and after the message gets considered 🎀
Receive Preferred Assert with RPTbit set We get a (*,G) assert that beats the current assert winner. We stay in Loser state and do Actions A2 below 📈
Receive Acceptable Assert from Current Winner with RPTbit set We get a (*,G) assert from the current assert winner that's better than our own metric for this group. (The winner's metric might be worse than it was before, though.) We stay in Loser state and do Actions A2 below 🙌
Receive Inferior Assert or Assert Cancel from Current Winner We get an assert from the current assert winner that's worse than our own metric for this group. This usually happens because the winner's metric got worse, or because it's now an assert cancel. We move to NoInfo state, delete this (*,G) assert state (Actions A5), and let the normal PIM Join/Prune mechanisms do their thing. Usually we'll eventually re-assert and win once data packets for G start flowing again 🌊
When we're in "I am Assert Loser" state, these events also cause transitions 🍓
Assert Timer Expires The (*,G) Assert Timer expires. We move to NoInfo state and delete this (*,G) assert info (Actions A5) 🧹
Current Winner's GenID Changes or NLT Expires The Neighbor Liveness Timer for the current winner expires, or we get a Hello message from the current winner reporting a different GenID than the one it reported before. This means the current winner's interface or router went down (and might have come back up), so we have to assume it no longer knows it was the winner. We move to NoInfo state and delete the (*,G) assert information (Actions A5) 🫣
AssertTrackingDesired(*,G,I)->FALSE AssertTrackingDesired(*,G,I) becomes FALSE. Our forwarding state changed so that (*,G) asserts on interface I no longer matter to us. We move to NoInfo state and delete this (*,G) assert info (Actions A5) 🙅♀️
My metric becomes better than the assert winner's metric Our routing metric, rpt_assert_metric(G,I), changed so that our assert metric for (*,G) is now better than the metric stored for the current assert winner. We move to NoInfo state, delete this (*,G) assert state (Actions A5), and let the normal PIM Join/Prune mechanisms operate. Usually we'll eventually re-assert and win once data packets for G start flowing again 🏅
RPF_interface(RP(G)) stops being interface I Interface I used to be the RPF interface for RP(G), and now it isn't. We move to NoInfo state and delete this (*,G) assert state (Actions A5) 🧭
Receive Join(,G) or Join(,*,RP(G)) on interface I We get a Join(*,G) or Join(*,*,RP(G)) whose Upstream Neighbor Address field is set to my primary IP address on interface I. We move to NoInfo state, delete this (*,G) assert state (Actions A5), and let the normal PIM Join/Prune mechanisms operate. If whoever sent the Join got it wrong, the normal assert mechanism will eventually reapply and we'll lose the assert again. But whoever sent the assert might know that the previous assert winner has died, so we may end up being the new forwarder 🧚♀️
(*,G) Assert State machine Actions
A1: Send Assert(*,G). Set the Assert Timer to (Assert_Time - Assert_Override_Interval). Store self as AssertWinner(*,G,I). Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I) 🏆
A2: Store the new assert winner as AssertWinner(*,G,I) and the assert winner's metric as AssertWinnerMetric(*,G,I). Set the Assert Timer to Assert_Time 📝
A3: Send Assert(*,G). Set the Assert Timer to (Assert_Time - Assert_Override_Interval) 🔁
A4: Send AssertCancel(*,G). Delete the assert info (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return their default values) 🛑
A5: Delete the assert info (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return their default values) 🗑️
Heads up: some of these actions can change the value ofJoinDesired(*,G)orRPF'(*,G)), and that can set off more transitions in other state machines 🚨
4.6.3. Assert Metrics ✨
Assert metrics are defined like this, and they're basically the vibe check for who wins 💅
struct assert_metric {
rpt_bit_flag;
metric_preference;
route_metric;
ip_address;
};When we compare assert_metrics, we check the rpt_bit_flag, metric_preference, and route_metric fields in order, and the first lower value wins 🥇. If every field is equal, the primary IP address of the router that sent the Assert message breaks the tie, and the highest IP address wins 🌸
An assert metric for (S,G) that goes into (or gets compared against) an Assert message sent on interface I should be worked out with this pseudocode 🧮
assert_metric
my_assert_metric(S,G,I) {
if( CouldAssert(S,G,I) == TRUE ) {
return spt_assert_metric(S,I)
} else if( CouldAssert(*,G,I) == TRUE ) {
return rpt_assert_metric(G,I)
} else {
return infinite_assert_metric()
}
}spt_assert_metric(S,I) gives the assert metric we use when we send an assert based on active (S,G) forwarding state 🦋
assert_metric
spt_assert_metric(S,I) {
return {0,MRIB.pref(S),MRIB.metric(S),my_ip_address(I)}
}rpt_assert_metric(G,I) gives the assert metric we use when we send an assert based only on (*,G) forwarding state 🌈
assert_metric
rpt_assert_metric(G,I) {
return {1,MRIB.pref(RP(G)),MRIB.metric(RP(G)),my_ip_address(I)}
}MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing metric for the route to a particular (unicast) destination X, as the MRIB determines them. my_ip_address(I) is just the router's primary IP address associated with the local interface I 🫶
infinite_assert_metric() gives the assert metric we need to send an assert when we don't match either (S,G) or (*,G) forwarding state 💀
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,0}
}4.6.4. AssertCancel Messages ✨
okay so an AssertCancel message is basically just an RPT Assert message but with an infinite metric 🔥 💅 The assert winner sends it when it deletes the forwarding state that caused the assert in the first place. Everyone else on the LAN sees that infinite metric and goes "oh, time to step up," so any router that has forwarding state sends its own assert and takes over forwarding. It's giving main character handoff 🦋
AssertCancel(S,G) is an infinite metric assert with the RPT bit set that names S as the source.
AssertCancel(*,G) is an infinite metric assert with the RPT bit set and the source set to zero.
AssertCancel messages are really just an optimization 🌸 The original Assert timeout mechanism will eventually get a subnet to become consistent, and the AssertCancel mechanism just makes that happen faster. No special processing is needed for an AssertCancel message, since it's literally just an Assert message from the current winner. Simple and iconic 👑
4.6.5. Assert State Macros ✨
okay the macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and lost_assert(*,G,I) are used in the olist computations of Section 4.1 💖 Here's how they're defined:
bool lost_assert(S,G,rpt,I) {
if ( RPF_interface(RP(G)) == I OR
( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) {
return FALSE
} else {
return ( AssertWinner(S,G,I) != NULL AND
AssertWinner(S,G,I) != me )
}
}
bool lost_assert(S,G,I) {
if ( RPF_interface(S) == I ) {
return FALSE
} else {
return ( AssertWinner(S,G,I) != NULL AND
AssertWinner(S,G,I) != me AND
(AssertWinnerMetric(S,G,I) is better
than spt_assert_metric(S,I) )
}
}Note: the term "AssertWinnerMetric(S,G,I) is better than spt_assert_metric(S,I)" is required to correctly handle the transition phase when a router has (S,G) join state, but has not yet set the SPT bit 🙈 In that case, it needs to ignore the assert state if it will win the assert once the SPTbit is set.
bool lost_assert(*,G,I) {
if ( RPF_interface(RP(G)) == I ) {
return FALSE
} else {
return ( AssertWinner(*,G,I) != NULL AND
AssertWinner(*,G,I) != me )
}
}AssertWinner(S,G,I) is the IP source address of the Assert(S,G) packet that won an Assert 🎀
AssertWinner(*,G,I) is the IP source address of the Assert(*,G) packet that won an Assert 🎀
AssertWinnerMetric(S,G,I) is the Assert metric of the Assert(S,G) packet that won an Assert ✨
AssertWinnerMetric(*,G,I) is the Assert metric of the Assert(*,G) packet that won an Assert ✨
AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I) defaults to Infinity when in the NoInfo state 🧚
Summary of Assert Rules and Rationale
okay so this part is a summary of the key rules for sending and reacting to asserts, plus the reasoning behind them 🫶 It is not meant to be a definitive spec, bestie. If you want the real behaviour, go to the state machines and pseudocode. This section is here to document the important vibes of the Assert protocol and help you understand and implement it 💅
- Behavior: Downstream neighbors send Join(*,G) and Join(S,G) periodic messages to the appropriate RPF' neighbor, i.e., the RPF neighbor as modified by the assert process. They are not always sent to the RPF neighbor as indicated by the MRIB. Normal suppression and override rules apply. Rationale: By sending the periodic and triggered Join messages to the RPF' neighbor instead of to the RPF neighbor, the downstream router avoids re-triggering the Assert process with every Join. A side effect of sending Joins to the Assert winner is that traffic will not switch back to the "normal" RPF neighbor until the Assert times out. This will not happen until data stops flowing, if item 8, below, is implemented. 🦋
- Behavior: The assert winner for (*,G) acts as the local DR for (*,G) on behalf of IGMP/MLD members. Rationale: This is required to allow a single router to merge PIM and IGMP/MLD joins and leaves. Without this, overrides don't work. 🔥
- Behavior: The assert winner for (S,G) acts as the local DR for (S,G) on behalf of IGMPv3 members. Rationale: Same rationale as for item 2. 💖
- Behavior: (S,G) and (*,G) prune overrides are sent to the RPF' neighbor and not to the regular RPF neighbor. Rationale: Same rationale as for item 1. 🌸
- Behavior: An (S,G,rpt) prune override is not sent (at all) if RPF'(S,G,rpt) != RPF'(*,G). Rationale: This avoids keeping state alive on the (S,G) tree when only (*,G) downstream members are left. Also, it avoids sending (S,G,rpt) joins to a router that is not on the (*,G) tree. This behavior might be confusing although this specification does indicate that such a join should be dropped. 🙈
- Behavior: An assert loser that receives a Join(S,G) with an Upstream Neighbor Address that is its primary IP address on that interface cancels the (S,G) Assert Timer. Rationale: This is necessary in order to have rapid convergence in the event that the downstream router that initially sent a join to the prior Assert winner has undergone a topology change. ⭐
- Behavior: An assert loser that receives a Join(*,G) or a Join(*,*,RP(G)) with an Upstream Neighbor Address that is its primary IP address on that interface cancels the (*,G) Assert Timer and all (S,G) assert timers that do not have corresponding Prune(S,G,rpt) messages in the compound Join/Prune message. Rationale: Same rationale as for item 6. 🧚
- Behavior: An assert winner for (*,G) or (S,G) sends a canceling assert when it is about to stop forwarding on a (*,G) or an (S,G) entry. This behavior does not apply to (S,G,rpt). Rationale: This allows switching back to the shared tree after the last SPT router on the LAN leaves. Doing this prevents downstream routers on the shared tree from keeping SPT state alive. 👑
- Behavior: Resend the assert messages before timing out an assert. (This behavior is optional.) Rationale: This prevents the periodic duplicates that would otherwise occur each time that an assert times out and is then re-established. 🌈
- Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) we need to trigger a Join(S,G,rpt) to RPF'(*,G). Rationale: This allows switching back to the RPT after the last SPT member leaves. 💜
4.7. PIM Bootstrap and RP Discovery ✨
okay bestie, for correct operation, every PIM router in a PIM domain must be able to map a particular multicast group address to the same RP 😭 If not, black holes can show up where some receivers in the domain can't get some groups. A domain here means a contiguous set of routers that all run PIM and are configured to operate within a common boundary 🌸
There's one notable exception: a PIM domain can be broken up into multiple administrative scope regions. These are regions where a border has been configured so that a range of multicast groups won't be forwarded across that border. For more on Administratively Scoped IP Multicast, see RFC 2365. The modified criteria for admin-scoped regions are that the region is convex with respect to forwarding based on the MRIB, and that all PIM routers within the scope region map scoped groups to the same RP within that region 🦋
This specification doesn't mandate a single mechanism for giving routers the info they need to do group-to-RP mapping. Currently there are four possible mechanisms, and all four have associated problems 🙈
- Static Configuration A PIM router MUST support the static configuration of group-to-RP mappings. Such a mechanism is not robust to failures, but does at least provide a basic interoperability mechanism. 🎀
- Embedded-RP Embedded-RP defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address [17]. 🧚
- Cisco's Auto-RP Auto-RP uses a PIM Dense-Mode multicast group to announce group-to-RP mappings from a central location. This mechanism is not useful if PIM Dense-Mode is not being run in parallel with PIM Sparse-Mode, and was only intended for use with PIM Sparse-Mode Version 1. No standard specification currently exists. 💀
- BootStrap Router (BSR) RFC 2362 specifies a bootstrap mechanism based on the automatic election of a bootstrap router (BSR). Any router in the domain that is configured to be a possible RP reports its candidacy to the BSR, and then a domain-wide flooding mechanism distributes the BSR's chosen set of RPs throughout the domain. As specified in RFC 2362, BSR is flawed in its handling of admin-scoped regions that are smaller than a PIM domain, but the mechanism does work for global-scoped groups. 👑
As far as PIM-SM is concerned, the only important requirement is that all routers in the domain (or admin scope zone for scoped regions) receive the same set of group-range-to-RP mappings. This may be achieved through any of these mechanisms, or through alternative mechanisms not currently specified 💜
It must be operationally ensured that any RP address configured, learned, or advertised is reachable from all routers in the PIM domain. 🚨
4.7.1. Group-to-RP Mapping ✨
okay so bestie, a PIM router can end up with one or more possible group-range-to-RP mappings 🗺️ 💅 Each mapping says which range of multicast groups (a group and a mask) goes to which RP. A mapping can also carry a priority. It's totally possible to get several mappings that all match the same group, and honestly that's the everyday situation with BSR 🫶 Here's how the router picks an RP:
- Perform longest match on group-range to obtain a list of RPs.
- From this list of matching RPs, find the one with highest priority. Eliminate any RPs from the list that have lower priorities.
- If only one RP remains in the list, use that RP.
- If multiple RPs are in the list, use the PIM hash function to choose one.
So, if two or more group-range-to-RP mappings cover the same group, the one with the longest mask wins 👑 If the mask lengths match, the highest priority wins. And if there's still a tie on both the longest mask and the priority, the hash function (see Section 4.7.2) picks the RP 💖
This algorithm gets run by a DR whenever it needs an RP for a group it doesn't know the RP for. Think a packet showing up, or an IGMP/MLD membership indication for a group 🧚 It also runs on any router that has (,,RP) state when a packet arrives with no matching (S,G) or (,G) entry. And every router runs the mapping function when it gets a (,G) or (,,RP) Join/Prune message 🌸
Also, if the set of possible group-range-to-RP mappings changes, every router has to check whether its existing groups are affected 👀 That could mean a DR or acting DR has to re-join a group, or restart register encapsulation to the new RP. Chaotic but manageable 💅
Implementation note: the bootstrap mechanism described in RFC 2362 omitted step 1 above. However, of the implementations we are aware of, approximately half performed step 1 anyway. Note that implementations of BSR that omit step 1 will not correctly interoperate with implementations of this specification when used with the BSR mechanism described in [11].
4.7.2. Hash Function ✨
The hash function is used by all routers within a domain to map a group to one of the RPs from the matching set of group-range-to-RP mappings. Everyone in that set has the same longest mask length and the same highest priority 🎀 The algorithm takes the group address plus the addresses of the candidate RPs from the mappings, and spits out one RP address to use.
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 matching group-range-to-RP mappings, compute a value:
Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31where C(i) is the RP address and M is a hash-mask. If BSR is being used, the hash-mask is given in the Bootstrap messages. If BSR is not being used, the alternative mechanism that supplies the group-range-to-RP mappings may supply the value, or else it defaults to a mask with the most significant 30 bits being one for IPv4 and the most significant 126 bits being one for IPv6. 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) and G must first be derived from the actual RP or group 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 exclusive-or of each 32-bit segment of the address for all other IPv6 addresses. For example, the digest of the IPv6 address 3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010, where ^ represents the exclusive-or operation 🦋
- The candidate RP with the highest resulting hash value is then the RP chosen by this Hash Function. If more than one RP has the same highest hash value, the RP with the highest IP address is chosen 👑
4.8. Source-Specific Multicast ✨
The Source-Specific Multicast (SSM) service model [6] can be implemented with a strict subset of the PIM-SM protocol mechanisms. Regular IP Multicast and SSM semantics can coexist on a single router, and both can be implemented using the PIM-SM protocol 🌈 A range of multicast addresses, currently 232.0.0.0/8 in IPv4 and FF3x::/32 for IPv6, is reserved for SSM. The choice of semantics is determined by the multicast group address in both data packets and PIM messages 💜
4.8.1. Protocol Modifications for SSM Destination Addresses ✨
The following rules override the normal PIM-SM behavior for a multicast address G in the SSM range:
- A router MUST NOT send a (*,G) Join/Prune message for any reason.
- A router MUST NOT send an (S,G,rpt) Join/Prune message for any reason.
- A router MUST NOT send a Register message for any packet that is destined to an SSM address.
- A router MUST NOT forward packets based on (,G) or (S,G,rpt) state. The (,G)- and (S,G,rpt)-related state summarization macros are NULL for any SSM address, for the purposes of packet forwarding.
- A router acting as an RP MUST NOT forward any Register-encapsulated packet that has an SSM destination address.
The last two rules are there to deal with "legacy" routers that don't know about SSM. Those routers might still be sending (*,G) and (S,G,rpt) Join/Prunes, or Register messages, for SSM destination addresses 🙈
Additionally:
- A router MAY be configured to advertise itself as a Candidate RP for an SSM address. If so, it SHOULD respond with a Register-Stop message to any Register message containing a packet destined for an SSM address.
- A router MAY optimize out the creation and maintenance of (S,G,rpt) and (*,G) state for SSM destination addresses -- this state is not needed for SSM packets 🧚
4.8.2. PIM-SSM-Only Routers ✨
An implementer may choose to implement only the subset of PIM Sparse-Mode that provides SSM forwarding semantics 💅
A PIM-SSM-only router MUST implement the following portions of this specification:
- Upstream (S,G) state machine (Section 4.5.7)
- Downstream (S,G) state machine (Section 4.5.3)
- (S,G) Assert state machine (Section 4.6.1)
- Hello messages, neighbor discovery, and DR election (Section 4.3)
- Packet forwarding rules (Section 4.2)
A PIM-SSM-only router does not need to implement the following protocol elements:
- Register state machine (Section 4.4)
- (,G), (S,G,rpt), and (,*,RP) Downstream state machines (Sections 4.5.2, 4.5.4, and 4.5.1)
- (,G), (S,G,rpt), and (,*,RP) Upstream state machines (Sections 4.5.6, 4.5.8, and 4.5.5)
- (*,G) Assert state machine (Section 4.6.2)
- Bootstrap RP Election (Section 4.7)
- Keepalive Timer
- SPTbit (Section 4.2.2)
The Keepalive Timer should be treated as always running, and SPTbit should be treated as always being set for an SSM address. Additionally, the Packet forwarding rules of Section 4.2 can be simplified in a PIM-SSM-only router:
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
oiflist = inherited_olist(S,G)
} else if( iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif
}
oiflist = oiflist (-) iif
forward packet on all interfaces in oiflistThis is nothing more than the reduction of the normal PIM-SM forwarding rule, with all (S,G,rpt) and (*,G) clauses replaced with NULL 🫶
4.9. PIM Packet Formats 🎀
This section describes the details of the packet formats for PIM control messages 📦
All PIM control messages have IP protocol number 103 ✨
PIM messages are either unicast (e.g., Registers and Register-Stop) or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g., Join/Prune, Asserts, etc.). The source address used for unicast messages is a domain-wide reachable address. The source address used for multicast messages is the link-local address of the interface on which the message is being sent 🌸
The IPv4 'ALL-PIM-ROUTERS' group is 224.0.0.13. The IPv6 'ALL-PIM-ROUTERS' group is ff02::d.
The PIM header common to all PIM messages is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Ver PIM Version number is 2.
Type Types for specific PIM messages. PIM Types are:
Message Type Destination
---------------------------------------------------------------------
0 = Hello Multicast to ALL-PIM-ROUTERS
1 = Register Unicast to RP
2 = Register-Stop Unicast to source of Register
packet
3 = Join/Prune Multicast to ALL-PIM-ROUTERS
4 = Bootstrap Multicast to ALL-PIM-ROUTERS
5 = Assert Multicast to ALL-PIM-ROUTERS
6 = Graft (used in PIM-DM only) Unicast to RPF'(S)
7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft
packet
8 = Candidate-RP-Advertisement Unicast to Domain's BSRReserved Set to zero on transmission. Ignored upon receipt.
Checksum The checksum is a standard IP checksum, i.e., the 16-bit one's complement of the one's complement sum of the entire PIM message, excluding the "Multicast data packet" section of the Register message. For computing the checksum, the checksum field is zeroed. If the packet's length is not an integral number of 16-bit words, the packet is padded with a trailing byte of zero before performing the checksum 🧮
For IPv6, the checksum also includes the IPv6 "pseudo-header", as specified in RFC 2460, Section 8.1 [5]. This "pseudo-header" is prepended to the PIM header for the purposes of calculating the checksum. The "Upper-Layer Packet Length" in the pseudo-header is set to the length of the PIM message, except in Register messages where it is set to the length of the PIM register header (8). The Next Header value used in the pseudo-header is 103 💖
If a message is received with an unrecognized PIM Ver or Type field, or if a message's destination does not correspond to the table above, the message MUST be discarded, and an error message SHOULD be logged to the administrator in a rate-limited manner 🚨 bestie, that's a must-do 😭
4.9.1. Encoded Source and Group Address Formats ✨
okay bestie, first up are the three encoded address formats, which are how PIM packs up a unicast address, a group, or a source so everyone knows who's talking 💅
Encoded-Unicast Address
Here's what an Encoded-Unicast address looks like 🦋
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: this is the PIM address family of the 'Unicast Address' field. Values 0-127 are assigned by the IANA for Internet Address Families in [7]. Values 128-250 are reserved so the IANA can assign them for PIM-specific Address Families. Values 251 through 255 are for private use, and since nobody's in charge of that space, collisions are something to expect 🙈
- Encoding Type: the type of encoding used within a specific Address Family. The value '0' is reserved for this field and stands for the native encoding of the Address Family.
- Unicast Address: the unicast address, as represented by the given Address Family and Encoding Type.
Encoded-Group Address
Encoded-Group addresses come in this shape 🌸
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 |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...- Addr Family: described above.
- Encoding Type: described above.
- [B]idirectional PIM: this indicates the group range should use Bidirectional PIM [13]. For PIM-SM defined in this specification, this bit MUST be zero. 🔥
- Reserved: transmitted as zero, and ignored upon receipt.
- Admin Scope [Z]one: this indicates the group range is an admin scope zone. It's only used in the Bootstrap Router Mechanism [11]. For all other purposes, this bit is set to zero and ignored on receipt.
- Mask Len: this field is 8 bits. The value is the number of contiguous one bits that are left justified and used as a mask. Combined with the group address, it describes a range of groups. 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, the Mask length has to equal the address length in bits for the given Address Family and Encoding Type (for example, 32 for IPv4 native encoding, 128 for IPv6 native encoding) ✨
- Group multicast Address: contains the group address.
Encoded-Source Address
And last but not least, the Encoded-Source address 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Wait, the diagram above got a tiny glitch in the original, so here's the exact version, bestie 🫶
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, and ignored on receipt.
- S: the Sparse bit is a 1-bit value, set to 1 for PIM-SM. It's used for PIM version 1 compatibility 🌈
- W: the WC (or WildCard) bit is a 1-bit value for use with PIM Join/Prune messages (see Section 4.9.5.1).
- R: the RPT (or Rendezvous Point Tree) bit is a 1-bit value for use with PIM Join/Prune messages (see Section 4.9.5.1). If the WC bit is 1, the RPT bit MUST be 1. 💜
- Mask Len: this field is 8 bits. The value is the number of contiguous one bits left justified and used as a mask which, combined with the Source Address, describes a source subnet. The mask length MUST be equal to the mask length in bits for the given Address Family and Encoding Type (32 for IPv4 native and 128 for IPv6 native). A router SHOULD ignore any messages received with any other mask length. 💀
- Source Address: the source address.
4.9.2. Hello Message Format 🎀
Hello messages get sent out regularly by routers on all interfaces, so they're basically the group chat check-ins of PIM 🦋
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 in Section 4.9.
- 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 that carries the value of the option.
The Option fields may hold the following values, so let's look at each one ✨
OptionType 1: Holdtime
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Holdtime is the amount of time a receiver has to keep the neighbor reachable, in seconds. If the Holdtime is set to 0xffff, the receiver of this message never times out the neighbor. This can be used with dial-on-demand links, to avoid keeping the link up with periodic Hello messages 🍓
Hello messages with a Holdtime value set to 0 are also sent by a router on an interface that's about to go down or changing IP address (see Section 4.3.1). These are effectively goodbye messages, and the receiving routers should immediately time out the neighbor information for the sender 👋
OptionType 2: LAN Prune Delay
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Propagation_Delay | Override_Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The LAN Prune Delay option is used to tune the prune propagation delay on multi-access LANs. The T bit specifies the ability of the sending router to disable joins suppression. Propagation_Delay and Override_Interval are time intervals in units of milliseconds. A router originating a LAN Prune Delay option on interface I sets the Propagation_Delay field to the configured value of Propagation_Delay(I), and the Override_Interval field to the value of Override_Interval(I). On a receiving router, the values of the fields are used to tune the value of the Effective_Override_Interval(I) and its derived timer values. Section 4.3.3 describes how these values affect the behavior of a router 🧚
- OptionType 3 to 16: reserved to be defined in future versions of this document.
- OptionType 18: deprecated, and it's a big no-no to use it 🙅♀️
OptionType 19: DR Priority
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 19 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+DR Priority is a 32-bit unsigned number, and it's meant to be considered in the DR election, as described in Section 4.3.2 👑
OptionType 20: Generation ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 20 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Generation ID is a random 32-bit value for the interface on which the Hello message is sent. The Generation ID is regenerated whenever PIM forwarding is started or restarted on the interface 🎲
OptionType 24: Address List
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 24 | Length = <Variable> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address N (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The contents of the Address List Hello option are described in Section 4.3.4. All addresses within a single Address List must belong to the same address family 🌸
OptionTypes 17 through 65000 are assigned by the IANA. OptionTypes 65001 through 65535 are reserved for Private Use, as defined in [9] 🌈
Unknown options MUST be ignored and MUST NOT prevent a neighbor relationship from being formed. The "Holdtime" option MUST be implemented, and the "DR Priority" and "Generation ID" options SHOULD be implemented. The "Address List" option MUST be implemented for IPv6. And that's the whole Hello message, bestie 💖
4.9.3. Register Message Format ✨
okay so a Register message is what the DR (or a PMBR) sends to the RP when a multicast packet needs to go out on the RP-tree 🌸 the IP source address is the DR's address and the destination is the RP's address 💅 and the IP TTL of the PIM packet is just the system's normal unicast TTL 🫶
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| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast data packet .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Version, Type, Reserved, Checksum🧚 described in Section 4.9. ngl the checksum for Registers is only done on the first 8 bytes of the packet (the PIM header plus the next 4 bytes), NOT the data packet part, so the encapsulation overhead stays low 💖 for interop reasons, a message carrying a checksum calculated over the entire PIM Register message should also be accepted 🦋 and when you calculate it, the IPv6 pseudoheader"Upper-Layer Packet Length"gets set to 8 🎀BThe Border bit 🍓 if the router is a DR for a source it's directly connected to, it sets B to 0. if the router is a PMBR for a source in a directly connected cloud, it sets B to 1 ✨NThe Null-Register bit 🌈 set to 1 by a DR that's probing the RP before it expires its local Register-Suppression Timer. set to 0 otherwise 💜Reserved2transmitted as zero, ignored on receipt 🌸Multicast data packetthe original packet the source sent 🦋 this packet must be of the same address family as the encapsulating PIM packet, e.g., an IPv6 data packet must be encapsulated in an IPv6 PIM packet 👑 the TTL of the original packet gets decremented before encapsulation, just like any other packet being forwarded 🔥 and then the RP decrements the TTL after decapsulating, before it forwards the packet down the shared tree 💅
For (S,G) Null-Registers, the Multicast data packet portion has a dummy IP header with S as the source address and G as the destination address 🙈 when you generate an IPv4 Null-Register message, the fields in the dummy IPv4 header SHOULD be filled in according to this table. Other IPv4 header fields can be any value that's valid for that field 🧚
Field Value
---------------------------------------
IP Version 4
Header Length 5
Checksum Header checksum
Fragmentation offset 0
More Fragments 0
Total Length 20
IP Protocol 103 (PIM)On receipt of an (S,G) Null-Register, if the Header Checksum field is non-zero, the recipient SHOULD check the checksum and discard null registers that have a bad checksum 💀 the recipient SHOULD NOT check the value of any individual fields, because a correct IP header checksum is sufficient ✨ and if the Header Checksum field is zero, the recipient MUST NOT check the checksum 🫶
With IPv6, an implementation generates a dummy IP header followed by a dummy PIM header, using the values in this table, plus the source and group. Other IPv6 header fields can be any value that's valid for that field 💖
Header Field Value
--------------------------------------
IP Version 6
Next Header 103 (PIM)
Length 4
PIM Version 0
PIM Type 0
PIM Reserved 0
PIM Checksum PIM checksum including
IPv6 "pseudo-header";
see Section 4.9On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM header is present, the recipient SHOULD check the checksum and discard Null-Registers that have a bad checksum 🌈
4.9.4. Register-Stop Message Format ⭐
okay this one's a unicast from the RP back to whoever sent the Register 🦋 the IP source address is the address the register was originally addressed to, and the IP destination address is the source address of the register message 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Version, Type, Reserved, Checksum🌸 described in Section 4.9.Group Addressthe group address from the multicast data packet in the Register 🍓 format described in Section 4.9.1. heads up: for Register-Stops, the Mask Len field holds the full address length* 8(e.g., 32 for IPv4 native encoding) if the message is sent for a single group ⚠️Source Addressthe host address of the source from the multicast data packet in the register 🧚 the format is the Encoded-Unicast address in Section 4.9.1. and a special wildcard value, an address field of all zeros, can be used to mean any source 🌈
that's the whole Register and Register-Stop dance, bestie 💖
4.9.5. Join/Prune Message Format 🦋
okay bestie, so the Join/Prune message is what routers send upstream toward sources and RPs 💅. Joins build the shared trees (RP trees) or source trees (SPT) ✨. Prunes tear down source trees when members leave groups 🍓, and they also handle sources that aren't using the shared tree 🙈. It's giving main character energy 👑.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Neighbor Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Version, Type, Reserved, Checksum 🌸 Same deal as before, so check out Section 4.9 for these.
Unicast Upstream Neighbor Address 💖 This is the address of the upstream neighbor that the message is aimed at. The format is the Encoded-Unicast address from Section 4.9.1. For IPv6, the source address used for multicast messages is the link-local address of the interface the message goes out on. For IPv4, it's the primary address on that interface.
Reserved 🫶 Transmitted as zero, ignored on receipt.
Holdtime ⏰ This is how long a receiver has to keep the Join/Prune state alive, measured in seconds. If the Holdtime is set to '0xffff', the receiver should hold the state until the matching canceling Join/Prune message shows up, or until local policy times it out. This can be handy on dial-on-demand links, since it avoids keeping the link up just for periodic Join/Prune messages 🧚.
Note that the HoldTime must be larger than the J/P_Override_Interval(I). Don't skip this one, bestie 🙈
Number of Groups 🍓 The number of multicast group sets in the message.
Multicast Group Address 🎀 For the format, see Section 4.9.1.
Number of Joined Sources ✨ The number of joined source addresses listed for a given group.
Joined Source Address 1 .. n 🦋 This is the list of sources for a given group that the sending router will forward multicast datagrams from, as long as they arrive on the interface the Join/Prune message goes out on. For the Encoded-Source-Address format, see Section 4.9.1.
Number of Pruned Sources 💜 The number of pruned source addresses listed for a group.
Pruned Source Address 1 .. n 🌈 This is the list of sources for a given group that the sending router does NOT want to forward multicast datagrams from when they arrive on the interface the Join/Prune message goes out on.
Okay now the rules, and these are serious 👑 Within one PIM Join/Prune message, all the Multicast Group Addresses, Joined Source addresses, and Pruned Source addresses MUST be of the same address family. Mixing IPv4 and IPv6 addresses in the same message is not permitted at all 💀. On top of that, the address family of the fields in the message SHOULD match the IP source and destination addresses of the packet. This gives dual-stack IPv4/IPv6 routers the most implementation flexibility 🫶. And if a router gets a message with mixed address families, it SHOULD only process the addresses that match the family of the unicast upstream neighbor address 🔥.
4.9.5.1. Group Set Source List Rules ✨
Okay so, bestie, like we said above, Join/Prune messages are built from one or more group sets 🎀. Each set has two source lists, the Joined Sources and the Pruned Sources 💜. This section breaks down the different group set types and source list entries that can show up in a Join/Prune message 🧚.
There are two valid group set types:
Wildcard Group Set 🌈 This one is the whole multicast range, so it's giving "everything at once" 💅. The group address field holds the start of the multicast address range, and the mask length field holds the prefix length of that range. So you get 224.0.0.0/4 for IPv4 or ff00::/8 for IPv6. Each Join/Prune message SHOULD contain at most one wildcard group set. A wildcard group set can hold one or more (,,RP) source list entries, in either the Joined or the Pruned list.
A (,,RP) source list entry can ONLY live in a wildcard group set, no exceptions 🙅♀️. When it's in a Joined source list, it says the router wants traffic for every group that maps to that RP. When it's in a Pruned source list, it says the router wants to stop getting that traffic. Heads up though: as the Join/Prune state machines show, a Join or Prune like this will not override Join/Prune state that was created with a Group-Specific Set (more on that below) 🙈.
For (,,RP) entries, the Source-Address is the RP's address, the Source-Address Mask-Len is the full length of the IP address, and both the WC and RPT bits of the Source-Address are set to 1 🔥.
Group-Specific Set 🍓 A Group-Specific Set is a valid IP multicast address in the group address field, with the full IP address length in the mask length field. Each Join/Prune message SHOULD NOT contain more than one group-specific set for the same IP multicast address. A group-specific set can hold (*,G), (S,G,rpt), and (S,G) source list entries, in the Joined or Pruned lists.
(,G) 💜 The (,G) source list entry gets sent in Join/Prune messages toward the RP for the specified group. It says whether the router is interested (or not) in traffic sent to the group through the Rendezvous-Point shared tree. There can only be one of these in each of the Joined and Pruned lists of a group-specific set.
For (*,G) entries, the Source-Address is the address of the RP for group G, the Source-Address Mask-Len is the full IP address length, and both the WC and RPT bits of the Encoded-Source-Address are set ✨.
(S,G,rpt) 🦋 The (S,G,rpt) source list entry also gets sent toward the RP for the specified group. It says whether the router wants (or doesn't want) traffic that the specified source sends to this group through the shared tree. For each source address, the entry can live in only one of the Joined and Pruned source lists of a group-specific set, never both 🙅♀️.
For (S,G,rpt) entries, the Source-Address is the address of source S, the Source-Address Mask-Len is the full IP address length, the WC bit is cleared, and the RPT bit is set in the Encoded-Source-Address 🧚.
(S,G) 🌸 The (S,G) source list entry gets sent toward the specified source. It says whether the router is interested (or not) in traffic that the source sends to the specified group through the shortest path tree. Same deal as before: for each source address, the entry can exist in only one of the Joined and Pruned source lists of a group-specific set, not both 💅.
For (S,G) entries, the Source-Address is the address of source S, the Source-Address Mask-Len is the full IP address length, and both the WC and RPT bits of the Encoded-Source-Address are cleared 🫶.
The rules above are enough to stop invalid combinations of source list entries in group-specific sets. BUT there are a bunch of combinations that do have a valid meaning and just aren't generated by the protocol as described in this spec 👀:
- Putting a (,G) Join and a (S,G,rpt) Join in the same message is redundant, because the (,G) entry already covers what the (S,G,rpt) entry says 🙄.
- The same goes for (*,G) Prunes and (S,G,rpt) Prunes.
- The combo of a (,G) Prune and a (S,G,rpt) Join isn't generated either. (S,G,rpt) Joins only get sent when the router is getting all the traffic for a group on the shared tree and wants to flag a change for one particular source. A (,G) Prune means the router doesn't want shared tree traffic anymore, so the (S,G,rpt) Join would be meaningless 💀.
- Join/Prune messages are aimed at one PIM neighbor, so including both a (S,G) Join and a (S,G,rpt) Prune in the same message is usually redundant. The (S,G) Join already tells the neighbor the sender wants that source on the shortest path tree, so there's no need to also say it doesn't want it on the shared tree. There IS a valid reading of this combo, though: a downstream router might need to tell its upstream to only start forwarding a specific source once it's already getting that source on the shortest-path tree 🧚.
- The combo of a (S,G) Prune and a (S,G,rpt) Join could possibly be used by a router to switch from getting a source on the shortest-path tree back to getting it on the shared tree. This only works if the RPF neighbor is the same for both the shortest-path and shared trees. But Sparse-Mode PIM doesn't have a mechanism for explicitly switching back to the shared tree, so that's a no-go 🙃.
Here are the rules summed up in tables 📋:
+----------++------+-------+-----------+-----------+-------+-------+
| ||Join | Prune | Join | Prune | Join | Prune |
| ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
+----------++------+-------+-----------+-----------+-------+-------+
|Join ||- | no | ? | yes | yes | yes |
|(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Prune ||no | - | ? | ? | yes | yes |
|(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Join ||? | ? | - | no | yes | ? |
|(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | ? | no | - | yes | ? |
|(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Join ||yes | yes | yes | yes | - | no |
|(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | yes | ? | ? | no | - |
|(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------++---------------++--------------+----------------+------------+
| ||Join (*,*,RP) | Prune (*,*,RP) | all others |
+---------------++--------------+----------------+------------+
|Join (*,*,RP) ||- | no | yes |
+---------------++--------------+----------------+------------+
|Prune (*,*,RP) ||no | - | yes |
+---------------++--------------+----------------+------------+
|all others ||yes | yes | see above |
+---------------++--------------+----------------+------------+How to read the codes 🔑:
- yes: Allowed and expected 💖.
- no: The protocol doesn't allow this combo, so a router MUST NOT generate it 🚫. A router MAY still accept these messages, but what happens is undefined 🤷♀️. It MAY also log an error message for the administrator, but only in a rate-limited way 📝.
- ?: The protocol doesn't expect this combo, but it's well-defined ✨. A router MAY accept it, but it SHOULD NOT generate it 🙅♀️.
The order of source list entries in a group set's source list doesn't matter, except where the packet format itself puts a limit on it 🎀.
4.9.5.2. Group Set Fragmentation 🧩
Okay, when a router is building a Join/Prune for a particular neighbor, it should try to pack in as much of the info it needs to send as possible 💪. That means one group set for each multicast group that has info waiting to go out, and each set includes all the relevant source list entries 🫶.
On a router with a LOT of multicast state, all those entries might make packets bigger than the maximum IP packet size 😭. In most of those cases, the info can be split across multiple messages 🦋.
There's one exception, and it's a big one 👑: group sets that contain a (*,G) Joined source list entry. That group set says the router wants all traffic for the group on the shared tree, so it MUST include an (S,G,rpt) Pruned source list entry for every source the router does NOT want. That list of (S,G,rpt) Pruned entries MUST not be split across multiple messages 🚫.
If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune message, but the router has more than N (S,G,rpt) Prunes to add, then the router MUST choose to include the first N (numerically smallest in network byte order) IP addresses 🔢💜.
4.9.6. Assert Message Format ✨
okay bestie, so the Assert message is how routers settle forwarder drama on a link 💅 A router sends one when it gets a multicast data packet on an interface where it would normally have forwarded that packet 👀 Assert messages can also be sent back in response to an Assert from another router, so it's a whole back-and-forth 🔥
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown, bestie 🎀
- PIM Version, Type, Reserved, Checksum: described in Section 4.9.
- Group Address: the group address the router wants to sort the forwarding conflict out for. It's an Encoded-Group address, as specified in Section 4.9.1.
- Source Address: the source address the router wants to sort the conflict out for. The source address MAY be set to zero for (*,G) asserts (see below). The format is given in Encoded-Unicast-Address in Section 4.9.1.
- R: the RPT-bit, a 1-bit value. It's set to 1 for Assert(*,G) messages and 0 for Assert(S,G) messages.
- Metric Preference: the preference value assigned to the unicast routing protocol that provided the route to the multicast source or Rendezvous-Point.
- Metric: the unicast routing table metric for the route used to reach the multicast source or Rendezvous-Point. It's in units that match the unicast routing protocol being used.
Assert messages can be sent to sort out a forwarding conflict for all traffic to a given group, or for one specific source and group 💖
- Assert(S,G): source-specific asserts are sent by routers forwarding a specific source on the shortest-path tree (SPTbit is TRUE) 🌸 These have the Group-Address field set to the group G and the Source-Address field set to the source S. The RPT-bit is set to 0, the Metric-Preference is set to MRIB.pref(S), and the Metric is set to MRIB.metric(S).
- Assert(*,G): group-specific asserts are sent by routers forwarding data for the group and source(s) that are in contention on the shared tree 🦋 These have the Group-Address field set to the group G. For data-triggered Asserts, the Source-Address field MAY be set to the IP source address of the data packet that triggered the Assert, and it's set to zero otherwise. The RPT-bit is set to 1, the Metric-Preference is set to MRIB.pref(RP(G)), and the Metric is set to MRIB.metric(RP(G)).
4.10. PIM Timers ⏰
bestie, PIM-SM keeps track of these timers, as discussed in Section 4.1 🧚 Every single one is a countdown timer: you set it to a value, it counts down to zero, and when it hits zero it usually triggers some action 💀 Totally valid to build them as count-up timers too, where you store the absolute expiry time and compare it to a real-time clock. This spec just assumes they count down to zero, so that's the vibe we're going with 💜
Global Timers
Per interface (I):
Hello Timer: HT(I)
Per neighbor (N):
Neighbor Liveness Timer: NLT(N,I)
Per active RP (RP):
(*,*,RP) Join Expiry Timer: ET(*,*,RP,I)
(*,*,RP) Prune-Pending Timer: PPT(*,*,RP,I)
Per Group (G):
(*,G) Join Expiry Timer: ET(*,G,I)
(*,G) Prune-Pending Timer: PPT(*,G,I)
(*,G) Assert Timer: AT(*,G,I)
Per Source (S):
(S,G) Join Expiry Timer: ET(S,G,I)
(S,G) Prune-Pending Timer: PPT(S,G,I)
(S,G) Assert Timer: AT(S,G,I)
(S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)
(S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)
Per active RP (RP):
(*,*,RP) Upstream Join Timer: JT(*,*,RP)
Per Group (G):
(*,G) Upstream Join Timer: JT(*,G)
Per Source (S):
(S,G) Upstream Join Timer: JT(S,G)
(S,G) Keepalive Timer: KAT(S,G)
(S,G,rpt) Upstream Override Timer: OT(S,G,rpt)
At the DRs or relevant Assert Winners only:
Per Source,Group pair (S,G):
Register-Stop Timer: RST(S,G)4.11. Timer Values 💅
okay so when timers get started or restarted, they get set to default values 🍓 This section sums those defaults up for you 🫶
Heads up, protocol events or configuration can change a timer's default value on a specific interface 👑 When timers are initialized in this document, the value specific to the interface in context must be used.
Some of the timers below (Prune-Pending, Upstream Join, Upstream Override) can be set to values that depend on the settings of Propagation_Delay and Override_Interval for the matching interface 🌈 The default values for those are given below.
Variable Name: Propagation_Delay(I)
+-------------------------------+--------------+----------------------+
| Value Name | Value | Explanation |
+-------------------------------+--------------+----------------------+
| Propagation_delay_default | 0.5 secs | Expected |
| | | propagation delay |
| | | over the local |
| | | link. |
+-------------------------------+--------------+----------------------+The Propagation_delay_default is chosen to be relatively large on purpose, so it stays compatible with older PIM implementations 🦋
Variable Name: Override_Interval(I)
+--------------------------+-----------------+-------------------------+
| Value Name | Value | Explanation |
+--------------------------+-----------------+-------------------------+
| t_override_default | 2.5 secs | Default delay |
| | | interval over |
| | | which to randomize |
| | | when scheduling a |
| | | delayed Join |
| | | message. |
+--------------------------+-----------------+-------------------------+Timer Name: Hello Timer (HT(I))
+---------------------+--------+---------------------------------------+
|Value Name | Value | Explanation |
+---------------------+--------+---------------------------------------+
|Hello_Period | 30 secs| Periodic interval for Hello messages. |
+---------------------+--------+---------------------------------------+
|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
| | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor. |
+---------------------+--------+---------------------------------------+At system power-up, the timer is initialized to rand(0, Triggered_Hello_Delay) to prevent synchronization ✨ When a new or rebooting neighbor is detected, a responding Hello is sent within rand(0, Triggered_Hello_Delay) 💖
Timer Name: Neighbor Liveness Timer (NLT(N,I))
+--------------------------+----------------------+--------------------+
| Value Name | Value | Explanation |
+--------------------------+----------------------+--------------------+
| Default_Hello_Holdtime | 3.5 * Hello_Period | Default holdtime |
| | | to keep neighbor |
| | | state alive |
+--------------------------+----------------------+--------------------+
| Hello_Holdtime | from message | Holdtime from |
| | | Hello Message |
| | | Holdtime option. |
+--------------------------+----------------------+--------------------+The Holdtime in a Hello Message should be set to (3.5 * Hello_Period), giving a default value of 105 seconds 🙈
Timer Names: Expiry Timer (ET(,,RP,I), ET(*,G,I), ET(S,G,I), ET(S,G,rpt,I))
+----------------+----------------+------------------------------------+
| Value Name | Value | Explanation |
+----------------+----------------+------------------------------------+
| J/P_HoldTime | from message | Holdtime from Join/Prune Message |
+----------------+----------------+------------------------------------+See details of JT(*,G) for the Holdtime that is included in Join/Prune Messages 🌸
Timer Names: Prune-Pending Timer (PPT(,,RP,I), PPT(*,G,I), PPT(S,G,I), PPT(S,G,rpt,I))
+--------------------------+---------------------+---------------------+
|Value Name | Value | Explanation |
+--------------------------+---------------------+---------------------+
|J/P_Override_Interval(I) | Default: | Short period after |
| | Effective_ | a join or prune to |
| | Propagation_ | allow other |
| | Delay(I) + | routers on the LAN |
| | EffectiveOverride_ | to override the |
| | Interval(I) | join or prune |
+--------------------------+---------------------+---------------------+Note that both the Effective_Propagation_Delay(I) and the Effective_Override_Interval(I) are interface-specific values that may change when Hello messages are received (see Section 4.3.3) 🧁
Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))
+---------------------------+---------------------+--------------------+
| Value Name | Value | Explanation |
+---------------------------+---------------------+--------------------+
| Assert_Override_Interval | Default: 3 secs | Short interval |
| | | before an assert |
| | | times out where |
| | | the assert winner |
| | | resends an Assert |
| | | message |
+---------------------------+---------------------+--------------------+
| Assert_Time | Default: 180 secs | Period after last |
| | | assert before |
| | | assert state is |
| | | timed out |+---------------------------+---------------------+--------------------+Okay so the Assert message is missing a Holdtime field 🙈 for historical reasons, which means changing the Assert Time from the default value is not recommended. Don't go messing with it, bestie 💅
Timer Names: Upstream Join Timer (JT(,,RP), JT(*,G), JT(S,G))
+-------------+--------------------+-----------------------------------+
|Value Name | Value | Explanation |
+-------------+--------------------+-----------------------------------+
|t_periodic | Default: 60 secs | Period between Join/Prune Messages|
+-------------+--------------------+-----------------------------------+
|t_suppressed | rand(1.1 * | Suppression period when someone |
| | t_periodic, 1.4 * | else sends a J/P message so we |
| | t_periodic) when | don't need to do so. |
| | Suppression_ | |
| | Enabled(I) is | |
| | true, 0 otherwise | |
+-------------+--------------------+-----------------------------------+
|t_override | rand(0, Effective_ | Randomized delay to prevent |
| | Override_ | response implosion when sending a |
| | Interval(I)) | join message to override someone |
| | | else's Prune message. |
+-------------+--------------------+-----------------------------------+t_periodic can be tuned to match things like the configured bandwidth and the expected average number of multicast route entries for the attached network or link 🍓 So the period would be longer for lower-speed links, or for routers in the center of the network that expect a bigger pile of entries. If the Join/Prune-Period gets modified during operation, those changes should be made relatively infrequently 🫶 Also, 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. That's the glow-up courtesy we all need ✨
The holdtime in a Join/Prune message should be set to (3.5 * t_periodic) ⏱️
t_override depends on the Effective_Override_Interval of the upstream interface, which can change when Hello messages are received. And t_suppressed depends on the Suppression State of the upstream interface (Section 4.3.3), and it drops to zero when suppression is disabled 🌸
Timer Name: Upstream Override Timer (OT(S,G,rpt))
+---------------+--------------------------+---------------------------+
| Value Name | Value | Explanation |
+---------------+--------------------------+---------------------------+
| t_override | see Upstream Join Timer | see Upstream Join Timer |
+---------------+--------------------------+---------------------------+The upstream Override Timer only ever gets set to t_override 🦋 That value is defined in the section on Upstream Join Timers, so go check there if you need the details.
Timer Name: Keepalive Timer (KAT(S,G))
+-----------------------+-----------------------+----------------------+
| Value Name | Value | Explanation |
+-----------------------+-----------------------+----------------------+
| Keepalive_Period | Default: 210 secs | Period after last |
| | | (S,G) data packet |
| | | during which (S,G) |
| | | Join state will be |
| | | maintained even in |
| | | the absence of |
| | | (S,G) Join |
| | | messages. |
+-----------------------+-----------------------+----------------------+
| RP_Keepalive_Period | ( 3 * Register_ | As |
| | Suppression_Time ) | Keepalive_Period, |
| | + Register_ | but at the RP when |
| | Probe_Time | a Register-Stop is |
| | | sent. |
+-----------------------+-----------------------+----------------------+The normal keepalive period for KAT(S,G) defaults to 210 seconds 💜 At the RP, though, the keepalive period must be at least the Register_Suppression_Time. If it isn't, the RP could time out the (S,G) state before the next Null-Register shows up, and that's a whole plot twist nobody wants 😭 So KAT(S,G) gets set to max(Keepalive_Period, RP_Keepalive_Period) whenever a Register-Stop is sent.
Timer Name: Register-Stop Timer (RST(S,G))
+---------------------------+--------------------+---------------------+
|Value Name | Value | Explanation |
+---------------------------+--------------------+---------------------+
|Register_Suppression_Time | Default: 60 secs | Period during |
| | | which a DR stops |
| | | sending Register- |
| | | encapsulated data |
| | | to the RP after |
| | | receiving a |
| | | Register-Stop |
| | | message. |
+---------------------------+--------------------+---------------------+
|Register_Probe_Time | Default: 5 secs | Time before RST |
| | | expires when a DR |
| | | may send a Null- |
| | | Register to the RP |
| | | to cause it to |
| | | resend a Register- |
| | | Stop message. |
+---------------------------+--------------------+---------------------+If Register_Suppression_Time or Register_Probe_Time get configured to anything other than the defaults, it MUST be ensured that Register_Probe_Time is less than half of Register_Suppression_Time 🚨 That stops a possible negative value from showing up in the setting of the Register-Stop Timer. Non-negotiable, periodt 💅
5. IANA Considerations ✨
5.1. PIM Address Family 🎀
Okay so the PIM Address Family field is 8 bits, and that was a tradeoff between packet format and using the IANA assigned numbers 🧚 When the PIM packet format was designed, only 15 Address Family values were assigned, and nobody was really picturing huge numbers of new ones, so 8 bits seemed like plenty. Plot twist, though: IANA assigns Address Families in a 16-bit field 😳 So the PIM Address Family is allocated like this:
Values 0 through 127 are designated to have the same meaning as
IANA-assigned Address Family Numbers [7].
Values 128 through 250 are designated to be assigned for PIM by the
IANA based upon IESG Approval, as defined in [9].
Values 251 through 255 are designated for Private Use, as defined
in [9].5.2. PIM Hello Options 🌈
Values 17 through 65000 are to be assigned by the IANA 🦋 The space is huge, so they may be assigned as First Come First Served, as defined in [9]. Those assignments are valid for one year and can be renewed. Permanent assignments require a specification (see "Specification Required" in [9].) 📝
6. Security Considerations 💀
This section covers various possible security concerns for the PIM-SM protocol, including how to use IPsec to secure the protocol 🔐 If you want more on PIM-SM and multicast security, check out [15] and [16]. The IPsec authentication header [8] MAY be used to provide data integrity protection and groupwise data origin authentication of PIM protocol messages. Authentication of PIM messages can protect against unwanted behaviors caused by unauthorized or altered PIM messages. This is serious stuff, bestie, so please take it seriously 😤
6.1. Attacks Based on Forged Messages 🙈
The damage a forger can do depends on what kind of counterfeit messages get accepted. Next we look at the impact of possible forgeries, including forged link-local (Join/Prune, Hello, and Assert) messages and forged unicast (Register and Register-Stop) messages 🕵️
6.1.1. Forged Link-Local Messages
Join/Prune, Hello, and Assert messages are all sent to the link-local ALL_PIM_ROUTERS multicast addresses, so a compliant router doesn't forward them 🛑 A forged message of this type can only reach a LAN if a local host sent it, or if a compromised or non-compliant router let it onto the LAN. Okay so here's the damage:
- A forged Join/Prune message can cause multicast traffic to be delivered to links where there are no legitimate requesters, which can waste bandwidth on that link 📉 A forged leave message on a multi-access LAN usually isn't a big deal in PIM, though. Any legitimately joined router on the LAN would override the leave with a join before the upstream router stops forwarding data to the LAN, so it's kind of self-healing 🩹
- By forging a Hello message, an unauthorized router can make itself the designated router on a LAN 👑 The designated router on a LAN is (when there are no asserts) responsible for forwarding traffic to that LAN on behalf of any local members. It's also responsible for register-encapsulating to the RP any packets that hosts on the LAN originate. So a forged Hello can compromise the ability of local hosts to send and receive multicast traffic 😱
- By forging an Assert message on a multi-access LAN, an attacker could make the legitimate designated forwarder stop forwarding traffic to the LAN 🥀 A forgery like that would stop any hosts downstream of that LAN from receiving traffic at all.
6.1.2. Forged Unicast Messages
Register and Register-Stop messages get forwarded by intermediate routers to their destination using normal IP forwarding 🌍 Without data origin authentication, an attacker located anywhere in the network may be able to forge a Register or Register-Stop message. Yikes. Here's what a forgery of each one would do:
- By forging a Register message, an attacker can cause the RP to inject forged traffic onto the shared multicast tree 🌳
- By forging a Register-stop message, an attacker can stop a legitimate DR from Registering packets to the RP 🚫 That can keep local hosts on that LAN from sending multicast packets at all.
Intermediate routers don't change the two PIM messages above, so only the intended receiver needs to examine them 🎯 That means these messages can be authenticated end-to-end, using AH. And attacks on Register and Register-Stop messages don't apply to a PIM-SSM-only implementation, since those messages aren't required for PIM-SSM 💖
6.2. Non-Cryptographic Authentication Mechanisms 🔐
okay so bestie, a PIM router SHOULD provide an option to limit which neighbors it'll listen to for Join/Prune, Assert, and Hello messages 🫶 You can do that with static configuration of IP addresses, or with an IPsec security association. And a PIM router SHOULD NOT accept protocol messages from a router it hasn't gotten a valid Hello message from yet 🙅♀️ no skipping the intro!!
A Designated Router MUST NOT register-encapsulate a packet and send it to the RP unless the packet's source address is a legal address for the subnet it arrived on 💅 Similarly, a Designated Router SHOULD NOT accept a Register-Stop packet whose IP source address isn't a valid RP address for the local domain. Main character energy is checking your ID at the door 🎀
An implementation SHOULD provide a mechanism that lets an RP restrict the range of source addresses it accepts Register-encapsulated packets from ✨
All options that restrict the range of addresses packets are accepted from MUST default to allowing all packets. So the open-door setting is the default, and you have to opt in to being picky 🌸
6.3. Authentication Using IPsec 🛡️
okay the IPsec [8] transport mode using the Authentication Header (AH) is the recommended method for stopping the attacks above against PIM 🦋 The network administrator picks the AH authentication algorithm and its parameters, including which algorithm and which key. When IPsec authentication is in use, a PIM router should reject (drop without processing) any unauthorized PIM protocol messages. Iconic behavior, no notes 💀
To use IPsec, the admin configures each PIM router with one or more security associations (SAs) and their Security Parameter Indexes (SPIs) 🧚 Senders use them to authenticate the PIM protocol messages they send, and receivers use them to authenticate what comes in. This document doesn't describe how to establish SAs. It assumes the SAs are configured manually, but it doesn't rule out a negotiation protocol like the Internet Key Exchange [14] for setting them up 🍓
IPsec [8] protects against replayed unicast and multicast messages 🔁 The anti-replay option for IPsec SHOULD be enabled on all SAs. Lowkey a must-have 💜
The next sections describe the SAs you need to protect PIM protocol messages ✨
6.3.1. Protecting Link-Local Multicast Messages
The network administrator defines one SA and SPI to authenticate all link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each link in a PIM domain 🌈
IPsec [8] lets you have different Security Policy Databases (SPD) for each router interface, but it doesn't force you to 🎀 If you can, it may be desirable to set up the Security Policy Database on a PIM router so that every incoming and outgoing Join/Prune, Assert, and Hello packet uses a different SA for each incoming or outgoing interface. Very organized, very iconic 👑
6.3.2. Protecting Unicast Messages
IPsec can also give data origin authentication and data integrity protection for the Register and Register-Stop unicast messages 🔒
6.3.2.1. Register Messages
Every PIM router's Security Policy Database is configured to pick an SA when it sends PIM Register packets to each rendezvous point 🦋
In the most general mode, the Security Policy Database at each DR is set to pick a unique SA and SPI for traffic going to each RP. That way each DR can use its own authentication algorithm and key to talk to the RP. But ngl, that creates a daunting key management and distribution problem for the network admin 😭 So in PIM domains where all the Designated Routers are under one administrative control, it may be preferable to use the same authentication algorithm parameters (including the key) for all Registered packets in the domain, no matter who is the RP and who is the DR ✨
In this "single shared key" mode, the network administrator must choose an SPI for each DR to use when sending it PIM protocol packets. The Security Policy Database at every DR is configured to pick an SA (the authentication algorithm, the authentication parameters, and this SPI) when it sends Register messages to this RP 🧚
Using a single authentication algorithm and its parameters makes the key distribution problem way simpler 🙌 Just note the catch: with this method, changing the authentication method or key means every router in the domain has to be updated. Not me having to update the whole fleet 🙈
6.3.2.2. Register-Stop Messages
Same energy here: the Security Policy Database at each Rendezvous Point should be configured to pick an SA for sending Register-Stop messages. Since Register-Stop messages are unicast to the destination DR, every DR needs its own SA, and potentially its own unique SPI 🦋
To simplify the management problem, it may be acceptable to use the same authentication algorithm and parameters no matter which RP is sending or which DR is the destination. Even though each DR needs a unique SA, the same authentication algorithm and parameters (secret key) can be shared by all DRs and all RPs 🫶
6.4. Denial-of-Service Attacks 🚨
okay this part is serious, bestie 😤 There are a bunch of possible denial-of-service attacks against PIM. They can come from generating false PIM protocol messages, or even from generating false data traffic. Authenticating PIM protocol traffic stops some of these attacks, but not all of them. Three of the possible attacks include:
- Sending packets to many different group addresses quickly can be a denial-of-service attack in and of itself. It causes lots of register-encapsulated packets, which loads the DR, the RP, and the routers between the DR and the RP. Overwhelming vibes 💀
- Forging Join messages can cause a multicast tree to get set up. A large number of forged joins can eat up router resources and lead to denial of service 🥀
- Forging a (,,RP) join is a possible denial-of-service attack, because it can send all traffic in the domain flowing to the PMBR that issued the join. The (,,RP) behavior is included here mainly for backwards compatibility with earlier revisions of the spec. However, implementing (,,RP) and PMBR is optional. When you do use (,,RP), the security concerns should be carefully considered 🙏
7. Acknowledgements ✨
PIM-SM was designed over many years by a huge group of people 🌸 Thank you to Deborah Estrin, Dino Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike Davison, James Huang, Christopher Thomas Brown, and James Lingard 🫶
Thanks are also due to the American Licorice Company, for its obscure but possibly essential role in the creation of this document 🍬💅
8. Normative References 📚
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[4] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4507, August 2006.
[7] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
9. Informative References 🧾
[10] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, May 2006.
[12] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-directional Protocol Independent Multicast", Work in Progress, October 2005.
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, August 2006.
[16] Savola, P. and J. Lingard, "Last-hop Threats to Protocol Independent Multicast (PIM)", Work in Progress, January 2005.
[17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[18] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
Appendix A. PIM Multicast Border Router Behavior 🌉
In some cases, PIM-SM domains will interconnect with non-PIM multicast domains 🌐 In these cases, the border routers of the PIM domain speak PIM-SM on some interfaces and speak other multicast routing protocols on other interfaces. Such routers are termed PIM Multicast Border Routers (PMBRs). In general, RFC 2715 [18] provides rules for interoperability between different multicast routing protocols. In this appendix, we specify how PMBRs differ from regular PIM-SM routers 🦋
From the point of view of PIM-SM, a PMBR has two tasks:
- To ensure that traffic from sources outside the PIM-SM domain reaches receivers inside the domain.
- To ensure that traffic from sources inside the PIM-SM domain reaches receivers outside the domain.
We note that multiple PIM-SM domains are sometimes connected together using protocols such as Multicast Source Discovery Protocol (MSDP), which provides information about active external sources but does not follow RFC 2715 👀 In such cases, the domains are not connected via PMBRs, because Join(S,G) messages traverse the border between domains. A PMBR is required when no PIM messages can traverse the border 💖
A.1. Sources External to the PIM-SM Domain ✨
Okay bestie, so a PMBR has to make sure traffic from multicast sources outside the PIM-SM domain actually reaches receivers inside it 💖. It follows the rules in RFC 2715, so that external traffic reaches the PMBR itself 🦋.
Per RFC 2715, the PIM-SM component of the PMBR gets an (S,G) Creation event when data from an (S,G) data packet from an external source first shows up at the PMBR 🧚. If RPF_interface(S) is an interface in the PIM-SM domain, the packet can't be originated into the PIM domain at this router, so the PIM-SM component of the PMBR will not process the packet 💀. Otherwise, the PMBR acts exactly as if it were the DR for this source (see Section 4.4.1), with these tweaks:
- The Border-bit is set in all PIM Register messages sent for these sources. 🎀
DirectlyConnected(S)is treated as being TRUE for these sources. 🌸- The PIM-SM forwarding rule
iif == RPF_interface(S)is relaxed to be TRUE ifiifis any interface that is not part of the PIM-SM component of the PMBR (see Section 4.2). 🫶
A.2. Sources Internal to the PIM-SM Domain 🌈
Now the other direction: a PMBR needs to make sure traffic from sources inside the PIM-SM domain reaches receivers outside it 😭. Using terminology from RFC 2715, there are two possible scenarios, and they're giving very different energy 💅.
- Another component of the PMBR is a wildcard receiver. In this case, the PIM-SM component of the PMBR must ensure that traffic from all internal sources reaches the PMBR until it is informed otherwise. 👑
Note that certain profiles of PIM-SM (e.g., PIM-SSM, PIM-SM with Embedded RP) cannot interoperate with a neighboring wildcard receiver domain. 🙈
- No other component of the PMBR is a wildcard receiver. In this case, the PMBR will receive explicit information as to which groups or (source,group) pairs the external domains wish to receive. 🍓
In the former case, the PMBR will need to send a Join(*,*,RP) to all the active RPs in the PIM-SM domain. It may also send a Join(*,*,RP) to all the candidate RPs in the PIM-SM domain. This will cause all traffic in the domain to reach the PMBR. The PMBR may then act as if it were a DR with directly connected receivers and trigger the transition to a shortest path tree (see Section 4.2.1). ✨
In the latter case, the PMBR will not need to send Join(*,*,RP) messages. However, the PMBR will still need to act as a DR with directly connected receivers on behalf of the external receivers, in terms of being able to switch to the shortest-path tree for internally-reached sources. 🧚
According to RFC 2715, the PIM-SM component of the PMBR may receive a number of alerts generated by events in the external routing components. To implement the above behavior, one reasonable way to map these alerts into PIM-SM state is as follows: 🎀
- When a PIM-SM component receives an (S,G) Prune alert, it sets
local_receiver_include(S,G,I)to FALSE for the discard interface. 🌸 - When a PIM-SM component receives a (*,G) Prune alert, it sets
local_receiver_include(*,G,I)to FALSE for the discard interface. 🌸 - When a PIM-SM component receives an (S,G) Join alert, it sets
local_receiver_include(S,G,I)to TRUE for the discard interface. 💜 - When a PIM-SM component receives a (*,G) Join alert, it sets
local_receiver_include(*,G,I)to TRUE for the discard interface. 💜 - When a PIM-SM component receives a (,) Join alert, it sets
DownstreamJPState(*,*,RP,I)to Join state on the discard interface for all RPs in the PIM-SM domain. 🔥 - When a PIM-SM component receives a (,) Prune alert, it sets
DownstreamJPState(*,*,RP,I)to NoInfo state on the discard interface for all RPs in the PIM-SM domain. 🔥
We refer above to the discard interface because the macros and state machines are interface specific, but we need to have PIM state that is not associated with any actual PIM-SM interface. Implementers are free to implement this in any reasonable manner. 🦋
Note that these state changes will then cause additional PIM-SM state machine transitions in the normal way. 💅
These rules are, however, not sufficient to allow pruning off the (,,RP) tree. Some additional rules provide guidance as to one way this may be done: 😭
- If the PMBR has joined on the (,,RP) tree, then it should set
DownstreamJPState(*,G,I)to JOIN on the discard interface for all active groups. 🌈 - If the router receives a (S,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I)to PRUNE on the discard interface. 🍓 - If the router receives a (*,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I)to PRUNE on the discard interface for all active sources sending to G. 🍓
The rationale for this is that there is no way in PIM-SM to prune traffic off the (,,RP) tree, except by Joining the (*,G) tree and then pruning each source individually. That's the whole vibe 🫶✨
Appendix B. Index ✨
Okay bestie, here's the index! 🧚 It's a big list of every name, timer, and variable from the spec, along with the page numbers where each one shows up. Lookup time 💅
Address_List. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
Assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
AssertCancel(*,G) . . . . . . . . . . . . . . . . . . . . . . . 97,99
AssertCancel(S,G) . . . . . . . . . . . . . . . . . . . . . .80,90,99
AssertTimer(*,G,I). . . . . . . . . . . . . . . . . . . .16,24,91,132
AssertTimer(S,G,I). . . . . . . . . . . . . . . . . . . .18,24,84,132
AssertTrackingDesired(*,G,I). . . . . . . . . . . . . . . . .93,94,96
AssertTrackingDesired(S,G,I). . . . . . . . . . . . . . . 85,86,87,89
AssertWinner(*,G,I) . . . . . . . . . . . . . . . .16,22,24,93,97,100
AssertWinner(S,G,I) . . . . . . . . . . . . . .18,22,24,86,90,100,100
AssertWinnerMetric(*,G,I) . . . . . . . . . . . . . . . . . 16,97,101
AssertWinnerMetric(S,G,I) . . . . . . . . . . . . . . . . . 18,90,101
assert_metric . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Assert_Override_Interval. . . . . . . . . . . . . . . . . . 90,97,132
Assert_Time . . . . . . . . . . . . . . . . . . . . . . . . 90,97,132
AT(*,G,I) . . . . . . . . . . . . . . . . . . . . . .16,24,91,129,132
AT(S,G,I) . . . . . . . . . . . . . . . . . . . . . .18,24,84,129,132
CheckSwitchToSpt(S,G) . . . . . . . . . . . . . . . . . . . . . 27,28
CouldAssert(*,G,I). . . . . . . . . . . . . . . . . . .92,93,94,95,98
CouldAssert(S,G,I). . . . . . . . . . . . . . . . . 84,86,87,88,89,98
CouldRegister(S,G). . . . . . . . . . . . . . . . . . . . . . . 39,41
Default_Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . . 33
DirectlyConnected(S). . . . . . . . . . . . . . . . . 27,27,29,41,143
DownstreamJPState(*,*,RP,I) . . . . . . . . . . . . . . . . . .23,145
DownstreamJPState(*,G,I). . . . . . . . . . . . . . . . . . . . . 23
DownstreamJPState(S,G,I). . . . . . . . . . . . . . . . . . . . 23,40
DownstreamJPState(S,G,rpt,I). . . . . . . . . . . . . . . . . . . 23
DR(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
dr_is_better(a,b,I) . . . . . . . . . . . . . . . . . . . . . . 33,33
DR_Priority . . . . . . . . . . . . . . . . . . . . . . . . . .31,32,33
Effective_Override_Interval(I). . . . . . . . . . . . . . .36,114,132
Effective_Propagation_Delay(I). . . . . . . . . . . . . . . . .35,132
ET(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . 15,46,128,131
ET(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . 16,50,128,131
ET(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . 18,53,129,131
ET(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . .20,57,59,129,131
GenID . . . . . . . . . . . . . . . . . 15,17,19,31,64,68,70,73,85,93
Hash_Function . . . . . . . . . . . . . . . . . . . . . . . . .12,105
Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . . . . .33,131
Hello_Period. . . . . . . . . . . . . . . . . . . . . . . . . .31,130
HT(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31,130
IGMP. . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
immediate_olist(*,*,RP) . . . . . . . . . . . . . . . . . . . . 22,64
immediate_olist(*,G). . . . . . . . . . . . . . . . . . . . . . 22,68
immediate_olist(S,G). . . . . . . . . . . . . . . . . . . . .22,40,73
infinite_assert_metric(). . . . . . . . . . . . . . . . . . . . . 99
inherited_olist(S,G). . . . . . . . . . . . . . 22,27,40,43,73,86,108
inherited_olist(S,G,rpt). . . . . . . . . . . . . . 22,27,29,76,79,81
I_Am_Assert_Loser(*,G,I). . . . . . . . . . . . . . . . . . . . . 24
I_Am_Assert_Loser(S,G,I). . . . . . . . . . . . . . . . . . . . . 24
I_am_DR(I). . . . . . . . . . . . . . . . . . . . . . .22,33,41,86,93
I_am_RP(G). . . . . . . . . . . . . . . . . . . . . . . . . . . 43,44
J/P_Holdtime. . . . . . . . . . . . .47,51,55,59,65,69,74,121,131,133
J/P_Override_Interval(I). . . . . . . . . . . . . 48,51,55,59,121,132
JoinDesired(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 64,79
JoinDesired(*,G). . . . . . . . . . . . . . . . . . . . .17,68,79,86,97
JoinDesired(S,G). . . . . . . . . . . . . . . . . . 19,29,73,86,88,90
joins(*,*,RP(G)). . . . . . . . . . . . . . . . . . . . . . . . . 22
joins(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
joins(*,G). . . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
joins(S,G). . . . . . . . . . . . . . . . . . . . . . . . . .22,23,86
JT(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . 15,62,129,133
JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . 16,67,129,133
JT(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 18,71,129,133
KAT(S,G). . . . . . . . . . . . . . .18,26,27,28,41,43,73,108,129,134
KeepaliveTimer(S,G) . . . . . . . 18,26,27,27,28,41,43,73,108,129,134
Keepalive_Period. . . . . . . . . . . . . . . . . . . . . . . .27,134
lan_delay_enabled(I). . . . . . . . . . . . . . . . . . . . . . 35,36
LAN_Prune_Delay . . . . . . . . . . . . . . . . . . . . . . . . . 31
local_receiver_exclude(S,G,I) . . . . . . . . . . . . . . . . . . 23
local_receiver_include(*,G,I) . . . . . . . . . . . . . . . 23,93,144
local_receiver_include(S,G,I) . . . . . . . . . . . . . . . . . 23,86
local_receiver_include(S,G,I).. . . . . . . . . . . . . . . . . . 144
lost_assert(*,G). . . . . . . . . . . . . . . . . . . . . . .22,24,86
lost_assert(*,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
lost_assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . 22,24
lost_assert(S,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
lost_assert(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . 24
lost_assert(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . .24,100
MBGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,7
MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6,13
MLD . . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
MRIB. . . . . . . . . . . . . .6,7,11,15,19,25,62,66,66,75,98,103,128
MRIB.next_hop(host) . . . . . . . . . . . . . . . . . . . 24,25,62,64
my_assert_metric(*,G,I) . . . . . . . . . . . . . . . . . . . . . 94
my_assert_metric(S,G,I) . . . . . . . . . . . . . . . . . 85,89,92,98
NBR(Interface,IP_address) . . . . . . . . . . . . . . .25,37,62,64,66
NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . 14,33,128,131
OT(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . 20,77,129,134
Override_Interval(I). . . . . . . . . . . . . 14,31,34,36,114,130,132
packet_arrives_on_rp_tunnel(pkt). . . . . . . . . . . . . . . . . 43
pim_exclude(S,G). . . . . . . . . . . . . . . . . . . . . 22,22,28,86
pim_include(*,G). . . . . . . . . . . . . . . . . . 17,22,22,28,86,93
pim_include(S,G). . . . . . . . . . . . . . . . . . . .19,22,22,28,86
PPT(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . 15,46,128,132
PPT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . 16,50,129,132
PPT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . 18,53,129,132
PPT(S,G,rpt,I). . . . . . . . . . . . . . . . . . . .20,57,59,129,132
Propagation_Delay(I). . . . . . . . . . . . . . . . . . 31,35,130,132
Propagation_delay_default . . . . . . . . . . . . . . . . . . . .35,130
PruneDesired(S,G,rpt) . . . . . . . . . . . . . . . . . . 79,80,88,90
prunes(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . .22,23,86
Register-Stop(*,G). . . . . . . . . . . . . . . . . . . . . . . . 42
Register-Stop(S,G). . . . . . . . . . . . . . . . . . . . . . . . 43
Register-StopTimer(S,G) . . . . . . . . . . . . . . . . 38,39,129,135
Register_Probe_Time . . . . . . . . . . . . . . . . . . . . 39,44,135
Register_Suppression_Time . . . . . . . . . . . . . . . . . 39,44,135
RP(G) . . . . . . . . . . . . 5,22,24,40,43,49,68,77,86,93,99,102,128
RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
RPF'(*,G) . . . . . . . . . . . . . . . . 24,29,67,68,70,76,79,97,101
RPF'(S,G) . . . . . . . . . . . . . . . . . . . 25,29,71,76,79,90,101
RPF'(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . .24,76,79,102
RPF_interface . . . . . . . . . . . . . . . . . . . . . . . . . . 93
RPF_interface(host) . . . . . .24,27,29,41,68,69,74,86,93,100,108,143
RPTJoinDesired(G) . . . . . . . . . . . . . . . . . . . . . .79,81,93
rpt_assert_metric(G,I). . . . . . . . . . . . . . . . . . . .96,97,99
RST(S,G). . . . . . . . . . . . . . . . . . . . . . . . 38,39,129,135
SPTbit(S,G) . . . . . . . 19,27,29,43,53,74,76,79,86,86,89,90,100,108
spt_assert_metric(S,I). . . . . . . . . . . . . . . . . . . 90,98,100
SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10,106
Suppression_Enabled(I). . . . . . . . . . . . . . . . . . . . .36,133
SwitchToSptDesired(S,G) . . . . . . . . . . . . . . . . . . .28,28,43
TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,13,26
Triggered_Hello_Delay . . . . . . . . . . . . . . . . . . . 31,32,130
t_joinsuppress. . . . . . . . . . . . . . . . . . . . . .64,65,68,69,74
t_override. . . . . . . . . . . . . . . . . . . . . 64,68,73,78,133,134
t_override_default. . . . . . . . . . . . . . . . . . . . . . .36,130
t_periodic. . . . . . . . . . . . . . . . . . . . . . . .64,68,73,133
t_suppressed. . . . . . . . . . . . . . . . . . . .36,65,69,73,74,133
Update_SPTbit(S,G,iif). . . . . . . . . . . . . . . . . . . . . 27,29
UpstreamJPState(S,G). . . . . . . . . . . . . . . . . . . . . .27,108Authors' Addresses 💖
Meet the squad behind the spec! These are the contact details exactly as they were written:
Bill Fenner
AT&T Labs - Research
1 River Oaks Place
San Jose, CA 95134
EMail: fenner@research.att.com
Mark Handley
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
United Kingdom
EMail: M.Handley@cs.ucl.ac.uk
Hugh Holbrook
Arastra, Inc.
P.O. Box 10905
Palo Alto, CA 94303
EMail: holbrook@arastra.com
Isidor Kouvelas
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
EMail: kouvelas@cisco.comFull Copyright Statement 🎀
Copyright (C) The Internet Society (2006). 🌈
Okay, legal bit, but make it cute: this document is subject to the rights, licenses and restrictions in BCP 78. Except as set forth there, the authors keep all their rights. 🦋
Also, this document and everything in it is provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. 💅
Intellectual Property 💅
Okay bestie, let's talk about who owns what 🧚. The IETF takes no position on whether any Intellectual Property Rights (or other rights) that someone might claim over the technology in this document are valid, or how far they reach. It also doesn't say whether any license under those rights might or might not be available. And no, it hasn't gone out and independently searched for any of those rights either 🙈. If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79 📚.
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses that have been offered. You can also find the result of any attempt to get a general license or permission for implementers or users to use those proprietary rights. All of it lives in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔥.
The IETF also wants to hear from you! If you know of any copyrights, patents, patent applications, or other proprietary rights that might cover technology you'd need to implement this standard, please tell them. Send it to the IETF at ietf-ipr@ietf.org 🫶. The whole point is that we all get to build the good stuff without any surprises 🌈.
Acknowledgement 🎀
Shoutout to the people keeping the lights on 👑. Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) ✨.
📦 where this page comes from
- ietf: rfc4601 2006-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms