RFC 8775
PIM Designated Router Load Balancing
PIM Designated Router Load Balancing 💖
Okay bestie, this is RFC 8775, and it's giving load balancing for multicast 🦋✨
- Document number: RFC 8775
- Category: Standards Track (the real deal, no cap 💅)
- Date: April 2020
- Authors: Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, and A. Green 🫶
- Affiliations: Alibaba Group, Cisco Systems, Inc., and British Telecom
- ISSN: 2070-1721
- Obsoletes / Updates: The title block doesn't list any, so nothing to see here 🙈
- Status: Internet Standards Track 🌈
Okay so, the whole point is this 👑 PIM-SM (PIM Sparse Mode) routers on a multi-access network elect one router as the Designated Router, and that DR is in charge of keeping track of local multicast listeners and forwarding data to them. Right now that's a lot of pressure on one router. This document changes PIM-SM so that more than one router can take on that job, and the forwarding load gets spread out across them. Main character energy for the whole LAN 🎀
1. Introduction ✨
Okay so picture a multi-access LAN (like Ethernet) with one or more PIM-SM [RFC7761] routers 🦋. One of them gets elected as the Designated Router (DR). The PIM DR has two jobs in PIM-SM 💅. First, for any active sources on the LAN, it registers with the Rendezvous Point (RP) if the group is operating in PIM-SM. Second, it tracks local multicast listeners and forwards data to them if the group is operating in PIM-SM. Iconic multitasking, honestly 😭
Let's look at this LAN in Figure 1 🌸:
(core networks)
| | |
| | |
R1 R2 R3
| | |
----(LAN)----
|
|
(many receivers)Figure 1: LAN with Receivers
So R1 gets elected as the DR 👑. According to PIM-SM, R1 is responsible for forwarding traffic onto that LAN for all the local members. On top of keeping track of membership reports, R1 also starts the creation of source and/or shared trees toward the senders or the RPs. The membership reports are IGMP or MLD messages, and this applies to any version of IGMP and MLD. The newest ones are IGMPv3 [RFC3376] and MLDv2 [RFC3810] 🧚.
Now here's the tea ☕. Having a single router be the DR and also do all the data-plane forwarding causes some problems 😭. One big one is that the total bandwidth is capped at whatever R1 can handle, meaning the capacity of its incoming links, its LAN interface, and its total forwarding capacity. Lowkey a bottleneck situation 💀. Also, it's super common for a LAN to have switches running IGMP/MLD or PIM snooping [RFC4541] 🍓. That lets multicast packets get forwarded only to the segments that lead to receivers who said they're interested in a group via IGMP or MLD. Switched Ethernet means the aggregated bandwidth can be way bigger, sometimes by a huge amount, than a single link. So let's upgrade Figure 1 and add an Ethernet switch in Figure 2 ✨:
(core networks)
| | |
| | |
R1 R2 R3
| | |
+=gi1===gi2===gi3=+
+ +
+ switch +
+ +
+=gi4===gi5===gi6=+
| | |
H1 H2 H3
Figure 2: LAN with Ethernet SwitchFigure 2: LAN with Ethernet Switch
Let's assume each individual link is Gigabit Ethernet 🔥. Each router (R1, R2, and R3) and the switch have enough forwarding capacity to handle hundreds of gigabits of data 💜.
Next, let's say each host asks for 500 Mbps of unique multicast data 🌈. That totals 1.5 Gbps, which is less than what the switch or the combined uplink bandwidth across the routers can handle, even if one router fails 🫶.
BUT here's the catch 🙈. The link between R1 and the switch, through port gi1, can only handle 1 Gbps of throughput. And if R1 is the only DR (the PIM DR elected using the procedure defined by [RFC7761]), at least 500 Mbps worth of data gets lost, because the only link that can pull traffic from the routers to the switch is gi1. Honestly the whole network's throughput is limited by that single connection between the PIM DR and the switch (or the LAN, as in Figure 1) 😭.
Another big issue is failover 🥺. If R1 is the only forwarder on a shared LAN and R1 goes out of service, multicast forwarding for the entire LAN has to be rebuilt by the newly elected PIM DR. But if multiple routers could forward to the LAN for different groups, a router failing would only disrupt a subset of the flows, which makes the whole network more resilient 💅✨.
So this document specifies a modification to PIM-SM that allows more than one of these routers, called Group Designated Routers (GDRs), to be selected so that the forwarding load can be distributed across a number of routers 🦋👑.
2. Terminology 🎀
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
With respect to PIM-SM, this document follows the terminology defined in [RFC7761] 🌸.
This document also introduces these new acronyms 🧚:
- GDR: Group Designated Router. For each multicast flow, either a (*,G) for Any-Source Multicast (ASM) or an (S,G) for Source-Specific Multicast (SSM) [RFC4607], a hash algorithm (described below) is used to select one of the routers as a GDR. The GDR is responsible for initiating the forwarding tree building process for the corresponding multicast flow. ✨
- GDR Candidate: a router that has the potential to become a GDR. There might be multiple GDR Candidates on a LAN, but only one can become the GDR for a specific multicast flow. 💖
3. Applicability 🦋
The extension specified in this document applies to PIM-SM routers acting as last-hop routers (the ones with directly connected receivers) 🎀. It does not change the behavior of a PIM DR or any other routers on the first-hop network (the ones with directly connected sources). Why? Because the source tree is built using the IP address of the sender, not the IP address of the PIM DR that sends PIM registers toward the RP 🙈. Load balancing between first-hop routers can happen naturally if an IGP provides equal-cost multiple paths, which it usually does in practice 💅. And distributing the load to do source registration doesn't justify the extra complexity needed to support it. Not me saying "not worth it" 💀.
🫶 That's part 1 of 4, bestie! More coming, so stay tuned 🌈💜
4. Functional Overview ✨
okay so, in the PIM DR election from [RFC7761] 💅, when a bunch of routers are hanging out on one multi-access LAN (think Ethernet 🌸), one of them gets picked to be the PIM DR. The PIM DR is the one in charge of sending local Join/Prune messages towards the RP or source. 🫶 To pick it, each PIM router on the LAN looks at the PIM Hello messages it gets and compares its own DR priority and IP address with its neighbors'. The router with the highest DR priority wins the PIM DR spot 👑. If there's a tie, the IP addresses break it, as described in [RFC7761].
Now here's the new bit 🦋. To share the forwarding load across last-hop routers, there's the normal PIM DR election AND one or more GDRs get elected on that multi-access LAN too. There's only one PIM DR on the LAN, but there can be multiple GDR Candidates, which is so iconic for load sharing 🔥.
For each multicast flow (that's (*,G) for ASM and (S,G) for SSM), a hash algorithm (Section 5.1) picks one router to be the GDR 💖. The brand new DR Load-Balancing Capability (DRLB-Cap) PIM Hello Option is how routers announce that they have the Capability, plus which hash algorithm type they use 🧚. Routers that put the new DRLB-Cap Option in their PIM Hello, use the same GDR election hash algorithm, and have the same DR priority as the PIM DR count as GDR Candidates ✨.
Hash masks are defined separately for Source, Group, and RP, so PIM ASM and SSM can both be handled 🌈. The masks, plus a sorted list of GDR Candidate addresses, get announced by the DR in a new DR Load-Balancing List (DRLB-List) PIM Hello Option 💜.
A hash algorithm built on the announced Source, Group, or RP masks lets one GDR get assigned to each multicast state 🎀. That GDR is responsible for starting the creation of the multicast forwarding tree for multicast traffic. Main character energy 👑😭.
4.1. GDR Candidates
GDR is the new concept this specification introduces 🍓. GDR Candidates are routers that are eligible for GDR election on the LAN. To become a GDR Candidate, a router must have the same DR priority and run the same GDR election hash algorithm as the DR on the LAN 💅.
Let's look at an example 🙈. Say there are 4 routers on the LAN: R1, R2, R3, and R4, each announcing a DRLB-Cap Option. R1, R2, and R3 all have the same DR priority, but R4's DR priority is less preferred. So R4 won't be eligible for GDR election, because R4 won't become a PIM DR unless all of R1, R2, and R3 go out of service 💀.
Now say router R1 wins the PIM DR election. R1 and R2 advertise the same hash algorithm for GDR election, but R3 advertises a different one. In this case, only R1 and R2 are eligible for GDR election, and R3 is left out 🥲.
As the DR, R1 includes its own Load-Balancing Hash Masks and the identities of R1 and R2 (the GDR Candidates) in its DRLB-List Hello Option 🫶.
5. Protocol Specification 🎀
5.1. Hash Mask and Hash Algorithm
A hash mask is used to pull out a number of bits from the matching IP address field (32 for IPv4, 128 for IPv6) and then calculate a hash value 🦋. The hash value is used to select a GDR from the GDR Candidates the PIM DR advertised. Hash masks let certain flows always get forwarded by the same GDR, because they ignore certain bits in the hash value calculation, so the hash values end up being the same ✨. For example, 0.0.255.0 defines a hash mask for an IPv4 address that masks the first, second, and fourth octets. That means only the third octet influences the hash value computed 🧚. The masks don't need to be a contiguous set of bits either. For example, for IPv4, 15.15.15.15 would be a valid mask 💅.
In the text below, a hash mask is sometimes said to be zero. A hash mask is zero if no bits are set, which means 0.0.0.0 for IPv4 and :: for IPv6 🌸. And a hash mask is said to be an all-bits-set mask if it's 255.255.255.255 for IPv4 or ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff for IPv6 🔥.
There are three hash masks defined:
- RP Hash Mask
- Source Hash Mask
- Group Hash Mask
The hash masks need to be configured on the PIM routers that could potentially become a PIM DR, unless the implementation provides default hash mask values 💖. An implementation SHOULD have default hash mask values as follows. The default RP Hash Mask SHOULD be zero (no bits set). The default Source and Group Hash Masks SHOULD both be all-bits-set masks. These default values are likely fine for most deployments and keep configuration simple 🫶. You only need other masks if you want to make sure certain flows get forwarded by the same GDR 👑.
The DRLB-List Hello Option contains a list of GDR Candidates. The first one listed has ordinal number 0, the second one listed has ordinal number 1, and the last one has ordinal number N - 1 if there are N candidates listed 🍓. The hash value computed will be the ordinal number of the GDR Candidate acting as the GDR for the flow in question 🦋.
The input to be hashed is determined like this 🌈:
- If the group is in ASM mode and the RP Hash Mask announced by the PIM DR is not zero (at least one bit is set), calculate the value of hashvalue_RP (Section 5.2) to determine the GDR.
- If the group is in ASM mode and the RP Hash Mask announced by the PIM DR is zero (no bits are set), obtain the value of hashvalue_Group (Section 5.2) to determine the GDR.
- If the group is in SSM mode, use hashvalue_SG (Section 5.2) to determine the GDR.
A simple modulo hash algorithm is defined in this document ✨. But to let another hash algorithm be used, a 1-octet "Hash Algorithm" field is included in the DRLB-Cap Hello Option, which specifies the hash algorithm the router uses 🧚.
If different hash algorithms are advertised among the routers on a LAN, only the routers that advertise the same hash algorithm as the DR (and also have the same DR priority as the DR) are eligible for GDR election 💅.
5.2. Modulo Hash Algorithm
As part of computing the hash, the notation LSZC(hash_mask) is used to denote the number of zeroes counted from the least significant bit of a hash mask hash_mask 🌸. For example, LSZC(255.255.128) is 7 and LSZC(ffff:8000::) is 111. If all bits are set, LSZC will be 0. If the mask is zero, LSZC will be 32 for IPv4 and 128 for IPv6 🔥.
The number of GDR Candidates is denoted as GDRC 💖.
The idea behind the modulo hash algorithm is, in simple terms, this: the matching mask gets applied to a value, then the result is shifted right LSZC(mask) bits, so the least significant bits that were masked out aren't considered 🫶. Then the result gets masked by 0xffffffff, which keeps only the last 32 bits of the result (this only makes a difference for IPv6) 👑. Finally, the hash value is this result modulo the number of GDR Candidates (GDRC) 🍓.
The modulo hash algorithm, for computing the values hashvalue_RP, hashvalue_Group, and hashvalue_SG, is defined as follows 🦋.
hashvalue_RP is calculated as:
(((RP_address & RP_mask) >> LSZC(RP_mask)) & 0xffffffff) % GDRC
RP_address is the address of the RP defined for the group, and
RP_mask is the RP Hash Mask.hashvalue_Group is calculated as:
(((Group_address & Group_mask) >> LSZC(Group_mask)) & 0xffffffff)
% GDRC
Group_address is the group address, and Group_mask is the Group
Hash Mask.hashvalue_SG is calculated as:
((((Source_address & Source_mask) >> LSZC(Source_mask)) &
0xffffffff) ^ (((Group_address & Group_mask) >> LSZC(Group_mask))
& 0xffffffff)) % GDRC
Group_address is the group address, and Group_mask is the Group
Hash Mask.5.2.1. Modulo Hash Algorithm Examples
Let's walk through an example to see how the algorithm works 🧚. Router X, with IPv4 address 203.0.113.1, receives a DRLB-List Hello Option from the DR. That option announces RP Hash Mask 0.0.255.0 and a list of GDR Candidates, sorted by IP address from high to low: 203.0.113.3, 203.0.113.2, and 203.0.113.1. The ordinal numbers assigned to those addresses would be:
0 for 203.0.113.3; 1 for 203.0.113.2; 2 for 203.0.113.1 (Router X).Assume there are 2 RPs: RP1 192.0.2.1 for Group1 and RP2 198.51.100.2 for Group2. Following the modulo hash algorithm 🌈:
- LSZC(0.0.255.0) is 8, and GDRC is 3. The hashvalue_RP for Group1 with RP RP1 is:
(((192.0.2.1 & 0.0.255.0) >> 8) & 0xffffffff % 3)
= 2 % 3
= 2This matches the ordinal number assigned to Router X, so Router X will be the GDR for Group1 🎉.
- The hashvalue_RP for Group2 with RP RP2 is:
(((198.51.100.2 & 0.0.255.0) >> 8) & 0xffffffff % 3)
= 100 % 3
= 1This is different from the ordinal number of Router X (2). So, Router X will not be GDR for Group2 🙅♀️.
For IPv6, consider a similar example 💜. Router X, with IPv6 address fe80::1, receives a DRLB-List Hello Option from the DR. That option announces RP Hash Mask ::ffff:ffff:ffff:0 and a list of GDR Candidates, sorted by IP address from high to low: fe80::3, fe80::2, and fe80::1. The ordinal numbers assigned to those addresses would be:
0 for fe80::3; 1 for fe80::2; 2 for fe80::1 (Router X).Assume there are 2 RPs: RP1 2001:db8::1:0:5678:1 for Group1 and RP2 2001:db8::1:0:1234:2 for Group2. Following the modulo hash algorithm 🦋:
- LSZC(::ffff:ffff:ffff:0) is 16, and GDRC is 3. The hashvalue_RP for Group1 with RP RP1 is:
(((2001:db8::1:0:5678:1 & ::ffff:ffff:ffff:0) >> 16) &
0xffffffff % 3)
= ((::1:0:5678:0 >> 16) & 0xffffffff % 3)
= (::1:0:5678 & 0xffffffff % 3)
= ::5678 % 3
= 2This matches the ordinal number assigned to Router X, so Router X will be the GDR for Group1 🌸.
- The hashvalue_RP for Group2 with RP RP2 is:
(((2001:db8::1:0:1234:1 & ::ffff:ffff:ffff:0) >> 16) &
0xffffffff % 3)
= ((::1:0:1234:0 >> 16) & 0xffffffff % 3)
= (::1:0:1234 & 0xffffffff % 3)
= ::1234 % 3
= 1This is different from the ordinal number of Router X (2). So, Router X will not be GDR for Group2 🙈.
5.2.2. Limitations
Okay, real talk, the modulo hash algorithm has poor failover characteristics when a shared LAN has more than two GDRs 😬. With more than two GDRs on a LAN, when one GDR fails, all of the groups may get reassigned to a different GDR, even the ones that weren't assigned to the failed GDR. However, lots of deployments only use two routers on a shared LAN for redundancy, so it's fine for them 🫶. Future work may define new hash algorithms where only the groups assigned to the failed GDR get reassigned 🔮.
The modulo hash algorithm uses, at most, 32 consecutive bits of the input addresses for its computation. Exactly which bits get used from the source, group, or RP addresses depends on the respective masks 🧐. This limitation may be an issue for IPv6 deployments, since not all bits of the IPv6 addresses are considered 💀. If this causes operational issues, a new hash algorithm would need to be defined 💅.
5.3. PIM Hello Options
okay so PIM routers add a brand new option called "Load-Balancing Capability (DRLB-Cap)" to their PIM Hello messages 💖
The elected PIM DR also adds its own thing: a "DR Load-Balancing List (DRLB-List) Hello Option" 🦋 This one holds three hash masks (the ones we just talked about) plus a list of the GDR Candidate addresses on the LAN. It is recommended that those GDR Candidate addresses get sorted in descending order. The reason is ✨ it makes the modulo hash algorithm predictable. Which GDR handles which groups stays the same no matter what order the DR happened to learn about the candidates in. Iconic behavior 👑
5.3.1. PIM DR Load-Balancing Capability (DRLB-Cap) Hello Option
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 = 34 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Hash Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: PIM DR Load-Balancing Capability Hello Option 🎀
Type: 34
Length: 4
Reserved: Transmitted as zero, ignored on receipt. 🌸
Hash Algorithm: The hash algorithm type. Pick a value from the IANA "PIM Designated Router Load-Balancing Hash Algorithms" registry. 0 is the one for the hash algorithm defined in this document.
This DRLB-Cap Hello Option MUST be advertised by routers on all interfaces where DR Load Balancing is enabled. Also note that the option gets included at most once, so no doubling up 🙈
5.3.2. PIM DR Load-Balancing List (DRLB-List) Hello Option
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 = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GDR Candidate Address(es) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: PIM DR Load-Balancing List Hello Option 🧚
Type: 35
Length: (3 + n) x (4 or 16) bytes, where n is the number of GDR Candidates. 🍓
Group Mask (32/128 bits): The mask applied to group addresses as part of the hash computation.
Source Mask (32/128 bits): The mask applied to source addresses as part of the hash computation.
RP Mask (32/128 bits): The mask applied to RP addresses as part of the hash computation.
All masks MUST have the same number of bits as the IP source address in the PIM Hello IP header. Bits must match, bestie, no exceptions 💅
GDR Candidate Address(es) (32/128 bits): The list of GDR Candidate(s).
All addresses MUST be in the same address family as the PIM Hello IP header. It is recommended that the addresses are sorted in descending order. 🌈
If the "Interface ID" option, as specified in [RFC6395], is present in a GDR Candidate's PIM Hello message and the "Router Identifier" portion is non-zero:
- For IPv4, the "GDR Candidate Address" will be set directly to the "Router Identifier". 🦋
- For IPv6, the "GDR Candidate Address" will be 96 bits of zeroes, followed by the 32 bit Router Identifier. ✨
If the "Interface ID" option is not present in a GDR Candidate's PIM Hello message, or if the "Interface ID" option is present but the "Router Identifier" field is zero, the "GDR Candidate Address" will be the IPv4 or IPv6 source address of the PIM Hello message. Fallback energy, but make it make sense 🫶
This DRLB-List Hello Option MUST only be advertised by the elected PIM DR. It MUST be ignored if received from a non-DR. The option MUST also be ignored if the hash masks are not the correct number of bits, or if GDR Candidate addresses are in the wrong address family. 💀 Rude to the wrong routers, but a safe move.
5.4. PIM DR Operation
The DR election process is still the same as defined in [RFC7761] 💜 Nothing new there, bestie. The DR advertises the new DRLB-List Hello Option, which contains the mask values from user configuration (or default values), followed by a list of GDR Candidate addresses.
Quick note: if a router included the "Interface ID" option in its hello and the Router ID is non-zero, the Router ID is what forms that router's GDR Candidate address, as we covered in the last section 🧠 It is recommended that the list be sorted from the highest value to the lowest value. The whole point of sorting is to keep behavior deterministic, no matter what order the DR learns about new candidates in. Also, as with non-DR routers, the DR advertises the DRLB-Cap Hello Option too, to show it can support the new functionality and which GDR election hash algorithm it uses 🔥
If a PIM DR receives a neighbor's DRLB-Cap Hello Option that has the same hash algorithm as the DR, and the neighbor has the same DR priority as the DR, the PIM DR SHOULD consider that neighbor as a GDR Candidate and insert the GDR Candidate's Address into the list of the DRLB-List Option. However, the DR may have policies limiting which candidates, or how many, get included. Likewise, the DR SHOULD include itself in the list of GDR Candidates. It is permissible not to, though, for instance if some policy restricts the candidate set 🎀
If a PIM neighbor in the list expires, stops announcing the DRLB-Cap Hello Option, changes DR priority, changes hash algorithm, or otherwise becomes ineligible as a candidate, the DR SHOULD immediately send a triggered hello with a new list in the DRLB-List option, excluding that neighbor. Plot twist handled, no drama 😭
If a new router becomes eligible as a candidate, there is no urgency to send out an updated list. An updated list SHOULD be included in the next hello. Chill, it's fine 🌸
5.5. PIM GDR Candidate Operation
When an IGMP/MLD report is received, the GDR Candidates use a hash algorithm to figure out which router is going to be responsible for building forwarding trees on behalf of the host 🦋
The router MUST include the DRLB-Cap Hello Option in all PIM Hello messages sent on the interface. Heads up, though: having the DRLB-Cap Option in your PIM Hello does NOT guarantee you'll be considered a GDR Candidate 🙈 Once the DR election is done, the DRLB-List Hello Option is received from the current PIM DR, and that list contains the selected GDR Candidates.
A router only acts as a GDR Candidate if it is included in the GDR Candidate list of the DRLB-List Hello Option. See the next section for details 💖
5.6. DRLB-List Hello Option Processing
This section covers how the DRLB-List Hello Option gets processed, including the case where it showed up in the previous hello but not in the current one 👑
All routers MUST ignore the DRLB-List Hello Option if it is received from a PIM router that is not the DR. The option MUST only be processed by routers that are announcing the DRLB-Cap Option, and only if the hash algorithm announced by the DR is the same as the local announcement. All GDR Candidates MUST use the hash masks advertised in the Option, even if they differ from the ones the candidate was configured with. The DR MUST also process its own DRLB-List Hello Option. Yes, the DR checks its own homework too 🫶
A router stores the latest option contents that were announced, if any, and deletes the previous contents. The router MUST also compare the new contents with any previous contents and, if there are any changes, continue processing as below. Note that if the option does not pass the above checks, the processing below MUST be done as if the option was not announced. ✨
If the contents of the DRLB-List Option, the masks, or the candidate list differ from the previously saved copy, if it is received for the first time, or if it is no longer being received or accepted, the option MUST be processed as below. Okay, here's the plan 🧚
- If the local router is included in the "GDR Candidate Address(es)" field, it looks for its own address, or, if it announces a non-zero Router ID, its own Router ID. For each of the groups, or source and group pairs, if the group is in SSM mode with local receiver interest, the router MUST run the hash algorithm to determine which of them is for the GDR.
- If there is no change in the GDR status, then no further action is required. Easy 🌈
- If the router becomes the new GDR, then a multicast forwarding tree MUST be built [RFC7761]. Main character moment 👑
- If the router is no longer the GDR, then it uses an Assert as explained in Section 5.7. 🥲
- If one of the following occurs:
- the local router is not included in the "GDR Candidate Address(es)" field,
- the DRLB-List Hello Option is no longer included in the DR's Hello, or
- the DR's Neighbor Liveness Timer expires [RFC7761],
then, for each group (or each source and group pair if the group is in SSM mode) with local receiver interest for which the router is the GDR, the router uses an Assert as explained in Section 5.7. Bye-bye, GDR role, but it's not personal 💅
5.7. PIM Assert Modification ✨
okay so GDR changes can happen for a few reasons 👀 like a config change, a GDR Candidate going down, or a brand new router showing up and becoming a GDR Candidate 🌸 and this can absolutely happen while flows are being forwarded 😭 If the GDR for an active flow changes, there's likely to be some disruption, like packet loss or duplicates. The asserts are what keep the packet loss low, while letting a small amount of duplicates sneak through. 🫶
When a router stops acting as the GDR for a group (or for a source and group pair if SSM), it MUST set the Assert metric preference to maximum (0x7fffffff) and the Assert metric to one less than maximum (0xfffffffe). 🔥 So whenever it sends or receives an Assert for the group, it must use these values as the metric preference and metric, not the ones the unicast routing protocol gave it. main character energy 💅
The rest of this section is just for illustration purposes and is not part of the protocol definition, bestie 🧚
Let's say there are two flows, G1 and G2. R1 is the GDR for G1, and R2 is the GDR for G2. Then R3 comes up 🎀 and it's possible R3 becomes the GDR for both G1 and G2, so R3 starts building the forwarding tree for both of them. If R1 and R2 stop forwarding before R3 finishes, that's packet loss. 😩 But if R1 and R2 keep forwarding while R3 is building its trees, you get duplicates instead. Ugh, the struggle is real 💀
So when the GDR role changes like this, R1 and R2 don't just stop forwarding right away. They keep forwarding to G1 and G2 respectively, while R3 builds the forwarding trees for G1 and G2 at the same time. This leads to PIM Asserts. 🦋
For G1, R1 and R3 use the functionality described in this document to figure out the new GDR, which is R3. With the modified Assert behavior, R1 sets its Assert metric to the near maximum value, as we talked about above. That makes R3, which has a normal metric in its Assert, the Assert winner. R3 really said "it's giving me the spotlight" 👑
5.8. Backward Compatibility 🌈
okay so picture a hybrid Ethernet shared LAN, where some PIM routers support this functionality and some don't 🙈
- If the DR doesn't support the new functionality, then there won't be any load balancing. 💔
- If non-DR routers don't support the new functionality, they won't be considered as GDR Candidates and won't take part in load balancing. Load balancing may still happen on the link though 🫶
6. Operational Considerations 🧠
An administrator needs to think about what the total bandwidth requirements are, and then find a set of routers that together have enough spare capacity 💪 They also have to make sure each router can handle its own part, assuming the traffic is spread roughly equally among the routers. Ideally, one should also have enough bandwidth to cover the case where at least one router fails. And all routers should be able to reach the sources and RPs (if applicable) without going through the LAN. 🌸
Care must be taken when choosing which hash masks to configure. 🎀 Typically you'd configure the same masks on all the routers, so they match no matter which router gets elected as DR. The default masks are likely suitable for most deployments, so don't panic. 🍓 The RP Hash Mask must be configured (the default is no bits set) if you want to hash based on the RP address instead of the group address for ASM. The default masks use the entire group address, and the source address too if SSM, as part of the hash. An administrator can set other masks that mask out part of the addresses, so certain flows always get hashed to the same router. How you do that depends on how the group addresses are allocated. ✨
Only the routers announcing the same hash algorithm as the DR would be considered as GDR Candidates. So network admins need to make sure the desired set of routers all announce the same algorithm 🔥 Migrating between different algorithms isn't covered in this document, so that's a later problem 😌
7. IANA Considerations 📋
IANA has made these assignments in the "PIM-Hello Options" registry: value 34 for the PIM DR Load-Balancing Capability (DRLB-Cap) Hello Option (with Length of 4), and value 35 for the PIM DR Load-Balancing List (DRLB-List) Hello Option (with variable Length). 🦋
Per this document, IANA has also created a registry called "PIM Designated Router Load-Balancing Hash Algorithms" in the "Protocol Independent Multicast (PIM)" branch of the registry tree. It lists hash algorithms for use by PIM Designated Router Load Balancing. 💖
7.1. Initial Registry 🍓
The initial content of the registry looks like this:
+-------+------------+-----------+
| Type | Name | Reference |
+=======+============+===========+
| 0 | Modulo | RFC 8775 |
+-------+------------+-----------+
| 1-255 | Unassigned | |
+-------+------------+-----------+
Table 17.2. Assignment of New Hash Algorithms 🌈
New hash algorithms get assigned through the "IETF Review" procedure, see [RFC8126]. 💅
8. Security Considerations 🚨
okay bestie, this part is serious 😭 Security of the new DR Load-Balancing PIM Hello Options is only guaranteed by the security of PIM Hello messages, so the security considerations for PIM Hello messages, as described in PIM-SM [RFC7761], apply here too. 🔐
If the DR gets subverted, it could omit or add certain GDRs, or announce an unsupported algorithm. And if some other router gets subverted, it could be made the DR and cause similar issues. 💀 These issues are specific to this specification, but they aren't that different from existing attacks, like subverting a DR and lowering its DR priority so a different router becomes the DR. Not me getting dragged by the old attacks again 🙈
If, for any reason, the DR includes a GDR in the announced list that announces a different algorithm from the one the DR announces, the GDR is required to ignore the announcement. Then there will be no router acting as the DR for the flows that hash to that GDR. 😩
If a GDR gets subverted, it could potentially be made to stop forwarding all the traffic it's supposed to forward. This is also similar to what happens today if a DR gets subverted. 🫠
An administrator may be able to get the desired load balancing of known flows, but an attacker could send a single high-rate flow that gets served by a single GDR. Or they could send multiple flows that are expected to hash to the same GDR. ⚠️ Stay alert, babes 👑
9. References 📚
9.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395,
October 2011, <https://www.rfc-editor.org/info/rfc6395>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.9.2. Informative References 🦋
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.Acknowledgements 🫶
Huge shoutout to Steve Simlo and Taki Millonis for helping with the original idea! 💖 Thank you also to Alia Atlas, Bill Atwood, Joe Clarke, Alissa Cooper, Jake Holland, Bharat Joshi, Anish Kachinthaya, Anvitha Kachinthaya, Benjamin Kaduk, Mirja Kühlewind, Barry Leiba, Ben Niven-Jenkins, Alvaro Retana, Adam Roach, Michael Scharf, Éric Vyncke, and Carl Wallace for reviews and comments ✨ and to Toerless Eckert and Rishabh Parekh for the helpful conversation on the document 🌸
Authors' Addresses 💌
Yiqun Cai
Alibaba Group
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: yiqun.cai@alibaba-inc.com
Heidi Ou
Alibaba Group
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: heidi.ou@alibaba-inc.com
Sri Vallepalli
Email: vallepal@yahoo.com
Mankamana Mishra
Cisco Systems, Inc.
821 Alder Drive,
Milpitas, CA 95035
United States of America
Email: mankamis@cisco.com
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Email: stig@cisco.com
Andy Green
British Telecom
Adastral Park
Ipswich
IP5 2RE
United Kingdom
Email: andy.da.green@bt.comThat's the whole spec, bestie! 🌈💖 You made it through the entire RFC 8775 glow-up 👑
📦 where this page comes from
- ietf: rfc8775 2020-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms