Network Working Group Johan Moreels Jeremy De Clercq John Fischer Matthew Bocci Internet Draft Alcatel Document: draft-moreels-multiproto-mpls-01.txt June 2003 Expires: December 2003 Multi-protocol encapsulation over MPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an encapsulation method for transporting Service Data Units (SDUs) of different protocols over a single Label Switched Path (LSP). The different protocols are identified by pre- pending an LLC / SNAP header to the SDU. The method allows interconnecting networks with a different layer 2 protocol via an intermediate MPLS network. The proposed encapsulation method is complementary to PWE3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Moreels Expires û December 2003 [Page 1] Multiprotocol encapsulation over MPLS June 2003 Table of Contents 1. Introduction..................................................2 2. Multi-protocol encapsulation over MPLS........................2 2.1 setting up the LSP........................................3 3. Multi-protocol encapsulation over a single LSP................3 3.1 Description using LLC/SNAP/NLPID..........................6 3.2 Establishing the LSP......................................7 4. Applications of Multi-Protocol Encapsulation..................8 4.1 DSL access................................................8 4.2 Service interworking over an MPLS core network............8 5. Conclusion....................................................9 Security Considerations..........................................9 References.......................................................9 Acknowledgments..................................................1 0 Author's Addresses...............................................1 0 1. Introduction The introduction of a multi-protocol header that identifies the protocol transported by the layer 2 network is not new. Standard implementations exist such as in ATM [3], Frame Relay [4] and Ethernet [5]. For example in an IEEE802.3 network, RFC1042 [6] describes the encapsulation of IP and ARP by introducing an LLC/SNAP header between the length field and the payload. This document only describes the encapsulation method and applications that benefit from the proposed encapsulation method. 2. Multi-protocol encapsulation over MPLS Existing proposals (Pseudo Wire Emulation Edge to Edge, PWE3) for transporting layer 2 Protocol Data Units (PDUs) across an MPLS network emulate wires transparently interconnecting pairs of layer 2 networks (network interworking). This requires that the PWE3 connected networks use the same layer 2 technology. This is referred to as network interworking. Therefore the encapsulation method, described in [7], [8], includes layer 2 protocol dependent information needed to reconstruct the original layer 2 protocol at each end of the PWE3 tunnel. In PWE3 one wants to extend services (user traffic and optionally OAM traffic) transparently across an IP/MPLS æbackboneÆ network [7]. Several drafts discuss the implementation details for various layer 2 networks ([7] [8] [9] [10] [11] [12] [13]). Moreels Expires - December 2003 [Page 2] Multiprotocol encapsulation over MPLS June 2003 In the existing IETF PWE3 drafts [7], [8], each Virtual Connection (VC), identified by the VC label, transports only one type of PDU. The type of the PDU and the VC label are signaled after the LSP between the LERs has been set up [15]. This means that several VCs must be defined between two end points if PDUs of multiple protocols are to be exchanged between those end points. The encapsulation method proposed in this document complements PWE3 by allowing a different layer 2 protocol at each end of the tunnel and by identifying the transported higher layer protocol on a frame by frame basis. In draft 14 a similar method, connecting dissimilar layer 2 networks, is described however the mechanism is limited to IP packets only. 2.1 setting up the LSP VC-labels can be signaled using the mechanism described in [15]. The LSPs are configured using standard MPLS signaling. The VC label bindings can be done by static configuration but are mostly distributed using LDP. A special LDP TLV is defined, which allows distributing for each VC the necessary information to the LERs, for each of the protocols defined in the PWE3 documents. This LDP FEC contains the VC label to be used for the connection, the layer 2 protocol transported by the PWE3 tunnel and parameters containing other protocol dependent information. 3. Multi-protocol encapsulation over a single LSP The following frame format is proposed to transport multi-protocol data over MPLS: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Layer 2 protocol Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Transport Header (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS virtual connection identifier (Required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC SNAP/NLPID header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDU Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: General format for multi-protocol encapsulation over MPLS Moreels Expires - December 2003 [Page 3] Multiprotocol encapsulation over MPLS June 2003 Layer 2 protocol Header ----------------------- This header depends on the layer 2 protocol used in the service provider network. MPLS Transport Header --------------------- This header is used to define a tunnel between end points of an MPLS switched core. It reduces the number of MPLS connections to setup in the network by grouping several VC connections in a single tunnel. MPLS virtual connection identifier ---------------------------------- This label is used to identify the individual connections within the MPLS tunnel. LLC SNAP/NLPID Header --------------------- The LLC SNAP/NLPID header identifies the protocol transported over the MPLS network. Depending on the protocol, an NLPID (for example in the case of PPP) or a SNAP header is used in combination with the LLC header (see 3.1). SDU Payload ----------- The SDU payload octet group is the payload of the service that is encapsulated. In the example, depicted in figure 2, a PPP frame is transported over ATM using AAL5 encoding. When using the described encapsulation mechanism, only the PPP frame needs to be transported over the LSP, i.e. the PPP frame is used as SDU over the MPLS network. There is no need to transport layer 2 specific information such as the ATM and/or AAL5 header. Moreels Expires - December 2003 [Page 4] Multiprotocol encapsulation over MPLS June 2003 +--------------------------+ | PPP frame | +--------------------------+ | LLC/NLPID (0xfefe03cf) | +--------------------------+ +--------------------------+ | PPP frame | | VC MPLS label | +--------------------------+ -> +--------------------------+ | AAL5 | | Tunnel MPLS label | +--------------------------+ +--------------------------+ | ATM | | Layer 2 header | +--------------------------+ +--------------------------+ Figure 2: encapsulation of VC-multiplexed PPP over AAL5 In the example, shown in figure 3, a PPPoE frame is transported over Ethernet (figure 3), the SDU will be the PPPoE frame without the Ethernet header containing a.o. MAC addressing. Note that other protocols transported over Ethernet can be transported in the same way (e.g. IP over Ethernet, IPX over Ethernet). +-------------------------------+ | PPPoE frame | +-------------------------------+ | LLC/SNAP (0xaaaa030000008864) | +-------------------------------+ | VC MPLS label | +--------------------------+ +-------------------------------+ | PPPoE frame | | Tunnel MPLS label | +--------------------------+ -> +-------------------------------+ | Ethernet header | | Layer 2 header | +--------------------------+ +-------------------------------+ Figure 3: encapsulation of PPPoE The same PPPoE frame can also be encapsulated in a different way as shown in figure 4: Moreels Expires - December 2003 [Page 5] Multiprotocol encapsulation over MPLS June 2003 +-------------------------------+ | PPPoE frame | +-------------------------------+ | Ethernet header | +-------------------------------+ | LLC/SNAP (0xaaaa030080C20007) | +-------------------------------+ | VC MPLS label | +--------------------------+ +-------------------------------+ | PPPoE frame | | Tunnel MPLS label | +--------------------------+ -> +-------------------------------+ | Ethernet header | | Layer 2 header | +--------------------------+ +-------------------------------+ Figure 4: alternative encapsulation of PPPoE The encapsulation of figure 3 terminates the Ethernet network at the LER and only transports the payload of the Ethernet frame. At the other end of the LSP a different layer 2 network can be used. The second encapsulation (figure 4) allows to transparently interconnect two Ethernet networks over an LSP, but cannot be used when the layer 2 networks connected to the end points of the LSP are different. Several encapsulation methods already exist to tunnel multiple protocol payloads of a layer 2 network without signaling. Most implementations use LLC combined with NLPID and/or SNAP (e.g. ATM [3], ...). International standard organizations maintain the list of agreed values. The most recent values for LLC can be found at http://www.iana.org/numbers.html. Possible NLPID values are found in ISO/IEC TR 9577 and the most recent SNAP types at http://www.iana.org/assignments/ethernet-numbers. 3.1 Description using LLC/SNAP/NLPID As seen in figure 1 the LLC/SNAP/NLPID header is inserted between the MPLS label stack and the SDU. The LLC header is 3 bytes long, the SNAP header 5 bytes and the NLPID header 1 byte long. The combination LLC/NLPID is indicated by LLC value 0xfefe03, the LLC/SNAP combination is indicated by LLC value 0xaaaa03. The LLC/NLPID combination with NLPID value 0x80, which indicates the presence of an additional SNAP header, will not be used. Also the NLPID value 0xcc which indicates the presence of an IP frame without using a SNAP header will not be used. An additional 2-byte padding is inserted when the SDU is not located at a 4-byte offset from the start of the frame. This encoding is similar to the one defined in [3]. Moreels Expires - December 2003 [Page 6] Multiprotocol encapsulation over MPLS June 2003 3.2 Establishing the LSP The multi-protocol encapsulation proposal presented here can use the same mechanism to set up the LSPs and distribute the VC labels as in [15]. The tunnel label is obtained using normal MPLS signaling to set up the tunnel LSPs. The VC label, when used in combination with a tunnel label, is treated as an implicit peering [16] or parameter label by the LERs. This label is exchanged between LERs by using an LDP message as defined in [15]. The format of this LDP message is given below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC tlv |C| VC Type |VC info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: VC label distribution LDP message VC type ------- The multi-protocol encapsulation method presented here requires a new VC type to be defined at IANA to indicate the presence of the LLC/SNAP header. Control word bit (C) -------------------- This bit indicates the presence of a control word in front of the SDU (PDU in PWE3) and has been defined for several layer 2 protocols in [15]. This bit must be zero since the VC type, needed to indicate multi-protocol encapsulation, already indicates the presence of an LLC/SNAP header. No additional control word, containing layer 2 information, is needed since the LLC/SNAP header provides the necessary information or the layer 2 network must be terminated at the LER for those layer 2 protocols that can not be identified by LLC/SNAP. Moreels Expires - December 2003 [Page 7] Multiprotocol encapsulation over MPLS June 2003 Interface parameters -------------------- The only interface parameter that is required is the MTU parameter. The value of this parameter must take into account the layer 2 MTU limitations of the MPLS network and the total size occupied by the MPLS labels and any additional encapsulation. 4. Applications of Multi-Protocol Encapsulation This section describes some applications that benefit from the proposed multiprotocol encapsulation method. 4.1 DSL access In DSL access many different frame encapsulations are used. The choice depends partially on the type of DSL modem chosen (USB, Ethernet, etc). In addition, the DSL end user has some freedom to change the frame encapsulation method. In the DSLAMs all these different encapsulations exist concurrently. In ATM this problem is solved by using the method described in RFC2684[3]. Traditionally DSLAMs are connected to an ATM access network and the connection between the DSL modem and the DSLAM is also ATM based. A DSLAM connected to an MPLS network needs to handle both the multiple encapsulations and the presence of different layer 2 networks. 4.2 Service interworking over an MPLS core network In some cases, it might be necessary to connect two networks with dissimilar layer 2 technologies via an IP/MPLS network. In this case, appropriate service interworking needs to be present. In [14], a mode is described that supports service interworking between dissimilar layer 2 networks. However, the mechanism is limited to IP packets only. When using the encapsulation method proposed in this document, service interworking between dissimilar layer 2 networks is done by identifying the transported protocol on a frame by frame basis. This means that the approach complements the IP only solution towards non-IP packets. Furthermore, the user has the freedom to send both IP and non-IP packets interchangeably. For example, consider an MPLS network that is interconnected to an ATM network. A CE device is connected to the ATM network using a Frame Relay interface; another CE device is connected to the MPLS network using an Ethernet interface. Communication between both CEs requires FR-ATM, ATM-MPLS and MPLS- Ethernet service interworking. The details of the data path interworking are as follows: Moreels Expires - December 2003 [Page 8] Multiprotocol encapsulation over MPLS June 2003 a. FR-ATM service interworking for bridged or routed PDU at the ATM network PE device, as per FRF8.1 Mode 2 (translation mode). b. ATM-MPLS service interworking for bridged or routed PDU at the MPLS network PE device. The PE needs to insert a NLPID in the AAL5 SDU. c. Ethernet-MPLS service interworking, bridged or routed PDU, at the Ethernet network PE device. The PE needs to insert a NLPID in the Ethernet frame (PE4-CE2 direction). 5. Conclusion The method described in the current document is complementary to existing PWE3 proposals. It allows PWE3-like connectivity between different layer 2 networks by means of a protocol identification mechanism on a frame by frame basis. By introducing an intermediate LLC/SNAP header, identifying the payload type, the same MPLS encapsulation as in PWE3 can be used. Due to this similarity, the same signaling mechanism as defined in PWE3 can set up the connections. Only one new VC type must be defined for the signaling message. Security Considerations This document does not affect the underlying security issues of MPLS. References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 J. Grossman, J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC2684, September 1999 4 C. Brown, A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC2427, September 1998 5 "Logical Link Control", International Standard ISO/IEC 8802- 2:1998 ANSI/IEEE Std 802.2, 1998 edition 6 Postel & Reynolds, "IP and ARP on IEEE 802 Networks", RFC 1042, February 1988 Moreels Expires - December 2003 [Page 9] Multiprotocol encapsulation over MPLS June 2003 7 C. Kawa, L. Martini et al., "Frame-Relay Over Pseudo-Wires", draft-ietf-pwe3-frame-relay-00, Work in Progress 8 L. Martini, et al., "Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks", draft-ietf-pwe3-atm- encap-01 (work in progress) 9 A. Malis, et al., "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation", draft-ietf-pwe3-sonet-01 (Work in progress) 10 L. Martini, et al., "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf-pwe3-hdlc- ppp-encap-mpls-00 (work in progress) 11 L. Martini, et al., "Encapsulation Methods for Transport of Ethernet Frames Over IP and MPLS Networks", draft-ietf-pwe3- ethernet-encap-02 (work in progress) 14 Kompella, K., et al., "Layer 2 VPNs Over Tunnels", draft- kompella-ppvpn-l2vpn-02 (work in progress) 15 L. Martini et al., "Pseudo-Wire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-02 (work in progress) 16 E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC3031, January 2001 Acknowledgments The authors want to thank the following people for their contribution to the discussions which resulted in the creation of this paper: M. Aissaoui, C. Hublet, N. Janssens, S. Ooghe, T. Pollet, P. Vandaele, B. Van Vlerken, J. Wuyts. Author's Addresses Johan Moreels Alcatel F. Wellesplein 1, 2018 Antwerp Phone: +32 3 240 4210 Email: johan.moreels@alcatel.be Jeremy De Clercq Alcatel F. Wellesplein 1, 2018 Antwerp Email: jeremy.de_clercq@alcatel.be John Fischer Moreels Expires - December 2003 [Page 10] Multiprotocol encapsulation over MPLS June 2003 Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: john.fischer@alcatel.com Matthew Bocci Alcatel Voyager Place, Shoppenhangers Rd Maidenhead, Berks, UK SL6 2PJ Email: matthew.bocci@alcatel.co.uk Moreels Expires - December 2003 [Page 11]