VPLS: Driving profitability for enterprises and service providers

VPLS is a revolutionary Ethernet VPN service that promises to create growth opportunities for service providers while enabling enterprises to cut their IT budgets and simplify their networks.

By JOHN BEATTY and MIKE LOOMIS
Nortel Networks

In today's trying economic environment, enterprises and service providers share a common goal: To drive profitability by any means necessary. However, the challenges that each must conquer to achieve this goal are quite different.

With Information Technology (IT) capital and operational costs ever increasing, enterprises are looking for ways to cut IT expenses so they can devote as much of their available resource as possible to their core competency--their strategic reason for being in business.

For service providers, traffic volumes continue to grow at significant rates, but their revenues remain flat. Supporting higher volumes of traffic at the same revenue means decreasing revenue per bit and a negative impact on the bottom line. These marketplace pressures have led service providers to implement cost reductions as they strive to be profitable. Service providers require the ability to generate new revenues while better controlling their ongoing operational costs to improve profits.

Virtual private LAN service (VPLS) is an Ethernet-based virtual private network (VPN) that promises to solve the difficulties facing service providers today in deploying wide-scale VPN services while improving the value proposition to enterprises for a managed VPN service.

VPNs have already achieved market acceptance. According to Infonetics Research (San Jose), worldwide end-user VPN service expenditures topped $18 billion in 2002. However, nearly $8 Billion of that market was enterprise owned and operated--the unmanaged portion. A robust VPLS gives service providers the ability to attack this part of the market and increase their revenues.

VPLS is a service provider offering that interconnects enterprise customer sites and their various LANs together within the metro or across the wide area. VPLS provides an "any-to-any" service that emulates an extension of the customer LAN to all endpoints of the VPN. Customer endpoints that were traditionally connected via point-to-point WAN links are bridged together at Layer 2 within a VPLS. All endpoints of the VPN appear to the customer to be connected by a single logical Ethernet bridge (See Figure 1). VPLS truly eliminates the boundary between the LAN and WAN by extending the LAN as a metropolitan and wide area service. It is a win/win scenario for enterprises and service providers.

Benefits to enterprises

VPLS offers enterprises an opportunity to significantly simplify and improve the performance of their network. Because VPLS is built on Ethernet LAN technology, the principles of the service are well understood; IT staffs are comfortable with Ethernet. Small and medium enterprises do not need large IT staffs to build, manage, and maintain a more complex routed network--WAN connectivity is achieve by extending the LAN.

Enterprises that have already invested in a routed network also benefit. By implementing VPLS in selective areas of the network, several remote sites can be collapsed into a single LAN. Flattening the network in this manner requires fewer routes to be advertised to the core, improving performance of already overworked core routers. The result is a leaner, simpler, and more efficient network.

Enterprises also appreciate the bandwidth flexibility and speeds offered by an Ethernet service. Ethernet access points easily scale to speeds of 1 Gbit/sec. Policing technology allows the enterprise to purchase only the bandwidth they need in more granular increments. As a Layer 2 service, VPLS is agnostic to all Layer 3 protocols and supports Internet Protocol (IP), SNA, Appletalk, and others in the same manner. There is no requirement to integrate IP addressing schemes with the service provider, which keeps the enterprise's addressing scheme private while simplifying operations on both ends.

Benefits to service providers

For service providers, VPLS helps generate revenues while simplifying operations, reducing costs, and improving overall responsiveness to the customer. As an additional offering, it broadens the services portfolio. VPLS offers a simple, straightforward service that is compatible with existing paradigms and can convince enterprise customers to employ a managed service. VPLS has the potential to increase the service providers' addressable market to include "greenfield" small and mid- sized enterprises that would prefer to outsource their WAN rather than create a complex and costly IT infrastructure.

Additionally, VPLS will allow service providers to capture a greater portion of the IT budget from existing customers and larger enterprises. VPLS moves enterprise IT operational expenditures into the value proposition of the service. If enterprises can save significant IT dollars by consolidating assets, centralizing their computing model, and spending a lot less on managing their WAN infrastructure, they will be willing to spend more on services. The economics are simply too compelling.

The heart of VPLS: The provider edge

Within the Internet Engineering Task Force (IETF), the Provider Provisioned VPN (PPVPN) Working Group is actively working toward standardization of VPLS. The Working Group has identified a reference architecture that defines three types of devices: the Customer Edge (CE) device, the Provider Edge (PE) device, and the Provider (P) device. With its role in the network and the tasks it must perform, the PE device is the focal point of various VPLS design proposals.

