Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels
updates
- rfc-4761 — Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
Extracted elements (16)
RFC 4761 defined the Control Flags Bit Vector but did not create a registry for it. This document retroactively creates the registry to formally track flag assignments and prevent future conflicts.
The optional flow label mode allows PWs to be transported over ECMPs to achieve load-balancing, particularly beneficial for high-bandwidth Ethernet services where PW attachment circuit bandwidth and PSN core link bandwidth are of the same order of magnitude. Single-path delivery to preserve packet order remains the default.
For inter-AS scenarios per RFC 4761 Section 3.4, the flow label must never be handled by ASBRs; only the terminating PEs on each AS are responsible for popping or pushing the flow label. This applies to Method B (ASBR label swap) as well.
The signaling procedure is backwards compatible with RFC 4761 implementations. A PE not supporting these extensions will always advertise R=0 and T=0, so flow labels will never be included in packets to or from it.
A PE sending T=1 and receiving R=1 MUST include a flow label in the PW packet. With any other combination of T and R bits, a PE MUST NOT include a flow label in the PW packet.
A PE that is willing to receive a flow label in a PW packet MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community with R=1 in the Control Flags field.
A PE that receives a VPLS BGP NLRI containing a Layer2 Info Extended Community with R=0 MUST NOT include a flow label in the PW packet.
A PE that wishes to send a flow label in a PW packet MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community with T=1 in the Control Flags field.
The remaining Z bits in the Control Flags field MUST be set to zero when sending and MUST be ignored when receiving the Layer2 Info Extended Community.
Flow label settings (T and R bits) MAY be configured on a per-service basis (e.g., per VPLS VFI). The presence of a flow label is determined on a per-peer basis according to local and remote T and R bit values.
The flow label is an additional Label Stack Entry (LSE) located at the bottom of the MPLS label stack, immediately after the PW LSE. Its value is a local matter for the ingress PE and is not signaled via BGP.
Two new Control Flags bits (T and R) are defined in the Layer2 Info Extended Community to signal flow label capability. T=1 indicates the PE can send PW packets with a flow label; R=1 indicates the PE can receive PW packets with a flow label.
IANA created the 'Layer2 Info Extended Community Control Flags Bit Vector' registry under bgp-extended-communities. Initial entries: T (send flow label, this document), R (receive flow label, this document), C (Control Word presence, RFC 4761), S (sequenced delivery, RFC 4761). Remaining bits are unassigned and MUST be zero on send, ignored on receive.
This BGP extension does not introduce new security issues beyond those inherent in RFC 4271 (BGP-4) and RFC 4761 (VPLS BGP signaling). Implementors should refer to the security considerations of those documents.
The Control Flags Bit Vector is an 8-bit field with layout: Z|Z|Z|Z|T|R|C|S, where Z bits MUST be zero. T is bit 4 (send flow label), R is bit 5 (receive flow label), C and S are defined in RFC 4761.
The Layer2 Info Extended Community is an 8-octet structure containing: Extended Community type (2 octets), Encaps Type (1 octet), Control Flags (1 octet), Layer-2 MTU (2 octets), and Reserved (2 octets). The Control Flags field is an 8-bit vector where bits 0-5 (Z) MUST be zero, and bits T, R, C, S are defined.