Packet Pseudowire Encapsulation over an MPLS PSN
Extracted elements (18)
Ethernet is used as the encapsulation mechanism solely for its protocol multiplexing capability and widespread hardware availability. No Ethernet features beyond protocol multiplexing are required; Ethernet OAM is not required, and VLANs, IEEE 802.1p, and 802.1Q tagging are explicitly not supported.
The packet PW uses a virtual Ethernet encapsulation because it is a well-known protocol stack already implemented on many hardware platforms, requires no new protocol design, and provides protocol multiplexing with fate sharing across all carried protocols. After evaluating PID-in-CW, PID label, and parallel PW approaches, virtual Ethernet was selected as the most readily deployable solution.
The parallel PW approach (one PW per protocol) was rejected because it breaks fate-sharing between protocol types, requires complex per-PW OAM binding, and significantly increases control-plane complexity, despite simplifying the forwarding plane.
The PID label approach was rejected because many hardware designs assume forwarding decisions are made on a single label, and the approach cannot be supported by many commodity chip sets, which would require new hardware, increase deployment cost, and delay adoption.
Two adjacent MPLS LSRs exchange not only MPLS packets but also IP packets (for adjacency, routing, label exchange), data-link packets (IS-IS hellos, LSPs), and OAM packets (LLDP). All these protocols must fate-share, which requires a multiplexing attachment mechanism — motivating the use of a virtual Ethernet rather than a single-protocol link.
The packet PW encapsulation conforms to the PW protocol stack defined in RFC 4448 (Ethernet PW). The loss of 32-bit alignment between the virtual Ethernet header and the optional control word is a deliberate choice to preserve backwards compatibility with the Ethernet PW design.
The use of VLANs, IEEE 802.1p, and IEEE 802.1Q tagging between PEs is not supported. Point-to-multipoint and multipoint-to-multipoint operation of the virtual Ethernet is also not supported.
Although the packet PW is a point-to-point connection, use of a multicast destination address in the Ethernet encapsulation is REQUIRED by some client-layer protocols. Peers MUST be prepared to handle a multicast destination address in the Ethernet encapsulation.
Ethernet Raw Mode (PW type 5) MUST be used for the packet PW.
PEs MAY use a local Ethernet address for the Ethernet header, or MAY use the special IANA-allocated Ethernet addresses 'PacketPWEthA' (00-00-5E-00-52-00) or 'PacketPWEthB' (00-00-5E-00-52-01).
Where no signaling PW protocol is used, suitable Ethernet addresses MUST be configured at each PE.
A packet PW PE comprises three components: a client LSR, a PW processor, and a server LSR. The client LSR encapsulates client packets in an Ethernet header (Ethertype set to the client protocol type, e.g., MPLS), and passes the result to the PW instance, which then processes it as an Ethernet PW per RFC 4448.
The network reference model places client LSRs (LSR1, LSR2) in the client MPLS PSN and PEs (PE1, PE2) in the server PSN. The attachment circuit between each LSR and PE is a virtual interface within the same physical equipment, not a physical link.
The packet PW appears as a single point-to-point link to the client layer. Network-layer adjacency formation, metric assignment, and protocol maintenance between client equipment follow normal client-layer practice, with no special packet PW awareness required at the client layer.
When RFC 4447 LDP signaling is used, the PE with the higher-value IP address uses PacketPWEthA as the Ethernet source/destination, while the LDP peer with the lower-value IP address uses PacketPWEthB. This deterministic assignment avoids the need to configure addresses manually when signaling is available.
IANA allocated two unicast Ethernet addresses from 'IANA Unicast 48-bit MAC Addresses': 00-00-5E-00-52-00 (PacketPWEthA) and 00-00-5E-00-52-01 (PacketPWEthB), both referenced to RFC 6658.
The virtual Ethernet approach to packet PW introduces no new security risks. Detailed pseudowire security discussion is provided in RFC 3985, RFC 4447, and RFC 3916.
The packet PW encapsulation stack consists of (bottom to top): server MPLS tunnel labels (n*4 octets), PW label (4 octets), optional control word (4 octets), Ethernet header (14 octets), and the client network-layer packet. The Ethernet header and control word do not maintain 32-bit alignment, which is intentional for backwards compatibility with RFC 4448.