Internet Engineering Task Force (IETF) S. Bryant, Ed. Request for Comments: 6658 L. Martini Category: Standards Track G. Swallow ISSN: 2070-1721 Cisco Systems A. Malis Verizon Communications July 2012 Packet Pseudowire Encapsulation over an MPLS PSN
AbstractThis document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6658. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Network Reference Model . . . . . . . . . . . . . . . . . . . 4 3. Client Network-Layer Model . . . . . . . . . . . . . . . . . . 5 4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5 5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 7 6. Ethernet and IEEE 802.1 Functional Restrictions . . . . . . . 8 7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Encapsulation Approaches Considered . . . . . . . . . 11 A.1. A Protocol Identifier in the Control Word . . . . . . . . 11 A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 12 A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . 13 A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . 13 A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 14
RFC5317]. The client may also be either an MPLS network or a network conforming to the MPLS-TP. Considerations regarding the use of an MPLS network as a server for an MPLS-TP network are outside the scope of this document. Where the client equipment is connected to the server equipment via a physical interface, the same data-link type must be used to attach the clients to the Provider Edge (PE) equipments, and a pseudowire (PW) of the same type as the data-link must be used [RFC3985]. The reason that interworking between different physical and data-link attachment types is specifically disallowed in the pseudowire architecture is because this is a complex task and not a simple bit- mapping exercise. The interworking is not limited to the physical and data-link interfaces and the state-machines. It also requires a compatible approach to the formation of the adjacencies between attached client network equipment. As an example, the reader should consider the differences between router adjacency formation on a point-to-point link compared to a multipoint-to-multipoint interface (e.g., Ethernet). A further consideration is that two adjacent MPLS Label Switching Routers (LSRs) do not simply exchange MPLS packets. They exchange IP packets for adjacency formation, control, routing, label exchange, management, and monitoring purposes. In addition, they may exchange data-link packets as part of routing (e.g., IS-IS Hellos and IS-IS Link State Packets) and for Operations, Administration, and Maintenance (OAM) purposes such as the Link-Layer Discovery Protocol [IEEE.802.1AB.2009]. Thus, the two clients require an attachment mechanism that can be used to multiplex a number of protocols. In addition, it is essential to the correct operation of the network layer that all of these protocols fate share. Where the client LSR and server PE are co-located in the same equipment, the data-link layer can be simplified to a point-to-point Ethernet used to multiplex the various data-link types onto a pseudowire. This is the method described in this document. Appendix A provides information on alternative approaches to providing a packet PW that were considered by the PWE3 Working Group and the reasons for using the method defined in this specification.
RFC2119]. Figure 1. This is an extension of Figure 3 "Pre-processing within the PWE3 Network Reference Model" from [RFC3985]. PW PW End Service End Service | | |<------- Pseudowire ------->| | | | Server | | |<- PSN Tunnel ->| | | V V | ------- +-----+-----+ +-----+-----+ ------- ) | | |================| | | ( Client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN ) | | | | | | ( ) | | |================| | | ( ------- +-----+-----+ +-----+-----+ -------- ^ ^ | | | | |<---- Emulated Service----->| | | Virtual physical Virtual physical termination termination Figure 1: Packet PW Network Reference Model In this model, the LSRs (LSR1 and LSR2) are part of the client MPLS PSN. The PEs (PE1 and PE2) are part of the server PSN that is to be used to provide connectivity between the client LSRs. The attachment circuit that is used to connect the MPLS LSRs to the PEs is a virtual interface within the equipment. A packet pseudowire is used to provide connectivity between these virtual interfaces. This packet pseudowire is used to transport all of the required layer 2 and layer 3 protocols between LSR1 and LSR2.
Figure 2. The forwarding operation can be likened to a virtual private network (VPN), in which a forwarding decision is first taken at the client layer, an encapsulation is applied, and then a second forwarding decision is taken at the server layer. +------------------------------------------------+ | | | +--------+ +--------+ | | | | Pkt +-----+ | | | ------+ +---------+ PW1 +--------+ +------ | | Client | AC +-----+ | Server | | Client | | LSR | | LSR | | Server Network | | | Pkt +-----+ | | | Network ------+ +---------+ PW2 +--------+ +------ | | | AC +-----+ | | | | +--------+ +--------+ | | | +------------------------------------------------+ Figure 2: Packet PW Forwarding Model A packet PW PE comprises three components: the client LSR, a PW processor, and a server LSR. Note that [RFC3985] does not formally indicate the presence of the server LSR because it does not concern itself with the server layer. However it is useful in this document to recognize that the server LSR exists. It may be useful to first recall the operation of a layer 2 PW such as an Ethernet PW [RFC4448] within this model. The client LSR is not present, and packets arrive directly on the attachment circuit (AC) that is part of the client network. The PW function undertakes any
header processing, if configured to do so; it then optionally pushes the PW control word (CW) and finally pushes the PW label. The PW function then passes the packet to the LSR function, which pushes the label needed to reach the egress PE and forwards the packet to the next hop in the server network. At the egress PE, the packet typically arrives with the PW label at the top of the stack; the packet is thus directed to the correct PW instance. The PW instance performs any required reconstruction using, if necessary, the CW, and the packet is sent directly to the attachment circuit. Now let us consider the case of client-layer MPLS traffic being carried over a packet PW. An LSR belonging to the client layer is embedded within the PE equipment. This is a type of native service processing element [RFC3985]. The client LSR determines the next hop in the client layer, and pushes the label needed by the next hop in the client layer. It then encapsulates the packet in an Ethernet header setting the Ethertype to MPLS, and the client LSR passes the packet to the correct PW instance. The PW instance then proceeds as defined for an Ethernet PW [RFC4448] by optionally pushing the control word, then pushing the PW label, and finally handing the packet to the server-layer LSR for delivery to the egress PE in the server layer. At the egress PE in the server layer, the packet is first processed by the server LSR, which uses the PW label to pass the packet to the correct PW instance. This PW instance processes the packet as described in [RFC4448]. The resultant Ethernet encapsulated client packet is then passed to the egress client LSR, which then processes the packet in the normal manner. Note that although the description above is written in terms of the behavior of an MPLS LSR, the processing model would be similar for an IP packet or any other protocol type. Note that the semantics of the PW between the client LSRs is a point- to-point link.
Figure 3. +-------------------------------+ | Client | | Network-Layer | | Packet | n octets | | +-------------------------------+ | | | Ethernet | 14 octets | Header | | +---------------+ | | +---------------+---------------+ | Optional Control Word | 4 octets +-------------------------------+ | PW Label | 4 octets +-------------------------------+ | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) +-------------------------------+ Figure 3: Packet PW Encapsulation This conforms to the PW protocols stack as defined in [RFC4448]. The protocol stack is unremarkable except to note that the stack does not retain 32-bit alignment between the virtual Ethernet header and the PW optional control word (or the PW label when the optional components are not present in the PW header). This loss of 32 bits of alignment is necessary to preserve backwards compatibility with the Ethernet PW design [RFC4448] Ethernet Raw Mode (PW type 5) MUST be used for the packet PW. The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network-layer packet or MAY use the special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as described below. IANA has allocated two unicast Ethernet addresses [RFC5342] for use with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB". Where [RFC4447] signaling is used to set up the PW, the LDP peers numerically compare their IP addresses. The LDP PE with the higher- value IP address will use PacketPWEthA, whilst the LDP peer with the lower-value IP address uses PacketPWEthB.
Where no signaling PW protocol is used, suitable Ethernet addresses MUST be configured at each PE. Although this PW represents a point-to-point connection, the 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. RFC3985] [RFC5659]. RFC3985], [RFC4447], and [RFC3916].
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. [IEEE.802.1AB.2009] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks -- Station and Media Access Control Connectivity Discovery", IEEE Standard 802.1AB, 2009. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009. [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
RFC4385] to make a 6-byte CW (it was thought that this approach would include 2 reserved bytes to provide 32-bit alignment, but then this was optimized out). A variant of this is just to use a 2-byte PID without a control word.
This is a simple approach and is basically a virtual PPP interface without the PPP control protocol. This has a smaller MTU than, for example, a virtual Ethernet would need; however, in forwarding terms, it is not as simple as the PID label or multiple PW approaches described next and may not be deployable on a number of existing hardware platforms. Figure 4. +-------------------------------+ | Client | | Network-Layer | | Packet | n octets | | +-------------------------------+ | Optional Control Word | 4 octets +-------------------------------+ | PID Label (S=1) | 4 octets +-------------------------------+ | PW Label | 4 octets +-------------------------------+ | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) +-------------------------------+ Figure 4: Encapsulation of a Pseudowire with a Pseudowire Load-Balancing Label In the PID label approach, a new Label Distribution Protocol (LDP) Forwarding Equivalence Class (FEC) element is used to signal the mapping between protocol type and the PID label. This approach complies with [RFC3031]. A similar approach to PID label is described in Section 3.4.5 of [RFC5921]. In this case, when the client is a network-layer packet service such as IP or MPLS, a service label and demultiplexer label (which may be combined) are used to provide the necessary identifications needed to carry this traffic over an LSP. The authors surveyed the hardware designs produced by a number of companies across the industry and concluded that whilst the approach complies with the MPLS architecture, it may conflict with a number of designers' interpretations of the existing MPLS architecture. This led to concerns that the approach may result in unexpected difficulties in the future. Specifically, there was an assumption in many designs that a forwarding decision should be made on the basis
of a single label. Whilst the approach is attractive, it cannot be supported by many commodity chip sets, and this would require new hardware, which would increase the cost of deployment and delay the introduction of a packet PW service. RFC4448] to carry the user traffic. This is conceptually simple and can be implemented today without any further standards action, although there are a number of applicability
considerations that it are useful to bring to the attention of the community. Conceptually, this is a simple approach, and some deployed equipments can already do this. However, the requirement to run a complete Ethernet adjacency led us to conclude that there was a need to identify a simpler approach. The packets encapsulated in an Ethernet header have a larger MTU than the other approaches, although this is not considered to be an issue on the networks needing to carry packet PWs. The virtual Ethernet mechanism was the first approach that the authors considered, before the merits of the other approaches appeared to make them more attractive. As we shall see below, however, the other approaches were not without issues, and it appears that the virtual Ethernet is the preferred approach to providing a packet PW.