Network Working Group Tissa Senevirathne Internet Draft (Consultant) Document: draft-tsenevir-gre-subip-00.txt Som Sikdar Category: Informational (Force10) March 2003 Service Emulation Over IP - A 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 Enhancement to Generic Routing Protocol (GRE) is presented. These enhancements are intend to Pseudo wire Services over IP networks. In addition methods presented in this document allow to transport Sub- IP protocols and services over IP networks. It is proposed, in this document, to use higher order bits of the GRE Key to identify the emulated service. Senevirathne, et.al.Informational û Expires September 2003 1 draft-tsenevir-gre-subip-00.txt March 2003 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 3. Introduction.................................................2 4. Association Parameter Index (API)............................3 5. Emulated Services over IP Protocol Type......................4 6. GRE Packet Header............................................4 7. Encapsulation................................................5 7.1 Ethernet Emulated Service...................................5 7.2 Virtual Private LAN Services................................5 7.2.1 Data Plane................................................6 7.2.2 Control Plane.............................................7 7.3 MPLS over GRE...............................................7 8. Issues.......................................................7 9. Security Considerations......................................8 10. References..................................................8 11. Acknowledgments.............................................8 12. Author's Addresses..........................................8 3. Introduction Emulation of wire services, such as Ethernet, ATM and Frame Relay, over IP networks is called Pseudo Wire Emulation. Pseudo Wire Emulation is gaining acceptance as way of creating over lap networks. Pseudo Wire Emulation over IP is particularly important due to the wide spread nature of the Internet. Multi Protocol Label Switching (MPLS) is an emerging protocol. Ability to transport MPLS over IP networks is required to create over lapping MPLS and IP networks or to provide connectivity between MPLS networks that are separated by IP networks such as Internet. 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. In this document the above three services (Pseudo Wire, MPLS over IP and Layer 2 VPN) are referred to as emulated services. 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 Senevirathne, et.al.Informational- Expire September 2003 2 draft-tsenevir-gre-subip-00.txt March 2003 concepts presented in [3] and [4] can be easily extended to encapsulate link layer protocols such as Ethernet or Sub-IP protocol such as MPLS over any arbitrary network layer protocol. In this document we present Enhancements to GRE encapsulation to provide combine PWE3 and Sub-IP services. Generic Routing Protocol (GRE) [3] specifies to use separate GRE protocol type for each protocol carried over the GRE tunnel. Due to the amount of wire services, Sub-IP encapsulation and services available, definition of unique protocol type to denote each encapsulation type becomes administratively difficult. In this document we propose to use a single protocol type to identify all three emulated services (Pseudo Wire, Sub-IP and L2 VPN) within the GRE encapsulation. It is proposed to use the higher order bits of the GRE Key [3] to identify the individual emulated service. 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. Association Parameter Index (API) Association parameter Index (API) also known as de-multiplexing key allows: 1. To identify the Emulated service provided 2. NSP Layer to provide required services. As an example, in Layer 2 VPN services - API allow PE device 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]. API is generated by the originating device (i.e. ingress) and distributed to remote device. As part of the ingress encapsulation process, API that corresponds to the Emulated service MUST be included in the "key" field of the GRE header. The egress device use the API embedded in the GRE key field to identify the PW or the emulated service. Source IP address combined with API allow the egress device to uniquely identify the service instance. 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 Senevirathne, et.al.Informational- Expire September 2003 3 draft-tsenevir-gre-subip-00.txt March 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Service | Session Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C - (1 bit ) - Payload contain the CRC of the packet. Service - ( 7 bit) - Type of the emulated Service 0 - Ethernet VLAN 1 - Ethernet Port 2 - Frame Relay 3 - ATM 4 - Virtual Private Wire Service (VPWS) 5 - Virtual Private LAN Service (VPLS) 6-127 - Reserved Session Index - ( 24 bits) - Interpreted Within the context of Emulated Service 5. Emulated Services over IP Protocol Type GRE [3] require defining a unique protocol type to identify the payload. Emulated services over IP is required to be identified uniquely from other GRE encapsulations. Presently 0x6558 is defined for transparent bridging. However, Emulation over IP goes beyond Transparent Bridging.. Hence it is important to uniquely identify the Emulated Services over IP. A new value will be requested from IANA. 6. 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 (API) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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- Expire September 2003 4 draft-tsenevir-gre-subip-00.txt March 2003 Key (API)(4 octets) Refer to section 7 above for details. All other fields carry the original meaning. 7. Encapsulation Entire Service Unit (Frame, Cell, or Packet) SHOULD be encapsulated into the IP payload. Fragmentation of the payload prior to the encapsulation is beyond the scope of this document. If the original payload contain a CRC field, CRC field MAY be included as part of the payload. If the CRC is included in the payload appropriate fields in the API MUST be set. 7.1 Ethernet Emulated Service Ethernet Emulated service can be constructed by emulating Ethernet Pseudo Wire. Ethernet PW can be constructed using the encapsulation method presented in this document. API (Application Parameter Index) presented in this document allow to identify the PW type. Two possible PW types are proposed in providing Ethernet emulated services. Namely, "Ethernet VLAN" and "Ethernet port". Ethernet VLAN service maps an incoming VLAN to a PW. Ethernet port service maps ingress port to a PW. API is generated by the originating device (i.e. ingress) and distributed to remote device. As part of the ingress encapsulation process, API that corresponds to the PW MUST be included in the "key" field of the GRE header. At ingress entire Ethernet packet , is encapsulated in to the GRE payload. Optionally, based on configuration , preamble and FCS fields MAY be included in the payload. There SHOULD not be any other processing such as 802.1Q Tag translation etc.. at the ingress. The egress device use the API embedded in the GRE key field to identify the PW or the emulated service. Source IP address combined with API allow the egress device to uniquely identify the service instance. Egress device MAY perform Ethernet processing such as 802.1Q Tag translation, Tagged or untagged. If the preamble and FCS are striped they MUST be regenerated. 7.2 Virtual Private LAN Services Lets consider the basic model of VPLS depicted in Fig 1 below. In this diagram we assume that there is a set of full mesh tunnels Senevirathne, et.al.Informational- Expire September 2003 5 draft-tsenevir-gre-subip-00.txt March 2003 between each member PE (Provider Edge) device of a given VPLS instance [req]. Each of the tunnel is a Ethernet PW presented in section 7.1. Each PE device is required to uniquely identify tunnels for a given VPLS from a given PE device. This identification is required for the purpose of MAC address learning and detection of MAC address moves. In the GRE based implementation presented in this document it is proposed to use Source IP address and Application Parameter Index (API) tuple to uniquely identify a tunnel. +----+ +----+ + C1 +---+ ........................... +---| C1 | +----+ | . . | +----+ Site A | +----+ +----+ | Site B +---| PE |---- GRE Cloud ----| PE |---+ +----+ | +----+ . | . . +----+ . ..........| PE |........... +----+ ^ | | | +-- Emulated VLAN +----+ (VPLS instance) | C1 | +----+ Site C Fig 1: VPLS architecture 7.2.1 Data Plane Flooding, Broadcast and Multicast Forwarding Unknown unicast packets, Broadcast packets and Multicast packets are generally forwarded more than one destination. Each of the destination is a remote PE device that is connected to the local PE via a tunnel (Ethernet PW). Hence ingress PE device MUST have capabilities to replicate and send packets over more than one tunnel. When forwarding Multicast packets, additional control plane and security policies define the scope of the packet forwarding. These issues are out of the scope of this document. Nevertheless, final forwarding functionality is modeled replication of packets to multiple destinations over Ethernet PW. Address Learning Senevirathne, et.al.Informational- Expire September 2003 6 draft-tsenevir-gre-subip-00.txt March 2003 Learning of relation ship between a given MAC address and PE device (or tunnel) is called address learning. Address learning is important for unicast forwarding. PE devices MUST have ability to learn addresses against Source IP address and API tuple. Unicast Forwarding A unicast packets with known destination address , subjected to security and forwarding policies, SHOULD be forwarded over the tunnel that the address was learnt. Address Move In an environment where CPE network is multihomed, address may move from one PE to another. In this situation , PE device MUST be able to identify the address move and learn against the new tunnel. 7.2.2 Control Plane GRE defines only encapsulation procedures. However for proper functioning of VPLS require signaling of new VPLS, distribution of API etc. We propose to use any IP based VPLS discovery protocol that is capable of distributing, VPLS instance ID, PE device address (same as source address in GRE packets) and API. As an example, BGP Autodiscovery presented in [BGP-DISC] provide methods to distribute all required parameters for GRE based VPLS. 7.3 MPLS over GRE Entire MPLS packet minus the Shim header SHOULD be encapsulated in to the GRE packet. The egress device SHOULD treat the GRE header as the shim header. API embedded in the GRE header and Source IP address of the GRE packet allow the receiving PE to identfy logical interface over with the MPLS packet arrived. 8. 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. Egress device use Source IP address and the API to uniquely identify a Emulated service. Special care must be taken when originating device is behind a NAT service. It is possible to combine sequence field and key field of the GRE header and embedded the originating devices IP address or identifier in the GRE header it self. In such event global uniqueness of the identifier MUST be ensured. Senevirathne, et.al.Informational- Expire September 2003 7 draft-tsenevir-gre-subip-00.txt March 2003 9. Security Considerations This draft does not address specific security issues. Security infrastructure provide by IP layer may be used to secure the emulated services. In the event of pseudo wire service, this lead to a secure pseudo wire. 10. 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. 11. Acknowledgments Interest in providing emulated services across IP networks motivated the work in this document. 12. Author's Addresses Tissa Senevirathne Force10 Networks 1440 McCartthy Blvd, Milpitas, CA 95035 Phone: 408-965-5103 Email: tsenevir@hotmail.com Som Sikdar Phone: 408-921-5051 Email: som@sikdhar.org Full Copyright Statement "Copyright (C) The Internet Society (2002). 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 implementation may be prepared, copied, published Senevirathne, et.al.Informational- Expire September 2003 8 draft-tsenevir-gre-subip-00.txt March 2003 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- Expire September 2003 9