Recommendation to Use the Ethernet Control Word
updates
- rfc-4448 — Encapsulation Methods for Transport of Ethernet over MPLS Networks
Extracted elements (19)
Early Ethernet PW deployments of commercial significance could not process the Ethernet CW, which motivated making CW optional in RFC 4448. Proprietary heuristic methods to discriminate Ethernet PW from IP packets were later developed but proved unreliable.
MPLS does not include a payload type in the packet; it relies on the control plane to signal payload type. Some LSRs attempt to deduce type via payload inspection, which is not exact science and can cause misordering even when a CW is present if inspection looks past the CW.
The Ethernet PW CW was originally optional in RFC 4448 because it was believed no IEEE-assigned Ethernet MAC address started with 0x4 or 0x6, making misidentification as IPv4/IPv6 practically impossible. That assumption is no longer valid.
The misidentification problem has become more serious because the IEEE RAC has assigned MAC addresses starting with 0x4 or 0x6, and MAC address randomization (deployed for privacy) produces addresses in those ranges approximately one time in eight.
When implementing software that follows this recommendation, care must be taken that it does not depend on existing configuration settings that disable the CW. Platform software should emit a rate-limited message when the CW is available but disabled by configuration.
Without a CW, LSRs that inspect past the MPLS label stack to apply five-tuple ECMP can mistake an Ethernet PW packet for an IP packet when the destination MAC address starts with 0x4 (IPv4) or 0x6 (IPv6), causing packet misordering or OAM path deviation.
Some LSRs inspect past the PW CW to determine payload type for ECMP. When operators enable such deep inspection, Ethernet frames may still be delivered out of order despite the presence of the CW, and this misordering can be difficult to diagnose.
When both FAT PW (RFC 6391) and ELI/EL (RFC 6790) are available, either may be used for ECMP; using both on the same PW simultaneously is not normally necessary and should be avoided. OAM path-following considerations apply to both methods as described in their respective RFCs.
Where the Ethernet PW CW cannot be used, ECMP effects can be disabled by carrying the PW over a traffic-engineered path such as RSVP-TE (RFC 3209) that does not subject the payload to load balancing, though such paths may still experience link-bundle load balancing.
Both the ingress provider edge (PE) and the egress PE SHOULD support the Ethernet PW CW, and if supported, the CW MUST be used. This updates RFC 4448.
Future implementations MUST be able to send and receive Ethernet PW frames without the control word present, to aid backwards compatibility with early deployments that do not include or process a CW.
In the case of multi-segment PWs, if ELI/EL is used for ECMP, it SHOULD be used on every segment of the PW. The method for guaranteeing this is out of scope.
Where ECMP is required and both ingress and egress PEs support ELI/EL and FAT PW, either method may be used. Using both on the same PW is not normally necessary and should be avoided unless circumstances require it.
ECMP path selection in LSRs is based on the 'five-tuple': IP source address, IP destination address, protocol/next-header, transport-layer source port, and transport-layer destination port, derived by inspecting past the MPLS label stack.
Entropy Label Indicator / Entropy Label (ELI/EL, RFC 6790) provides ECMP for Ethernet PWs by including an entropy value in the LSP label stack layer, pushed after the PW label. Requires ingress/egress PE support and sufficient LSR support.
Flow-Aware Transport of Pseudowires (FAT PW, RFC 6391) provides ECMP for Ethernet PWs by increasing the entropy of the bottom-of-stack label; requires both ingress and egress PEs and sufficient LSRs on the path to support it.
In multi-segment PWs using ELI/EL, the PW label is pushed before the LSP label; ELI/EL labels are part of the LSP layer and are therefore pushed after the PW label.
The Ethernet PW Control Word (CW) is based on the Generic PW MPLS Control Word (RFC 4385). It provides individual frame sequencing, avoidance of ECMP load-balancing, and OAM mechanisms including VCCV.
This document expresses a preference for one existing and widely deployed Ethernet PW encapsulation over another. The two methods have identical security considerations, discussed in RFC 4448. No additional security issues are introduced.