Bidirectional Forwarding Detection (BFD) for Multipoint Networks
updated by
- rfc-9780 — Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)
updates
- rfc-5880 — Bidirectional Forwarding Detection (BFD)
Extracted elements (29)
Multipoint BFD operates without a three-way handshake because the many-to-one nature of multipoint paths makes session establishment and teardown handshakes neither possible nor appropriate. Tails may discover the head dynamically from received BFD packets alone.
MultipointHead sessions cannot fail by definition and are always administratively driven. The head remains always-Up and in Demand mode because the unidirectional multipoint model gives the head no BFD mechanism to learn of tail state—this is intentionally asymmetric.
The protocol purposely verifies only unidirectional multipoint connectivity (head to tails), not bidirectional paths. Point-to-point BFD can be run independently among the same nodes without overhead penalty when bidirectional verification is needed.
Bootstrapping a multipoint BFD session to a multipoint MPLS LSP may use the control plane (e.g., as described in MVPN-FAILOVER); the exact mechanism is outside the scope of this document. Tail notification to the head is similarly deferred to RFC 8563.
RFC 8562 replaces Sections 6.8.6 and 6.8.7 of RFC 5880 with extended procedures that handle MultipointHead, MultipointTail, and PointToPoint session types, while preserving backward-compatible processing for existing point-to-point BFD sessions.
A MultipointHead session SHOULD NOT initiate a Poll Sequence for timer changes; instead it MUST send packets with the P bit set to signal a change. A MultipointTail MUST NOT reply when the M and P bits are set and bfd.RequiredMinRxInterval is zero.
A newly started head SHOULD begin with bfd.SessionState set to Down and SHOULD remain in this state for (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure all MultipointTail sessions are reset before service is brought up.
A system MUST NOT transmit any BFD Control packets if bfd.SessionType is MultipointTail, and MUST NOT set the Demand (D) bit if bfd.SessionType is MultipointTail.
bfd.DemandMode MUST be initialized to 1 for session type MultipointHead and MUST be initialized to zero for session type MultipointTail.
BFD packets received on tails for an IP multicast group MUST be consumed by tails and MUST NOT be forwarded to receivers. MultipointTail nodes MUST identify packets as BFD Control packets when the destination UDP port equals 3784.
bfd.RequiredMinRxInterval MUST be initialized to zero for session type MultipointHead, since the head neither receives nor negotiates receive rates with individual tails.
For multipoint LSPs using IP/UDP encapsulation, MultipointTail MUST expect destination UDP port 3784 and the destination IP address MUST be in 127.0.0.0/8 (IPv4) or 0:0:0:0:0:FFFF:7F00:0/104 (IPv6), consistent with RFC 8029.
If bfd.SessionType is MultipointHead, the transmit interval MUST be set to bfd.DesiredMinTxInterval (automatically enforced since bfd.RemoteMinRxInterval will be zero).
If the State field is Init and bfd.SessionType is not PointToPoint, the packet MUST be discarded during demultiplexing, enforcing the no-Init-state rule for multipoint sessions.
IP and MPLS multipoint tails MUST demultiplex BFD packets based on a combination of the source address, My Discriminator, and the identity of the multipoint path on which the packet was received, together uniquely identifying the head.
Sessions of type MultipointHead MUST NOT send BFD Control packets with the State field set to INIT, and INIT packets MUST be ignored on receipt, because three-way handshakes are neither possible nor appropriate in multipoint BFD.
The bfd.SessionType variable MUST be initialized to the appropriate type (PointToPoint, MultipointHead, or MultipointTail) when the session is created.
The Detection Time for a MultipointTail session is calculated as the product of the last received values of Desired Min TX Interval and Detect Mult. MultipointTail cannot negotiate the head's transmit rate via Required Min RX Interval due to the one-to-many relationship.
The My Discriminator value on a MultipointHead session MUST NOT be changed during the life of a session, because the more complex demultiplexing scheme in multipoint BFD depends on a stable discriminator value.
To shut down a multipoint session in a controlled fashion, the head MUST administratively set bfd.SessionState to Down or AdminDown and SHOULD continue sending BFD Control packets in that state for (bfd.DesiredMinTxInterval * bfd.DetectMult) so tails detect the shutdown quickly.
When a BFD Control packet is received with the M bit set, if the Your Discriminator field is nonzero the packet MUST be discarded. A MultipointTail session may be created dynamically on receipt of a multipoint BFD Control packet, subject to local policy.
When a MultipointHead increases its transmit interval, it MUST send BFD Control packets with the P bit set at the old transmit interval before switching to the higher value, to avoid false detection timeouts at tails.
When BFD is used across multiple hops, a congestion control mechanism MUST be implemented, and when congestion is detected the BFD implementation MUST reduce the amount of traffic it generates.
When head-awareness of tail session state is required in a multipoint deployment, it is RECOMMENDED to implement the extension described in RFC 8563, since the head has no BFD-based mechanism to detect tail-side link failures.
Multipoint BFD Control packets are explicitly marked by setting the Multipoint (M) bit defined in RFC 5880. This allows tails to identify multipoint packets without relying on knowledge of whether the packet was received over a multipoint path.
Multipoint BFD defines three session types: MultipointHead (on the sender, transmits BFD Control packets over a multipoint path, never receives), MultipointTail (on each receiver, receives BFD Control packets from the head), and PointToPoint (classic BFD per RFC 5880). These types are encoded in the bfd.SessionType state variable.
Implementations that dynamically create MultipointTail sessions upon receipt of multipoint BFD Control packets MUST implement protective measures to prevent an unbounded number of sessions from being created, including verifying multicast path validity, bounding session counts based on expected stream count, and generating alarms on anomalies.
Shared authentication keys in multipoint BFD allow any tail to spoof the head from the viewpoint of any other tail. Shared-key authentication is a significant security exposure unless all tails are trusted; asymmetric authentication (e.g., TESLA per RFC 4082) would be needed otherwise, but its applicability is left for further study.
MultipointTail sessions have only two states: Down and Up (no Init state). Transitions: Down→Up on receiving State=Up from head; Up→Down on receiving State=Down or AdminDown, or on Detection Timer expiration. MultipointHead sessions have no Detection Timer and are driven purely by administrative action.