Layer-2 VPNs

Hold on to your toolbelt. Over the next eight months, new layer-2 (L2) Multiprotocol Label Switch (MPLS)-based VPN services are expected to deliver ATM- and frame-like connectivity at a fraction of ATM and frame prices.

Unlike most existing MPLS VPN services, these new L2 VPNs afford networks the same raw L2 protocol that any data service might provide, but they deliver it over an integrated backbone capable of supporting both voice and data. The result, say proponents, is a huge cost savings-one that, at least in part, is expected to be passed back to the consumer. L2 VPNs will also offer networkers better control and a smoother migration path to an MPLS backbone than is possible with existing layer-3 (L3) VPN offerings.

Of course, with more choices comes more confusion. Not only will companies need to select between L2 and L3 VPNs, they'll likely have to choose between two types of L2 VPNs. To get ready for the CEO's and CTO's inevitable purchasing questions, start by defining VPNs for them: a closed user group where admittance is based on an address, such as the Ethernet or frame address for L2 VPNs, and the IP address for L3 VPNs. Then explain the differences between L2 and L3 VPNs, as well as the differences between L2 VPN approaches.

Today's VPNs

Most of today's MPLS-based VPNs are L3 VPN services, well suited to IP-centric corporate networks with simple routing architectures. But they also include companies with offices connected via a mix of frame relay and ATM, or Ethernet and leased line connections, as well as companies looking for more advanced services, such as filtering and Class of Service (COS).

The basis for these VPN services (RFCs 2547 and 2547bis), though, imposes significant scalability, reliability, and operational challenges on providers, even as the RFCs enable them to multi-source their equipment. While only the biggest networks should be impacted by the scalability limitations of L3 VPNs, VPNs can still span about 200 sites, and router instability is another matter. With L3 VPNs, customer routers can flap their routes, or very rapidly turn their routes on and off, causing instability in the provider's edge router or even the carrier's entire network (see "Inside RFC 2547bis" for a more in-depth analysis of the RFC specification at www.networkmagazine.com).

L2 VPNs offer a compromise. They enable networkers to connect new sites with native IP connections, while migrating existing frame relay or ATM sites to MPLS by providing native L2 connections-similar to AT&T's original IP Enabled Frame Relay or IP Enabled ATM services, but based on approved standards. Existing sites might continue connecting with one another via frame relay, while new sites might access the corporate network via Ethernet, all the while carrying a wide range of protocols across the MPLS connection. As for L2 reliability, at worst a Customer Edge (CE) router might destabilize its own line, but it wouldn't destabilize another customer's connection.

The L2 Solutions

Pundits proposed L2 VPN drafts in two groups within IETF: the Pseudo Wire Emulation Edge to Edge (PWE3) group and the Provider-Provisioned VPN (PPVPN) group. The PWE3 group is working on the Martini draft, named after Luca Martini, a senior architect at Level 3 Communications (www.level3.com) and a major contributor to the draft. The draft has garnered broad industry support from many companies including Cisco Systems and Juniper Networks (www.juniper.net), and defines a provider-provisioned point-to-point service called Virtual Private Wire Service (VPWS). Within the PPVPN group, the less-popular Kompella draft, named after Kireeti Kompella, a distinguished engineer at Juniper, defines a provider-provisioned VPWS and a point-to-multipoint service called a Virtual Private LAN Service (VPLS), previously known as a Transparent LAN Service (TLS).

Both drafts specify a way to group individual connections at different routers into a flat network. Those connections may be a single physical segment, as in the case of Ethernet, or virtual channels over a particular port, such as VLANs in Ethernet or virtual circuits in the case of frame relay or ATM.

Under Martini, providers build VPNs from VC IDs, tags that identify the virtual channels running between the specific ports on a CE router and the locally connected Provider Edge (PE) router. Provisioning a link involves configuring an MPLS tunnel between a VC ID on one PE router to the VC ID on another PE router. The provider enters the remote VC ID information at each PE router, associates the ingress and egress VC IDs with one another, and then relies on MPLS's Label Distribution Protocol (LDP) to distribute the necessary label information among the interior routers to carry the L2 packet through an MPLS tunnel between the two points.

With Kompella, however, providers build VPNs with a BGP attribute, the Route Target community. With BGP, PE routers can learn the VPN membership, freeing up the providers from supplying all of the information at every router. To do that providers must first configure PE routers with a list of the locally connected CE routers (identified through a CE-id) participating in each VPN, the specific Route Target community, and the physical interface over which those customers connect to the PE router (called the Interface Index). The router derives the Label Block, a block of MPLS labels mapped to the VCs connecting to the CE, on its own.

Using BGP, PE routers then announce all of this information to the other PE routers. The PE routers receive the announcement and check whether they belong to the particular Route Target community. If they do they add the CE ID and Label Block to their databases for the VPN, and create the necessary routes in their MPLS tables. The L2 address is then associated with an MPLS tunnel.

