RFC 3973
Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)
💖 Part 1 of 12! Sections 1 through 2.2 are below, and more parts are coming.
Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) 🦋
RFC 3973 is from the Network Working Group, and its category is Experimental. It was published in January 2005. The authors are A. Adams (NextHop Technologies), J. Nicholas (ITT A/CD), and W. Siadak (NextHop Technologies). The title block doesn't list anything this RFC obsoletes or updates. ✨
Status of This Memo 📝
This memo defines an Experimental Protocol for the Internet community, so it is not an Internet standard of any kind. The authors are asking for discussion and suggestions for improvement, and distribution of this memo is unlimited. 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2005). 🎀
Abstract 🌟
Okay, so this document specifies Protocol Independent Multicast - Dense Mode (PIM-DM) 💅. PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Then, to stop future messages from reaching routers that have no group membership information, it uses prune messages 🙈.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . 5
3. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . . 5
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . 7
4.1.1. General Purpose State . . . . . . . . . . . . . 7
4.1.2. (S,G) State . . . . . . . . . . . . . . . . . . 8
4.1.3. State Summarization Macros . . . . . . . . . . . 8
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . 10
4.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Sending Hello Messages . . . . . . . . . . . . . 11
4.3.2. Receiving Hello Messages . . . . . . . . . . . . 11
4.3.3. Hello Message Hold Time . . . . . . . . . . . . 12
4.3.4. Handling Router Failures . . . . . . . . . . . . 12
4.3.5. Reducing Prune Propagation Delay on LANs . . . . 13
4.4. PIM-DM Prune, Join, and Graft Messages . . . . . . . . . 13
4.4.1. Upstream Prune, Join, and Graft Messages . . . . 14
4.4.1.1. Transitions from the Forwarding
(F) State . . . . . . . . . . . . . . 17
4.4.1.2. Transitions from the Pruned
(P) State . . . . . . . . . . . . . . 18
4.4.1.3. Transitions from the AckPending
(AP) State . . . . . . . . . . . . . . 19
4.4.2. Downstream Prune, Join, and Graft Messages . . . 21
4.4.2.1. Transitions from the NoInfo State . . 23
4.4.2.2. Transitions from the PrunePending
(PP) State . . . . . . . . . . . . . . 24
4.4.2.3. Transitions from the Prune
(P) State . . . . . . . . . . . . . . 25
4.5. State Refresh . . . . . . . . . . . . . . . . . . . . . 26
4.5.1. Forwarding of State Refresh Messages . . . . . . 26
4.5.2. State Refresh Message Origination . . . . . . . 28
4.5.2.1. Transitions from the NotOriginator
(NO) State . . . . . . . . . . . . . . 29
4.5.2.2. Transitions from the Originator
(O) State . . . . . . . . . . . . . . 29
4.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . 30
4.6.1. Assert Metrics . . . . . . . . . . . . . . . . . 30
4.6.2. AssertCancel Messages . . . . . . . . . . . . . 31
4.6.3. Assert State Macros . . . . . . . . . . . . . . 32
4.6.4. (S,G) Assert Message State Machine . . . . . . . 32
4.6.4.1. Transitions from NoInfo State . . . . 34
4.6.4.2. Transitions from Winner State . . . . 35
4.6.4.3. Transitions from Loser State . . . . . 36
4.6.5. Rationale for Assert Rules . . . . . . . . . . . 38
4.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . 38
4.7.1. PIM Header . . . . . . . . . . . . . . . . . . . 38
4.7.2. Encoded Unicast Address . . . . . . . . . . . . 39
4.7.3. Encoded Group Address . . . . . . . . . . . . . 40
4.7.4. Encoded Source Address . . . . . . . . . . . . . 41
4.7.5. Hello Message Format . . . . . . . . . . . . . . 42
4.7.5.1. Hello Hold Time Option . . . . . . . . 43
4.7.5.2. LAN Prune Delay Option . . . . . . . . 43
4.7.5.3. Generation ID Option . . . . . . . . . 44
4.7.5.4. State Refresh Capable Option . . . . . 44
4.7.6. Join/Prune Message Format . . . . . . . . . . . 45
4.7.7. Assert Message Format . . . . . . . . . . . . . 47
4.7.8. Graft Message Format . . . . . . . . . . . . . . 48
4.7.9. Graft Ack Message Format . . . . . . . . . . . . 48
4.7.10. State Refresh Message Format . . . . . . . . . . 48
4.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . 50
5. Protocol Interaction Considerations . . . . . . . . . . . . . 53
5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . 53
5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . 54
5.3. Source Specific Multicast (SSM) Interactions . . . . . . 54
5.4. Multicast Group Scope Boundary Interactions . . . . . . 54
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . 54
6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . 55
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 55
7.1. Attacks Based on Forged Messages . . . . . . . . . . . . 55
7.2. Non-cryptographic Authentication Mechanisms . . . . . . 56
7.3. Authentication Using IPsec . . . . . . . . . . . . . . . 56
7.4. Denial of Service Attacks . . . . . . . . . . . . . . . 58
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Normative References . . . . . . . . . . . . . . . . . . 58
9.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 611. Introduction 🌈
Here's the vibe: this specification defines a multicast routing algorithm for multicast groups that are densely distributed across a network 🍓. PIM-DM doesn't have a topology discovery mechanism, which is something a lot of unicast routing protocols do have. It uses the same packet formats as sparse mode PIM (PIM-SM), and this protocol is called PIM - Dense Mode. The whole design was largely built on Deering's early work on IP multicast routing [12] 👑.
2. Terminology 📚
Let's get the key words sorted first 🫶. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [11]. They set the requirement levels for compliant PIM-DM implementations 💖.
2.1. Definitions 🔍
Multicast Routing Information Base (MRIB) This is the multicast topology table. It's usually derived from the unicast routing table, or from routing protocols such as MBGP that carry multicast-specific topology information. PIM-DM uses the MRIB to make decisions about RPF interfaces 🧭.
Tree Information Base (TIB) This is the collection of state a PIM router keeps, created by receiving PIM messages and IGMP information from local hosts. It basically stores the state of all multicast distribution trees at that router 🌳.
Reverse Path Forwarding (RPF) RPF is a multicast forwarding mode where a data packet is only accepted for forwarding if it arrives on an interface that's used to reach the source in unicast 🪞.
Upstream Interface This is the interface facing the source of the datagram. It's also known as the RPF Interface ⬆️.
Downstream Interface This means all the interfaces that aren't the upstream interface, and that includes the router itself ⬇️.
(S,G) Pair This is the source S and destination group G associated with an IP packet 🎯.
2.2. Pseudocode Notation 🧮
Okay, so this specification uses set notation in several places 🫧.
A (+) B is the union of two sets, A and B.
A (-) B gives the elements of set A that are not in set B.
NULL is the empty set or list.
Note that operations MUST be conducted in the order specified 🚨. The reason is that (-) isn't a true difference operator, because B is not necessarily a subset of A. So A (+) B (-) C = A (-) C (+) B is not a true statement unless C is a subset of both A and B. Main character energy: order matters! 💅
On top of that, there's some C-like syntax:
= denotes assignment of a variable.
== denotes a comparison for equality.
!= denotes a comparison for inequality.
Braces { and } are used for grouping ✨.
3. PIM-DM Protocol Overview ✨
okay bestie, this section is the intro to how PIM-DM works 💅 It's a vibe check, not the final word 🙈 For the definitive spec, go to Section 4, Protocol Specification.
PIM-DM basically assumes that when a source starts sending, every downstream system wants the multicast datagrams 🌈 So at first, datagrams get flooded to all areas of the network. To stop them from looping while they flood, PIM-DM uses RPF 🔁 If some areas don't have any group members, PIM-DM prunes that forwarding branch by creating prune state 🌸
Prune state has a finite lifetime ⏳ When it expires, data gets forwarded down the previously pruned branch again.
Prune state is tied to an (S,G) pair. When a new member for group G shows up in a pruned area, a router can "graft" toward the source S for that group, which turns the pruned branch back into a forwarding branch 🌿
The broadcast of datagrams followed by pruning the unwanted branches is often called a flood and prune cycle, and it's typical of dense mode protocols 🦋
To avoid repeated flooding and the pruning that comes with a particular (S,G) pair, PIM-DM uses a state refresh message 💖 This message is sent by the router(s) directly connected to the source and gets propagated throughout the network. When a router receives it on its RPF interface, the state refresh message refreshes the existing prune state ✨
Compared with multicast routing protocols that have built-in topology discovery mechanisms (e.g., DVMRP [13]), PIM-DM has a simpler design and isn't hard-wired into a specific topology discovery protocol 🧚 The catch is that this simplicity means more overhead. Flooding and pruning can happen on some links that could be skipped if enough topology information were available, like knowing whether an interface leads to any downstream members of a particular group. So the extra overhead is the trade-off for the simplicity and flexibility of not depending on one topology discovery protocol 🫶
PIM-DM differs from PIM-SM in two big ways: 1) there are no periodic joins sent, only explicitly triggered prunes and grafts, and 2) there is no Rendezvous Point (RP) 👑 That second one is a big deal in networks that can't tolerate a single point of failure. (An RP is the root of a shared multicast distribution tree. For more details, see [4].) 🙌
4. Protocol Specification 🎀
okay the spec is split into a bunch of parts, so here's the map 🗺️
- Section 4.1 details the protocol state stored.
- Section 4.2 specifies the data packet forwarding rules.
- Section 4.3 specifies generation and processing of Hello messages.
- Section 4.4 specifies the Join, Prune, and Graft generation and processing rules.
- Section 4.5 specifies the State Refresh generation and forwarding rules.
- Section 4.6 specifies the Assert generation and processing rules.
- Section 4.7 gives details on PIM-DM Packet Formats.
- Section 4.8 summarizes PIM-DM timers and their defaults.
4.1. PIM Protocol State 🧠
This section spells out all the protocol state a PIM-DM implementation should maintain to work correctly. We call this state the Tree Information Base or TIB, since it holds the state of all the multicast distribution trees at this router 🌳 The PIM-DM mechanisms are defined in terms of the TIB. Realistically, only a super simple implementation would do packet forwarding straight off this state. Most implementations use it to build a multicast forwarding table, which then gets updated whenever the relevant TIB state changes 💅
Unlike PIM-SM, PIM-DM doesn't keep a keepalive timer for each (S,G) route 🙅♀️ Instead, route and state information for an (S,G) entry MUST be kept as long as any timer tied to that (S,G) entry is active. Once no timer for that (S,G) entry is active, all info about that (S,G) route may be discarded 🗑️
Here's the tea: even though the state is specified precisely, an implementation doesn't have to store it in this exact form. This is an abstract state definition, mainly so the router's behavior can be specified 🧃 An 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 ✨
4.1.1. General Purpose State 🌸
A router stores the following non-group-specific state:
For each interface:
Hello Timer (HT)
State Refresh Capable
LAN Delay Enabled
Propagation Delay (PD)
Override Interval (OI)
Neighbor State:
For each neighbor:
Information from neighbor's Hello
Neighbor's Gen ID.
Neighbor's LAN Prune Delay
Neighbor's Override Interval
Neighbor's State Refresh Capability
Neighbor Liveness Timer (NLT)4.1.2. (S,G) State 🦋
For every source/group pair (S,G), a router stores the following state:
(S,G) state:
For each interface:
Local Membership:
State: One of {"NoInfo", "Include"}
PIM (S,G) Prune State:
State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending"
(PP)}
Prune Pending Timer (PPT)
Prune Timer (PT)
(S,G) Assert Winner State:
State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won
Assert" (W)}
Assert Timer (AT)
Assert winner's IP Address
Assert winner's Assert Metric
Upstream interface-specific:
Graft/Prune State:
State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F),
"AckPending" (AP) }
GraftRetry Timer (GRT)
Override Timer (OT)
Prune Limit Timer (PLT)
Originator State:
Source Active Timer (SAT)
State Refresh Timer (SRT)4.1.3. State Summarization Macros 🧁
Using the state defined above, the following "macros" are defined. They get used in the state machine descriptions and pseudocode in the sections that follow 📝
The most important macros are the ones that define the outgoing interface list (or "olist") for the relevant state 💖
immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+)
(pim_include(*,G) (-) pim_exclude(S,G) ) (+)
pim_include(S,G) (-) lost_assert(S,G) (-)
boundary(G)
olist(S,G) = immediate_olist(S,G) (-) RPF_interface(S)The macros pim_include(*,G) and pim_include(S,G) show the interfaces where traffic might or might not get forwarded because of hosts that are local members on those interfaces 👀
pim_include(*,G) = {all interfaces I such that:
local_receiver_include(*,G,I)}
pim_include(S,G) = {all interfaces I such that:
local_receiver_include(S,G,I)}
pim_exclude(S,G) = {all interfaces I such that:
local_receiver_exclude(S,G,I)}The macro RPF_interface(S) returns the RPF interface for source S. In other words, it returns the interface used to reach S as indicated by the MRIB 🧭
The macro local_receiver_include(S,G,I) is true if the IGMP module or some other local membership mechanism ([1], [2], [3], [6]) has figured out that there are local members on interface I who want to receive traffic sent specifically by S to G 🙋♀️
The macro local_receiver_include(*,G,I) is true if the IGMP module or another local membership mechanism has figured out that there are local members on interface I who want to receive all traffic sent to G. Heads up: this determination is expected to account for membership joins initiated on or by the router too 🫶
The macro 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 pim_nbrs is the set of all interfaces where the router has at least one active PIM neighbor 🤝
The set prunes(S,G) is the set of all interfaces where the router has received Prune(S,G) messages:
prunes(S,G) = {all interfaces I such that
DownstreamPState(S,G,I) is in Pruned state}The set lost_assert(S,G) is the set of all interfaces where the router has lost an (S,G) Assert:
lost_assert(S,G) = {all interfaces I such that
lost_assert(S,G,I) == TRUE}boundary(G) = {all interfaces I with an administratively scoped
boundary for group G}A few more pseudocode macro definitions get used all over the spec. Basically, RPF' is the RPF neighbor toward a source, unless a PIM-DM Assert has overridden the normal neighbor choice 🪄
neighbor RPF'(S,G) {
if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) {
return AssertWinner(S, G, RPF_interface(S) )
} else {
return MRIB.next_hop( S )
}
}The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine (in Section 4.6) for (S,G) on interface I is in the "I am Assert Loser" state 🥺
4.2. Data Packet Forwarding Rules 📦
The PIM-DM packet forwarding rules are defined below in pseudocode 💻
iif is the incoming interface of the packet. S is the source address of the packet. G is the destination address of the packet (the group address). RPF_interface(S) is the interface the MRIB says would be used to route packets to S 🛣️
First, an RPF check MUST be performed to decide whether the packet should be accepted, based on TIB state and the interface the packet arrived on. Packets that fail the RPF check MUST NOT be forwarded, and the router will conduct an assert process for the (S,G) pair in the packet. Packets with no route to the source MUST be discarded 🚫
If the RPF check passes, an outgoing interface list gets built for the packet. If that list isn't empty, the packet MUST be forwarded to all listed interfaces ✅ If the list is empty, the router will conduct a prune process for the (S,G) pair in the packet 🌿
Upon receipt of a data packet from S addressed to G on interface iif:
if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) {
oiflist = olist(S,G)
} else {
oiflist = NULL
}
forward packet on all interfaces in oiflistThis pseudocode uses the following "macro" definition:
UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in Section 4.4.1 🧚
4.3. Hello Messages 👋
This section describes the generation and processing of Hello messages 💖
4.3.1. Sending Hello Messages 🎀
okay so PIM-DM uses Hello messages to find other PIM routers 👀. They get sent regularly on every PIM-enabled interface, and they go out as multicast to the ALL-PIM-ROUTERS group 📣. When PIM is turned on for an interface, or a router first starts up, the Hello Timer (HT) MUST be set to a random value between 0 and Triggered_Hello_Delay 🎲. The randomness is there so Hellos don't all sync up and flood the link when a bunch of routers get powered on together 🙈.
After that first Hello, a Hello message MUST be sent every Hello_Period 💖. One single Hello timer MAY be used to trigger Hellos on all the active interfaces 🧚. The Hello Timer SHOULD NOT be reset except when it expires 💅.
4.3.2. Receiving Hello Messages ✨
When a Hello message comes in, the receiving router SHALL record the receiving interface, the sender, and any info inside the options it recognizes 📝. That info gets kept for a number of seconds set in the Hold Time field of the Hello Message ⏳. If a new Hello comes in from a particular neighbor N, its Neighbor Liveness Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime 🔄. And if the Hello is from a brand-new neighbor, the router SHOULD send its own Hello after a random delay between 0 and Triggered_Hello_Delay 🤝.
4.3.3. Hello Message Hold Time 🕰️
The Hold Time in the Hello Message should be set to a value that can reasonably be expected to keep the Hello active until a new Hello message is received. On most links, that's 3.5 times the value of Hello_Period 📐.
If the Hold Time is set to '0xffff', the receiving router MUST NOT time out that Hello message 🛑. This feature might be useful for on-demand links, so you don't keep the link up with periodic Hello messages 🔌.
If a Hold Time of '0' is received, the corresponding neighbor state expires immediately 💨. When a PIM router takes an interface down or changes its IP address, a Hello message with a zero Hold Time SHOULD be sent immediately (with the old IP address if the IP address is changed), so any PIM neighbors drop the old info right away 👋.
4.3.4. Handling Router Failures 💀
If a Hello message comes in from an active neighbor with a different Generation ID (GenID), that neighbor has restarted and may not have the correct (S,G) state 😬. A Hello message SHOULD be sent after a random delay between 0 and Triggered_Hello_Delay (see 4.8), before any other messages are sent. If the neighbor is downstream, the router MAY replay the last State Refresh message for any (S,G) pairs it is the Assert Winner for, indicating Prune and Assert status, to that downstream router 🔁. These State Refresh messages SHOULD be sent out immediately after the Hello message 🚀. If the neighbor is the upstream neighbor for an (S,G) entry, the router MAY cancel its Prune Limit Timer, so it can send a prune and re-establish a Pruned state in the upstream router 🧠.
Upon startup, a router MAY use any State Refresh messages received within Hello_Period of its first Hello message on an interface to establish state information 🏗️. The State Refresh source will be the RPF'(S), and Prune status for all interfaces will be set according to the Prune Indicator bit in the State Refresh message. If the Prune Indicator is set, the router SHOULD set the PruneLimitTimer to Prune_Holdtime and set the PruneTimer on all downstream interfaces to the State Refresh's Interval times two ⏲️. The router SHOULD then propagate the State Refresh as described in Section 4.5.1 📨.
4.3.5. Reducing Prune Propagation Delay on LANs 🐢
If all routers on a LAN support the LAN Prune Delay option, then the PIM routers on that LAN will use the values received to adjust their J/P_Override_Interval on that interface, and the interface is LAN Delay Enabled. Basically, to avoid synchronizing Prune Override (Join) messages when multiple downstream routers share a multi-access link, sending these messages is delayed by a small random amount of time ⏳. The period of randomization is configurable and has a default value of 3 seconds ⏱️.
Each router on the LAN expresses its view of the amount of randomization it needs in the Override Interval field of the LAN Prune Delay option. When all routers on a LAN use the LAN Prune Delay Option, all routers on the LAN MUST set their Override_Interval to the largest Override value on the LAN 👑.
The LAN Delay a router inserts in the LAN Prune Delay option expresses the expected message propagation delay on the link, and SHOULD be configurable by the system administrator 🛠️. When all routers on a link use the LAN Prune Delay Option, all routers on the LAN MUST set Propagation Delay to the largest LAN Delay on the LAN 📈.
PIM implementers should enforce a lower bound on the permitted values for this delay, to allow for scheduling and processing delays within their router ⚠️. Such delays may cause received messages to be processed later and triggered messages to be sent later than intended. Setting this LAN Prune Delay to too low a value may result in temporary forwarding outages, because a downstream router will not be able to override a neighbor's prune message before the upstream neighbor stops forwarding 😭.
4.4. PIM-DM Prune, Join, and Graft Messages 🌈
This section covers how PIM-DM Join, Prune, and Graft messages get generated and processed 💌. Prune messages are sent toward the upstream neighbor for S to say that traffic from S addressed to group G isn't desired 🙅. Say downstream routers A and B: if A wants to keep receiving data and B doesn't, A sends a Join in response to B's Prune to override it. That's the only situation in PIM-DM where a Join message is used 🫶. Finally, a Graft message is used to re-join a previously pruned branch to the delivery tree 🌳.
4.4.1. Upstream Prune, Join, and Graft Messages 🎯
The Upstream(S,G) state machine for sending Prune, Graft, and Join messages is below, and it has three states 🧩.
- Forwarding (F): This is the starting state of the
Upsteam(S,G)state machine. The state machine is in this state if it just started or ifoiflist(S,G) != NULL. - Pruned (P): The set,
olist(S,G), is empty. The router will not forward data from S addressed to group G. - AckPending (AP): The router was in the Pruned(P) state, but a transition has occurred in the Downstream(S,G) state machine for one of this (S,G) entry's outgoing interfaces, indicating that traffic from S addressed to G should again be forwarded. A Graft message has been sent to
RPF'(S), but a Graft Ack message has not yet been received.
In addition, there are three state-machine-specific timers ⏰:
- GraftRetry Timer (GRT(S,G)): This timer is set when a Graft is sent upstream. If a corresponding GraftAck is not received before the timer expires, then another Graft is sent, and the GraftRetry Timer is reset. The timer is stopped when a Graft Ack message is received. This timer is normally set to
Graft_Retry_Period(see 4.8). - Override Timer (OT(S,G)): This timer is set when a
Prune(S,G)is received on the upstream interface whereolist(S,G) != NULL. When the timer expires, aJoin(S,G)message is sent on the upstream interface. This timer is normally set tot_override(see 4.8). - Prune Limit Timer (PLT(S,G)): This timer is used to rate-limit Prunes on a LAN. It is only used when the Upstream(S,G) state machine is in the Pruned state. A Prune cannot be sent if this timer is running. This timer is normally set to
t_limit(see 4.8).
+-------------+ +-------------+
| | olist == NULL | |
| Forward |----------------------->| Pruned |
| | | |
+-------------+ +-------------+
^ | ^ |
| | | |
| |RPF`(S) Changes olist == NULL| |
| | | |
| | +-------------+ | |
| +-------->| |----------+ |
| | AckPending | |
+-------------| |<-------------+
Rcv GraftAck OR +-------------+ olist != NULL
Rcv State Refresh
With (P==0) OR
S Directly Connect
Figure 1: Upstream Interface State MachineIn tabular form, the state machine is defined as follows 📋:
+-------------------------------+--------------------------------------+
| | Previous State |
| +------------+------------+------------+
| Event | Forwarding | Pruned | AckPending |
+-------------------------------+------------+------------+------------+
| Data packet arrives on | ->P Send | ->P Send | N/A |
| RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | |
| olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| |
| PLT(S,G) not running | | | |
+-------------------------------+------------+------------+------------+
| State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set |
| from RPF`(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) |
| Prune Indicator == 1 | | | |
+-------------------------------+------------+------------+------------+
| State Refresh(S,G) received | ->F | ->P Send |->F Cancel |
| from RPF`(S) AND | | Prune(S,G) | GRT(S,G) |
| Prune Indicator == 0 AND | |Set PLT(S,G)| |
| PLT(S,G) not running | | | |
+-------------------------------+------------+------------+------------+
+-------------------------------+--------------------------------------+
| | Previous State |
+ +------------+------------+------------+
| Event | Forwarding | Pruned | AckPending |
+-------------------------------+------------+------------+------------+
| See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel |
| | OT(S,G) | | OT(S,G) |
+-------------------------------+------------+------------+------------+
| See Prune(S,G) | ->F Set | ->P |->AP Set |
| | OT(S,G) | | OT(S,G) |
+-------------------------------+------------+------------+------------+
| OT(S,G) Expires | ->F Send | N/A |->AP Send |
| | Join(S,G) | | Join(S,G) |
+-------------------------------+------------+------------+------------+
| olist(S,G)->NULL | ->P Send | N/A |->P Send |
| | Prune(S,G) | | Prune(S,G) |
| |Set PLT(S,G)| |Set PLT(S,G)|
| | | | Cancel |
| | | | GRT(S,G) |+-------------------------------+------------+------------+------------+
| olist(S,G)->non-NULL | N/A | ->AP Send | N/A |
| | | Graft(S,G) | |
| | |Set GRT(S,G)| |
+-------------------------------+------------+------------+------------+
| RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send |
| olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) |
| |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)|
+-------------------------------+------------+------------+------------+
| RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel |
| olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) |
+-------------------------------+------------+------------+------------+
| S becomes directly connected | ->F | ->P |->F Cancel |
| | | | GRT(S,G) |
+-------------------------------+------------+------------+------------+
| GRT(S,G) Expires | N/A | N/A |->AP Send |
| | | | Graft(S,G) |
| | | |Set GRT(S,G)|
+-------------------------------+------------+------------+------------+
| Receive GraftAck(S,G) from | ->F | ->P |->F Cancel |
| RPF'(S) | | | GRT(S,G) |
+-------------------------------+------------+------------+------------+okay so the table above is the whole cheat sheet for the state machine 🧠✨ The transition event RcvGraftAck(S,G) basically means a Graft Ack message showing up, addressed to this router's address on the incoming interface for the (S,G) entry. 🎀 And bestie, if the destination address isn't correct, the state transitions in this state machine must not occur. Not me being dramatic, that's just the rule 💅
4.4.1.1. Transitions from the Forwarding (F) State ✨
okay so when the Upstream(S,G) state machine is in the Forwarding (F) state, these events can trigger a transition 🦋
Data Packet arrives on the RPF interface 🌸 Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S NOT directly connected The Upstream(S,G) state machine MUST transition to the Pruned (P) state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit seconds. Iconic, no notes 💀
State Refresh(S,G) Received from RPF'(S) 💜 The Upstream(S,G) state machine stays in a Forwarding state. If the received State Refresh has the Prune Indicator bit set to one, this router must override the upstream router's Prune state after a short random interval. If OT(S,G) is not running and the Prune Indicator bit equals one, the router MUST set OT(S,G) to t_override seconds.
See Join(S,G) to RPF'(S) 🫶 This one 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). If OT(S,G) is running, that means this router had scheduled a Join to override a previously received Prune. Another router responded faster with a Join, so the local router SHOULD cancel its OT(S,G), if it is running. The Upstream(S,G) state machine remains in the Forwarding (F) state. Main character energy from the other router, honestly 👑
See Prune(S,G) AND S NOT directly connected 🙈 Again, only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(S,G). Since this router is in Forwarding state, it must override the Prune after a short random interval. If OT(S,G) is not running, the router MUST set OT(S,G) to t_override seconds. The Upstream(S,G) state machine remains in Forwarding (F) state. Stay strong, router 🧚
OT(S,G) Expires AND S NOT directly connected ⏰ The OverrideTimer (OT(S,G)) expires. The router MUST send a Join(S,G) to RPF'(S) to override a previously detected prune. The Upstream(S,G) state machine remains in the Forwarding (F) state. Redemption arc, we love to see it 🔥
olist(S,G) -> NULL AND S NOT directly connected 🍓 The Upstream(S,G) state machine MUST transition to the Pruned (P) state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit seconds.
RPF'(S) Changes AND olist(S,G) is non-NULL AND S NOT directly connected 🌈 Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the AckPending (AP) state, unicast a Graft to the new RPF'(S), and set the GraftRetry Timer (GRT(S,G)) to Graft_Retry_Period. Plot twist, we're moving houses 🏠✨
RPF'(S) Changes AND olist(S,G) is NULL 🥀 Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the Pruned (P) state.
4.4.1.2. Transitions from the Pruned (P) State 🦋
okay so when the Upstream(S,G) state machine is in the Pruned (P) state, these events can trigger a transition 💖
Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT directly connected 📦 Either another router on the LAN wants traffic from S addressed to G, or a previous Prune got lost 🙃 To stop the router from generating a Prune(S,G) in response to every single data packet, the PruneLimit Timer (PLT(S,G)) is used. Once PLT(S,G) expires, the router needs to send another prune in response to a data packet not received directly from the source. A Prune(S,G) MUST be sent to RPF'(S), and PLT(S,G) MUST be set to t_limit.
State Refresh(S,G) Received from RPF'(S) 🌸 The Upstream(S,G) state machine remains in a Pruned state. If the State Refresh has its Prune Indicator bit set to zero and PLT(S,G) is not running, a Prune(S,G) MUST be sent to RPF'(S), and PLT(S,G) MUST be set to t_limit. If the State Refresh has its Prune Indicator bit set to one, the router MUST reset PLT(S,G) to t_limit.
See Prune(S,G) to RPF'(S) 🧁 A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The Upstream(S,G) state machine stays in the Pruned (P) state. The router MAY reset its PLT(S,G) to the value in the Holdtime field of the received message if that value is greater than the current value of PLT(S,G).
olist(S,G)->non-NULL AND S NOT directly connected 🚀 The set of interfaces defined by the olist(S,G) macro becomes non-empty, which means traffic from S addressed to group G must be forwarded now. The Upstream(S,G) state machine MUST cancel PLT(S,G), transition to the AckPending (AP) state, and unicast a Graft message to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to Graft_Retry_Period. Wakey wakey, we're back on the menu 🍽️
RPF'(S) Changes AND olist(S,G) == non-NULL AND S NOT directly connected 🔀 Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST cancel PLT(S,G), transition to the AckPending (AP) state, send a Graft unicast to the new RPF'(S), and set the GraftRetry Timer (GRT(S,G)) to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected 🫧 Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine stays in the Pruned (P) state and MUST cancel the PLT(S,G) timer.
S becomes directly connected 🏡 Unicast routing changed so that S is directly connected. The Upstream(S,G) state machine remains in the Pruned (P) state.
4.4.1.3. Transitions from the AckPending (AP) State 💅
okay so when the Upstream(S,G) state machine is in the AckPending (AP) state, these events can trigger a transition 🎀
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1 💜 The Upstream(S,G) state machine remains in an AckPending state. The router must override the upstream router's Prune state after a short random interval. If OT(S,G) is not running and the Prune Indicator bit equals one, the router MUST set OT(S,G) to t_override seconds.
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0 ✨ The router MUST cancel its GraftRetry Timer (GRT(S,G)) and transition to the Forwarding (F) state. Graduated, no cap 🎓
See Join(S,G) to RPF'(S,G) 🫶 This one 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). If OT(S,G) is running, that means this router had scheduled a Join to override a previously received Prune. Another router responded faster with a Join, so the local router SHOULD cancel its OT(S,G), if it is running. The Upstream(S,G) state machine remains in the AckPending (AP) state.
See Prune(S,G) 🙈 This one only matters if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(S,G). Since this router is in AckPending (AP) state, it must override the Prune after a short random interval. If OT(S,G) is not running, the router MUST set OT(S,G) to t_override seconds. The Upstream(S,G) state machine remains in AckPending (AP) state.
OT(S,G) Expires ⏰ The OverrideTimer (OT(S,G)) expires. The router MUST send a Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in the AckPending (AP) state.
olist(S,G) -> NULL 🍓 The set of interfaces defined by the olist(S,G) macro becomes null, which means traffic from S addressed to group G should no longer be forwarded. The Upstream(S,G) state machine MUST transition to the Pruned (P) state. A Prune(S,G) MUST be multicast to the RPF_interface(S), with RPF'(S) named in the upstream neighbor field. The GraftRetry Timer (GRT(S,G)) MUST be cancelled, and PLT(S,G) MUST be set to t_limit seconds. Okay, we're tidying up the whole situation 🧹
RPF'(S) Changes AND olist(S,G) does not become NULL AND S NOT directly connected 🌈 Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine stays in the AckPending (AP) state. A Graft MUST be unicast to the new RPF'(S), and the GraftRetry Timer (GRT(S,G)) is reset to Graft_Retry_Period.
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected 🥀 Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the Pruned (P) state. The GraftRetry Timer (GRT(S,G)) MUST be cancelled.
S becomes directly connected 🏡 Unicast routing has changed so that S is directly connected. The GraftRetry Timer MUST be cancelled, and the Upstream(S,G) state machine MUST transition to the Forwarding(F) state.
GRT(S,G) Expires ⌛ The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry. The Upstream(S,G) state machine stays in the AckPending (AP) state. Another Graft message for (S,G) SHOULD be unicast to RPF'(S), and the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is RECOMMENDED that the router retry a configured number of times before ceasing retries. Persistence is a whole aesthetic 🫡
See GraftAck(S,G) from RPF'(S) 🎉 A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be cancelled, and the Upstream(S,G) state machine MUST transition to the Forwarding(F) state. We did it, bestie 🥹🫶
4.4.2. Downstream Prune, Join, and Graft Messages ✨
okay bestie, this is the Prune(S,G) Downstream state machine 🦋 It's how a router handles Prune, Join, and Graft messages arriving on interface I. This machine MUST always be in the NoInfo state on the upstream interface 💅 It has three states.
NoInfo(NI) The interface has no (S,G) Prune state, and neither the Prune timer (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running.
PrunePending(PP) The router has received a Prune(S,G) 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 PrunePending state functions exactly like the NoInfo state.
Pruned(P) The router has received a Prune(S,G) on this interface from a downstream neighbor, and the Prune was not overridden. Data from S addressed to group G is no longer being forwarded on this interface.
There are also two timers in the mix 🎀
PrunePending Timer (PPT(S,G,I)) This timer is set when a valid Prune(S,G) is received. Expiry of the PrunePending Timer (PPT(S,G,I)) causes the interface to transition to the Pruned state.
Prune Timer (PT(S,G,I)) This timer is set when the PrunePending Timer (PT(S,G,I)) expires. Expiry of the Prune Timer (PT(S,G,I)) causes the interface to transition to the NoInfo (NI) state, thereby allowing data from S addressed to group G to be forwarded on the interface.
Here's the picture, it's giving diagram energy 🌈
+-------------+ +-------------+
| | PPT Expires | |
|PrunePending |----------------------->| Pruned |
| | | |
+-------------+ +-------------+
| ^ |
| | |
| |Rcv Prune |
| | |
| | +-------------+ |
| +---------| | |
| | NoInfo |<-------------+
+------------>| | Rcv Join/Graft OR
Rcv Join/Graft OR +-------------+ PT Expires OR
RPF_Interface(S)->I RPF_Interface(S)->I
Figure 2: Downstream Interface State MachineAnd here's the same thing as a table, for the visual learners 🍓
+-------------------------------+--------------------------------------+
| | Previous State |
+ +------------+------------+------------+
| Event | No Info | PrunePend | Pruned |
+-------------------------------+------------+------------+------------+
| Receive Prune(S,G) |->PP Set |->PP |->P Reset |
| | PPT(S,G,I) | | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| Receive Join(S,G) |->NI |->NI Cancel |->NI Cancel |
| | | PPT(S,G,I) | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| Receive Graft(S,G) |->NI Send |->NI Send |->NI Send |
| | GraftAck | GraftAck | GraftAck |
| | | Cancel | Cancel |
| | | PPT(S,G,I) | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| PPT(S,G) Expires | N/A |->P Set | N/A |
| | | PT(S,G,I) | |
+-------------------------------+------------+------------+------------+
| PT(S,G) Expires | N/A | N/A |->NI |
+-------------------------------+------------+------------+------------+
| RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel |
| | | PPT(S,G,I) | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| Send State Refresh(S,G) out I |->NI |->PP |->P Reset |
| | | | PT(S,G,I) |
+-------------------------------+------------+------------+------------+The transition events "Receive Graft(S,G)", "Receive Prune(S,G)", and "Receive Join(S,G)" are about receiving a Graft, Prune, or Join message where this router's address on I shows up in the message's upstream neighbor field 🧚 If the upstream neighbor field doesn't match this router's address on I, then these transitions must not occur in this state machine. Not me being picky, just how it works 🙈
4.4.2.1. Transitions from the NoInfo State
When the Prune(S,G) Downstream state machine is in the NoInfo (NI) state, the following events may trigger a transition 💜
Receive Prune(S,G) A Prune(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the PrunePending (PP) state. The PrunePending Timer (PPT(S,G,I)) MUST be set to J/P_Override_Interval if the router has more than one neighbor on I. If the router has only one neighbor on interface I, then it SHOULD set the PPT(S,G,I) to zero, effectively transitioning immediately to the Pruned (P) state.
Receive Graft(S,G) A Graft(S,G) is received on the interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I stays in the NoInfo (NI) state. A GraftAck(S,G) MUST be unicast to the originator of the Graft(S,G) message.
4.4.2.2. Transitions from the PrunePending (PP) State
When the Prune(S,G) downstream state machine is in the PrunePending (PP) state, the following events may trigger a transition 🫶
Receive Join(S,G) A Join(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
Receive Graft(S,G) A Graft(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state and MUST unicast a Graft Ack message to the Graft originator. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
PPT(S,G,I) Expires The PrunePending Timer (PPT(S,G,I)) expires, indicating that no neighbors have overridden the previous Prune(S,G) message. The Prune(S,G) Downstream state machine on interface I MUST transition to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and MUST be initialized to the received Prune_Hold_Time minus J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) message multicast by the upstream router to a LAN, with itself as the Upstream Neighbor. Its purpose is to add additional reliability so that if a Join that should have overridden the Prune is lost locally on the LAN, the PruneEcho(S,G) may be received and trigger a new Join message. A PruneEcho(S,G) is OPTIONAL on an interface with only one PIM neighbor. In addition, the router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
RPF_Interface(S) becomes interface I The upstream interface for S has changed. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
4.4.2.3. Transitions from the Prune (P) State
When the Prune(S,G) Downstream state machine is in the Pruned (P) state, the following events may trigger a transition ✨
Receive Prune(S,G) A Prune(S,G) is received on the interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I remains in the Pruned (P) state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime contained in the Prune(S,G) message if it is greater than the current value.
Receive Join(S,G) A Join(S,G) is received on the interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) downstream state machine on interface I MUST transition to the NoInfo (NI) state. The Prune Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
Receive Graft(S,G) A Graft(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state and send a Graft Ack back to the Graft's source. The Prune Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
PT(S,G,I) Expires The Prune Timer (PT(S,G,I)) expires, indicating that it is again time to flood data from S addressed to group G onto interface I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
RPF_Interface(S) becomes interface I The upstream interface for S has changed. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The PruneTimer (PT(S,G,I)) MUST be cancelled.
Send State Refresh(S,G) out interface I The router has refreshed the Prune(S,G) state on interface I. The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime from an active Prune received on interface I. The Holdtime used SHOULD be the largest active one but MAY be the most recently received active Prune Holdtime.
4.5. State Refresh
This section walks through the major bits of the state refresh mechanism 🌸
4.5.1. Forwarding of State Refresh Messages ✨
okay so when a State Refresh message (SRM 💌) shows up, it gets forwarded with this pseudo-code 💅
if (iif != RPF_interface(S))
return;
if (RPF'(S) != srcaddr(SRM))
return;
if (StateRefreshRateLimit(S,G) == TRUE)
return;
for each interface I in pim_nbrs {
if (TTL(SRM) == 0 OR (TTL(SRM) - 1) < Threshold(I))
continue; /* Out of TTL, skip this interface */
if (boundary(I,G))
continue; /* This interface is scope boundary, skip it */
if (I == iif)
continue; /* This is the incoming interface, skip it */
if (lost_assert(S,G,I) == TRUE)
continue; /* Let the Assert Winner do State Refresh */
Copy SRM to SRM'; /* Make a copy of SRM to forward */
if (I contained in prunes(S,G)) {
set Prune Indicator bit of SRM' to 1;
if StateRefreshCapable(I) == TRUE
set PT(S,G) to largest active holdtime read from a Prune
message accepted on I;
} else {
set Prune Indicator bit of SRM' to 0;
}
set srcaddr(SRM') to my_addr(I);
set TTL of SRM' to TTL(SRM) - 1;
set metric of SRM' to metric of unicast route used to reach S;
set pref of SRM' to preference of unicast route used to reach S;
set mask of SRM' to mask of route used to reach S;
if (AssertState == NoInfo) {
set Assert Override of SRM' to 1;
} else {
set Assert Override of SRM' to 0;
}
transmit SRM' on I;
}Next up, the little macros that the code above leans on 🧚 Here's the vibe for each one:
Boundary(I,G)is TRUE if an administratively scoped boundary for group G is configured on interface I. 🚧StateRefreshCapable(I)is TRUE if all neighbors on an interface use the State Refresh option. 🦋StateRefreshRateLimit(S,G)is TRUE if the time elapsed since the last received StateRefresh(S,G) is less than the configured RefreshLimitInterval. ⏱️TTL(SRM)returns the TTL contained in the State Refresh Message, SRM. Heads up, this is different from the TTL contained in the IP header! 🙈Threshold(I)returns the minimum TTL that a packet must have before it can be transmitted on interface I. 🌸srcaddr(SRM)returns the source address contained in the network protocol (e.g., IPv4) header of the State Refresh Message, SRM. 💜my_addr(I)returns this node's network (e.g., IPv4) address on interface I. 🫶
4.5.2. State Refresh Message Origination 🌈
This section is all about where State Refresh messages come from. They're generated periodically by the PIM-DM router that's directly connected to a source. There's exactly one Origination(S,G) state machine for each (S,G) entry in a PIM-DM router, so it's giving very "one per customer" energy 💅
The Origination(S,G) state machine has the following states:
- NotOriginator(NO): This is the starting state. While a router is here, it does NOT originate State Refresh messages for the (S,G) pair. 😴
- Originator(O): In this state, the router periodically originates State Refresh messages. Only routers directly connected to S may transition to this state. 👑
There are also two state-machine-specific timers, and they're the main characters of this whole thing 🎀
- State Refresh Timer (SRT(S,G)): This timer controls when State Refresh messages get generated. It gets set when the Origination(S,G) state machine moves into the O state, and it gets cancelled when the machine moves into the NO state. Normally it's set to StateRefreshInterval (see 4.8). ⏰
- Source Active Timer (SAT(S,G)): This one gets set first when the Origination(S,G) state machine moves into the O state, and it resets every time a data packet from S addressed to group G arrives. When it expires, the state machine transitions to the NO state. Normally it's set to SourceLifetime (see 4.8). 🥀
Here's the state diagram, bestie 🦋
+-------------+ Rcv Directly From S +-------------+
| |----------------------->| |
|NotOriginator| | Originator |
| |<-----------------------| |
+-------------+ SAT Expires OR +-------------+
S NOT Direct Connect
Figure 3: State Refresh State MachineAnd here's the same thing in table form, so you can check every single box 📋
+----------------------------------------------------------------------+
| | Previous State |
| +---------------+-------------------+
| Event | NotOriginator | Originator |
+----------------------------------+---------------+-------------------+
| Receive Data from S AND | ->O | ->O Reset |
| S directly connected | Set SRT(S,G) | SAT(S,G) |
| | Set SAT(S,G) | |
+----------------------------------+---------------+-------------------+
| SRT(S,G) Expires | N/A | ->O Send |
| | | StateRefresh(S,G) |
| | | Reset SRT(S,G) |
+----------------------------------+---------------+-------------------+
| SAT(S,G) Expires | N/A | ->NO Cancel |
| | | SRT(S,G) |
+----------------------------------+---------------+-------------------+
| S no longer directly connected | ->NO | ->NO |
| | | Cancel SRT(S,G) |
| | | Cancel SAT(S,G) |
+----------------------------------+---------------+-------------------+4.5.2.1. Transitions from the NotOriginator (NO) State 🌱
When the Originating(S,G) state machine is in the NotOriginator (NO) state, the following event may trigger a transition:
- Data Packet received from directly connected Source S addressed to group G: The router MUST transition to an Originator (O) state, set SAT(S,G) to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The router SHOULD record the TTL of the packet for use in State Refresh messages. 🚀
4.5.2.2. Transitions from the Originator (O) State 💫
When the Originating(S,G) state machine is in the Originator (O) state, the following events may trigger a transition:
- Receive Data Packet from S addressed to G: The router remains in the Originator (O) state and MUST reset SAT(S,G) to SourceLifetime. The router SHOULD increase its recorded TTL to match the TTL of the packet, if the packet's TTL is larger than the previously recorded TTL. A router MAY record the TTL based on an implementation specific sampling policy, so it doesn't have to examine the TTL of every multicast packet it handles. 👀
- SRT(S,G) Expires: The router remains in the Originator (O) state and MUST reset SRT(S,G) to StateRefreshInterval. The router MUST also generate State Refresh messages for transmission, following the State Refresh Forwarding rules (Section 4.5.1), except for the TTL. If the TTL of data packets from S to G are being recorded, then the TTL of each State Refresh message is set to the highest recorded TTL. Otherwise, the TTL is set to the configured State Refresh TTL. Let I denote the interface over which a State Refresh message is being sent. If the Prune(S,G) Downstream state machine is in the Pruned (P) state, then the Prune-Indicator bit MUST be set to 1 in the State Refresh message being sent over I. Otherwise, the Prune-Indicator bit MUST be set to 0. 📣
- SAT(S,G) Expires: The router MUST cancel the SRT(S,G) timer and transition to the NotOriginator (NO) state. 🫥
- S is no longer directly connected: The router MUST transition to the NotOriginator (NO) state and cancel both the SAT(S,G) and SRT(S,G). 👋
4.6. PIM Assert Messages 🎀
4.6.1. Assert Metrics 📏
Assert metrics are defined like this:
struct assert_metric {
metric_preference;
route_metric;
ip_address;
};When assert_metrics get compared, the metric_preference and route_metric fields are compared in order, where the first lower value wins. If all fields are equal, the IP address of the router that sourced the Assert message is used as a tie-breaker, with the highest IP address winning. 🏆
An Assert metric for (S,G) to include in (or compare against) an Assert message sent on interface I should be computed using the following pseudocode:
assert_metric
my_assert_metric(S,G,I) {
if (CouldAssert(S,G,I) == TRUE) {
return spt_assert_metric(S,G,I)
} else {
return infinite_assert_metric()
}
}spt_assert_metric(S,I) gives the Assert metric we use when we're sending 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_addr(I)}
}MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing metrics associated with the route to a particular (unicast) destination X, as determined by the MRIB. my_addr(I) is simply the router's network (e.g., IP) address associated with the local interface I. 🗺️
infinite_assert_metric() gives the Assert metric we need when we send an Assert but it doesn't match (S,G) forwarding state:
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,0}
}4.6.2. AssertCancel Messages 🛑
An AssertCancel(S,G) message is basically an Assert message for (S,G) with infinite metric. The Assert winner sends this message when it changes its upstream interface to this interface. Other routers will see this metric, which makes the ones with forwarding state send their own Asserts so they can re-establish an Assert winner. 🔁
AssertCancel messages are just an optimization, lowkey 🫶 The original Assert timeout mechanism will eventually let a subnet become consistent. The AssertCancel mechanism simply causes faster convergence. No special processing is required for an AssertCancel message, since it's simply an Assert message from the current winner. ⚡
4.6.3. Assert State Macros 🧩
The macro lost_assert(S,G,I) is used in the olist computations of Section 4.1.3, and it's defined like this:
bool lost_assert(S,G,I) {
if ( RPF_interface(S) == I ) {
return FALSE
} else {
return (AssertWinner(S,G,I) != me AND
(AssertWinnerMetric(S,G,I) is better than
spt_assert_metric(S,G,I)))
}
}AssertWinner(S,G,I) defaults to NULL, and AssertWinnerMetric(S,G,I) defaults to Infinity when in the NoInfo state. 💖
4.6.4. (S,G) Assert Message State Machine ✨
okay so the (S,G) Assert state machine for interface I is shown in Figure 4 🦋. there are three states, bestie 💅:
- NoInfo (NI): this router has no (S,G) Assert state on interface I. 🫥
- I am Assert Winner (W): this router has won an (S,G) Assert on interface I. it is now responsible for forwarding traffic from S destined for G via interface I. 👑
- I am Assert Loser (L): this router has lost an (S,G) Assert on interface I. it must not forward packets from S destined for G onto interface I. 💀
in addition, an Assert Timer (AT(S,G,I)) is used to time out the Assert state. ⏰
+-------------+ +-------------+
| | Rcv Pref Assert or SR | |
| Winner |----------------------->| Loser |
| | | |
+-------------+ +-------------+
^ | ^ |
| | Rcv Pref Assert or| |
| |AT Expires OR State Refresh| |
| |CouldAssert->FALSE | |
| | | |
| | +-------------+ | |
| +-------->| |----------+ |
| | No Info | |
+-------------| |<-------------+
Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR
OR Rcv Inferior Assert Rcv Inf SR from Winner OR
OR Rcv Inferior SR AT Expires OR
CouldAssert Changes OR
Winner's NLT Expires
Figure 4: Assert State Machinein tabular form, the state machine goes like this 📋:
+-------------------------------+--------------------------------------+
| | Previous State |
| +------------+------------+------------+
| Event | No Info | Winner | Loser |
+-------------------------------+------------+------------+------------+
| An (S,G) Data packet received | ->W Send | ->W Send | ->L |
| on downstream interface | Assert(S,G)| Assert(S,G)| |
| | Set | Set | |
| | AT(S,G,I) | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
| Receive Inferior (Assert OR | N/A | N/A |->NI Cancel |
| State Refresh) from Assert | | | AT(S,G,I) |
| Winner | | | |
+-------------------------------+--------------------------------------+
| Receive Inferior (Assert OR | ->W Send | ->W Send | ->L |
| State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| |
| Winner AND CouldAssert==TRUE | Set | Set | |
| | AT(S,G,I) | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
+-------------------------------+--------------------------------------+
| | Previous State |
| +------------+------------+------------+
| Event | No Info | Winner | Loser |
+-------------------------------+------------+------------+------------+
| Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set |
| State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) |
| | Set | Set | |
| | AT(S,G,I) | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
| Send State Refresh | ->NI | ->W Reset | N/A |
| | | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
| AT(S,G) Expires | N/A | ->NI | ->NI |
+-------------------------------+--------------------------------------+
| CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel |
| | | AT(S,G,I) | AT(S,G,I) |
+-------------------------------+--------------------------------------+
| CouldAssert -> TRUE | ->NI | N/A |->NI Cancel |
| | | | AT(S,G,I) |
+-------------------------------+--------------------------------------+
| Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel |
| | | | AT(S,G,I) |
+-------------------------------+--------------------------------------+
| Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send |
| or Graft(S,G) | | | Assert(S,G)|
+-------------------------------+--------------------------------------+Terminology: A "preferred assert" is one with a better metric than the current winner. An "inferior assert" is one with a worse metric than my_assert_metric(S,G,I). 🧠
the state machine uses this macro 🔧:
CouldAssert(S,G,I) = (RPF_interface(S) != I)4.6.4.1. Transitions from NoInfo State 🌸
in the NoInfo state, these events may trigger transitions:
- An (S,G) data packet arrives on downstream interface I
- An (S,G) data packet arrived on a downstream interface. It is optimistically assumed that this router will be the Assert winner for this (S,G). The Assert state machine MUST transition to the "I am Assert Winner" state, send an Assert(S,G) to interface I, store its own address and metric as the Assert Winner, and set the Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating the Assert negotiation for (S,G). 🚀
- Receive Inferior (Assert OR State Refresh) AND CouldAssert(S,G,I)==TRUE
- An Assert or State Refresh is received for (S,G) that is inferior to our own assert metric on interface I. The Assert state machine MUST transition to the "I am Assert Winner" state, send an Assert(S,G) to interface I, store its own address and metric as the Assert Winner, and set the Assert Timer (AT(S,G,I)) to Assert_Time. 💪
- Receive Preferred Assert or State Refresh
- The received Assert or State Refresh has a better metric than this router's, and therefore the Assert state machine MUST transition to the "I am Assert Loser" state and store the Assert Winner's address and metric. If the metric was received in an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was received in a State Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three times the received State Refresh Interval. If CouldAssert(S,G,I) == TRUE, the router MUST also multicast a Prune(S,G) to the Assert winner with a Prune Hold Time equal to the Assert Timer and evaluate any changes in its Upstream(S,G) state machine. 🙈
4.6.4.2. Transitions from Winner State 🏆
when in "I am Assert Winner" state, these events trigger transitions:
- An (S,G) data packet arrives on downstream interface I
- An (S,G) data packet arrived on a downstream interface. The Assert state machine remains in the "I am Assert Winner" state. The router MUST send an Assert(S,G) to interface I and set the Assert Timer (AT(S,G,I) to Assert_Time. ✨
- Receive Inferior Assert or State Refresh
- An (S,G) Assert is received containing a metric for S that is worse than this router's metric for S. Whoever sent the Assert is in error. The router MUST send an Assert(S,G) to interface I and reset the Assert Timer (AT(S,G,I)) to Assert_Time. 😤
- Receive Preferred Assert or State Refresh
- An (S,G) Assert or State Refresh is received that has a better metric than this router's metric for S on interface I. The Assert state machine MUST transition to "I am Assert Loser" state and store the new Assert Winner's address and metric. If the metric was received in an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was received in a State Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three times the State Refresh Interval. The router MUST also multicast a Prune(S,G) to the Assert winner, with a Prune Hold Time equal to the Assert Timer, and evaluate any changes in its Upstream(S,G) state machine. 🌈
- Send State Refresh
- The router is sending a State Refresh(S,G) message on interface I. The router MUST set the Assert Timer (AT(S,G,I)) to three times the State Refresh Interval contained in the State Refresh(S,G) message. 📣
- AT(S,G,I) Expires
- The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine MUST transition to the NoInfo (NI) state. ⌛
- CouldAssert(S,G,I) -> FALSE
- This router's RPF interface changed, making CouldAssert(S,G,I) false. This router can no longer perform the actions of the Assert winner, so the Assert state machine MUST transition to NoInfo (NI) state, send an AssertCancel(S,G) to interface I, cancel the Assert Timer (AT(S,G,I)), and remove itself as the Assert Winner. 🫧
4.6.4.3. Transitions from Loser State ✨
okay bestie, when we're in the "I am Assert Loser" state, a few transitions can happen 🦋
Receive Inferior Assert or State Refresh from Current Winner
An Assert or State Refresh shows up from the current Assert winner, but it's worse than this router's metric for S (usually the winner's metric got worse 😭). The Assert state machine MUST transition to NoInfo (NI) state and cancel AT(S,G,I). The router MUST delete the previous Assert Winner's address and metric, and evaluate any possible transitions to its Upstream(S,G) state machine. Usually this router will eventually re-assert and win once data packets from S start flowing again 💅
Receive Preferred Assert or State Refresh
An Assert or State Refresh comes in with a metric that's better than or equal to the current Assert winner's, and the Assert state machine stays in Loser (L) state 🌸 If the metric came in an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. If it came in a State Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three times the received State Refresh Interval. And if the metric is better than the current Assert Winner, the router MUST store the address and metric of the new Assert Winner. If CouldAssert(S,G,I) == TRUE, the router MUST multicast a Prune(S,G) to the new Assert winner 🔥
AT(S,G,I) Expires
The (S,G) Assert Timer (AT(S,G,I)) runs out of time ⏰ The Assert state machine MUST transition to NoInfo (NI) state. The router MUST delete the Assert Winner's address and metric. If CouldAssert == TRUE, the router MUST evaluate any possible transitions to its Upstream(S,G) state machine.
CouldAssert -> FALSE
CouldAssert has flipped to FALSE because interface I has become the RPF interface for S. The Assert state machine MUST transition to NoInfo (NI) state, cancel AT(S,G,I), and delete information concerning the Assert Winner on I 🙈
CouldAssert -> TRUE
CouldAssert has flipped to TRUE because interface I used to be the RPF interface for S, and now it isn't. The Assert state machine MUST transition to NoInfo (NI) state, cancel AT(S,G,I), and delete information concerning the Assert Winner on I 🧚
Current Assert Winner's NeighborLiveness Timer Expires
The current Assert winner's NeighborLiveness Timer (NLT(N,I)) has expired 💀 The Assert state machine MUST transition to the NoInfo (NI) state, delete the Assert Winner's address and metric, and evaluate any possible transitions to its Upstream(S,G) state machine.
Receive Prune(S,G), Join(S,G), or Graft(S,G)
A Prune(S,G), Join(S,G), or Graft(S,G) message arrived on interface I with its upstream neighbor address set to the router's address on I 👑 The router MUST send an Assert(S,G) on the receiving interface I to kick off an Assert negotiation. The Assert state machine stays in the Assert Loser (L) state. If a Graft(S,G) was received, the router MUST respond with a GraftAck(S,G) 🫶
4.6.5. Rationale for Assert Rules 🌈
Here's a quick summary of the rules for making and handling Assert messages. It's NOT meant to be the definitive version (the state machines and pseudocode are the real source of truth 💅). Instead, it gives you some rationale for the behavior.
- The Assert winner for (S,G) must act as the local forwarder for (S,G) on behalf of all downstream members.
- PIM messages are directed to the RPF' neighbor and not to the regular RPF neighbor.
- An Assert loser that receives a Prune(S,G), Join(S,G), or Graft(S,G) directed to it initiates a new Assert negotiation so that the downstream router can correct its RPF'(S).
- An Assert winner for (S,G) sends a cancelling assert when it is about to stop forwarding on an (S,G) entry. Example: If a router is being taken down, then a canceling assert is sent 🍓
4.7. PIM Packet Formats 🎀
All PIM-DM packets use the same format as PIM-SM packets. In the event of a discrepancy, PIM-SM [4] should be considered the definitive specification. All PIM control messages have IP protocol number 103. All PIM-DM messages MUST be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to the sender of the Graft.
The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS group is ff02::d.
4.7.1. PIM Header 💖
All PIM control messages have the following header:
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 is the PIM version number, which is 2.
Type tells you which PIM message this is. The available types are:
0 = Hello
1 = Register (PIM-SM only)
2 = Register Stop (PIM-SM only)
3 = Join/Prune
4 = Bootstrap (PIM-SM only)
5 = Assert
6 = Graft
7 = Graft Ack
8 = Candidate RP Advertisement (PIM-SM only)
9 = State RefreshReserved is set to zero on transmission and ignored upon receipt.
Checksum is the standard IP checksum, i.e., the 16 bit one's complement of the one's complement sum of the entire PIM message. For computing the checksum, the checksum field is zeroed 🧮
For IPv6, the checksum also includes the IPv6 "pseudo-header", as specified in RFC 2460, Section 8.1 [5].
4.7.2. Encoded Unicast Address 🦋
An Encoded Unicast Address has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Addr Family is the PIM Address Family of the 'Unicast Address' field of this address. Values 0 - 127 are as assigned by the IANA for Internet Address Families in [9]. Values 128 - 250 are reserved to be assigned by the IANA for PIM specific Address Families. Values 251 - 255 are designated for private use. As there is no assignment authority for this space, collisions should be expected 💥
Encoding Type is the type of encoding used with a specific Address Family. The value '0' is reserved for this field and represents the native encoding of the Address Family.
Unicast Address is the unicast address as represented by the given Address Family and Encoding Type.
4.7.3. Encoded Group Address 🌸
An Encoded Group address has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Addr Family is as described above.
Encoding Type is as described above.
B indicates that the group range should use Bidirectional PIM [16]. It's transmitted as zero and ignored upon receipt.
Reserved is transmitted as zero and ignored upon receipt.
Z indicates that the group range is an admin scope zone. This is used in the Bootstrap Router Mechanism [18] only. For all other purposes, this bit is set to zero and ignored on receipt.
Mask Len is 8 bits. The value is the number of contiguous left justified one bits used as a mask, which, combined with the address, describes a range of addresses. 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 address, then the mask length MUST equal the address length. PIM-DM routers MUST only send for a single address 🙌
Group Multicast Address is the address of the multicast group.
4.7.4. Encoded Source Address 🧚
An Encoded Source address has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Addr Family is as described above.
Encoding Type is as described above.
Rsrvd is reserved, transmitted as zero, and ignored upon receipt.
S is the Sparse Bit. It's set to 0 for PIM-DM and ignored upon receipt.
W is the Wild Card Bit. It's set to 0 for PIM-DM and ignored upon receipt.
R is the Rendezvous Point Tree bit. It's set to 0 for PIM-DM and ignored upon receipt.
Mask Len is as described above. PIM-DM routers MUST only send for a single source address.
Source Address is the source address.
4.7.5. Hello Message Format 🍓
The PIM Hello message, as defined by PIM-SM [4], has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Ver, Type, Reserved, and Checksum are described above.
Option Type is the type of option given in the Option Value field. The available types are:
0 Reserved
1 Hello Hold Time
2 LAN Prune Delay
3 - 16 Reserved
17 To be assigned by IANA
18 Deprecated and SHOULD NOT be used
19 DR Priority (PIM-SM Only)
20 Generation ID
21 State Refresh Capable
22 Bidir Capable
23 - 65000 To be assigned by IANA
65001 - 65535 Reserved for Private Use [9]Unknown options SHOULD be ignored 🌈
4.7.5.1. Hello Hold Time Option 🦋
okay so the Hello Hold Time option is Type 1 with a Length of 2, and it carries the Hold Time 💖 The Hold Time is how many seconds a receiver MUST keep the neighbor reachable. If it's set to '0xffff', the receiver never times the neighbor out 🫶 This is lowkey useful for dial-on-demand links, since you don't have to keep the link up just to send periodic Hello messages 🌸 And if the Holdtime is '0', the info gets timed out immediately, no cap 💀 The Hello Hold Time option MUST be used by PIM-DM routers ✨
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.7.5.2. LAN Prune Delay Option 🧚
the LAN_Prune_Delay option is what tunes how long a prune takes to propagate on multi-access LANs 💅 Type 2, Length 4, and it's got a T bit plus the LAN Delay and Override Interval fields 🍓 The T bit is used by PIM-SM and SHOULD be set to 0 by PIM-DM routers, and it gets ignored when received 🙈 The LAN Delay and Override Interval are time intervals in milliseconds, and they're what tune the J/P Override Interval and its derived timers. Section 4.3.5 explains how those values change what a router does 👑 The LAN Prune Delay SHOULD be used by PIM-DM routers 🌈
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| LAN Prune Delay | Override Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.7.5.3. Generation ID Option ✨
the Generation ID is a random value for the interface the Hello message goes out on 🎀 It gets regenerated whenever PIM forwarding is started or restarted on that interface, so it's like a fresh little identity each time 🦋 Type 20, Length 4. The Generation ID option MAY be used by PIM-DM routers 💜
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.7.5.4. State Refresh Capable Option 🌸
Type 21, Length 4, and it's got a Version field set to 1, an Interval field, and a Reserved field 🫶 The Interval field is the router's configured State Refresh Interval in seconds ⭐ Reserved is set to zero and ignored on receipt. The State Refresh Capable option MUST be used by State Refresh capable PIM-DM routers 👑
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 = 21 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 | Interval | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.7.6. Join/Prune Message Format 💅
okay this one's a big deal 🔥 PIM Join/Prune messages, as defined in PIM-SM [4], look like this:
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 | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Ver, Type, Reserved, Checksum Described above.
Upstream Neighbor Address The address of the upstream neighbor. The format for this address is given in the Encoded Unicast address in Section 4.7.2. PIM-DM routers MUST set this field to the RPF next hop 🧚
Reserved Transmitted as zero. Ignored upon receipt.
Hold Time The number of seconds a receiving PIM-DM router MUST keep a Prune state alive, unless it's removed by a Join or Graft message. If the Hold Time is '0xffff', the receiver MUST NOT remove the Prune state unless a corresponding Join or Graft message is received. The Hold Time is ignored in Join messages 🙈
Number of Groups Number of multicast group sets contained in the message.
Multicast Group Address The multicast group address in the Encoded Multicast address format given in Section 4.7.3.
Number of Joined Sources Number of Join source addresses listed for a given group.
Number of Pruned Sources Number of Prune source addresses listed for a given group.
Join Source Address 1..n This list contains the sources from which the sending router wishes to continue to receive multicast messages for the given group on this interface. The addresses use the Encoded Source address format given in Section 4.7.4. 💖
Prune Source Address 1..n This list contains the sources from which the sending router does not wish to receive multicast messages for the given group on this interface. The addresses use the Encoded Source address format given in Section 4.7.4. 🌸
4.7.7. Assert Message Format 🎀
PIM Assert Messages, as defined in PIM-SM [4], have the following format 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address (Encoded Group Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Ver, Type, Reserved, Checksum Described above.
Multicast Group Address The multicast group address in the Encoded Multicast address format given in Section 4.7.3.
Source Address The source address in the Encoded Unicast address format given in Section 4.7.2.
R The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt. 🙈
Metric Preference The preference value assigned to the unicast routing protocol that provided the route to the source.
Metric The cost metric of the unicast route to the source. The metric is in units applicable to the unicast routing protocol used.
4.7.8. Graft Message Format 🧚
PIM Graft messages use the same format as Join/Prune messages, except that the Type field is set to 6. The source address MUST be in the Join section of the message. The Hold Time field SHOULD be zero and SHOULD be ignored when a Graft is received 💅
4.7.9. Graft Ack Message Format 🌈
PIM Graft Ack messages are identical in format to the received Graft message, except that the Type field is set to 7. The Upstream Neighbor Address field SHOULD be set to the sender of the Graft message and SHOULD be ignored upon receipt 🫶
4.7.10. State Refresh Message Format ✨
okay so here's the State Refresh message layout 🎀 PIM State Refresh Messages look like this:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address (Encoded Group Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Masklen | TTL |P|N|O|Reserved | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Let's break down every field 💅
PIM Ver,Type,Reserved,Checksum: these are described above 🦋 so no need to rehash!Multicast Group Address: the multicast group address in the Encoded Multicast address format given in Section 4.7.3.Source Address: the address of the data source in the Encoded Unicast address format given in Section 4.7.2.Originator Address: the address of the first hop router in the Encoded Unicast address format given in Section 4.7.2.R: the Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt.Metric Preference: the preference value assigned to the unicast routing protocol that provided the route to the source.Metric: the cost metric of the unicast route to the source. The metric is in units applicable to the unicast routing protocol used.Masklen: the length of the address mask of the unicast route to the source.TTL: the Time To Live of the State Refresh message. It gets decremented each time the message is forwarded. Note that this is different from the IP Header TTL, which is always set to 1 🙈P: the Prune indicator flag. This MUST be set to 1 if the State Refresh is to be sent on a Pruned interface. Otherwise, it MUST be set to 0.N: the Prune Now flag. This SHOULD be set to 1 by the State Refresh originator on every third State Refresh message and SHOULD be ignored upon receipt. This is for compatibility with earlier versions of state refresh 🍓O: the Assert Override flag. This SHOULD be set to 1 by upstream routers on a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be ignored upon receipt. This is for compatibility with earlier versions of state refresh 🌸Reserved: set to zero and ignored upon receipt.Interval: set by the originating router to the interval (in seconds) between consecutive State Refresh messages for this (S,G) pair.
4.8. PIM-DM Timers ⏰
okay so PIM-DM keeps track of a bunch of timers 💜 They're all countdown timers, which means they get set to a value and count down to zero, and when they hit zero they usually trigger an action. You could absolutely implement them as count-up timers instead, where you store the absolute expiry time and compare it against a real-time clock, but this spec just assumes they count downward toward zero. ✨
Here's the full timer tree 🌈
Global Timers
Hello Timer: HT
Per interface (I):
Per neighbor (N):
Neighbor Liveness Timer: NLT(N,I)
Per (S,G) Pair:
(S,G) Assert Timer: AT(S,G,I)
(S,G) Prune Timer: PT(S,G,I)
(S,G) PrunePending Timer: PPT(S,G,I)
Per (S,G) Pair:
(S,G) Graft Retry Timer: GRT(S,G)
(S,G) Upstream Override Timer: OT(S,G)
(S,G) Prune Limit Timer: PLT(S,G)
(S,G) Source Active Timer: SAT(S,G)
(S,G) State Refresh Timer: SRT(S,G)When timer values get started or restarted, they're set to default values 🎀 The tables below sum up those defaults.
Timer Name: Hello Timer (HT)
+----------------------+--------+--------------------------------------+
| Value Name | Value | Explanation |
+----------------------+--------+--------------------------------------+
|Hello_Period | 30 sec | Periodic interval for hello messages |
+----------------------+--------+--------------------------------------+
|Triggered_Hello_Delay | 5 sec | Random interval for initial Hello |
| | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor |
+----------------------+--------+--------------------------------------+Hello messages go out on every active interface once every Hello_Period seconds 💖 At system power-up, the timer is initialized to rand(0,Triggered_Hello_Delay) so things don't synchronize. 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 |
+-------------------+-----------------+--------------------------------+
| Hello Holdtime | From message | Hold Time from Hello Message |
+-------------------+-----------------+--------------------------------+Timer Name: PrunePending Timer (PPT(S,G,I))
+-----------------------+---------------+------------------------------+
| Value Name | Value | Explanation |
+-----------------------+---------------+------------------------------+
| J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to |
| | | allow other routers on the |
| | | LAN to send a Join |
+-----------------------+---------------+------------------------------+The J/P_Override_Interval is the sum of the interface's Override_Interval (OI(I)) and Propagation_Delay (PD(I)) 🦋 If all routers on a LAN are using the LAN Prune Delay option, both parameters MUST be set to the largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST be set to 2.5 seconds, and the Propagation_Delay (PD(I)) MUST be set to 0.5 seconds.
Timer Name: Prune Timer (PT(S,G,I))
+----------------+----------------+------------------------------------+
| Value Name | Value | Explanation |
+----------------+----------------+------------------------------------+
| Prune Holdtime | From message | Hold Time read from Prune Message |
+----------------+----------------+------------------------------------+Timer Name: Assert Timer (AT(S,G,I))
+--------------------------+---------+---------------------------------+
| Value Name | Value | Explanation |
+--------------------------+---------+---------------------------------+
| Assert Time | 180 sec | Period after last assert before |
| | | assert state is timed out |
+--------------------------+---------+---------------------------------+Here's some tea ☕ For historical reasons, the Assert message lacks a Holdtime field. Thus, changing the Assert Time from the default value is not recommended. If all members of a LAN are state refresh enabled, the Assert Time will be three times the received RefreshInterval(S,G) 😭
Timer Name: Graft Retry Timer (GRT(S,G))
+--------------------+-------+-----------------------------------------+
| Value Name | Value | Explanation |
+--------------------+-------+-----------------------------------------+
| Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck |
| | | message, the time before retransmission |
| | | of a Graft message |
+--------------------+-------+-----------------------------------------+Timer Name: Upstream Override Timer (OT(S,G))
+------------+----------------+----------------------------------------+
| Value Name | Value | Explanation |
+------------+----------------+----------------------------------------|
| t_override | rand(0, OI(I)) | Randomized delay to prevent response |
| | | implosion when sending a join message |
| | | to override someone else's prune |
+------------+----------------+----------------------------------------+t_override is a random value between 0 and the interface's Override_Interval (OI(I)) 🧚 If all routers on a LAN are using the LAN Prune Delay option, the Override_Interval (OI(I)) MUST be set to the largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST be set to 2.5 seconds.
Timer Name: Prune Limit Timer (PLT(S,G))
+------------+--------------------+------------------------------------+
| Value Name | Value | Explanation |
+------------+--------------------+------------------------------------|
| t_limit | Default: 210 secs | Used to prevent Prune storms on a |
| | | LAN |
+------------+--------------------+------------------------------------+Timer Name: Source Active Timer (SAT(S,G))
+----------------+-------------------+---------------------------------+
| Value Name | Value | Explanation |
+----------------+-------------------+---------------------------------+
| SourceLifetime | Default: 210 secs | Period of time after receiving |
| | | a multicast message a directly |
| | | attached router will continue |
| | | to send State Refresh messages |
+----------------+-------------------+---------------------------------+Timer Name: State Refresh Timer (SRT(S,G))
+-----------------+------------------+---------------------------------+
| Value Name | Value | Explanation |
+-----------------+------------------+---------------------------------+
| RefreshInterval | Default: 60 secs | Interval between successive |
| | | state refresh messages |
+-----------------+------------------+---------------------------------+5. Protocol Interaction Considerations 🌈
okay so PIM-DM is built to be independent of the underlying unicast routing protocols 💅 It only interacts with them to the extent needed to do RPF checks. It's generally assumed that multicast area and autonomous system boundaries line up with the same boundaries for unicast routing, though a deployment that doesn't follow this assumption isn't ruled out by this specification 🦋
In general, PIM-DM interactions with other multicast routing protocols should be in compliance with RFC 2715 [7]. Other specific interactions are noted below ✨
5.1. PIM-SM Interactions 🦋
okay so PIM-DM is not supposed to interact directly with PIM-SM 🙈, even though they totally share the same packet format. the important tea is that a router literally can't tell a PIM-DM neighbor from a PIM-SM neighbor just by looking at Hello messages. the vibes are identical 💀
if a PIM-DM router becomes a neighbor of a PIM-SM router, they basically form a simplex link 🎀. the PIM-DM router sends all its multicast messages to the PIM-SM router, but the PIM-SM router sends zero multicast messages back. one-way street bestie 🚦
the common packet format would also allow a hybrid PIM-SM/DM implementation that uses PIM-SM when a rendezvous point is known and PIM-DM when one is not 🧚. that kind of hybrid is outside the scope of this document, so we're not going there today 💅
5.2. IGMP Interactions 💜
PIM-DM will forward received multicast data packets to neighboring host group members in all cases, except when the PIM-DM router is in an Assert Loser state on that interface ✨. also, a PIM Prune message is not permitted to stop delivery of messages to a network with group members. no prune can block the group members, periodt 🙅♀️
A PIM-DM Router MAY use the DR Priority option described in PIM-SM [14] to elect an IGMP v1 querier 🌸.
5.3. Source Specific Multicast (SSM) Interactions 🌷
PIM-DM makes no special considerations for SSM [15]. like, all Prunes and Grafts inside the protocol are for a specific source, so no extra checks have to be made. easy breezy, lemon squeezy 🍋
5.4. Multicast Group Scope Boundary Interactions 🍓
okay, multicast group scope boundaries are usually the same as routing area boundaries, but it's totally conceivable that a routing area might get partitioned for one particular multicast group 🧩. in that case, PIM-DM routers MUST NOT send any messages about that group across that group's scope boundary. hard boundary, no exceptions 🚧
6. IANA Considerations 🌈
6.1. PIM Address Family 🧁
the PIM Address Family field was made 8 bits as a tradeoff between the packet format and using the IANA assigned numbers 🎀. when PIM packets were designed, only 15 values were assigned for Address Families, and nobody was picturing a huge pile of new ones. 8 bits seemed like plenty at the time 🙈. but the IANA assigns Address Families as a 16 bit value, so the PIM Address Family is allocated like this:
Values 0 - 127 are designated to have the same meaning as IANA assigned Address Family Numbers [9].
Values 128 - 250 are designated to be assigned by the IANA based on IESG approval, as defined in [8].
Values 251 - 255 are designated for Private Use, as defined in [8].
6.2. PIM Hello Options 🦋
Values 17 - 65000 are to be assigned by the IANA. the space is huge, so they can be assigned on a First Come First Served basis, as defined in [8] 🏃♀️. assignments are valid for one year and can be renewed. permanent assignments require a specification, as defined in [8] 📜.
7. Security Considerations 🔐
okay this section is serious, bestie, so pay attention 😭🔥
The IPsec authentication header [10] 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. in any case, a PIM router SHOULD NOT accept and process PIM messages from neighbors unless a valid Hello message has been received from that neighbor. no hello, no entry 🚪
note that PIM-DM has no rendezvous point, and therefore no single point of failure that could be vulnerable 🌈. but because PIM-DM uses unicast routes provided by an unknown routing protocol, it may suffer collateral effects if that unicast routing protocol gets attacked 😱.
7.1. Attacks Based on Forged Messages 💀
the damage depends on what kind of counterfeit messages get accepted, so let's look at the forgeries. a forged PIM-DM message is link local and can only reach a LAN if it was sent by a local host or if it was let onto the LAN by a compromised or non-compliant router 🕵️♀️.
- a forged Hello message can make multicast traffic get delivered to links with no legitimate requestors, which can waste bandwidth on that link 🗑️. on a multi-access LAN the effects are limited without the ability to forge a Join message, because other routers will Prune the link if the traffic isn't wanted 🙅♀️.
- a forged Join/Prune message can make multicast traffic get delivered to links with no legitimate requestors, which can waste bandwidth on that link. a forged Prune on a multi-access LAN is generally not a significant attack in PIM, because any legitimately joined router on the LAN would override the Prune with a Join before the upstream router stops forwarding data to the LAN 🙌.
- a forged Graft message can make multicast traffic get delivered to links with no legitimate requestors, which can waste bandwidth on that link. in principle, Graft messages could be sent multiple hops because they are unicast to the upstream router. this should not be a problem, since the remote forger should have no way to get a Hello message to the target of the attack. without a valid Hello message, the receiving router SHOULD NOT accept the Graft 🙈.
- a forged GraftAck message has no impact, since it gets ignored unless the router has recently sent a Graft to its upstream router 🤷♀️.
- by forging an Assert message on a multi-access LAN, an attacker could make the legitimate forwarder stop forwarding traffic to the LAN. that kind of forgery would stop any hosts downstream of that LAN from receiving traffic 😭.
- a forged State Refresh message on a multi-access LAN would have the same impact as a forged Assert message, since they have the same general functions. plus, forged State Refresh messages would get propagated downstream and might be used in a denial of service attack 💥. so a PIM-DM router SHOULD rate limit State Refresh messages propagated 🚦.
7.2. Non-cryptographic Authentication Mechanisms 🔑
a PIM-DM router SHOULD provide an option to limit the set of neighbors it will accept PIM-DM messages from 🧐. you can do this with static configuration of IP addresses or with an IPSec security association. all options that restrict the range of addresses packets are accepted from MUST default to allowing all packets, so nothing gets blocked by accident 🌸.
furthermore, a PIM router SHOULD NOT accept protocol messages from a router it has not yet received a valid Hello message from 🫶.
7.3. Authentication Using IPsec 🧚
the IPSec [10] transport mode using the Authentication Header (AH) is the recommended method to prevent the above attacks in PIM 💜. the specific AH authentication algorithm and parameters, including the choice of authentication algorithm and the choice of key, are configured by the network administrator 🧑💼. the Encapsulating Security Payload (ESP) MAY also be used to provide both encryption and authentication of PIM protocol messages ✨. when IPsec authentication is used, a PIM router SHOULD reject (drop without processing) any unauthorized PIM protocol messages 🗑️.
to use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices. senders use these to authenticate PIM protocol messages, and receivers use them to authenticate received PIM protocol messages 🔐. this document does not describe protocols for establishing Security Associations. it assumes manual configuration of Security Associations is performed, but it does not rule out some future negotiation protocol such as GDOI [17] being used to establish them 🌟.
the network administrator defines a Security Association (SA) and Security Parameters Index (SPI) to be used to authenticate all PIM-DM protocol messages from each router on each link in a PIM-DM domain 🗺️.
to avoid the problem of allocating individual keys for each neighbor on a link to each individual router, it is acceptable to establish only one authentication key for all PIM-DM routers on a link 🔑. this won't specifically authenticate the individual router sending the message, but it will make sure the sender is a PIM-DM router on that link. if this method is used, the receiver of the message MUST ignore the received sequence number, which disables anti-replay mechanisms 😬. the effects of disabling anti-replay mechanisms are basically the same as the effects of forged messages, described in Section 7.1, with the extra protection that the forger can only reuse legitimate messages 🙃.
the Security Policy Database at a PIM-DM router should be configured so that all incoming and outgoing PIM-DM packets use the SA associated with the interface the packet is sent on 🗂️. note that, according to [10], there is nominally a different Security Association Database (SAD) for each router interface. so the selected Security Association for an inbound PIM-DM packet can vary depending on the interface it arrived on. this lets the network administrator use different authentication methods for each link, even though the destination address is the same for most PIM-DM packets, no matter the interface 🎀.
7.4. Denial of Service Attacks 💥
there are a bunch of possible denial of service attacks against PIM, caused by generating false PIM protocol messages or even by generating false data traffic 😤. authenticating PIM protocol traffic stops some of these attacks, but not all of them. the possible attacks include the following:
- sending packets to many different group addresses quickly can be a denial of service attack all on its own 🌪️. these messages get flooded throughout the network before they are pruned back, and the maintenance of state machines and State Refresh messages will be a constant drain on network resources 📉.
- forged State Refresh messages sent quickly could be propagated by downstream routers, creating a potential denial of service attack. so a PIM-DM router SHOULD limit the rate of State Refresh messages propagated 🚦.
8. Acknowledgments 🫶
the major features of PIM-DM were originally designed by Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, David Meyer, and Liming Wei 👑. additional features for state refresh were designed by Dino Farinacci, Isidor Kouvelas, and Kurt Windisch 🌟. this revision was undertaken to incorporate some of the lessons learned during the evolution of the PIM-SM specification and early deployments of PIM-DM 🧠.
Thanks the PIM Working Group for their comments 💖.
9. References 📚
9.1. Normative References 📚✨
Okay bestie, these are the must-reads. This spec leans on all of these, so you need them to get the full picture 🤓
- [1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
- [2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
- [3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
- [4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
- [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
- [7] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
- [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [9] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html. - [10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 💡
These ones are extra juicy background reading. Not required, but so good if you want the backstory 🧚
- [12] Deering, S.E., "Multicast Routing in a Datagram Internetwork", Ph.D. Thesis, Electrical Engineering Dept., Stanford University, December 1991.
- [13] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
- [14] Fenner, W., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work in Progress.
- [15] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress.
- [16] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-directional Protocol Independent Multicast", Work in Progress.
- [17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
- [18] Fenner, W., Handley, M., Kermode, R., and D. Thaler, "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress.
Authors' Addresses 💌
The people who made this happen, and where to find them 🫶
Andrew Adams
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108-2738
EMail: ala@nexthop.com
Jonathan Nicholas
ITT Industries
Aerospace/Communications Division
100 Kingsland Rd
Clifton, NJ 07014
EMail: jonathan.nicholas@itt.com
William Siadak
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108-2738
EMail: wfs@nexthop.comFull Copyright Statement ©
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
Heads up: this part is about who owns what, so read it carefully 👀
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the IETF's procedures for rights in IETF Documents is in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use these proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3973 2005-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms