Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
updated by
Extracted elements (25)
PW-ACH encapsulation of BFD (CV Types 0x10 and 0x20) is preferred over IP/UDP encapsulation in the capability selection priority order because it avoids the overhead of IP/UDP headers while still providing reliable demultiplexing via the Channel Type field.
The destination IP address for IP/UDP-encapsulated BFD is chosen from the 127/8 or IPv6 equivalent range (loopback) to prevent forwarding of these packets beyond the immediate VCCV hop, as explained in RFC 4379 Section 2.1.
The VCCV control channel provides the context to bind and bootstrap the BFD session without exchanging discriminator values out-of-band; the pseudowire demultiplexer field (MPLS PW Label or L2TPv3 Session ID) demultiplexes the first BFD Control packet, so single-hop BFD initialization procedures are followed.
The new BFD CV Types are PW demultiplexer-agnostic and applicable to both MPLS and L2TPv3 pseudowire demultiplexers; this specification covers only single-segment pseudowires (SS-PWs) and BFD asynchronous mode.
After selecting a BFD CV Type, a node MUST NOT use any of the other three BFD CV Types; all BFD CV Types are mutually exclusive.
BFD CV Types 0x08 and 0x20 (fault detection and status signaling) SHOULD NOT be used when a control protocol such as LDP or L2TPv3 is available to signal AC/PW status.
BFD MUST be run in asynchronous mode over VCCV control channels.
Both endpoints of the bidirectional pseudowire MUST send BFD messages on the VCCV control channel, making BFD VCCV operation symmetrical.
For dynamically established PWs, both ends MUST have common CV Types in the VCCV capability advertised and received before selecting a BFD CV Type.
For IP/UDP encapsulation of BFD with a PW Associated Channel Header, the Channel Type MUST indicate either IPv4 (0x0021) or IPv6 (0x0057).
Once a PE has chosen a single BFD CV Type to use, it MUST continue using it until the PW is re-signaled; changing the BFD CV Type requires tearing down and re-establishing the PW.
Pseudowires that do not use a CW or L2SS using the PW Associated Channel Header MUST NOT use BFD CV Types 0x10 or 0x20 (PW-ACH encapsulation of BFD without IP/UDP headers).
The IP version (IPv4 or IPv6) used in IP/UDP BFD encapsulation MUST match the IP version used for signaling for dynamically established pseudowires, or MUST be configured for statically provisioned pseudowires.
The VCCV channel MUST NOT be rate-limited below the maximum configurable BFD bandwidth, or BFD will not operate correctly.
The VCCV channel SHOULD NOT use any additional congestion control loop that would interfere or negatively interact with that of BFD.
When VCCV carries PW-ACH-encapsulated BFD, the PW-ACH Channel Type MUST be set to 0x0007 to indicate 'BFD Control, PW-ACH-encapsulated' (BFD without IP/UDP headers).
A single BFD session exists per pseudowire. Both PW endpoints take the Active role, sending initial BFD Control packets with a Your Discriminator field of zero; the pseudowire demultiplexer field provides context to demultiplex the first BFD Control packet.
Four BFD CV Types are defined, combining two encapsulation methods (IP/UDP headers vs. PW-ACH without IP/UDP headers) with two functional modes (fault detection only vs. fault detection and AC/PW fault status signaling), with bitmask values 0x04, 0x08, 0x10, and 0x20.
IANA augmented the 'VCCV Connectivity Verification (CV) Types' registry (MPLS) in the Pseudowire Name Spaces with four new BFD CV Type bits: 0x04 (BFD IP/UDP, fault detection only), 0x08 (BFD IP/UDP, fault detection and status signaling), 0x10 (BFD PW-ACH, fault detection only), 0x20 (BFD PW-ACH, fault detection and status signaling).
IANA reserved four L2TPv3 BFD CV Types (0x04, 0x08, 0x10, 0x20) in the 'VCCV Capability AVP Values' registry in the L2TP Name Spaces, mirroring the MPLS CV Types.
IANA reserved PW Associated Channel Type 0x0007 in the Pseudowire Associated Channel Types Registry to indicate 'BFD Control, PW-ACH encapsulation (without IP/UDP Headers)', with TLV Follows = No.
Implementations are subject to the same security considerations as RFC 5085, RFC 5880, and RFC 5881; no additional security issues are raised. The IP/UDP-encapsulated BFD uses TTL/Hop Limit procedures and the Generalized TTL Security Mechanism (GTSM) from RFC 5881 Section 5 as a security mechanism.
When a downstream PE (D-PE) does not receive BFD Control messages within the Detection Time (Detect Mult * negotiated interval), it declares the PW receive direction down (PW receive defect state), signals State=Down with Diagnostic 1; the upstream PE (U-PE) then sets State=Down with Diagnostic 3 and enters PW transmit defect state.
For IP/UDP BFD encapsulation, BFD Control packets are transmitted in UDP with destination port 3784, source port in range 49152–65535, destination IP from 127/8 (IPv4) or 0:0:0:0:0:FFFF:127.0.0.0/104 (IPv6), and TTL/Hop Limit set to 255.
For PW-ACH BFD encapsulation, a raw BFD Control packet follows directly after the PW-ACH header with Channel Type 0x0007, with no IP/UDP headers; requires use of a CW or L2SS with PW-ACH format.