The PE is the point of service demarcation that forwards traffic from the CE devices to the P devices of the VPN backbone, connecting customer sites across the provider core. The connections across the core (between PEs) are referred to as 'pseudo-wires,' unique tunnels across the backbone that connect a particular ingress endpoint with an egress endpoint. Pseudo-wires are created across Multi-Protocol Label Switched (MPLS) backbones using Label Switched Paths (LSPs). LSPs have two labels--an outer label that defines the traffic-engineered route between PEs, and an inner label that provides service separation and definition. Minimizing the number of meshed LSPs between PEs maintains simplicity of the control plane and removes operational headaches as the networks scale.

PEs must also perform basic bridging functions on a per-service basis. This involves learning and retaining end-user Media Access Control (MAC) addresses to determine the appropriate pseudo-wire upon which to forward traffic. PE service endpoints can learn remote MAC addresses by associating a remote MAC address with the pseudo-wire upon which they arrived. Alternatively, PEs may learn MACs from the remote endpoint from which the packet was sent. This method of MAC learning ensures that when a customer packet arrives at the PE, it can be encapsulated and securely forwarded across the MPLS backbone based on the packet's final destination MAC address. The method of learning MAC addresses and the access required to the CPU for MAC learning must be carefully architected to allow VPLS to scale.

Because the technology is Ethernet, broadcast traffic is an important design consideration. As Ethernet LAN segments get very large, the number of broadcast packets sent in the course of normal network operations can create network congestion on their own if gone unchecked. Within a VPLS, broadcast, multicast, and unknown MAC packets are forwarded by service-unique, multi-cast labels down all pseudo-wires relevant to that VPN. This requires packet replication across the backbone. Minimization of such replication across the core is another important consideration for a scalable VPLS solution.

With the various functions and requirements the PE must fulfill, it is no surprise that multiple design proposals have been created for a VPLS implementation.

VPLS implementation options

Though there are several drafts currently within the PPVPN Working Group, fundamentally, these drafts define two basic approaches for deploying the PE function. The functionally distributed model splits the PE function between two devices, a customer facing PE-Edge and a network facing PE-Core. The non-distributed model implements the PE function on a single device.

However, it is not as simple as a "one-box" or "two-box" comparison. Though the non-distributed model implements functionality within a single device, the functionally distributed model provides a solution that is more scalable and easier to provision, operate, and maintain (See Figure 2). Because the function is split between two devices, each device can be purpose-built to efficiently support specific functions of the service, thereby lowering the overall cost of building and operating a wide-scale VPLS.

The distributed model offers a simpler and more scalable control plane. In both models, a full mesh of LSPs is required between all PEs. As the number of PEs increases, the number of meshed LSPs increases exponentially (this is known as the "n-squared" problem). However the distributed model allows for significantly more VPN endpoints per PE, and the endpoints can be geographically dispersed across a metro. The result is fewer PE instances that scale to thousands of VPN endpoints across a wider area. Fewer PEs means fewer meshed LSPs across the MPLS backbone, resulting in a control plane that is easier to manage and update, simplifying operations.

The distributed model also has advantages when it comes to packet replication. Packets need only be sent across the core if they are not members of the local PE instance. Because of the functional distribution across network elements, a single logical PE instance can easily encompass an entire metro. With local switching capabilities within this PE instance, packet replication is also localized, maximizing efficiency across expensive core links.

However, service providers may choose to deploy the non-distributed model depending on the environment, the number of customers, and their requirements. For a provider serving multiple tenants in a city skyscraper, for example, the density and proximity of customers to the service provider point of presence lends itself more toward the non-distributed model and the aggregation of customer traffic on one device.

Service providers require the flexibility to deploy the model that best suits the needs of a given situation within a specific metro. Therefore, both models must be able to co-exist and interwork seamlessly within one network.

A new submission into the IETF's PPVPN Working Group outlines the path to this interoperability. Generic Virtual Private LAN Service (GVPLS) presents an option to integrate the various proposals. The major differences between the functionally distributed and non-distributed offerings are the methods by which MAC address learning is accomplished and how service endpoints are discovered and provisioned. GVPLS allows each PE--whether a single device or a distributed logical entity--to advertise how it learns MAC addresses and how endpoints have been provisioned. This enables interoperability between various PE implementations, which in turn allows service providers to implement the model that best suits their needs for a given set of customers.

The resulting interoperability provides the key for VPLS deployment, as service providers can now choose the model they wish to deploy on a metro-by-metro (or even within a metro) basis. VPLS is a revolutionary Ethernet VPN service that promises to cut IT budgets while simplifying enterprise networks and create growth opportunities for service providers. The standards are evolving with GVPLS to enable interoperability-- paving the way for profitable, secure deployment.