The two drafts are almost identical during the packet's movement across the MPLS network and in the way PE routers encapsulate ATM, frame relay, or Ethernet signals inside MPLS. When a packet reaches the ingress PE router, it determines the appropriate tunnel and constructs a VC Label. The VC Label is determined from the ingress Interface Index and the VC ID or CE ID (depending on if it's Martini or Kompella), and contains information about the type of circuit (VC Type), as well as specifics about the egress interface. A separate field, called the sequencing control word, provides the circuit's properties, such as the sequential packet propagation, padding, and control bit propagation. The router constructs and appends the VC Label and the requisite MPLS labels to the L2 packet. Depending on the connection, the packet will also get a sequencing control word. Under Kompella, if the network runs IP Interworking, the PE router also strips off the L2 header (see Figure 1).

Figure 1: While Kompella and Martini may differ in their signaling, their generalized packet configuration is very similar. The L1 encapsulation is the additional L1 information, most likely Sonet or SDH, needed to move data across the carrier's infrastructure. The Transport Label is the MPLS label that identifies the MPLS tunnel transporting the encapsulated L2 frames or cells through the MPLS network. The VC label is an MPLS label that identifies the particular L2 virtual connection, such as a Frame Relay DLCI, that is being transported through the MPLS tunnel. The control word contains information about the connection. It may be optional or mandatory depending on the network configuration. The L2 frame or cell is the L2 frame presented to the provider's edge router.

The packet then traverses the MPLS network until reaching the penultimate router or the egress router, where, depending on the network configuration, one of the two strips off the last MPLS label and exposes the VC Label. Either way the egress PE router reads the VC Label, determines the outgoing channel and interface, and sends the L2 packet to the receiving CE device (see Figure 2).

Figure 2: With L2 VPNs, the provider's edge router encapsulates the L2 packet within an MPLS frame and adds a a special MPLS label, the VPN Label, that designates the destined port and virtual circuit (1). The packet traverses the MPLS network, with each MPLS router swapping labels (2). The final router removes the VPN Label exposing the L2 packet to the customer edge (CE) router (3).

Differences

Martini and Kompella share much in common vis- -vis the packet formats and their ability to connect customer premises with a range of L2 protocols including frame relay, ATM, Ethernet, and leased lines. Their respective strengths and weakness are largely derived from their use of BGP, in the case of Kompella, or LDP, in the case of Martini, to distribute VPN information.

Kompella argues that configuring a Martini network is more complicated in two ways. First, Martini lacks a distribution scheme for spreading configuration information across the network, requiring service providers to provision both ends of the circuit. Martini networks only support point-to-point circuits, requiring providers to configure more circuits in a fully meshed network than Kompella requires. Kompella permits both point-to-multipoint and point-to-point circuits.

However, Luca Martini agues that there's likely to be little difference as provisioning systems will automate circuit establishment under either draft. And the use of point-to-multipoint circuits may be a mixed blessing. However, carriers typically want partially meshed networks, he contends, and establishing those under Kompella is greatly complicated by the PE router's need to filter BGP advertisements.

Kompella argues that troubleshooting a VPN under the Kompella draft is simpler than under Martini. Configuring both ends of the links introduces additional operational complexity of the network, especially if a full mesh is required. With a 40-site VPN, Martini would require 1,600 configuration statements while Kompella would require just 40. A separate draft defining single-sided provisioning for Martini would help the matter, reducing the number of statements to 800.

Martini says that the number of such configuration statements is irrelevant because it only affects the router at boot-up time. Even when individuals need to identify specific lines of configuration code, major equipment providers offer tools to zoom in on a specific point in the configuration, leaving the number of statements irrelevant, says Martini.

Finally, Kompella points out that the existing Martini draft inherently limits VPNs to a single Autonomous System (AS) as the draft relies on LDP, an intra-AS protocol. The Kompella-draft's use of BGP for label distribution enables VPNs to work between ASs.

Even so, Martini argues that LDP can be used between ASs, and that according to Nasser El-Aawar, director of engineering at Level 3 and a coauthor of the Martini draft, the company chose LDP because it offers better protection from Internet attacks on L2 infrastructures , and because LDP reduces the long convergence time inherent in BGP. Regardless, networkers should drill service providers about support for such a draft and how they'll interconnect offices that might exist on other providers' networks or in different ASs.

Additional thanks go out to Andrew Malis, chief technologist at Vivace Networks, and Dr. Vijay Srinivasan, senior vice president of technology, and Chandru Sargor, principal engineer, at Cosine Communications for lending their expertise in the formation of this article.

This tutorial, number 171, by David Greenfield, was originally published in the October 2002 issue of Network Magazine.