Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
updated by
Extracted elements (26)
ECMP Redirect messages are sent only when there is a need to rebalance traffic (i.e., a Join or multicast traffic is detected on a non-desired interface), reducing the amount of control traffic compared to periodic or broadcast mechanisms.
Existing PIM ECMP implementations use hash algorithms to select RPF paths, which do not allow traffic distribution according to administrative metrics such as bandwidth, delay, or routing preferences. This leads to inefficient use of network resources and motivates the ECMP Redirect mechanism.
The ECMP Redirect is modeled after the existing PIM Assert message but differs in scope: Assert selects an upstream router within the same multi-access network, while Redirect selects both a network (interface) and an upstream router across different ECMP links.
A PIM router that does not support this specification will ignore PIM ECMP Redirect Hello Options and ECMP Redirect messages in received PIM packets, providing backward compatibility without disruption.
ECMP Redirect applies only to PIM Sparse Mode shared and source trees per RFC 4601. Its use in PIM Dense Mode (RFC 3973) or Bidirectional PIM (RFC 5015) is explicitly out of scope.
A router supporting this specification SHOULD NOT send ECMP Redirects on interfaces in an ECMP bundle if any neighbor in that bundle does not advertise the ECMP Redirect Hello Option; however, it SHOULD still process received ECMP Redirects on those interfaces.
An upstream router MAY choose not to send ECMP Redirects if it becomes aware that some downstream routers are unreachable via some links in the ECMP bundle.
An upstream router MUST send the PIM ECMP Redirect Hello Option in its PIM Hello messages if it supports this specification.
During transient state caused by a single link cut, the downstream router SHOULD select a new RPF neighbor, preferring one on the same LAN as the previous RPF neighbor. If none is reachable there, a different LAN is used, preferring the router that previously served as RPF neighbor (identified by Router ID in the Interface ID Hello option).
If a downstream router receives ECMP Redirects from multiple upstream routers, it SHOULD use the Preference, Metric, and address fields as tiebreakers (same procedure as PIM Assert) to choose the most preferred RPF interface and neighbor.
If an upstream router receives an ECMP Redirect, it SHOULD NOT change its forwarding behavior even if the Redirect makes it a less preferred RPF neighbor on the receiving interface.
If the Interface ID is not ignored, the receiving router MUST use the Interface ID instead of Neighbor Address to identify the new RPF neighbor, and MUST discard the message if the Interface ID does not match the cached Interface ID.
If the Router ID portion of the Interface ID field is zero, the Interface ID field MUST be ignored.
The Neighbor Address in an ECMP Redirect message MUST be associated with an interface in the same ECMP bundle as the message's outgoing interface.
When downstream routers receive an ECMP Redirect, they SHOULD trigger PIM Joins toward the new RPF neighbor specified in the packet.
When the Interface ID field is ignored, an ECMP Redirect message MUST be discarded if the Neighbor Address field does not match the cached neighbor address.
An ECMP Bundle is a set of PIM-enabled interfaces on a router where all interfaces share the same routing metric and all next hops are one hop away. Each interface belongs to exactly one bundle; bundles are created via configuration.
The PIM ECMP Redirect Hello Option (Type=32, Length=0) is advertised in PIM Hello messages to signal support for ECMP Redirect. A router sends ECMP Redirects on an interface only when all neighbors on that interface have advertised this option.
The PIM ECMP Redirect message (Type=11) is sent by an upstream router to instruct downstream routers to redirect PIM Joins to a new RPF neighbor via a different ECMP interface. It carries Group Address, Source Address, Neighbor Address, Interface ID, Preference, and Metric fields.
PIM-Hello Option Type 32 has been assigned to the PIM ECMP Redirect Hello Option.
PIM Message Type 11 has been assigned to the ECMP Redirect message in the PIM Message Types registry created by RFC 6166.
Security of ECMP Redirect depends entirely on the security of the underlying PIM packet; the security considerations for PIM Assert packets in RFC 4601 apply. Spoofed ECMP Redirect packets may cause downstream routers to send PIM Joins to an undesired upstream router and trigger cascading ECMP Redirect messages.
The Metric field (64 bits) is the second tiebreaker when Preference values are equal; smaller values win. When both Preference and Metric are equal, the Neighbor Address or Interface ID (whichever identifies the RPF neighbor) is the third tiebreaker, with the larger value winning.
The PIM ECMP Redirect Hello Option is encoded as a 4-byte field with Type=32 (16 bits) and Length=0 (16 bits), carrying no additional data.
The PIM ECMP Redirect message carries: PIM Ver/Type/Reserved/Checksum (standard header), Group Address (64 or 160 bits, Encoded-Group format), Source Address (48 or 144 bits, Encoded-Unicast format), Neighbor Address (32 or 128 bits), Interface ID (64 bits), Preference (8 bits), and Metric (64 bits).
The Preference field (8 bits) is the primary tiebreaker; numerically smaller values are preferred. Reserved value 15 indicates the Metric field contains an NTP timestamp (RFC 5905 format) taken when the router started forwarding on that interface.