rfc-5015

Bidirectional Protocol Independent Multicast (BIDIR-PIM)

M. Handley, I. Kouvelas, T. Speakman, L. Vicisano
date2007-10 streamIETF areartg wgpim statusPROPOSED STANDARD pages43 canonicalhttps://www.rfc-editor.org/rfc/rfc5015 doi10.17487/RFC5015 errataview
This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]

updated by

Extracted elements (25)

design-rationale §1

BIDIR-PIM eliminates both Register encapsulation and source-specific (S,G) state by allowing packets to be natively forwarded from a source to the RP using shared tree state alone. This removes data-driven protocol events entirely, a key advantage over PIM-SM.

multicast, routing

design-rationale §3.5.1

The DF election algorithm is biased towards discarding DF information and suspending forwarding during periods of ambiguity. This is deliberate: the forwarding rules in Section 3.3 can produce loops if multiple routers simultaneously believe they are the DF, so safety is prioritized over continuity.

multicast, routing

design-rationale §3.5.1

The DF election is RPA-specific rather than group-specific. Because all bidirectional groups sharing an RPA have the same upstream direction, a single per-RPA per-link election suffices, significantly reducing the number of elections that must be performed.

multicast, routing

design-rationale §2.1

The RPA (Rendezvous Point Address) does not need to correspond to a physical interface of a real router, unlike PIM-SM which requires an actual RP router. This allows the RPA to be any routable address, giving administrators more flexibility in tree root placement.

multicast, routing

interoperability-note §3.2

BIDIR-PIM reuses the PIM-SM Hello and Join/Prune message formats and the Encoded-Unicast address format without modification. Routers must detect BIDIR-PIM capability via the OptionType 22 Hello option; absence of the option from a neighbor indicates a non-BIDIR-capable router and must be logged.

multicast, routing

normative-requirement §3.2 MUST

A BIDIR-PIM capable router MUST include the Bidirectional Capable PIM-Hello option (OptionType 22) in all Hello messages. If a neighbor's Hello lacks this option, the error MUST be logged to the router administrator in a rate-limited manner.

multicast, routing

normative-requirement §5.2 SHOULD NOT

A BIDIR-PIM router SHOULD provide an option to limit the set of neighbors from which it will accept Join/Prune, Assert, and DF-election messages. A PIM router SHOULD NOT accept protocol messages from a router from which it has not yet received a valid Hello message.

multicast, security

normative-requirement §3.4.1 RECOMMENDED

On point-to-point unnumbered interfaces, the router's address SHOULD be the source address chosen for its Hello packet. Additionally, BIDIR-PIM RECOMMENDS accepting PIM messages with a destination address of all zeros on point-to-point links to accommodate unnumbered interfaces.

multicast, routing

normative-requirement §3.5.2 MUST

When a router participates in a DF election for an RPA on the interface that its MRIB indicates as the RPF Interface, it MUST always advertise an infinite metric. On any other interface it MUST advertise the MRIB-provided metrics.

multicast, routing

normative-requirement §5.1.1 MUST

When authentication is available, spoofed DF-election messages MUST be discarded and a rate-limited warning message SHOULD be logged. BIDIR-PIM routers SHOULD also check the destination MAC address of received DF-election messages to prevent unicast-MAC partitioning attacks.

multicast, security

normative-requirement §3.4.1 MUST

When receiving a Join(*,G) or Prune(*,G), a router MUST first check whether the RP address in the message matches RPA(G). If it does not match, the Join or Prune MUST be silently dropped.

multicast, routing

protocol-element §3.6

Election reliability parameters: Election_Robustness defaults to 3 (minimum messages that must be lost for election to fail), Offer_Period is 100 ms, Backoff_Period is 1 second. Retransmissions within an election are randomly spaced using OPlow = rand(0.5, 1) * Offer_Period.

multicast, routing

protocol-element §2.1

