Using VPNs to deliver prioritized business services

By Peter Lunk, Extreme Networks -- While MPLS has established itself in the marketplace, emerging native Ethernet technologies present a compelling alternative to MPLS.

While MPLS has established itself in the marketplace, emerging native Ethernet technologies present a compelling alternative to MPLS.

By Peter Lunk, Extreme Networks

Separating the physical network topology from the logical network through the use of virtual private network (VPN) technology is one of the more powerful mechanisms for handling the complexity of triple-play networks. Logically separating the network topology from the services provided by the physical network eases service management, improves reliability through increased redundancy, and enables higher levels of scalability as converged networks continue to expand.

While straightforward in concept, VPNs can be implemented in a variety of ways, causing some confusion among operators looking to deploy these networks. Multi-Protocol Label Switching (MPLS)-based VPNs support multiple types of tunneling, which differ according to the service provided to the end subscriber. The more common types include Layer 3 VPNs using Border Gateway Protocol (BGP)-based MPLS VPNs, Layer 2 VPNs using Virtual Private LAN Service (VPLS), and Hierarchical VPLS. While MPLS has established itself in the marketplace, emerging native Ethernet technologies present a compelling alternative to MPLS.

MPLS

The original driver for MPLS deployment was the performance improvement achieved by cleanly separating forwarding control functions from payload data, thereby leveraging the speed of Layer 2 switching into Layer 3. BGP, one of the more common routing protocols used in carrier backbone networks, is used to distribute routes for MPLS VPNs. However, in this configuration, it is necessary to peer provider and subscriber switches so that a unique IP network can be established for each subscriber switch. Unfortunately, this requires private routes associated with each subscriber to be shared with the provider, forcing subscribers to relinquish some security and control over their network. Additionally, maintaining a separate Virtual Route Forwarding (VRF) table for each VPN can be resource intensive on a router.

While BGP-based MPLS VPNs are well suited for connecting multiple regional sites across the backbone network, many business subscribers are not willing to share their private route domain. Moreover, the cost and complexity associated with configuring dynamic routes through a large heterogeneous network, integrating the network configuration with existing operating support systems (OSS), and upgrading provider routers to support multiple VRFs often is not economically viable for the service provider.

Bringing VPN management down to Layer 2 through VPLS provides inherently more flexibility than Layer 3 VPNs because Layer 2 switches can ignore the higher layer protocols of the immediate network. The provider switch creates a single virtual LAN for each business, thereby eliminating the need to maintain any routing information (i.e. private routes) for the subscriber's network. VPLS effectively isolates and secures the entire network, enabling the business to interact across sites as if connected to a common LAN segment. VPLS is an excellent technology for connecting subscriber LANs within a metro area; it can be deployed without a lot complexity or expensive core IP routers.

The primary shortcoming of VPLS--scalability--has been addressed to some degree through the hub-and-spoke model of Hierarchical VPLS (HVPLS). Of more immediate concern, however, is its inability to efficiently handle multicast traffic with point-to-multipoint Label Switched Paths (LSPs), an issue only recently addressed by the industry. Other concerns include the relatively high cost of equipment and expansion modules for end-to-end deployment.

Although MPLS can reduce complexity in the WAN, it may not be ideal for use in the metro, where an end-to-end MPLS implementation actually can increase complexity as well as impede the performance and flexibility of wire-speed Layer 2 switches.

Hierarchical metro Ethernet network service

Recent extensions to Ethernet have been instrumental in expanding its scope. Figure 1 illustrates how multiple Ethernet-based VPN technologies seamlessly form an end-to-end implementation that leverages the cost structure and simplicity of Ethernet while providing sufficient service instances to handle virtually any size service provider network.

The core of a hierarchical metro Ethernet implementation is the virtual LAN (VLAN). VLANs, based on the IEEE 802.1Q standard, isolate traffic groupings and enable these groupings to be managed as unique entities as though they were on the same physical LAN. VLANs create broadcast domains without the restriction of physical connections and provide adequate scaling for simple enterprise LAN applications. As VLAN networks expand, however, they quickly hit the scalability wall of 4,096 VLANs imposed by 12-bit VLAN IDs. Additionally, media access controller (MAC) address table size increases significantly, and support for quality-of-service (QoS) is often inadequate.

