rfc-8775

PIM Designated Router Load Balancing

Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, A. Green
date2020-04 streamIETF areartg wgpim statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc8775 doi10.17487/RFC8775
On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to the PIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers.

Extracted elements (28)

design-rationale §5.3

GDR Candidate addresses in the DRLB-List are recommended to be sorted in descending order so that hash-based GDR assignment is deterministic regardless of the order in which the DR learns of new candidates.

multicast, realtime

design-rationale §5.7

The Assert mechanism is reused for GDR transitions (with near-maximum metric values) to minimize packet loss while tolerating a brief period of duplicates, rather than requiring a coordinated cut-over that would risk traffic black-holing.

multicast, realtime

design-rationale §5.2.2

The modulo hash algorithm has poor failover characteristics with more than two GDRs: when one GDR fails, all groups may be reassigned to different GDRs rather than only those previously served by the failed router. This is acknowledged as a known limitation; future work may define consistent-hashing alternatives.

multicast, realtime

design-rationale §3

This extension applies only to last-hop routers, not first-hop routers, because source tree building uses the sender's IP address rather than the DR's address, and first-hop load balancing can be achieved naturally via IGP equal-cost multipath without additional protocol complexity.

multicast, realtime

interoperability-note §5.8

Backward compatibility: if the DR does not support DRLB, no load balancing occurs. If non-DR routers do not support DRLB, they are simply not considered GDR Candidates and load balancing may still operate among supporting routers.

multicast, realtime

interoperability-note §5.1

If different hash algorithms are advertised among routers on a LAN, only routers advertising the same hash algorithm as the DR (and with the same DR priority) are eligible for GDR election; others are excluded from load balancing.

multicast, realtime

normative-requirement §5.6 MUST

All GDR Candidates MUST use the hash masks advertised in the DRLB-List Option, even if they differ from those the candidate was locally configured with.

multicast, realtime

normative-requirement §5.3.2 MUST

All hash masks in the DRLB-List Option MUST have the same number of bits as the IP source address in the PIM Hello IP header, and all GDR Candidate addresses MUST be in the same address family as the PIM Hello IP header.

multicast, realtime

normative-requirement §5.6 MUST

All routers MUST ignore the DRLB-List Hello Option if received from a PIM router that is not the DR; it MUST only be processed by routers announcing the DRLB-Cap Option with the same hash algorithm as the DR.

multicast, realtime

normative-requirement §5.1 SHOULD

Default hash mask values SHOULD be: RP Hash Mask zero (no bits set), Source and Group Hash Masks all-bits-set. These simplify configuration for most deployments.

multicast, realtime

normative-requirement §5.4 SHOULD

If a PIM neighbor in the GDR Candidate list expires, stops announcing DRLB-Cap, changes DR priority or hash algorithm, the DR SHOULD immediately send a triggered hello with an updated DRLB-List excluding that neighbor.

multicast, realtime

normative-requirement §5.6 MUST

If the router becomes the new GDR for a group or (S,G) pair with local receiver interest, a multicast forwarding tree MUST be built per RFC 7761.

multicast, realtime

normative-requirement §5.4 SHOULD

The DR SHOULD consider a neighbor as a GDR Candidate and insert it into the DRLB-List if the neighbor's DRLB-Cap announces the same hash algorithm and the neighbor has the same DR priority as the DR.

multicast, realtime

normative-requirement §5.3.1 MUST

The DRLB-Cap Hello Option MUST be advertised by routers on all interfaces where DR Load Balancing is enabled, and it MUST be included at most once.

multicast, realtime

normative-requirement §5.3.2 MUST

The DRLB-List Hello Option MUST only be advertised by the elected PIM DR and MUST be ignored if received from a non-DR router.

multicast, realtime

normative-requirement §5.7 MUST

When a router stops acting as the GDR for a group, it MUST set the Assert metric preference to maximum (0x7fffffff) and the Assert metric to one less than maximum (0xfffffffe) to minimize packet loss during GDR transitions.

multicast, realtime

protocol-element §4.1

GDR Candidate: a router eligible for GDR election that has the same DR priority and runs the same GDR election hash algorithm as the DR. Only routers included in the DR's DRLB-List act as GDR Candidates.

multicast, realtime

protocol-element §5.3.2

GDR Candidate address in DRLB-List: if the Interface ID option (RFC 6395) is present with a non-zero Router Identifier, the candidate address is set to that Router ID (for IPv6: 96 zero bits followed by the 32-bit Router ID); otherwise the PIM Hello IP source address is used.

multicast, realtime

protocol-element §2

Group Designated Router (GDR): for each multicast flow ((*,G) for ASM or (S,G) for SSM), a hash algorithm selects one router as the GDR, which is responsible for initiating the multicast forwarding tree building process for that flow.

multicast, realtime

protocol-element §5.1

Hash masks (RP Hash Mask, Source Hash Mask, Group Hash Mask) are used to extract bits from IP address fields for hash computation. A zero mask means no bits are set; an all-bits-set mask means all bits participate in hashing.

multicast, realtime

protocol-element §5.2

The modulo hash algorithm computes hashvalue_SG as the XOR of the masked-and-shifted source and group address values, modulo the number of GDR Candidates (GDRC). For ASM, hashvalue_RP or hashvalue_Group is used depending on whether the RP Hash Mask is non-zero.

multicast, realtime

registry §7

IANA assigned value 34 in the 'PIM-Hello Options' registry for the DRLB-Cap Hello Option (Length 4), and value 35 for the DRLB-List Hello Option (variable Length).

registry, multicast

registry §7

IANA created the 'PIM Designated Router Load-Balancing Hash Algorithms' registry under the 'Protocol Independent Multicast (PIM)' branch. Initial entry: Type 0 = Modulo (RFC 8775). Types 1-255 are Unassigned. New assignments require IETF Review.

registry, multicast

security-consideration §8

An attacker may send a single high-rate flow or multiple flows designed to hash to the same GDR, overloading that router and undermining the intended load balancing. If a GDR is subverted, it can be made to stop forwarding all traffic assigned to it.

security, multicast

security-consideration §8

Security of the DRLB Hello Options relies entirely on the security of PIM Hello messages (RFC 7761). A subverted DR could omit or add GDR Candidates or advertise an unsupported algorithm, disrupting load balancing—analogous to existing DR subversion attacks that manipulate DR priority.

security, multicast

state-machine §5.6

GDR role state: a router transitions to GDR when it is in the DRLB-List Candidate field and the hash algorithm selects it for a group; it transitions out of GDR (and sends an Assert with near-maximum metric) when removed from the list, when the DRLB-List is no longer received, or when the DR neighbor liveness timer expires.

multicast, realtime

wire-format §5.3.1

DRLB-Cap Hello Option: Type=34, Length=4. Contains a 24-bit Reserved field (transmitted as zero) and an 8-bit Hash Algorithm field indicating the GDR election algorithm (0 = Modulo, per IANA registry).

multicast, realtime

wire-format §5.3.2

DRLB-List Hello Option: Type=35, variable Length=(3+n)x(4 or 16) bytes. Contains Group Mask, Source Mask, and RP Mask (each 32 or 128 bits depending on IP version), followed by a list of n GDR Candidate Addresses (32 or 128 bits each).

multicast, realtime