PPVPN Working Group Tissa Senevirathne Force10 Document: draft-tsenevir-gre-vpls-01.txt Category: Informational February 2002 Virtual Private LAN Service (VPLS) Solution Using GRE Based IP Tunnels 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 Abstract In this document we present VPLS solution that use GRE and IP tunnels. It is anticipated use of IP tunnels simplify the backend tunneling plane of VPLS solutions, specially compared to MPLS based solutions. Senevirathne Informational - Expiration August 2002 1 drfat-tsenevir-gre-vpls-00.txt February 2002 Placement of this Memo in Sub-IP Area RELATED DOCUMENTS Cited in the reference below WHERE DOES THIS FIT IN THE PICTURE OF SUB-IP AREA PPVPN WHY IS IT TARGETED AT THIS WG The charter of the PPVPN WG specifies Virtual Private LAN Services (VPLS) and Layer 2 VPN. This ID presents a IP tunnel based solution for VPLS. JUSTIFICATION Presently published VPLS solutions are based on MPLS. In this ID we present GRE based solution. In our opinion solution presented in this ID is much simpler and scalable. Hence WG may consider the solution provided in this ID. 1. 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]. 2. Introduction Virtual Private LAN services (VPLS) formally known as Transparent LAN Services (TLS) is used in extending private Local Area Networks across public networks. It is anticipated that VPLS will gain wider deployment with the growth of Metro Area Networks. Presently there are several proposed VPLS solutions. Almost all of these solutions use MPLS as the service provider tunneling protocol. Use of MPLS essentially adds one more protocol to maintain. Most of service provider backbones are based on IP. Hence ability carry VPLS traffic using the same native protocol simplify the operations of the service provider; reduce the cost of providing VPLS services. In this document we provide a VPLS solution based on IP tunnels. [4] Specify encapsulation of Ethernet frames over IP using Generic Routing Encapsulation (GRE) [3]. is used encapsulate VPLS packets over IP tunnels. In this document we propose to extend methods specified in [4] to provide VPLS services. 3. Overview of the Solution Senevirathne Informational - August 2002 2 drfat-tsenevir-gre-vpls-00.txt February 2002 [5] provide detail set of VPLS requirements and related reference models. Any VPLS solution at minimum MUST support following requirements. - Representation of VPLS users - Traffic separation (That is methods to de-multiplex traffic belonging to different users) - Address learning and Unicast forwarding - Broadcast/Multicast/Unknown traffic forwarding - Membership and configuration discovery 3.1 Representation of users Different users of VPLS services are treated as a separate VPN and represented by a unique VPLS-ID. 3.2 Traffic Separation Each PE device is required to identify the VPLS instance before making any forwarding decision. In the proposed solution we suggest to use the embedded GRE Key for this purpose. See section 4 below for the details. 3.3 Address learning and Unicast Forwarding Unicast MAC addresses are only needed to be forwarded to the destination that own that MAC address. Traditional Layer 2 devices accomplish this by learning the addresses. In the proposed solution addresses are learnt against the originating PE device (tunnel). A given PE or tunnel can carry multiple VPLS traffic streams that belong to different VPLS-ID. Hence we propose for each PE device to distribute a unique key for each VPLS-ID. Thus the receiving PE can uniquely identify the VPLS of the packet using the embedded GRE key; and the packet originator PE by the Source IP address of the IP header. In another words MAC addresses are learnt against a Virtual Circuit (VC). See section 4 below for VC representation. 3.4 Broadcast/Multicast/Unknown traffic forwarding Broadcast/Multicast/Unknown traffic are required to be replicated to all members of that VPLS-ID. The originating PE accomplish this by replicating packet over each VC that is part of the Virtual Port (VP) of that VPLS-ID see section 4 below for details. 3.5 Membership and configuration discovery Each PE device who is a member of a given VPLS MUST acquire information about other member PE devices of the VPLS. Information Senevirathne Informational - August 2002 3 drfat-tsenevir-gre-vpls-00.txt February 2002 include IP address of the PE, associated GRE Key (VC ID) and other optional information. Such information can either be manually configured or automatically discovered. Automatic VPLS discovery solutions are presented in [6] [7] [8]. 4. Virtual Circuits (VC) and Virtual Ports (VP) 4.1 Virtual Circuit (VC) There is a separate VC to each participating PE device. Sending device MUST replicate Broadcast, unknown and multicast packets over each VC. VC-ID is locally significant only. VC-ID (GRE Key) is locally allocated and distributed (manually or automatically) to all other devices. Remote sending devices MUST encode the local receiving devices VC-ID (GRE Key) in the encapsulation header. Hence following mappings are needed when address learning VC-ID (GRE Key in the Header) - > VPLS-ID(local) Source IP Address, VLPS-ID -> VC-ID (GRE Key of the remote) All the addresses are learnt against the VC-ID remote. Consider the following example: --------------------------------> VC-AB== GREKey_AB MAC A--> PE-A PE-B <-------------------------------- VC-BA== GREKey_BA MAC address is serviced by PE-A Now FIB at PE-B would looks like MAC Address Destination A,VPLS_ID Encap=GRE, DstIp=IPPE-A, VC= GREKey_BA 4.2 Virtual port (VP) Virtual Port or VP concept is used to avoid loops. Virtual Port is defined as set of Virtual Circuits (VC) that belong to a given VPLS. A given VC can only be a member of one and only one VP. Virtual Port (VP) is defined in the scope of a VPLS. For simplicity and scalability reasons it is always assumed that there is a set of fully meshed tunnels between member PE devices. Hence to avoid loops packets received on a VC MUST not be sent back on another VC that is part of the same VP. A typical Broadcast FIB entry may appear like - Senevirathne Informational - August 2002 4 drfat-tsenevir-gre-vpls-00.txt February 2002 MAC address Destination -------------------------- **,VPLS-ID Encap=GRE, VP= {( srcIp=IPPE-A, VC= GREKey_BA)....} 5. Discussion IP tunnel based VPLS solution presented in this document has several advantages compared to MPLS based VPLS solutions. - Simplicity There is no additional control plane; uses native IP plane for tunnels - Scalability Scalability of MPLS is mainly governed by software scalability. Due to the simplicity of the GRE key management, it is expected the proposed solution to scale to a much higher degree than MPLS based solutions. However the proposed solution require a larger encapsulation header compared to MPLS based solutions. For smaller packets, especially, this overhead can be significant. 6. Security Considerations The solution presented in this draft does not compromise the security of IP infrastructure. VPLS related security issues are discussed in [5]. 7. 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 Senevirathne, T., "Ethernet Over IP - A Layer 2 VPM Solution using Generic Routing Encapsulation (GRE)", Work in Progress, July 2001. 5 Augustyn, W., "Requirements for Virtual Private LAN service (VPLS)", Work In Progress, August 2002. Senevirathne Informational - August 2002 5 drfat-tsenevir-gre-vpls-00.txt February 2002 6 Senevirathne, T., "Distribution of 802.1Q VLAN information using Opaque LSA", Work in Progress, January 2001. 7 Senevirathne, T., "Use of BGP-MP for Layer 2 VPN Membership discovery", Work in Progress. July 2001. 8 Ould-Brahim, H. et.al, "Using BGP as an Auto-Discovery Mechanism for Network Based VPNs', January 2002. 8.Acknowledgments Increasing interest on VPLS and demand for simpler solutions inspired the work presented in this document. 9. Author's Addresses Tissa Senevirathne Force10 Networks 1440 McCarthy Blvd, Milpitas, CA Phone: 408-965-5103 Email: tsenevir@hotmail.com Senevirathne Informational - August 2002 6 drfat-tsenevir-gre-vpls-00.txt February 2002 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 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 Informational - August 2002 7