Virtual Private LAN Service

Transcription

1 Virtual Private LAN Service Authors Kireeti Kompella, Juniper Networks, 1194 N Mathilda Avenue, Sunnyvale, CA 94089, USA kireeti@juniper.net Jean-Marc Uzé, Juniper Networks, Espace 21, 31 Place Ronde, Paris la Défense, France juze@juniper.net Keywords: Virtual worlds and virtual communities, Ethernet Multipoint Service, End-to-end model, Border Gateway Protocol Executive Summary The ultimate goal of Metro Ethernet is to provide a multipoint-to-multipoint Ethernet service that can connect multiple LANs that are either within the same metro area or spread across geographically disparate metro areas such that they behave as if they were all attached to the same Ethernet LAN. An emerging standard called Virtual Private LAN services (VPLS) provides the promise of delivering on this vision. However, not all implementations of VPLS offer the same operational efficiencies. This paper highlights the differences between two leading IETF drafts and deals with specific issues related to Research & Education Networking environment that requires end-to-end solutions across multiple domains. Abstract Ethernet is the most widely deployed and ubiquitous local area network (LAN) technology in the world with over 100 million Ethernet clients deployed today. Over the past few years, there has been significant innovation around Ethernet standards, not only in the form of dramatic throughput increases from 10 Mbps all the way to 10 Gbps, but also protocol enhancements extending Ethernet s physical reach to function as a wide area network (WAN) solution commonly known as Metro Ethernet. In those areas today where Metro Ethernet service is offered by service providers, it is often point to point connections between multiple sites within the same metro. However, the ultimate vision held by Metro Ethernet proponents is the ability to move beyond point-to-point connectivity that is confined to a single metro area to deliver multipoint-to-multipoint connectivity either within a single metro or spanning multiple metro areas. In other Virtual Private LAN Service p.1

2 words, deliver a service to an enterprise such that all sites appear if they are connected to the same simple Ethernet LAN, irrespective of whether the sites are in the same metro area or spread across multiple metro areas. One of the most talked about and promising approaches to delivering on this vision is known as Virtual Private LAN Service (VPLS), which provides both intra- and inter-metro multipoint-to-multipoint Ethernet connectivity over a scalable IP/MPLS service provider network. Metro Ethernet service offerings today are somewhat limited. Many providers are simply supporting a point-to-point connection that either provides dedicated Internet access or a private interconnect between sites within the same metro. Some providers supporting only a few customers have deployed multipoint-to-multipoint Ethernet LAN connectivity within a single metro; multiple sites in the same metropolitan area are connected as if they are on the same LAN, using VLAN IDs for logical traffic separation. However, since most service providers delivering Metro Ethernet services today have constructed their networks out of Ethernet switches, providing this service across a large metro network has some inherent problems. The service is difficult to manage and sometimes unavailable due to spanning tree protocol instability, broadcast storm issues, and other known problems with large Ethernet networks. These networks are also limited in the ultimate number of customers that can be deployed; they can only support 4,096 VLAN Ids. One ID is required per customer, and since VLAN IDs are globally significant, they must all be unique within the service provider. Providing LAN functionality across multiple metros with this architecture is simply out of the question because it would require that the service provider build an even larger Layer 2 Ethernet network. Therefore, deployment of multipoint-to-multipoint Metro Ethernet service across multiple metros has been unrealistic to date. Because multi-site enterprises have been limited to point-to-point connections across multiple metro areas, they typically implement a hub and spoke network topology for WAN connectivity. Remote offices are connected into a central headquarters facility that in turn is connected to strategic resources such as datacenters or network attached storage (NAS). There are a number of drawbacks to this architecture: The architecture burdens the service provider with the overhead involved in managing numerous point-to-point connections, requiring additional staff and operational expense Each time a spoke is added, both the hub and the spoke CPE 1 must be configured. A failure of the hub incurs total failure of the enterprise network (an enterprise could mitigate this by using multiple hubs, but that in turn would make the first two drawbacks even more serious). Site-to-site traffic frequently has to traverse the service provider network twice, and does so via the hub, thus greatly increasing the bandwidth requirement of the hub connection. 1 Customer Premises Equipment Virtual Private LAN Service p.2