Virtual MANs (vMANs), based on the IEEE 802.1ad specification, build upon VLANs by enabling users to "tunnel" 802.1Q VLANs. vMAN tunnels are completely isolated; they provide transparent private networks with point-to-point or point-to-multipoint connectivity, enabling service providers to separate subscriber traffic while providing different levels of QoS. Subscribers have access to 4,096 VLAN IDs to separate traffic types and classes within their network. Figure 2 illustrates how VLAN tagging within the vMAN tunnel is transparent to the tunnel.

Thus, the vMAN trunk hides subscriber information from the service provider when end-to-end tunnels are employed. Additionally, only one physical port is required to aggregate multiple applications from a single subscriber. By assigning a vMAN for each content network, service providers can map the subscriber VLAN to the appropriate content networks (see Figure 3).

While vMANs do improve scalability, they can face scalability challenges in very large metro networks and provider backbones because of the 4,096-ID limit. In addition, vMANs increase the size of a Layer 2 network, thus increasing the number of MAC addresses that must be learned.

MAC-in-MAC

The emerging IEEE 802.1ah Provider Backbone Bridges standard, also known as MAC-in-MAC, provides a mechanism for gracefully scaling vMANs while enforcing QoS rules across a provider backbone. Figure 4 depicts an Ethernet frame encapsulated within a service provider MAC header (i.e., MAC-in-MAC). This frame format successfully separates service provider resources. Ethernet packets are switched across the service provider network using information in the MAC-in-MAC frame header. The service provider egress switch then removes the MAC-in-MAC header and forwards the Ethernet packet to the subscriber. VLAN IDs and QoS can be preserved or overwritten as desired.

MAC-in-MAC surpasses other VPN implementations--Ethernet or otherwise--by providing millions of service instances and seamless interoperability with vMANs without the complexity of MPLS. Additionally, it elegantly resolves Layer 2 scalability issues related to learning hundreds of thousands of MAC addresses.

However, scale and flexibility are only part of accommodating converged services over Ethernet. Coupled with other technologies that improve network resiliency and visibility, MAC-in-MAC can provide carrier-class performance, reliability, and availability. For example, the Ethernet Automatic Protection Switching (EAPS) standard enables fault-tolerant Layer 2 ring topologies with loop-free operation and sub-50-msec ring recovery. Layer 3-style operation, administration, and maintenance (OAM) capabilities, including ping, Traceroute, and continuity checks, are available through the IEEE 802.1ag Connectivity Fault Management (CFM) standard, which effectively addresses connectivity verification and fault isolation on Ethernet networks, troubleshooting of multi-provider Layer 2 networks, and subscriber monitoring capabilities.

The purpose-built VPN network

VPN implementations need not be mutually exclusive. The efficiency of a particular approach depends upon scale, subscriber service requirements, and legacy deployments, among other factors. In many cases, a combination of several VPN technologies offers the most efficient approach. For example, service providers can continue to leverage existing MPLS implementations in the provider core but deploy native Ethernet VPNs elsewhere in the network when expanding to meet new subscriber needs.

While BGP-based MPLS VPNs are pervasive throughout the core of many IP networks, MPLS is far less compelling in the metro, given the added complexity, privacy issues, and substantial resource requirements of MPLS. VPLS and HVPLS are well suited for metro and smaller backbone MPLS implementations but are difficult to implement in larger backbone applications. With the arrival of VMAN and MAC-in-MAC technology, native Ethernet VPNs now provide a simple and cost-effective all-Ethernet approach for implementing carrier-class converged networks that deliver prioritized VPN services to businesses. Through a combination of these VPN technologies, carriers can offer multiple VPN services to subscribers while making the most efficient use of network resources.

Peter Lunk is senior manager of service provider marketing at Extreme Networks (Santa Clara, CA). He may be reached via the company's Web site at www.extremenetworks.com.

More in Packet Transport