Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
updated by
- rfc-7274 — Allocating and Retiring Special-Purpose MPLS Labels
Extracted elements (27)
An alternative approach of creating multiple PWs and distributing flows among them was considered but rejected: it introduces less entropy than an additional LSE, and it requires additional PWs to be set up and maintained, increasing control plane overhead.
Asymmetric operation is explicitly supported: one PE may include a flow LSE while its peer does not. This accommodates scenarios where only one direction has sufficient bandwidth to justify flow classification, or where a PE must receive the entire PW on a single interface for context-dependent processing such as egress policing.
High entropy in flow label values is recommended because ECMP load balancing is statistical: it does not account for per-flow bandwidth. A large number of low-bandwidth flows with randomly distributed labels approximates an even spread; recommending high entropy discourages overloading the label value with additional semantic meaning.
The flow label mechanism is designed so that the flow LSE is transparent to the label swap operation at Switching PEs (S-PEs) in multi-segment PWs. Interface parameter Sub-TLV signalling is transitive, so multi-segment PWs work without any modification to S-PEs.
The flow label value is a local matter for the ingress PE and is not signalled. Only the desire to include the flow LSE in the label stack (via the T and R bits) is signalled. This keeps the signalling lightweight and the ECMP hash function implementation-specific.
The FAT-PW mechanism is described as complementary to, but distinct from, the MPLS Entropy Label proposal (RFC 6790 precursor). While both add a bottom-of-stack label for hash diversity, they differ in which network components impose the label and in their associated signalling mechanisms.
The FL Sub-TLV mechanism is backwards compatible with existing PW implementations because RFC 4447 requires that unknown interface parameter Sub-TLVs be silently ignored. A PE that does not understand the FL Sub-TLV will not send one, causing the ingress PE to omit the flow label.
When VCCV out-of-band OAM (Type 2) is used, an MPLS Router Alert label is inserted above the PW LSE in the label stack. Depending on how many labels the LSR hashes, the Router Alert label may cause the OAM packet to be load-balanced to a different path than data packets with identical flow and PW labels.
A PE that wishes to send flow labels MUST include an FL Sub-TLV with T=1 in its label mapping message. A PE willing to receive flow labels MUST include an FL Sub-TLV with R=1. A PE that sends T=1 and receives R=1 MUST include a flow label; under all other FL Sub-TLV combinations it MUST NOT.
An ingress PE using PW signalling that does not send an FL Sub-TLV MUST NOT include a flow label in PW packets. Similarly, if it does not receive an FL Sub-TLV from its egress peer, it MUST NOT include a flow label. This preserves backwards compatibility.
At the egress PE, if a flow LSE is present it MUST be checked to determine whether it carries a reserved label. If it is a reserved label the packet is processed according to that label's rules; otherwise the flow LSE is discarded without further processing.
Ethernet control frames SHOULD always be mapped to the same PSN path to ensure in-order delivery when the Ethernet PW carries non-IP traffic.
Flow-aware transport (FAT-PW) MUST NOT be deployed in a network conforming to MPLS-TP unless the integrity requirements specified in the applicable SLA (no reordering or corruption) can be satisfied, because the flow LSE defeats MPLS-TP fate sharing between OAM and data.
For static pseudowires (where LDP signalling is not in use), whether the flow label is used MUST be identically provisioned in both PEs at the PW endpoints. The default behaviour when no provisioning support exists is not to include the flow label.
If sequence number support is required for a pseudowire, the flow label mechanism MUST NOT be used, because the flow label promotes out-of-order delivery across flows.
Implementations conforming to this specification MUST set the Traffic Class (TC) field of the flow LSE to zero at the ingress and MUST ignore the TC field at the egress, as no use for TC is defined by this document.
Indivisible flows within the PW MUST be mapped to the same flow label by the ingress PE to preserve per-flow packet ordering across ECMP paths.
The flow label allocated to a flow MUST NOT be an MPLS reserved label and SHOULD remain constant for the life of the flow. The method used to generate flow labels SHOULD introduce a high degree of entropy to maximise ECMP distribution.
The flow label MUST NOT be an MPLS reserved label (values 0–15 as defined in RFC 3032). It is otherwise unconstrained by the protocol.
Where it is required to verify that a pseudowire is fully functional for all flows, a VCCV connectivity verification message MUST be sent over each ECMP path to the pseudowire egress PE.
The flow Label Stack Entry (flow LSE) is an additional MPLS label stack entry interposed between the PW LSE and the control word, or between the PW LSE and the PW payload when no control word is present. The label carried by the flow LSE is called the flow label and is chosen by the ingress PE to stimulate ECMP load-balancing in the PSN.
The Flow Label Sub-TLV (FL Sub-TLV) is a new Pseudowire Interface Parameter Sub-TLV used with LDP signalling (RFC 4447) to synchronise flow label capability between ingress and egress PEs. It carries T and R bits indicating the sender's intent to transmit and ability to receive flow-labeled PW packets, respectively.
IANA assigned Flow Label Sub-TLV type 0x17 (length 4) in the 'Pseudowire Interface Parameters Sub-TLV type Registry' under 'Pseudowire Name Spaces (PWE3)'. This is the identifier for the FL Sub-TLV defined by RFC 6391.
Setting the TTL of the flow LSE to 1 prevents accidental forwarding of a packet based on the flow label value if, due to an error, the flow LSE becomes the top of the MPLS label stack. The flow LSE is at the bottom of the stack so it will normally always be preceded by the PW label at the PE.
The generic PW security considerations from RFC 3985, the security considerations for specific PW types (e.g., Ethernet PW in RFC 4448), and the MPLS/GMPLS security framework in RFC 5920 all apply to flow-aware pseudowires. No additional security threats beyond existing PW security are introduced.
The encapsulation stack from outermost to innermost is: MPLS Tunnel LSE(s) (n*4 octets), PW LSE (4 octets), Flow LSE (4 octets), Optional Control Word (4 octets), and Payload (n octets). The flow LSE is a standard MPLS LSE placed directly above the control word or payload.
The FL Sub-TLV is 4 octets: type field FL=0x17 (8 bits), Length=4 (8 bits), T bit (1 bit, request to send flow labels), R bit (1 bit, ability to receive flow labels), and Reserved (14 bits). Reserved bits MUST be zero on transmit and MUST be ignored on receive.