3 Transaction latency occurs due to congestion at the hub when multiple remote offices access a resource through headquarters and oversubscribe its bandwidth. Use of the Spanning Tree Protocol (STP) for both loop detection as well as fast convergence has the potential to cause difficulties. While STP is effective at loop detection, using STP for fast convergence has led to a number of issues. VPLS delivers a multipoint-to-multipoint Ethernet service that can span one or more metro areas and that provides connectivity between multiple sites as if these sites were attached to the same Ethernet LAN. In contrast to the current Ethernet multipoint to multipoint service offering that is delivered upon a service provider infrastructure composed of Ethernet switches, VPLS uses the IP/MPLS service provider infrastructure. From the service provider's point of view, use of IP/MPLS routing protocols and procedures instead of the Spanning Tree Protocol and MPLS labels instead of VLAN IDs within the service provider infrastructure results in significant improvements in the scalability of the VPLS as a service. Each Provider Edge (PE) router at the edge of the service provider s IP/MPLS network is enhanced with special VPLS features as defined by the IETF drafts that will be discussed in this paper. There are one or more VPLS domains that will be associated with each enterprise that is using the service provider network as a virtual LAN. Each VPLS domain is composed of some number of PEs, each running a VPLS instance that participates in that particular VPLS domain. To keep the concept simple, assume that there is only one VPLS domain per enterprise such that a VPLS instance will run on each PE that is connected to a site belonging to that enterprise. A full mesh of LSPs must be built between all of the VPLS instances on each of the PEs in a particular VPLS domain. Depending on the exact VPLS implementation, when a new PE or VPLS instance is added, the amount of effort to establish this mesh of LSPs can vary dramatically. Once the LSP mesh is built, the VPLS instance on a particular PE is now able to receive Ethernet frames from the customer site and, based on the MAC address, switch those frames into the appropriate LSP. This is possible because VPLS enables the PE router to act as a learning bridge with one MAC table per VPLS instance on each PE. In other words, the VPLS instance on the PE router has a MAC table that is populated by snooping, that is, learning, the MAC addresses as Ethernet frames enter on specific physical or logical ports, exactly the same way that an Ethernet switch works today. Once an Ethernet frame enters via a customer-facing ingress port, the destination MAC address is looked up in the MAC table and the frame is sent unaltered (as long as the MAC table contains the MAC address) into the LSP that will deliver it to the correct PE attached to the remote site. If the MAC address is not in the MAC address table, the Ethernet frame is replicated and flooded to all logical ports associated with that VPLS instance, except the ingress port where it just entered. Once the PE hears back from the host that owns that MAC address on a specific port, the MAC table is updated in the PE. Just like a switch, the MAC addresses that have not been used for a certain amount of time are aged out to control the MAC table size. This Paper will carefully describe both approaches followed by the IETF standard organization and compare the solutions from operational, provisioning and management perspectives. Virtual Private LAN Service p.3

4 Then the paper will explain how VPLS services can be expanded across multiple domains in the Research and Education environment by looking at the existing MP-BGP based solutions but also from a new recent perspective developed at IETF, which is about Inter-region MPLS Traffic Engineering. References Kompella K., et al, Virtual Private LAN Service, draft-kompella-ppvpn-vpls, W. Augustyn et al, Architecture and Model for Virtual Private LAN Services (VPLS), draft-augustyn-vpls-arch, W. Augustyn et al, Requirements for Virtual Private LAN Services (VPLS), draft-ietf-ppvpn-vpls-requirements, P. Knight et al, Logical PE Auto-Discovery Mechanism, draft-knight-l2vpnlpe-ad, K. Kompella et al, Decoupled Virtual Private LAN Services draft-kompellappvpn-dtls, draft-kompella-ppvpn-dtls, K. Kompella et al, Layer 2 VPNs Over Tunnels, draft-kompella-ppvpn-l2vpn, Lasserre M., Kompella V., et al, Virtual Private LAN Services over MPLS, draft-ietf-l2vpn-vpls-ldp, Martini, L., et al, "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", draft-martini-l2circuit-encap-mpls, Martini, L., et al, "Transport of Layer 2 Frames Over MPLS", draft-martinil2circuit-trans-mpls, Rosen E., Rekhter Y., BGP/MPLS VPNs, RFC2547, Mars Rosen E., Rekhter Y., et. al., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis, Vitae Dr. Kireeti Kompella is a Distinguished Engineer at Juniper Networks. His current interests are all aspects of Multi-Protocol Label Switching, including Traffic Engineering, Generalized MPLS, and MPLS applications such as VPNs. Dr. Kompella is active at the IETF where he is a co-chair of the CCAMP Working Group and the author of several Internet Drafts and RFCs in the areas of CCAMP, IS-IS, L2VPN, MPLS, OSPF and TE. He specializes in Layer 2 VPNs, Metro Ethernet and Virtual Private LAN Service. Previously, he worked in the area of filesystems at Network Appliance and SGI; and earlier in the area of security and cryptography. Virtual Private LAN Service p.4

5 Dr. Kompella received his B.S. in Electrical Engineering and M.S. in Computer Science at the Indian Institute of Technology, Kanpur; and his PhD in Computer Science at the University of Southern California. Jean-Marc Uzé is consultant at Juniper Networks since 2001, and his role is focused on Research, Education and Government Networks and Institutions. Jean-Marc spent 4 years at GIP Renater (the French Academic Research Network). As Project Director, he led the Renater 2 Project, the new generation National Research Network of France. As International Project Manager, he was involved in several projects such as TEN-34, TEN-155 and the US connectivity. In addition, he led and coordinated the MPLS activities of the European technical Task Force TF-TEN and TF-TANT. Jean-Marc has a Master of Science in Network Engineering, and started his carrier as head of the Data-processing center of INRA, the French Agronomic Research Institute in Versailles, France. Virtual Private LAN Service p.5