RFC 5015
Bidirectional Protocol Independent Multicast (BIDIR-PIM)
Bidirectional Protocol Independent Multicast (BIDIR-PIM) 🦋
Okay bestie, this is RFC 5015 💖 Here's the title block, all in one spot ✨
RFC number: 5015 🎀 Title: Bidirectional Protocol Independent Multicast (BIDIR-PIM) Network Working Group, dated October 2007 📅 Category: Standards Track ⭐, so it's a real protocol spec Authors: M. Handley (UCL) 🌈, I. Kouvelas (Cisco) 💅, T. Speakman (Cisco) 🫶, and L. Vicisano (Digital Fountain) 👑 Obsoletes and updates: the header doesn't list anything it obsoletes or updates 🙈
Status of This Memo ✨
This one is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 🌸 If you want the current standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Also, distribution of this memo is unlimited, so share away 💜
Abstract 🌸
Okay, so the big idea here is Bidirectional PIM (BIDIR-PIM) 🦋 It's a variant of PIM Sparse-Mode that builds bidirectional shared trees, which connect multicast sources and receivers ✨
The trees get built with a fail-safe Designated Forwarder (DF) election mechanism 🔥 That election runs on every link in a multicast topology. With the DF's help, multicast data gets natively forwarded from sources to the Rendezvous-Point (RP), and then along the shared tree to receivers 🧚 No source-specific state needed, which is so clean 💅
The DF election happens at RP discovery time and also provides the route to the RP 🫶 Which means there's no need for data-driven protocol events, and that's iconic ✨
Table of Contents 📚
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Definitions ................................................4
2.2. Pseudocode Notation ........................................6
3. Protocol Specification ..........................................6
3.1. BIDIR-PIM Protocol State ...................................7
3.1.1. General Purpose State ...............................8
3.1.2. RPA State ...........................................8
3.1.3. Group State .........................................9
3.1.4. State Summarization Macros .........................10
3.2. PIM Neighbor Discovery ....................................11
3.3. Data Packet Forwarding Rules ..............................11
3.3.1. Upstream Forwarding at RP ..........................12
3.3.2. Source-Only Branches ...............................12
3.3.3. Directly Connected Sources .........................13
3.4. PIM Join/Prune Messages ...................................13
3.4.1. Receiving (*,G) Join/Prune Messages ................13
3.4.2. Sending Join/Prune Messages ........................16
3.5. Designated Forwarder (DF) Election ........................18
3.5.1. DF Requirements ....................................18
3.5.2. DF Election Description ............................19
3.5.2.1. Bootstrap Election ........................20
3.5.2.2. Loser Metric Changes ......................20
3.5.2.3. Winner Metric Changes .....................21
3.5.2.4. Winner Loses Path .........................22
3.5.2.5. Late Router Starting Up ...................22
3.5.2.6. Winner Dies ...............................22
3.5.3. Election Protocol Specification ....................22
3.5.3.1. Election State ............................22
3.5.3.2. Election Messages .........................23
3.5.3.3. Election Events ...........................24
3.5.3.4. Election Actions ..........................25
3.5.3.5. Election State Transitions ................26
3.5.4. Election Reliability Enhancements ..................30
3.5.5. Missing Pass .......................................30
3.5.6. Periodic Winner Announcement .......................30
3.6. Timers, Counters, and Constants ...........................31
3.7. BIDIR-PIM Packet Formats ..................................34
3.7.1. DF Election Packet Formats .........................34
3.7.2. Backoff Message ....................................36
3.7.3. Pass Message .......................................36
3.7.4. Bidirectional Capable PIM-Hello Option .............37
4. RP Discovery ...................................................37
5. Security Considerations ........................................38
5.1. Attacks Based on Forged Messages ..........................38
5.1.1. Election of an Incorrect DF ........................38
5.1.2. Preventing Election Convergence ....................39
5.2. Non-Cryptographic Authentication Mechanisms ...............39
5.2.1. Basic Access Control ...............................39
5.3. Authentication Using IPsec ................................40
5.4. Denial-of-Service Attacks .................................40
6. IANA Considerations ............................................40
7. Acknowledgments ................................................40
8. Normative References ...........................................40
9. Informative References .........................................41
List of Figures
Figure 1. Downstream group per-interface state machine ............15
Figure 2. Upstream group state machine ............................17
Figure 3. Designated Forwarder election state machine .............271. Introduction 🍓
Alright, so this doc specifies Bidirectional PIM (BIDIR-PIM) 💖 It's a variant of PIM Sparse-Mode (PIM-SM) [4], and what it does is build bidirectional shared trees that connect multicast sources and receivers ✨
PIM-SM builds unidirectional shared trees to forward data from senders to receivers of a multicast group 🧚 It can also build source-specific trees, but that's a separate thing and not what this document is about 🙈
Each multicast group gets a shared tree rooted at a multicast router called the Rendezvous Point (RP) 🌈 And different groups can use different RPs inside the same PIM domain, which is lowkey so flexible 💅
Okay, so in unidirectional PIM-SM there are two ways data packets get distributed on the shared tree 🔥 They differ in how packets travel from a source to the RP:
- First, when a source starts transmitting, its first hop router wraps the data packets up in special control messages called Registers, which get unicast to the RP. Once they reach the RP, the packets get unwrapped and distributed on the shared tree 🫶
- Later on, the distribution can switch away from that first method. That happens by building source-specific state on all routers along the path between the source and the RP. That state then gets used to natively forward packets from that source 👑
Both of these have problems, ngl 😭 The wrapping step adds a lot of processing, bandwidth, and delay overhead. Forwarding with source-specific state needs extra protocol and memory resources 💀
Bidirectional PIM skips both the wrapping and the source state 🦋 Instead, packets get natively forwarded from a source to the RP using shared tree state. Unlike PIM-SM, this forwarding mode doesn't need any data-driven events, so it's giving efficiency ✨
Heads up: the protocol spec in this document assumes you already know the PIM-SM spec in [4] 📚 Any parts of BIDIR-PIM that work exactly like PIM-SM are only defined by reference, so go read [4] first, bestie 🫶
2. Terminology 💜
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] 🎀 They indicate the requirement levels for compliant BIDIR-PIM implementations, so these words are the ones that really matter 💅
2.1. Definitions ✨
okay so this section is the glossary bestie, and it's giving "learn the vocab before the group project" energy 📚 BIDIR-PIM has its own roles for routers, so these terms matter a lot.
Multicast Routing Information Base (MRIB) The multicast topology table. It's usually derived from the unicast routing table, or from routing protocols like Multiprotocol BGP (MBGP) [8] that carry multicast-specific topology info. PIM uses it to set the RPF interface (used in the forwarding rules). In PIM-SM, the MRIB also decides where Join/Prune messages get forwarded, but in BIDIR-PIM it's a source for routing metrics for the DF election process 🗺️
Rendezvous Point Address (RPA) An RPA is an address used as the root of the distribution tree for a range of multicast groups. The RPA must be routable from all routers in the PIM domain. It does NOT need to match an interface address on a real router, and this is where BIDIR-PIM is different from PIM-SM, which needs an actual router configured as the Rendezvous Point (RP). Join messages from receivers for a BIDIR-PIM group propagate hop-by-hop toward the RPA 🎀
Rendezvous Point Link (RPL) The RPL for a particular RPA is the physical link that the RPA belongs to. In BIDIR-PIM, all multicast traffic for groups mapping to a specific RPA gets forwarded on that RPA's RPL. The RPL is special inside a BIDIR-PIM domain because it's the only link where a Designated Forwarder election does NOT happen (see the DF definition below) 🦋
Upstream Toward the root (RPA) of the tree. It's the direction packets travel from sources to the RPL 🌱
Downstream Away from the root of the tree. It's the direction packets travel from the RPL to receivers 🌊
Designated Forwarder (DF) This protocol is basically built around the concept of a Designated Forwarder (DF) 💅 There's a single DF for each RPA on every link in a BIDIR-PIM domain (both multi-access and point-to-point links). The one exception is the RPL, which has no DF. The DF is the router on the link with the best route to the RPA, figured out by comparing MRIB-provided metrics. For a given RPA, the DF is in charge of forwarding downstream traffic onto its link, and forwarding upstream traffic from its link toward the RPL. It does this for ALL the bidirectional groups that map to that RPA. The DF on a link also handles Join messages from downstream routers on the link, and makes sure packets get forwarded to local receivers (found through a local membership mechanism like MLD [3] or IGMP [2]) 👑
RPF Interface RPF stands for "Reverse Path Forwarding" 🔁 A router's RPF Interface for an address is the interface that the MRIB says should be used to reach that address. For a BIDIR-PIM multicast group, the RPF interface is found by looking up the RPA in the MRIB. The RPF info decides which interface the router would use to send packets toward the RPL for the group 🧭
RPF Neighbor The RPF Neighbor of a router for an address is the neighbor the MRIB says should be used to reach that address. Heads up: in BIDIR-PIM, the RPF neighbor for a group is NOT necessarily the router on the RPF interface that Join messages for that group would go to. Join messages only get directed to the DF on the RPF interface for the group 🙈
Tree Information Base (TIB) This is the collection of state at a PIM router, built from receiving PIM Join/Prune messages, PIM DF election messages, and IGMP or MLD info from local hosts. Basically, it stores the state of ALL the multicast distribution trees at that router 🌳
Multicast Forwarding Information Base (MFIB) The TIB holds all the state needed to forward multicast packets at a router. Still, although this spec defines forwarding in terms of the TIB, actually forwarding packets straight off the TIB is super inefficient 😭 So a real router implementation will normally build an efficient MFIB from the TIB state to do the forwarding. How that's done is implementation-specific and isn't covered in this document ⚡
2.2. Pseudocode Notation
we use set notation in a few places in this spec, plus some C-like syntax. here's the whole cheat sheet 🧁
A (+) B
is the union of two sets, A and B.
A (-) B is the elements of set A that are not in set B.
NULL
is the empty set or list.
= denotes assignment of a variable.
== denotes a comparison for equality.
!= denotes a comparison for inequality.
Braces { and } are used for grouping.3. Protocol Specification ✨
the BIDIR-PIM spec is split into several parts, so here's the map 🗺️
- Section 3.1 details the protocol state stored.
- Section 3.2 defines the BIDIR-PIM extensions to the PIM-SM [4] neighbor discovery mechanism.
- Section 3.3 specifies the data packet forwarding rules.
- Section 3.4 specifies the BIDIR-PIM Join/Prune generation and processing rules.
- Section 3.5 specifies the Designated Forwarder (DF) election.
- Section 3.7 specifies the PIM packet formats.
- Section 3.6 summarizes BIDIR-PIM timers and gives their default values.
3.1. BIDIR-PIM Protocol State 💖
this section lays out ALL the protocol state a BIDIR-PIM implementation should maintain to work correctly. We call this state the Tree Information Base or TIB, because it holds the state of all the multicast distribution trees at this router. In this spec, PIM mechanisms are defined in terms of the TIB. Honestly though, only a super simple implementation would actually do packet forwarding straight off this state. Most implementations use this state to build a multicast forwarding table, and then update that table whenever the relevant TIB state changes 🧠
Here's the twist: we specify the state precisely, but that does NOT mean an implementation has to hold it in this form. This is an abstract state definition, needed so we can specify the router's behavior. A BIDIR-PIM implementation is free to hold whatever internal state it needs, and it's still conformant with this spec as long as it results in the same externally visible protocol behavior as an abstract router holding the following state 🦋
We split the TIB state into two sections:
RPA state State that maintains the DF election information for each RPA.
Group state State that maintains a group-specific tree for groups that map to a given RPA.
The state that should be kept is described below. Implementations will only maintain state when it's relevant to forwarding operations. For example, the "NoInfo" state might be assumed from the lack of other state information, instead of being held explicitly 🌸
3.1.1. General Purpose State
A router holds the following state that isn't specific to an RPA or group 🎀
Neighbor State:
For each neighbor:
o Neighbor's Gen ID
o Neighbor liveness timer (NLT)
o Other information from neighbor's HelloFor more on Hello info, check out Section 3.2 as well as the PIM-SM specification in [4] 💅
3.1.2. RPA State
A router maintains a multicast-group to RPA mapping, which is built through static configuration or by using an automatic RP discovery mechanism like BSR or AUTO-RP (see Section 4). For each BIDIR-PIM RPA, a router holds the following state 🗺️
o RPA (actual address)
Designated Forwarder (DF) State:
For each router interface:
Acting DF information:
o DF IP Address
o DF metric
Election information:
o Election State
o DF election-Timer (DFT)
o Message-Count (MC)
Current best offer:
o IP address of best offering router
o Best offering router metricDesignated Forwarder state is described in Section 3.5 👑
3.1.3. Group State
For every group G, a router keeps the following state 🫶
Group state:
For each interface:
Local Membership:
o State: One of {"NoInfo", "Include"}
PIM Join/Prune State:
o State: One of {"NoInfo" (NI), "Join" (J),
"PrunePending" (PP)}
o PrunePendingTimer (PPT)
o Join/Prune Expiry Timer (ET)
Not interface specific:
o Upstream Join/Prune Timer (JT)
o Last RPA UsedLocal membership is the result of the local membership mechanism (like IGMP [2]) running on that interface. This info is used by the pim_include(*,G) macro described in Section 3.1.4 🌈
PIM Join/Prune state is the result of receiving PIM (,G) Join/Prune messages on this interface, and it's specified in Section 3.4.1. This state is used by the macros that calculate the outgoing interface list in Section 3.1.4, and in the JoinDesired(G) macro (defined in Section 3.4.2), which decides whether a Join(,G) should be sent upstream 🔥
The upstream Join/Prune timer is used to send out periodic Join(,G) messages, and to override Prune(,G) messages from peers on an upstream LAN interface ⏰
The last RPA used must be stored, because if the group-to-RPA mapping changes (see RP Set changes in [4]), then state must be torn down and rebuilt for groups whose RPA changes 🔄
3.1.4. State Summarization Macros
Using this state, we define the following "macro" definitions that get used in the state machine and pseudocode descriptions in the following sections ✨
olist(G) =
RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G)RPF_interface(RPA) is the interface the MRIB indicates would be used to route packets to RPA. olist(G) is the list of interfaces on which packets to group G must be forwarded 🦋
The macro pim_include(G) indicates the interfaces to which traffic might be forwarded because of hosts that are local members on that interface 🌸
pim_include(G) =
{ all interfaces I such that:
I_am_DF(RPA(G),I) AND local_receiver_include(G,I) }The clause I_am_DF(RPA,I) is TRUE if the router is in the Win or Backoff states in the DF election state machine (described in Section 3.5) for the given RPA on interface I. Otherwise, it's FALSE 💜
The clause local_receiver_include(G,I) is true if the IGMP module, MLD module, or other local membership mechanism has determined that there are local members on interface I that want to receive traffic sent to group G 🎀
The set joins(G) is the set of all interfaces on which the router has received (*,G) Joins 🍓
joins(G) =
{ all interfaces I such that
I_am_DF(RPA(G),I) AND
DownstreamJPState(G,I) is either Joined or PrunePending }DownstreamJPState(G,I) is the state of the finite state machine in Section 3.4.1 🧚
RPF_DF(RPA) is the neighbor that Join messages must be sent to in order to build the group shared tree rooted at the RPL for the given RPA. This is the Designated-Forwarder on the RPF_interface(RPA) 🫶
3.2. PIM Neighbor Discovery ✨
okay so PIM routers are always chatting with their neighboring PIM routers 💬 by sending each other PIM-Hello messages 🦋. These hellos are what keep the Neighbor State from Section 3.1 up to date 💅. The full how-to for generating and processing Hello messages, plus maintaining that Neighbor State, lives in the PIM-SM [4] documentation 🧚.
BIDIR-PIM adds the Bidirectional Capable PIM-Hello option, and bestie, this one is non-negotiable 👑. It MUST be included in all Hello messages from a BIDIR-PIM capable router. It's basically the router saying "hey, I can do BIDIR-PIM!" ✨ The option advertises that ability, and its format is described in Section 3.7 🎀.
If a BIDIR-PIM router gets a PIM-Hello from one of its neighbors that does not have the Bidirectional Capable option, the error must be logged to the router administrator 🙈. It has to be done in a rate-limited manner so nobody gets spammed 😭.
3.3. Data Packet Forwarding Rules 💖
For groups mapping to a given RPA, the DF for that RPA on each link has some responsibilities that belong only to them 👑:
- The DF is the only router that forwards packets traveling downstream onto the link.
- The DF is the only router that picks-up upstream traveling packets off the link to forward towards the RPL.
Non-DF routers on a link can also do some forwarding for bidirectional groups, but only if that link is their RPF interface to reach the RPA 🌸. Those actions are:
- Forward packets from the link towards downstream receivers.
- Forward packets from downstream sources onto the link (provided they are the DF for the downstream link from which the packet was picked-up).
Here's the BIDIR-PIM packet forwarding logic written as pseudocode 🤓. First, the terms:
iif is the incoming interface of the packet.
G is the destination address of the packet (group address).
RPA is the Rendezvous Point Address for this group.Step one is checking whether the packet should be accepted at all 🔍. That depends on the TIB state and the interface the packet showed up on. A packet is accepted if it arrives on the RPF interface to reach the RPA (that's a downstream traveling packet), or if the router is the DF on the interface where it arrives (that's an upstream traveling packet).
Step two: if the packet should be forwarded, the router builds an outgoing interface list for it 📝.
Step three: the incoming interface gets removed from that outgoing interface list. If what's left isn't empty, the packet gets forwarded out of those interfaces 🦋.
The whole thing looks like this:
On receipt of data to G on interface iif:
if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) {
oiflist = olist(G) (-) iif
forward packet on all interfaces in oiflist
}3.3.1. Upstream Forwarding at RP 🌈
When you're setting up a BIDIR-PIM domain, the Rendezvous Point Address (RPA) doesn't have to belong to a physical box 📦. It can just be a routable address, and that's totally a valid choice ✨. Routers that have interfaces on the RPL that the RPA belongs to will upstream forward traffic onto the link. Joins from receivers in the domain propagate hop-by-hop until they reach one of the routers connected to the RPL, and that's where they terminate, since there's no DF elected on the RPL 🙌.
If the administrator goes with the RPA being the address of a physical interface on a specific router instead, nothing changes 🤷♀️. That router still has to upstream forward traffic onto the RPL, and it behaves no differently from any other router with an interface on the RPL 💅.
Now, if you want a BIDIR-PIM network to act kind of like PIM-SM, where one router (the RP) is the root of the distribution tree 👑, you can configure the RPA to be the loopback interface of a router 🎀.
3.3.2. Source-Only Branches 🦋
Source-only branches of the distribution tree for a group G are branches that don't lead to any receivers 🙃. They're there to forward packets traveling upstream from sources toward the RPL. Routers along these branches only have the RPF interface to the RPA in their olist for G, so they don't need to keep any group-specific state 🧠. Upstream forwarding can be done using only RPA-specific state, which is so efficient 😍.
An implementation is allowed to keep group state for source-only branches for accounting or performance reasons 📊. Just know that doing this means it needs data-driven events to discover which groups have active sources, and that gives up one of the main benefits of BIDIR-PIM 💀.
3.3.3. Directly Connected Sources 💜
One major perk of using a Designated Forwarder in BIDIR-PIM, compared to PIM-SM, is that directly connected sources don't need any special treatment 🥳. Data from those sources doesn't have to be differentiated from other multicast traffic. It gets picked up by the DF and forwarded upstream automatically ⭐. That means there's no need for a directly-connected-source check for data going to groups that don't have existing state 🙌.
3.4. PIM Join/Prune Messages 🎀
BIDIR-PIM Join/Prune messages build the group-specific distribution trees between receivers and the RPL 🌳. Joins start at last-hop routers that have been elected as the DF on an interface with directly connected receivers 💖. From there they propagate hop-by-hop toward the RPA until they hit a router connected to the RPL 🚀.
A BIDIR-PIM Join/Prune message is basically a list of Joined and Pruned Groups 📋. When a router processes one, it looks at each Joined or Pruned Group individually by applying the state machines 🧩. If the PIM Destination field of the message addresses this router, then (*,G) Joins and Prunes can affect the downstream state machine 👑. If the PIM Destination field addresses another router instead, most Join or Prune entries could affect the upstream state machine 🔼.
3.4.1. Receiving (*,G) Join/Prune Messages ✨
Okay so when a router gets a Join(,G) or Prune(,G), the very first thing it MUST do is check whether the RP address in the message matches RPA(G) 🎀. That's the router's own idea of what the Rendezvous Point Address is. If the RP address doesn't match, the Join or Prune MUST be silently dropped. It just gets ghosted 👻
If a router has no RPA info for the group (like it hasn't gotten a BSR message recently 🙈), then it MAY choose to accept the Join(,G) or Prune(,G) and treat the RP address in the message as RPA(G). And if that newly discovered RPA didn't already exist for any other group, a DF election has to be kicked off 🗳️
Also, a router will process a Join(*,G) that's targeted to itself, even if it isn't the DF for RP(G) on the interface where the message came in. This is an optimisation that gets rid of a whole Join delay of one Join period (t_periodic) in the case where a new DF handles the received Pass and Join messages in reverse order. The BIDIR-PIM forwarding logic makes sure data packets aren't forwarded out of that interface while the router isn't the DF (unless it's the RPF interface towards the RPA). So it's safe, bestie 💅
Here's the per-interface state machine for receiving (*,G) Join/Prune Messages. There are three states:
- NoInfo (NI): The interface has no (*,G) Join state and no timers running.
- Join (J): The interface has (*,G) Join state. If the router is the DF on this interface (
I_am_DF(RPA(G),I)is TRUE), the Join state causes us to forward packets destined for G out this interface 🦋 - PrunePending (PP): The router got a Prune(*,G) on this interface from a downstream neighbor and is waiting to see if another downstream router overrides it. For forwarding purposes, PrunePending works exactly like Join. Iconic behaviour 👑
The state machine also uses two timers:
- ExpiryTimer (ET): This timer gets restarted when a valid Join(*,G) comes in. When it expires, the interface state reverts to NoInfo for this group.
- PrunePendingTimer (PPT): This timer gets set when a valid Prune(*,G) comes in. When it expires, the interface state reverts to NoInfo for this group.
Figure 1: Downstream group per-interface state machine in tabular form
+---------------++---------------------------------------------------+
| || Prev State |
|Event ++---------------+-----------------+-----------------+
| || NoInfo (NI) | Join (J) | PrunePending |
| || | | (PP) |
+---------------++---------------+-----------------+-----------------+
| || -> J state | -> J state | -> J state |
|Receive || start Expiry | restart Expiry | restart Expiry |
|Join(*,G) || Timer | Timer | Timer; stop |
| || | | PrunePending- |
| || | | Timer |
+---------------++---------------+-----------------+-----------------+
|Receive || - | -> PP state | -> PP state |
|Prune(*,G) || | start Prune- | |
| || | PendingTimer | |
+---------------++---------------+-----------------+-----------------+
|PrunePending- || - | - | -> NI state |
|Timer Expires || | | Send Prune- |
| || | | Echo(*,G) |
+---------------++---------------+-----------------+-----------------+
|Expiry Timer || - | -> NI state | -> NI state |
|Expires || | | |
+---------------++---------------+-----------------+-----------------+
|Stop Being DF || - | -> NI state | -> NI state |
|on I || | | |
+---------------++---------------+-----------------+-----------------+The transition events "Receive Join(,G)" and "Receive Prune(,G)" mean receiving a Join or Prune that's targeted to this router's address on the interface it came in on. If the destination address isn't correct, these state transitions in this state machine must not occur, though seeing such a packet may still cause state transitions in other state machines 🙃
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it picked for the Hello packet it sent over that interface. However, on point-to-point links, we also RECOMMEND that PIM messages with a destination address of all zeros also be accepted ✨
The transition event "Stop Being DF" means a DF re-election is happening on this router interface for RPA(G), and the router is switching from being the active DF to being a non-DF router (the value of the I_am_DF macro changes to FALSE). Plot twist 🌪️
When ExpiryTimer is started or restarted, it's set to the HoldTime from the Join/Prune message that triggered it. When PrunePendingTimer is started, it's set to the J/P_Override_Interval if the router has more than one neighbor on that interface. Otherwise, it's set to zero, so it expires immediately.
The action "Send PruneEcho(,G)" happens when the router stops forwarding on an interface because of a Prune. A PruneEcho(,G) is just a Prune(,G) that the upstream router sends to itself on a LAN. Its purpose is to add extra reliability. If a Prune that should have been overridden by another router gets lost locally on the LAN, the PruneEcho may still be received and cause the override to happen 🫶 A PruneEcho(,G) doesn't need to be sent when the router has only one neighbor on the link.
3.4.2. Sending Join/Prune Messages 🌸
The downstream per-interface state machines described above hold Join state from downstream PIM routers. That state decides whether a router needs to pass a Join(,G) upstream towards the RPA. These Join(,G) messages go out the RPF interface towards the RPA and are targeted at the DF on that interface.
If a router wants to propagate a Join(,G) upstream, it also has to watch for messages on its upstream interface from other routers on that subnet, and those messages can change how it behaves. If it sees a Join(,G) going to the correct upstream neighbor, it should suppress its own Join(,G). If it sees a Prune(,G) going to the correct upstream neighbor, it should be ready to override that Prune by sending a Join(,G) almost immediately. Finally, if it sees the Generation ID (see PIM-SM specification [4]) of the correct upstream neighbor change, it knows that the upstream neighbor has lost state, and it should be ready to refresh that state by sending a Join(,G) almost immediately. Spy mode activated 👀
Also, changes in the next hop towards the RPA trigger a Prune off the old next hop and a Join towards the new next hop. Two events can cause this kind of change:
- The MRIB indicates that the RPF Interface towards the RPA has changed. In this case, the DF on the new RPF interface becomes the new RPF Neighbor.
- There's a DF re-election on the RPF interface and a new router emerges as the DF.
The upstream (*,G) state machine only has two states:
- Not Joined: The downstream state machines indicate that the router doesn't need to join the RPA tree for this group.
- Joined: The downstream state machines indicate that the router would like to join the RPA tree for this group.
On top of that, one timer JT(G) is kept. It triggers the sending of a Join(*,G) to the upstream next hop towards the RPA (the DF on the RPF interface for RPA(G)).
Figure 2: Upstream group state machine in tabular form
+---------------------+----------------------------------------------+
| | Event |
| Prev State +-----------------------+----------------------+
| | JoinDesired(G) | JoinDesired(G) |
| | ->True | ->False |
+---------------------+-----------------------+----------------------+
| | -> J state | - |
| NotJoined (NJ) | Send Join(*,G); | |
| | Set Timer to | |
| | t_periodic | |
+---------------------+-----------------------+----------------------+
| Joined (J) | - | -> NJ state |
| | | Send Prune(*,G) |
+---------------------+-----------------------+----------------------+And here are the extra transitions that happen inside the Joined state:
+--------------------------------------------------------------------+
| In Joined (J) State |
+----------------+----------------+-----------------+----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF_DF(RPA(G)) |
| | to | to | GenID changes |
| | RPF_DF(RPA(G)) | RPF_DF(RPA(G)) | |
+----------------+----------------+-----------------+----------------+
|Send | Increase Timer | Decrease Timer | Decrease Timer |
|Join(*,G); Set | to | to t_override | to t_override |
|Timer to | t_suppressed | | |
|t_periodic | | | |
+----------------+----------------+-----------------+----------------++--------------------------------------------------------------------+
| In Joined (J) State |
+-----------------------------------+--------------------------------+
| Change of RPF_DF(RPA(G)) | RPF_DF(RPA(G)) GenID |
| | changes |
+-----------------------------------+--------------------------------+
| Send Join(*,G) to new | Decrease Timer to |
| DF; Send Prune(*,G) to | t_override |
| old DF; set Timer to | |
| t_periodic | |
+-----------------------------------+--------------------------------+This state machine uses the following macro:
bool JoinDesired(G) {
if (olist(G) (-) RPF_interface(RPA(G))) != NULL
return TRUE
else
return FALSE
}3.5. Designated Forwarder (DF) Election 🦋
This section presents a fail-safe mechanism for electing a per-RPA designated router on each link in a BIDIR-PIM domain. We call this router the Designated Forwarder (DF). The DF election does not take place on the RPL for an RPA.
3.5.1. DF Requirements ✨
Okay so the DF election picks the best router on a link to take charge of forwarding traffic between the RPL and that link, for the range of multicast groups served by the RPA 💖. Different multicast groups that share a common RPA also share the same upstream direction, which means electing an upstream forwarder on each link doesn't have to be group-specific. It can be RPA-specific 🦋. There are usually only a few RPAs, so this cuts the number of elections that need to happen way down. Iconic efficiency 💅
To optimise tree creation, the winner should ideally be the router on the link with the "best" unicast routing metric (as reported by the MRIB) for reaching the RPA 🌸. When comparing metrics from different unicast routing protocols, we use the same comparison rules as the PIM-SM assert process [4]. No cap, it's a whole thing 🧚
The election needs to happen when info about a new RPA first shows up. The result can be reused as new bidir groups that map to the same RPA pop up 🎀. But there are some situations where the election has to be updated:
- There is a change in unicast metric to reach the RPA for any of the routers on the link.
- The interface on which the RPA is reachable (RPF Interface) changes to an interface for which the router was previously the DF.
- A new PIM neighbor starts up on a link that must participate in the elections and be informed of the current outcome.
- The elected DF fails (detected through neighbor information timeout or MRIB RPF change at downstream router).
The election process has to be robust enough to make sure, with very high probability, that every router on the link has a consistent view of the DF 🫶. Remember the forwarding rules from Section 3.3? If multiple routers end up thinking they're supposed to be forwarding, loops can happen 😭. To lower the chances of that, the election algorithm is biased toward discarding DF information and suspending forwarding during periods of ambiguity. Lowkey the safest move, honestly 💀
3.5.2. DF Election Description
This section gives an outline of the DF election process 🌈. It is not the definitive spec for the DF election, so if there's any discrepancy between Section 3.5.3 and this section, Section 3.5.3 is the one to trust ⭐.
To elect the DF for a particular RPA, routers on a link need to swap their unicast routing metric info for reaching the RPA 💜. Routers advertise their own metrics in Offer, Winner, Backoff, and Pass messages. The advertised metric is calculated using the RPF Interface and the metric to reach the RPA available through the MRIB. When a router is taking part in a DF election for an RPA on the interface its MRIB marks as the RPF Interface, it MUST always advertise an infinite metric in its election messages. When a router is taking part in a DF election on any other interface, it MUST advertise the MRIB-provided metrics in its election messages. Main character rules, no exceptions 👑
In the election protocol below, lots of message exchanges get repeated Election_Robustness times for reliability 🍓. In all of those cases, the retransmissions are spaced out by a small random interval. Everything in this description is specific to the election on a single link for a single RPA 🦋.
3.5.2.1. Bootstrap Election
At the start, when no DF has been elected yet, routers that find out about a new RPA jump into the election by sending Offer messages 🌸. Offers include the router's metric to reach the RPA, and they get retransmitted periodically with a period of Offer_Interval.
If a router hears a better offer than its own from a neighbor, it steps out of the election for a period of Election_Robustness * Offer_Interval, which gives the neighbor with the better metric a real shot at becoming DF 🙈. If no winner is elected during that window, the router restarts the election from the beginning. And if, at any point during the initial election, a router gets an out of order offer with worse metrics than its own, it also restarts the election from the beginning 🔄.
The end result should be that all routers except the best candidate stop advertising their offers 💅.
A router becomes the DF after it has advertised its metrics Election_Robustness times without hearing any offer from another neighbor 👑. At that point, it sends a Winner message that tells every other router on the link who the winner is and what metrics it's using.
Routers that receive a Winner message stop participating in the election and record the winner's identity and metrics 🫶. If a router's local metrics are better than the winner's, it records the winner's identity (accepting them as the acting DF), but it also re-initiates the election to try to take over. Not me being competitive 😤
3.5.2.2. Loser Metric Changes
Whenever the unicast metric to an RPA changes at a non-DF router to a value that's better than what the acting DF previously advertised, that router should take action so it can eventually take over forwarding 🦋. When the change is detected, the non-DF router with the newly better metric restarts the DF election by sending Offer messages with this new metric 💖. Keep in mind that if no response comes back after Election_Robustness retransmissions of an offer, the router assumes the role of the DF using the usual Winner announcement procedure 🎀.
When the DF gets an offer that's worse than its current metric, it responds with a Winner message that declares its status and advertises its better metric 💅. When the originator of the Offer gets that Winner message, it records the DF's identity and aborts the election 🌈.
When the DF gets an offer that's better than its current metric, it records the identity and metrics of the offering router and responds with a Backoff message ⏸️. This tells the offering router to hold off for a short while, so unicast routing can settle and other routers get a chance to put in their offers 🧚. The Backoff message includes the offering router's new metric and address. Every router on the link with a pending offer whose metric is worse than the one in the Backoff message (including the original offering router) holds off on further offers for the period defined in the Backoff message 🫶.
If a third router sends a better offer during the Backoff_Period, the Backoff message gets repeated for the new offer and the Backoff_Period restarts ⏳.
Before the Backoff_Period runs out, the acting DF nominates the router that made the best offer as the new DF by sending a Pass message 👑. This message includes the IDs and metrics of both the old and new DFs. The old DF stops doing its job at the moment the Pass message is sent, and the new DF takes over as soon as it receives the Pass message 💜. All the other routers on the link take note of the new DF and its metric. This event counts as an RPF Neighbor change, which may trigger Join messages to the new DF (see Section 3.4) ✨.
3.5.2.3. Winner Metric Changes
If the DF's routing metric to reach the RPA gets worse, the DF sends a set of Election_Robustness randomly spaced Winner messages on the link, advertising the new metric 🍓. Routers that hear this announcement but have a better metric might respond with an Offer message, which kicks off the same handoff procedure described above 🦋. Until they see a Pass or Winner message showing the change, all routers keep assuming the DF hasn't changed 🙈.
There's no pressure to hand off quickly if the acting DF still has a path to the RPL 🌸. The old path might be suboptimal now, but it'll still work while the re-election is happening 💅.
3.5.2.4. Winner Loses Path
If a router's RPF Interface to the RPA switches to a link where it's acting as the DF, it can no longer provide forwarding services for that link 😭. So it immediately stops being the DF and restarts the election. Because its path to the RPA now goes through that link, it uses an infinite metric in the Offer message it sends 💀.
3.5.2.5. Late Router Starting Up
A late router that starts up after the DF election has already finished doesn't know the outcome yet 🧚. So it starts advertising its metric in Offer messages. As soon as that happens, the currently elected DF responds: with a Winner message if its metric is better than the metric in the Offer, or with a Backoff message if its metric is worse than the metric in the Offer 🎀.
3.5.2.6. Winner Dies
Whenever the DF dies, a new DF has to be elected 😭. How fast that happens depends on whether there are any downstream routers on the link 🌈.
If there are downstream routers, their MRIB-reported next-hop before the DF died was typically the DF itself 🫶. So they'll notice either a change in the metric for the route to the RPA or a change in next-hop away from the DF, and they can restart the election by transmitting Offer messages 💖. If the MRIB says the RPA is now reachable through the same link via another upstream router, an infinite metric gets used in the Offer 👑.
If there are no downstream routers, the only way the other upstream routers can detect a DF failure is by timing out the PIM neighbor information, which takes significantly longer 🙈.
3.5.3. Election Protocol Specification
This section is the definitive spec for the DF election process 📜. If there's any discrepancy between Section 3.5.2 and this section, this section is the one to trust 💜.
3.5.3.1. Election State
The DF election state is kept per RPA for each multicast-enabled interface I on the router, as introduced in Section 3.1 🎀.
The state machine has four states 🦋:
Offer: The initial election state. In this state, a router thinks it can eventually become the winner, so it periodically generates Offer messages 🌸.Lose: In this state, the router knows either that there's a different election winner or that no router on the link has a path to the RPA 😭.Win: The router is the acting DF with no contest 👑.Backoff: The router is the acting DF, but another router has made a bid to take over 😤.
In the state machine, a router counts as an acting DF if it's in the Win or Backoff state 💅.
The election protocol uses the variables and timers described below 🧚:
Acting DF information: Stores the identity and advertised metrics of the election winner that is currently the acting DF 💖.DF election-Timer (DFT): Schedules transmission of Offer, Winner, and Pass messages ⏳.Message-Count (MC): Keeps track of how many times an Offer or Winner message has been transmitted 🍓.Best-Offer: Used by the DF to record the identity and advertised metrics of the router that made the last offer, for use when sending the Path message 🌈.
3.5.3.2. Election Messages 🎀
Okay, so the election runs on four PIM control messages 💅 The packet format lives in Section 3.7, so peek there if you want the bits.
Offer (OfferingID, Metric)
Winner (DF-ID, DF-Metric)
Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric,
BackoffInterval)
Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric)- Offer: routers send this when they think they've got a better metric to the RPA than the one currently on offer 🙌
- Winner: a router sends this when it takes over as the DF, or when it re-asserts itself because of worse offers 👑
- Backoff: the DF uses this to acknowledge better offers. It tells everyone with equal or worse offers to chill and wait until the DF hands responsibility over to whoever made the offer 🫶
- Pass: the old DF uses this to pass forwarding responsibility to a router that already made an offer. The Old-DF-Metric is the DF's current metric at the moment the pass gets sent 🦋
Okay, the big one: when a router is in a DF election for an RPA on the interface its MRIB says is the RPF Interface, it MUST always advertise an infinite metric in its election messages 🔥 If it's in a DF election on any other interface, it MUST advertise the MRIB-provided metrics instead ✨
3.5.3.3. Election Events 🦋
Things can happen during protocol operation, and these are the main ones:
- Control message reception: one of the four DF election messages (Offer, Winner, Backoff, and Pass) shows up. When actions depend on metrics being Better or Worse, the comparison must be done like this:
- On receipt of an Offer or Winner message, compare the current metrics for the RPA with the metrics advertised for the sender of the message.
- On receipt of a Backoff or Pass message, compare the current metrics for the RPA with the metrics advertised for the target of the message.
- Path to RPA lost: losing the path can happen in two ways 😭 The first is when the route learned through the MRIB gets withdrawn and the MRIB no longer reports an available route to the RPA. The second is when the next-hop info from the MRIB changes to a next-hop reachable through the router interface under consideration. Clearly, if the router is using that interface as its RPF Interface, it can't offer forwarding services towards the RPL to other routers on that link 🙈
- Metric reported by the MRIB to reach the RPA changes: this fires when the MRIB info for the RPA changes and the new info gives a path to the RPA. If the new MRIB info reports no route, or a next-hop interface through the interface where the DF election is happening, then the "Path to RPA lost" event triggers instead. In specific states, the event may be further filtered by specifying whether the metric is expected to get better or worse, and which of the stored metrics the new MRIB information must be compared against. The new info must be compared with either the router's old metric, the stored DF metric, or the stored Best Offer metric 💜
- Election-Timer (DFT) expiration: when the DFT election timer expires, it can cause message transmission and state transitions. The event might be further qualified by the value of the Message Count (MC), plus whether a path to the RPA currently exists (as defined above) 🧚
- Detection of DF failure: this can happen through the timeout of PIM neighbor state 💀
3.5.3.4. Election Actions 🌸
The DF election state machine action descriptions use the following notation, on top of the pseudocode notation described earlier in this specification:
?=: lowers a timer to a new value. If the timer isn't running, it gets started with the new value. If the timer is running with an expiration lower than the new value, it isn't changed ⏰
When an action of set DF to Sender or Target shows up during receipt of a Winner, Pass, or Backoff message, here's what it means 💅
- On receipt of a Winner message, set the DF to be the originator of the message and record its metrics.
- On receipt of a Pass message, set the DF to be the target of the message and record its metrics.
- On receipt of a Backoff message, set the DF to be the originator of the message and record its metrics.
3.5.3.5. Election State Transitions ✨
okay so this is where the election gets its whole plot 🎬. when a Designated Forwarder election kicks off, everyone starts in the Offer state, the message counter (MC) gets set to zero, and the DF election timer (DFT) gets set to OPlow 💅 (peek at Section 3.6 for what the timer values mean, bestie 🧚).
Here's the full state machine in table form 🦋 Figure 3: Designated Forwarder election state machine in tabular form
+-------------+------------------------------------------------------+
| | Event |
| Prev State +-----------------+------------------+-----------------+
| | Recv better | Recv better | Recv better |
| | Pass / Win | Backoff | Offer |
+-------------+-----------------+------------------+-----------------+
| | -> Lose | - | - |
| Offer | DF = Sender or | DFT = BOperiod | DFT = OPhigh; |
| | Target; Stop | + OPlow; MC = | MC = 0 |
| | DFT | 0 | |
+-------------+-----------------+------------------+-----------------+
| | - | - | -> Offer |
| Lose | DF = Sender or | DF = Sender | DFT = OPhigh; |
| | Target | | MC = 0 |
+-------------+-----------------+------------------+-----------------+
| | -> Lose | -> Lose | -> Backoff |
| | DF = Sender or | DF = Sender; | Set Best to |
| Win | Target; Stop | Stop DFT | Sender; Send |
| | DFT | | Backoff; DFT = |
| | | | BOperiod |
+-------------+-----------------+------------------+-----------------+
| | -> Lose | -> Lose | - |
| | DF = Sender or | DF = Sender; | Set Best to |
| Backoff | Target; Stop | Stop DFT | Sender; Send |
| | DFT | | Backoff; DFT = |
| | | | BOperiod |
+-------------+-----------------+------------------+-----------------+
+-----------+-------------------------------------------------------+
| | Event |
| +-------------+-------------+--------------+------------+
|Prev State |Recv Backoff |Recv Pass |Recv Worse |Recv worse |
| |for us |for us |Pass / Win / |Offer |
| | | |Backoff | |
+-----------+-------------+-------------+--------------+------------+
| |- |-> Win |- |- |
| |DFT = |Stop DFT |Set DF to |DFT ?= |
|Offer |BOperiod + | |Sender or |OPlow; MC = |
| |OPlow; MC = | |Target; DFT |0 |
| |0 | |?= OPlow; MC | |
| | | |= 0 | |
+-----------+-------------+-------------+--------------+------------+
| |-> Offer |-> Offer |-> Offer |-> Offer |
| |DF = Sender; |DF = Sender; |DF = Sender |DFT = OPlow;|
|Lose |DFT = OPlow; |DFT = OPlow; |or Target; |MC = 0 |
| |MC = 0 |MC = 0 |DFT = OPlow; | |
| | | |MC = 0 | |
+-----------+-------------+-------------+--------------+------------+
| |-> Offer |-> Offer |-> Offer |- |
| |DF = Sender; |DF = Sender; |DF = Sender |Send Winner |
|Win |DFT = OPlow; |DFT = OPlow; |or Target; | |
| |MC = 0 |MC = 0 |DFT = OPlow; | |
| | | |MC = 0 | |
+-----------+-------------+-------------+--------------+------------+
| |-> Offer |-> Offer |-> Offer |-> Win |
| |DF = Sender; |DF = Sender; |DF = Sender |Send Winner;|
|Backoff |DFT = OPlow; |DFT = OPlow; |or Target; |Stop DFT |
| |MC = 0 |MC = 0 |DFT = OPlow; | |
| | | |MC = 0 | |
+-----------+-------------+-------------+--------------+------------+
+--------------------------------------------------------------------+
| In Offer State |
+----------------------+----------------------+----------------------+
| DFT Expires and MC | DFT Expires and MC | DFT Expires and MC |
| is less than | is equal to | is equal to |
| Robustness | Robustness and we | Robustness and |
| | have path to RPA | there is no path |
| | | to RPA |
+----------------------+----------------------+----------------------+
| - | -> Win | -> Lose |
| Send Offer; DFT = | Send Winner | Set DF to None |
| OPlow; MC = MC + 1 | | |
+----------------------+----------------------+----------------------+
+--------------------------------------------------------------------+
| In Offer State |
+--------------------------------------------------------------------+
| Metric changes and is now worse |
+--------------------------------------------------------------------+
| DFT ?= OPlow |
| MC = 0 |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
| In Lose State |
+------------------------------+-------------------------------------+
| Detect DF Failure | Metric changes and now |
| | is better than DF |
+------------------------------+-------------------------------------+
| -> Offer | -> Offer |
| DF = None; DFT = | DFT = OPlow_int; MC = 0 |
| OPlow_int; MC = 0 | |
+------------------------------+-------------------------------------+
+--------------------------------------------------------------------+
| In Win State |
+----------------------+-----------------------+---------------------+
| Metric changes and | Timer Expires and | Path to RPA lost |
| is now worse | MC is less than | |
| | Robustness | |
+----------------------+-----------------------+---------------------+
| - | - | -> Offer |
| DFT = OPlow; MC = | Send Winner; DFT = | Set DF to None; |
| 0 | OPlow; MC = MC + 1 | DFT = OPlow; MC = |
| | | 0 |
+----------------------+-----------------------+---------------------+
+--------------------------------------------------------------------+
| In Backoff State |
+----------------------+-----------------------+---------------------+
| Metric changes and | Timer Expires | Path to RPA lost |
| is now better than | | |
| Best | | |
+----------------------+-----------------------+---------------------+
| -> Win | -> Lose | -> Offer |
| Stop Timer | Send Pass; Set DF | Set DF to None; |
| | to stored Best | DFT = OPlow; MC = |
| | | 0 |
+----------------------+-----------------------+---------------------+3.5.4. Election Reliability Enhancements 🛡️
for BIDIR-PIM to behave, it's super important to avoid situations where two routers both think they're the Designated Forwarders for the same link 😭. the two precautions below aren't required for correct operation, but they can help you diagnose and fix anomalies 🩺.
3.5.5. Missing Pass 👀
after a DF has been elected, a router whose metrics change to become better than the DF will try to take over 🏃♀️. but if the acting DF has a condition that makes it lose all of the election messages (like a CPU overload 💀), the new candidate transmits three offers and becomes the forwarder, so now there are two DFs on the link 😱. this is pathological, and the fix is to un-overload that router, obviously 🙄. it's desirable that a network administrator can detect this kind of event 🕵️.
when a router becomes the DF for a link without receiving a Pass message from the known old DF, it can mark the old DF's PIM neighbor information to show that 🏷️. then, when the next PIM Hello message comes in from the old DF, the router can retransmit Winner messages for all the RPAs it's acting as DF for 📣. the router may also log the anomaly, in a rate-limited way, to alert the operator 🚨.
3.5.6. Periodic Winner Announcement 🧸
an extra layer of safety is possible: the DF for each RPA periodically announces its status in a Winner message 📢. the periodic Winner message can be restricted to RPAs that have active groups, so you skip the extra control traffic in parts of the network with no senders or receivers for a particular RPA 🙌💖
3.6. Timers, Counters, and Constants ⏰
okay bestie, BIDIR-PIM keeps track of a bunch of timers 🕰️ (we already talked about them in Section 3.1). Every single one is a countdown timer: you set it to a value, it counts down to zero, and then it usually triggers some action. Could you build them as count-up timers instead, storing the absolute expiry time and comparing it against a real-time clock? Sure, totally. But this spec just assumes they count down to zero, so that's the vibe we're going with 💅
Here's how the timers are organized:
- Per Rendezvous-Point Address (RPA):
- Per interface (I):
DF Election Timer: DFT(RPA,I)
- Per interface (I):
- Per Group (G):
Upstream Join Timer: JT(G)- Per interface (I):
Join Expiry Timer: ET(G,I)PrunePendingTimer: PPT(G,I)
When timers get started or restarted, they're set to default values. This section sums up those defaults, so you don't have to hunt for them 🎀
Timer Name: DF Election Timer (DFT)
+-------------------+------------------------+-----------------------+
| Value Name | Value | Explanation |
+-------------------+------------------------+-----------------------+
| Offer_Period | 100 ms | Interval to wait |
| | | between repeated |
| | | Offer and Winner |
| | | messages. |
+-------------------+------------------------+-----------------------+
| Backoff_Period | 1 sec | Period that acting |
| | | DF waits between |
| | | receiving a better |
| | | Offer and sending |
| | | the Pass message |
| | | to transfer DF |
| | | responsibility. |
+-------------------+------------------------+-----------------------+
| OPlow | rand(0.5, 1) * | Range of actual |
| | Offer_Period | randomised value |
| | | used between |
| | | repeated messages. |
+-------------------+------------------------+-----------------------+
| OPhigh | Election_Robustness | Interval to wait |
| | * Offer_Period | in order to give a |
| | | chance to a router |
| | | with a better |
| | | Offer to become |
| | | the DF. |
+-------------------+------------------------+-----------------------+Timer Names: Join Expiry Timer (ET(G,I))
+---------------+---------------+------------------------------------+
|Value Name | Value | Explanation |
+---------------+---------------+------------------------------------+
|J/P HoldTime | from message | Hold Time from Join/Prune Message |
+---------------+---------------+------------------------------------+Timer Names: PrunePendingTimer (PPT(G,I))
+-------------------------+-------------------+----------------------+
| Value Name | Value | Explanation |
+-------------------------+-------------------+----------------------+
| J/P Override Interval | Default: 3 secs | Short period after |
| | | a Join or Prune to |
| | | allow other |
| | | routers on the LAN |
| | | to override the |
| | | Join or Prune |
+-------------------------+-------------------+----------------------+Heads up! The J/P Override Interval is interface specific. It depends on both the Propagation_Delay and the Override_Interval values, and those can change when Hello messages are received [4].
Timer Names: Upstream Join Timer (JT(G))
+------------+-------------------+-----------------------------------+
Value Name |Value Explanation |
+------------+-------------------+-----------------------------------+
t_periodic |Default: 60 secs Period between Join/Prune Messages |
+------------+-------------------+-----------------------------------+
t_suppressed |rand(1.1 * Suppression period when someone |
| |t_periodic, 1.4 * else sends a J/P message so we |
| |t_periodic) don't need to do so. |
+------------+-------------------+-----------------------------------+
t_override |rand(0, 0.9 * J/P Randomized delay to prevent |
| |Override Interval) response implosion when sending a |
| | Join message to override someone |
| | else's Prune message. |
+------------+-------------------+-----------------------------------+For more info on these values, check out the PIM-SM [4] documentation 🧚
Constant Name: DF Election Robustness
+-------------------------+------------------+-----------------------+
| Constant Name | Value | Explanation |
+-------------------------+------------------+-----------------------+
| Election_Robustness | Default: 3 | Minimum number of |
| | | election messages |
| | | that must be lost |
| | | in order for |
| | | election to fail. |
+-------------------------+------------------+-----------------------+3.7. BIDIR-PIM Packet Formats 📦
This section covers the packet formats for BIDIR-PIM control messages. BIDIR-PIM shares a bunch of control messages with PIM-SM [4] (the Hello and Join/Prune messages, plus the Encoded-Unicast address format). For the details on those, go look at the PIM-SM documentation 🙈 Here we only define the extra packets BIDIR-PIM brings to the party: the ones used in the DF election process, and the Bidirectional Capable PIM-Hello option ✨
3.7.1. DF Election Packet Formats
All PIM control messages have IP protocol number 103.
BIDIR-PIM messages get multicast with TTL 1 to the ALL-PIM-ROUTERS' group. The IPv4 ALL-PIM-ROUTERS' group is 224.0.0.13'. The IPv6 ALL-PIM-ROUTERS' group is `ff02::d'.
Every DF election BIDIR-PIM control message shares the common header below 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |Subtype| Rsvd | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address (Encoded-Unicast format) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means:
PIM Ver: the PIM Version number is 2.Type: all DF-Election PIM control messages share the PIM message Type of 10.Subtype: the subtypes for DF election messages are:
1 = Offer
2 = Winner
3 = Backoff
4 = PassRsvd: set to zero on transmission, ignored on receipt.Checksum: a standard checksum IP checksum is used. That means the 16-bit one's complement of the one's complement sum of the entire PIM message. When computing it, the checksum field gets zeroed first 🧮RP Address: the bidirectional RPA the election is happening for. The format is described in [4], Section 4.9.1.Sender Metric Preference: the preference value given to the unicast routing protocol the message sender used to get the route to the RPA.Sender Metric: the unicast routing table metric the message sender used to reach the RPA. It's measured in units that make sense for whichever unicast routing protocol is in use.
Besides the fields above, the Backoff and Pass messages have some extra fields of their own 👑
3.7.2. Backoff Message
The Backoff message uses the following fields on top of the common election message format we just covered ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offering Address (Encoded-Unicast format) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offering Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offering Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Offering Address: the address of the router that made the last (best) Offer. The format is described in [4], Section 4.9.1.Offering Metric Preference: the preference value given to the unicast routing protocol the offering router used to get the route to the RPA.Offering Metric: the unicast routing table metric the offering router used to reach the RPA. It's in units that match the unicast routing protocol being used.Interval: the backoff interval in milliseconds that routers with worse metrics than the offering router should use.
3.7.3. Pass Message
The Pass message uses the following fields on top of the common election fields we already went over 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Winner Address (Encoded-Unicast format) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Winner Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Winner Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+New Winner Address: the address of the router that made the last (best) Offer. The format is described in [4], Section 4.9.1.New Winner Metric Preference: the preference value given to the unicast routing protocol the offering router used to get the route to the RPA.New Winner Metric: the unicast routing table metric the offering router used to reach the RPA. It's in units that match the unicast routing protocol being used.
3.7.4. Bidirectional Capable PIM-Hello Option ✨
Okay bestie, BIDIR-PIM only adds one new PIM-Hello option 🎀 That's it, that's the whole glow-up. It's giving minimalism 💅
- OptionType 22: Bidirectional Capable
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 = 22 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4. RP Discovery 🧚
So routers need to figure out two things. First, that a range of multicast group addresses runs in bidirectional mode. Second, that the Rendezvous-Point address (RPA) is the one serving that group range. They can learn this either through static configuration, or through an automatic RP discovery mechanism like the PIM Bootstrap mechanism (BSR) [7] or Auto-RP. The way that everything clicks together here is honestly iconic 🦋
5. Security Considerations 🔒
Okay, this section is serious, so let's go 😭 The IPsec [5] authentication header MAY be used to provide data integrity protection and group-wise data origin authentication of BIDIR-PIM protocol messages. Authenticating BIDIR-PIM messages can protect against unwanted behaviour caused by unauthorized or altered BIDIR-PIM messages. Main character energy: protect the network or get wrecked 💀
5.1. Attacks Based on Forged Messages 🙈
Same vibe as PIM Sparse-Mode, ngl. How much damage an attacker can do depends on what kinds of fake messages get accepted. BIDIR-PIM only uses link-local multicast messages sent to the ALL_PIM_ROUTERS address. So attacks can only be carried out by directly connected nodes, or with the complicity of directly connected routers. Not you, random stranger on the internet 🙅♀️
Some BIDIR-PIM protocol messages (Join/Prune and Hello) are identical to the matching PIM-SM messages, both in format and in what they do. Security considerations for those are in [4]. The other messages (DF-election messages) are specific to BIDIR-PIM, and we'll get into them in the next bits.
By forging DF-election messages, an attacker can mess with the election of the Designated Forwarder on a link in two different ways:
5.1.1. Election of an Incorrect DF 👑
An attacker can force itself to be elected DF by joining a regular election and advertising the best metric to reach the RPA. An attacker can also try to force another router to become DF, by sending an Offer, Winner, or Pass message while impersonating that router. In some cases (for example, the Offer), an attack might need several messages. Hard to pull off, but still a vibe 💅
For Offer or Winner messages, the attacker has to impersonate the node it wants to become the DF. For a Pass message, it has to impersonate the current DF. This kind of attack causes the wrong DF to be recorded in every node except the one being impersonated. That node will usually be able to notice something's off and, possibly, restart a new election.
A more sophisticated attacker might run a concurrent DoS attack on the node being impersonated. Then that node can't detect the forged packets and/or take countermeasures. Rude, but also lowkey genius 🫠
All impersonation attacks can be detected by all routers, and avoided, if the source of DF-election messages can be authenticated. When authentication is available, spoofed messages MUST be discarded and a rate-limited warning message SHOULD be logged. Authentication = no drama 🧁
A more subtle attacker could use MAC-level addresses to split up the set of recipients of DF-election messages, and create an inconsistent DF view on the link. For example, the attacker could use unicast MAC addresses for its forged DF-election messages. To prevent this kind of attack, BIDIR-PIM routers SHOULD check the destination MAC address of received DF-election messages. This is ineffective on links that do not support layer-2 multicast delivery, though 😬
Source authentication is also sufficient to prevent this kind of attack ✨
5.1.2. Preventing Election Convergence 🌀
By forging DF-election messages, an attacker can stop the election from converging, which disrupts the setup of multicast forwarding trees. There are lots of ways to do this. The simplest is sending an infinite sequence of Offer messages (the metric in those messages doesn't matter). Literally a never-ending group chat that nobody can end 🙃
5.2. Non-Cryptographic Authentication Mechanisms 🔐
A BIDIR-PIM router SHOULD provide an option to limit the set of neighbors it will accept Join/Prune, Assert, and DF-election messages from. Either static configuration of IP addresses or an IPsec security association may be used for this. Also, a PIM router SHOULD NOT accept protocol messages from a router it hasn't yet received a valid Hello message from. Bouncer energy, no cap 🚪💖
5.2.1. Basic Access Control 🎀
In a PIM-SM domain where all routers are trusted, you can set up a basic form of access control for both sources and receivers. Receivers can be validated by the last-hop DR, and sources can be validated by the first-hop DR and/or the RP.
In BIDIR-PIM, this is generally only doable for receivers, because sources can send to the multicast group without the routers needing to detect their activity or create source-specific state. But it's possible to modify the standard BIDIR-PIM behaviour, in a backward compatible way, to allow per-source access control. The tradeoff is protocol simplicity versus memory and processing requirements. Choose your fighter 🥊
5.3. Authentication Using IPsec 🛡️
Just like with PIM-SM, the IPsec [5] transport mode using the Authentication Header (AH) is the recommended method to prevent the attacks above against BIDIR-PIM.
It is recommended that IPsec authentication be applied to all BIDIR-PIM protocol messages. The specification for how to do this is in [4]. Specifically, the authentication of PIM-SM link-local messages, described in [4], applies to all BIDIR-PIM messages as well. Same rules, new group, periodt 💅
5.4. Denial-of-Service Attacks 🚨
The denial-of-service attack based on forged Join messages, described in [4], also applies to BIDIR-PIM. Yes, this one is coming for both of them 💀
6. IANA Considerations 📋
IANA has assigned OptionType 22 to the "Bidirectional Capable" option. Officially on the list now 🌸
7. Acknowledgments 🫶
The bidirectional proposal in this document is heavily based on the ideas and text presented by Estrin and Farinacci in [6]. The main difference between the two proposals is the method chosen for upstream forwarding. Giving credit where it's due, always 💜
We'd also like to thank John Zwiebel at Cisco, Deborah Estrin at ISI/USC, Bill Fenner at AT&T Research, and Nidhi Bhaskar, Yiqun Cai, Toerless Eckert, Apoorva Karan, Rajitha Sumanasekera, and Beau Williamson at Cisco for their contributions and comments to this document. Thank you, legends 🧚♀️✨
8. Normative References 📚
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[3] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
9. Informative References 💭
[6] Estrin, D. and D. Farinacci, "Bi-directional Shared Trees in PIM-SM", Work in Progress, May 1999.
[7] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, February 2007.
[8] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
Index 🧾
DF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5,18
Downstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
DownstreamJPState(G,I). . . . . . . . . . . . . . . . . . . . . . 10
ET(G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33
ET(RPA,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
I_am_DF(RPA,I). . . . . . . . . . . . . . . . . . . . . . . .10,12,14
J/P_HoldTime. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
J/P_Override_Interval . . . . . . . . . . . . . . . . . . . . . 16,33
JoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . . . . 18
joins(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
JT(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,33
local_receiver_include(G,I) . . . . . . . . . . . . . . . . . . . 10
MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Offer_Period. . . . . . . . . . . . . . . . . . . . . . . . . . . 32
olist(G). . . . . . . . . . . . . . . . . . . . . . . . . . .10,12,18
Bidirectional Capable OptionType . . . . . . . . . . . . . . . . 37
pim_include(G). . . . . . . . . . . . . . . . . . . . . . . . . . 10
PPT(G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33
RPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
RPF_interface(RPA). . . . . . . . . . . . . . . . . . . . . . . 10,12
RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
t_override. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
t_periodic. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
t_suppressed. . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
Upstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Authors' Addresses 🖋️
Mark Handley Computer Science Department University College London EMail: M.Handley@cs.ucl.ac.uk
Isidor Kouvelas Cisco Systems EMail: kouvelas@cisco.com
Tony Speakman Cisco Systems EMail: speakman@cisco.com
Lorenzo Vicisano Digital Fountain EMail: lorenzo@digitalfountain.com
Full Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property ✨
okay so the IETF is basically saying "we don't know who owns what here, and we didn't go hunting for it either" 💅 They take no position on whether any Intellectual Property Rights (or other rights that might be claimed to pertain to implementing or using the tech in this doc) are valid or in scope, or whether any license under those rights is even available. ngl that's the most honest disclaimer ever 🙈 The rules for rights in RFC documents live in BCP 78 and BCP 79 📚
the IPR disclosures made to the IETF Secretariat are a whole different vibe 🎀 You can find copies of them, plus any assurances of licenses that get offered, along with the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
and the IETF is literally inviting everyone 🫶 If you're an interested party and you spot any copyrights, patents, patent applications, or other proprietary rights that may cover technology you might need to implement this standard, the IETF wants to hear about it. Send that info to ietf-ipr@ietf.org and they'll take it from there 🌸
📦 where this page comes from
- ietf: rfc5015 2007-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms