Network Working Group Tissa Senevirathne Internet Draft Som Sikdar Document: draft-tsenevir-l2vpn-gre-00.txt Neena Premmaraju Category: Informational (Force10) July 2001 Ethernet Over IP - A Layer 2 VPN Solution using Generic Routing Encapsulation (GRE) 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract Generic Routing Encapsulation is presented in this document as a method to provide Ethernet Layer 2 VPN services. Solution discussed in this document allows providers to provision Ethernet Layer 2 VPN services across public IP networks. Senevirathne, et.al. Informational û January 2002 1 draft-tsenevir-l2vpn-gre-00.txt July 2001 2. 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]. Table of Content 1. Abstract.....................................................1 2. Conventions used in this document............................2 3. Introduction.................................................2 4. Requirements.................................................3 5. End-point discovery and de-multiplexing......................3 6. Encapsulation of Ethernet frame in to IP payload using GRE...3 7. Association Parameter Index (API)............................4 8. Ethernet over IP Protocol Type...............................4 9. GRE Packet Header............................................4 10. Issues......................................................5 11. Security Considerations.....................................5 12. References..................................................5 13. Acknowledgments.............................................5 14. Author's Addresses..........................................6 3. Introduction Layer 2 VPN services are gaining popularity as a low cost, low maintenance VPN service. Providing Layer 2 VPN services for Ethernet is attracting attention due to the wide spread deployment of Ethernet technology. Several MPLS solutions have been proposed to tunnel inter-site Ethernet traffic across shared networks. However, MPLS still has not reached wide deployment. However, IP is widely used over the Internet. Hence use of IP to transport Ethernet across IP networks allow providers to provision Layer 2 VPN services across the existing public Internet. Generic Routing Protocol (GRE) [3], present methods to encapsulate any arbitrary network layer protocol over another arbitrary network Layer protocol. [4] Present GRE encapsulation over IP networks. The concepts presented in [3] and [4] can be easily extended to encapsulate link layer protocols such as Ethernet over any arbitrary network layer protocol. In this document we present the GRE encapsulation needed to transport Ethernet over IP. In addition, when providing Layer 2 VPN services, end devices MUST have capabilities to discover the remote ends, de-encapsulate GRE Senevirathne, et.al. Informational- January 2002 2 draft-tsenevir-l2vpn-gre-00.txt July 2001 frame and forward the Ethernet frame appropriately. In this document we present methods to address these requirements. In this document we assume that readers are familiar with GRE related encapsulation formats and header formats. [3] and [4] provides the required background. 4. Requirements Some of the requirements are common to Layer 2 VPN services; others are specific to Ethernet over IP using GRE. 1. Ethernet over IP using GRE SHOULD be a point-to-point Layer 2 VPN service. 2. Discovery and signaling protocols SHOULD be using IP protocol or IP routing protocol. 3. Methods MUST be defined to identify Ethernet over IP packets and de-multiplex them into appropriate layer 2 forwarding instance. 4. Encapsulation of Ethernet packets in to IP payloads using GRE MUST be defined. 5. Mapping of 802.1p and other QoS parameters to Delivery IP header and vise versa MUST be defined. However, this requirement is largely considered a local policy. 5. End-point discovery and de-multiplexing A given PE device may service more than one Layer 2 VPN service. Each of these VPN may terminate at different remote sites. In smaller deployments VPN end-points MAY be manually configured. However, ability to discover remote sites is essential in larger deployments. In order to discover and bind remote end points to local end points, Layer 2 VPN service MUST be able to identify the VPN uniquely. [5] Has provided Layer2NBVPN_ID as a unique parameter to identify the VPN. [6] Has provided methods to discover and bind Layer 2 VPN services. The remote site is required to de-multiplex receiving Ethernet over IP packets to appropriate outgoing layer 2 forwarding instance. We propose to use either OPSF Opaque LSA or BGP-MP to distribute local de-multiplexing key. [6] Has provided methods to distribute a MPLS label for Layer 2 VPN. This same method can be used in Ethernet over IP using GRE. The de-multiplexing key distributed by the signaling protocol, called Association Parameter Index (API), is encoded in to the "key" field of the GRE Header [3]. Remote side, when de- encapsulating the GRE packet can use the API to forward the Ethernet packet appropriately. 6. Encapsulation of Ethernet frame in to IP payload using GRE Senevirathne, et.al. Informational- January 2002 3 draft-tsenevir-l2vpn-gre-00.txt July 2001 Entire Ethernet packet MUST be encapsulated into IP payload using GRE. Fragmentation of Ethernet packet before encapsulation is beyond the scope of this document. Optionally, CRC of the original Ethernet packet MAY be included. 7. Association Parameter Index (API) Association parameter Index (API) also known as de-multiplexing key allows remote sites to bind the terminating Ethernet over IP packets to appropriate Layer 2 VPN service and forward according to local policies. API is a 32-bit number. API is encoded in to the "key" field of the GRE Header [3]. The MSB (bit 0) indicates that incoming Ethernet carries the original CRC. 8. Ethernet over IP Protocol Type GRE [3] require defining a unique protocol type to identify the payload. Ethernet over IP is required to be identified uniquely from other GRE encapsulations. Presently 0x6558 is defined for transparent bridging. However, Ethernet over IP goes beyond Transparent Bridging in the way of providing Layer 2 VPN service. Hence it is important to uniquely identify the Ethernet over IP for Layer 2 VPN. A new value is being requested from IANA. 9. GRE Packet Header In this section we outline the GRE Header specified in [3]. Only the fields applicable are discussed. For detail information please refer to [3] and [4]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R|K|S|s|Recur| Flags | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Offset (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing (optional) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol Type Protocol Type specifies that this is an Ethernet over IP Layer 2 VPN packet. A value being requested from IANA for the purpose. Senevirathne, et.al. Informational- January 2002 4 draft-tsenevir-l2vpn-gre-00.txt July 2001 Key (4 octets) The Key field is mandatory in Ethernet over IP. Hence Key field in flags MSUT be set. Setting MSbit (bit 0) to 1 of key indicates Ethernet payload carries the original CRC. All other fields carry the original meaning. 10. Issues Ethernet encapsulation over IP using GRE requires at minimum IP Header + GRE Header (+ MAC header). When carrying small packets (64 bytes), proposed method introduce a large overhead. If fragmentation allowed in the IP header, end devices MUST have capabilities to re-assemble the packet. 11. Security Considerations This draft does not address specific security issues. 12. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Hanks, S., "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. 4 Hanks, S., "Generic Routing Encapsulation over IPV4 networks", RFC 1702, October 1994. 5 Senevirathne, T., Requirements for Network Based Layer 2 VPN, Work In Progress, July 2001. 6 Senevirathne, T., BGP/MPLS Layer 2 VPN, Work In Progress, July 2001. 13. Acknowledgments Senevirathne, et.al. Informational- January 2002 5 draft-tsenevir-l2vpn-gre-00.txt July 2001 Interest in providing Layer 2 VPN services across IP networks motivated the work in this document. 14. Author's Addresses Tissa Senevirathne Force10 Networks 1440 McCartthy Blvd, Milpitas, CA 95035 Phone: 408-965-5103 Email: tissa@force10networks.co.m Som Sikdar Force10 Networks 1440 McCartthy Blvd, Milpitas, CA 95035 Neena Premmaraju Force10 Networks 1440 McCartthy Blvd, Milpitas, CA 95035 Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne, et.al. Informational- January 2002 6