The Designated Forwarder (DF) is a single router elected per RPA on every link (except the RPL itself). The DF holds exclusive responsibility for forwarding downstream traffic onto its link and forwarding upstream traffic from its link toward the RPL for all bidirectional groups mapping to that RPA.

multicast, routing

protocol-element §3.5.3.2

The DF election uses four control messages: Offer (advertising sender metric), Winner (declaring DF status), Backoff (DF acknowledging a better offer and instructing others to hold), and Pass (old DF transferring responsibility to the best offering router). All are sent to the ALL-PIM-ROUTERS group with TTL 1.

multicast, routing

registry §6

IANA assigned OptionType 22 to the 'Bidirectional Capable' PIM-Hello option. Additionally, all DF-election PIM control messages use PIM message Type 10 with subtypes 1–4 (Offer, Winner, Backoff, Pass).

registry, multicast

security-consideration §5.1.2

An attacker can prevent the DF election from ever converging by sending an infinite sequence of Offer messages, blocking establishment of multicast forwarding trees. BIDIR-PIM messages are link-local only (TTL 1 to ALL-PIM-ROUTERS), so all attacks require a directly connected attacker or a compromised router.

security, multicast

security-consideration §5.1.1

An attacker with direct link access can forge DF-election messages to either win the DF election itself (advertising the best metric) or install an arbitrary router as DF (impersonating the current DF in a Pass message). A concurrent DoS attack on the impersonated router can prevent it from detecting and correcting the anomaly.

security, multicast

security-consideration §5.3

IPsec transport mode with the Authentication Header (AH) is the recommended method to authenticate BIDIR-PIM messages and prevent forged-message attacks. The specification in PIM-SM [RFC 4601] for authenticating link-local messages applies to all BIDIR-PIM messages as well.

security, multicast, ipsec

state-machine §3.5.3.1

The DF election state machine has four states: Offer (initial, sending periodic Offer messages), Lose (another router is DF or no path exists), Win (acting DF without contest), and Backoff (acting DF but another router is challenging). A router is considered acting DF only in Win or Backoff states.

multicast, routing

state-machine §3.4.1

The downstream (*,G) per-interface state machine has three states: NoInfo, Join, and PrunePending. Transitions are triggered by receiving Join(*,G) or Prune(*,G) targeted to this router, PrunePendingTimer or ExpiryTimer expiry, and the 'Stop Being DF' event. PrunePending functions identically to Join for forwarding purposes.

multicast, routing

state-machine §3.4.2

The upstream (*,G) state machine has two states: NotJoined and Joined, driven by the JoinDesired(G) boolean. In Joined state, the timer is suppressed when a matching Join is observed upstream, decreased to t_override on upstream Prune or RPF_DF GenID change, and reset on RPF_DF change (which also triggers a Prune to the old DF).

multicast, routing

wire-format §3.7.1

All DF election messages share a common header: PIM Ver (4 bits, value 2), Type (4 bits, value 10), Subtype (4 bits: 1=Offer, 2=Winner, 3=Backoff, 4=Pass), Rsvd (4 bits), Checksum (16 bits), RP Address (Encoded-Unicast), Sender Metric Preference (32 bits), Sender Metric (32 bits).

multicast, routing

wire-format §3.7.2

The Backoff message appends to the common header: Offering Address (Encoded-Unicast), Offering Metric Preference (32 bits), Offering Metric (32 bits), and Interval (16 bits, in milliseconds) specifying how long routers with worse metrics must hold their offers.

multicast, routing

wire-format §3.7.4

The Bidirectional Capable PIM-Hello option has OptionType 22 and Length 0, carrying no payload. Its mere presence in a Hello message signals that the router is capable of participating in BIDIR-PIM.

multicast, routing

wire-format §3.7.3

The Pass message appends to the common header: New Winner Address (Encoded-Unicast), New Winner Metric Preference (32 bits), New Winner Metric (32 bits). The Sender fields in the common header carry the old DF's identity and current metric at pass time.

multicast, routing