It’s true that carriers don’t have a lot of money to buy equipment at the moment. But that doesn’t mean that innovation has fallen by the wayside. For one, there is a massive shift going on in carrier networks – from circuit-based to packet-based. If carriers expect to ever get out of their downward financial spiral, they’re going to have to deploy innovative new technology and cook up exciting new services to spur growth.

Virtual Private LAN Service (a.k.a. Transparent LAN Service) is just one example of a packet technology of the future. Essentially, it’s another class of Virtual Private Networks (VPNs) that allow corporate users to secure pipes through public networks.

It’s an emerging subset of technologies that enable new private data services to be offered across standards-based packet networks. The main advantage of VPLS is that it offers a seamless integration between the carrier network and private, corporate networks. Using VPLS, customers can connect multiple sites over a provider-managed IP/MPLS network. All customer sites in a VPLS appear to be on the same LAN, regardless of their location. More importantly, VPLS uses Ethernet as the customer handoff, simplifying the LAN/WAN boundary and allowing for rapid and flexible service provisioning.

Even though the VPLS standard has been in development for roughly two years, VPLS implementations are still in their early days. The service is dependent on the rollout of Ethernet services. Vendors are just now beginning to introduce products that conform to one of two standards drafts.

Here’s a hyperlinked summary:

Webinar

This report was previewed in a Webinar moderated by the author and sponsored by Timetra Networks and Juniper Networks Inc. (Nasdaq: JNPR). It may be viewed free of charge in our Webinar archives by clicking here.

Background Reading and Listening

— Marguerite Reardon is a Senior Editor of Light Reading.

VPLS extends Ethernet from the enterprise LAN environment to the metro network. Each customer site has a customer edge (CE) device – usually an edge router – that it uses to connect to the IP/MPLS cloud either through an aggregation device or directly to a router at the edge of the service provider network.

VPLS's reliance on Ethernet is what could potentially make it huge. After all, Ethernet LANs are standard in the corporate networking market. So, why not just extend them over the wide area, to connect networks over the service provider networks that have already been built?

The driving economic force is the fact that Ethernet is cheap, plentiful, standardized, and easily provisioned in various increments.

How does it work? Point-to-point connections are established between provider edge (PE) devices across an IP/MPLS network run by the service provider or a network of service providers. Using MPLS technology in the routing core, a Label Switched Path (LSP) is established to connect each PE to another PE. The PE devices then extend to an aggregation device, known as a multi-tenant unit (MTU), which is connected to a CE switch or router at a customer site. The PE can also be directly connected to the customer edge device. The devices can then create virtual private LANS by building a tunnel through these connections.

As demonstrated in the diagram above, the VPLS A sites are connected together through the IP/MPLS cloud; the VPLS B sites are connected through the same cloud, but A and B are run as separate VPNs.

Let’s take a step back for a moment. Clearly, VPNs are hot. Service providers have long made money from their Layer 2 Frame Relay services, and some are starting to roll out VPNs based on IP and MPLS. But what is it exactly that carriers need from a VPN service? They want to be able to leverage existing infrastructure; they need something that is scaleable; and they need something that is easily managed.

“Customers want the flexibility to offer multiple services,” says Michael Capuano, director of product marketing for Juniper Networks Inc. (Nasdaq: JNPR). “And they want equipment that can allow them to offer a wide range of offerings.”

There are a lot of choices when it comes to VPNs. There are Asynchronous Transfer Mode (ATM) and Frame Relay links, which are considered the traditional Layer 2 VPNs. Then there are four main flavors of MPLS VPNs. The most widely deployed today are Layer 3 IP VPNs based on an Internet Engineering Task Force (IETF) standard known as RFC 2547. AT&T Corp. (NYSE: T) is offering the service here in the U.S., and a number of European carriers are also offering it (see Virtual Private Networks).

MPLS-based VPNs can be categorized in two main ways. There are those that connect sites together in a point-to-point fashion, and those that connect them together in a mesh to provide what industry experts call any-to-any connectivity. Layer 2 VPNs, including those using the IETF's Draft Martini or Draft Kompella, offer point-to-point services. Layer 3 IP VPNs based on RFC 2547 and VPLS offer any-to-any connectivity.

Layer 3 IP VPNs provide a flexible service that scales well. But because IP VPNs are a Layer 3 service, they can be complicated to configure. The other limitation of IP VPNs is that they are limited strictly to IP.

This is where Layer 2 MPLS VPNS come into play. Draft Kompella, which uses BGP signaling just like IP VPNs, can be configured in a multipoint configuration, but this draft is not widely endorsed. Juniper, which has developed the draft and continues to be its sole supporter, claims that it has several customers signed up for Layer 2 services based on the technology. But for the most part, vendors today are using Draft Martini for Layer 2 point-to-point MPLS VPNs.

VPLS, based as it is on Ethernet, has been designed to overcome at least some of the shortcomings associated with other Layer 2 VPNs, like ATM and Frame Relay. VPLS allows any-to-any connectivity, so that multiple sites can be linked together in the VPN. It can be simple to provision, and it scales well for router interconnect.

“VPLS is more easily managed than some of these other approaches,” says Ferit Yegenoglu, a director at the independent testing lab, Isocore. “Now that Ethernet is more available as an access technology, there is opportunity for it to be deployed more widely.”

But there are limitations. VPLS can have scaling issues. Experts designing gear and working in the standards groups recommend that the critical PE devices used to provide the service be routers instead of switches. The reason is that when a switch is used, all the MAC addresses of devices sitting behind the PE are seen by all the other PE devices. This requires other devices in the VPLS to manage and hold hundreds and potentially thousands of MAC addresses in its table. This problem is greatly reduced when a router is used, because now only one MAC address is seen per routed segment of the network. This makes things easier to scale, since fewer MAC addresses need to be stored in FIB (forwarding information base) tables.

But there are some people in the industry who warn that VPLS might be trotting down the path of other failed technologies, like ATM LAN emulation. Azhar Sayeed, product line manager at Cisco Systems Inc. (Nasdaq: CSCO), says ATM LAN emulation was hyped in the 1990s as a WAN technology. But after much work, development faded as many realized it was not scaleable.

“VPLS makes sense in a metro network,” says Sayeed. “But I’m not convinced it is right for the wide-area network in general. By nature, switching is simpler and routing is more complex. That’s why people don’t build a WAN with Ethernet switches these days.”

Luca Martini, senior architect at Level 3 Communications Inc. (Nasdaq: LVLT) and author of the eponymous draft, agrees that VPLS may not be well suited for the WAN. He says one of the biggest issues with VPLS is management – the multipoint configuration makes it difficult to debug problems.

“It becomes too difficult to manage where there is more than a few switches involved,” he says. “It essentially creates a flat network. And, in general, service providers don’t like flat networks, because it’s difficult to charge different rates over that type of network.”

The primary group working on VPLS standards is called the Provider Provisioned Virtual Private Network, or PPVPN group, within the IETF.

Three issues dominate debate among the different proposed drafts: MTU scaleability; discovery of devices; and pseudowire signaling.

Let’s briefly look at each of these issues:

Draft Lasserre-V. Kompella vs. KompellaThis brings us to the two major standards: Draft Lasserre-V. Kompella and Kompella. No – those aren’t typos. It was primarily two brothers behind the standards (see Kompella vs Kompella).

Lasserre-V. Kompella has been written by Marc Lasserre of Riverstone Networks Inc. (Nasdaq: RSTN) and Vach Kompella of Timetra Networks. Kompella has been written by Kireeti Kompella – Vach Kompella’s older brother and a distinguished engineer at Juniper.

What’s the difference? Right now, it’s about signaling, discovery, and MTU scaleability – the issues mentioned above. It’s also interesting that many players are backing Lasserre-V. Kompella, while Juniper Networks is pretty much the sole backer of Kompella. That’s quite a gamble for Juniper, if you think about it. The reason for this is that Juniper was one of the first players to develop VPLS technology. Once you head down a certain path, it’s hard to reverse course. Juniper argues, however, that it is making provisions to back both technologies in its equipment.

It makes sense for Juniper to cover all its bases, considering that the Lasserre-V. Kompella is close to becoming a working group document, say IETF insiders. All of the interoperability tests are using Lasserre-V. Kompella. Isocore, an independent laboratory based in McLean, Va., conducted tests using this draft in March. Several vendors – including Cisco Systems Inc. (Nasdaq: CSCO), Extreme Networks Inc. (Nasdaq: EXTR), Foundry Networks Inc. (Nasdaq: FDRY), and Timetra – participated.

“It’s important to demonstrate to service providers that these technologies and features are ready to be used today,” says Bijan Jabbari, president of Isocore. “During the testing a number of issues were identified and fixed. Some ambiguities in the LDP VPLS draft were found which were clarified during the testing, and feedback was provided to authors of the draft.”

The MPLS/Frame Relay Alliance is also hosting a VPLS interoperability event for the Lasserre-V. Kompella draft during the Supercomm 2003 tradeshow in early June in Atlanta.

The main differentiator between the two approaches has to do with which protocols to use for signaling and discovery. The Lasserre-V. Kompella draft supports the use of LDP for signaling, but it doesn’t explicitly address pseudowire signaling. The Kompella draft suggests using BGP for signaling as well as discovery.

The drafts also discuss MTU scaleability. Both drafts suggest establishing a hierarchy or a tiered approach. Lasserre-V. Kompella advocates using MPLS, while Kompella suggests using multiple VLAN tags or Q-in-Q.

As noted, virtually every vendor working on VPLS says that it is supporting Lasserre-V. Kompella. Juniper is currently the only vendor that stands firmly behind the Kompella draft.

“Our first release of VPLS is BGP-based,” says Kireeti Kompella, primary author of Draft Kompella and distinguished engineer at Juniper. “But if the industry supports LDP and we have customers asking for LDP, we will support it. We don’t have a religion when it comes to the technology. We may try to guide our customers toward a solution we think is better, but it’s up to them to decide.”

In the end, some experts say that carriers will choose devices not based on the inherent merits of BGP or LDP, but based on the technology with which they feel most familiar.

“When things settle down, much of the contention will go away between LDP and BGP supporters,” says Loa Andersson, the co-chair of the MPLS working group in the IETF and former chief architect for European service provider, Utfors AB. “LDP will be used by service providers using small edge boxes that aren’t running any Layer 3 services. And larger carriers that are already managing routed networks will use BGP.”

For the full scoop on these differences check out the March issue of Light Reading Insider (formerly Optical Oracle) (see VPLS: The Future of VPNs?).

Regardless of which standard wins, there are some fundamental features that every provider edge router must have in order for it to be able to deliver VPLS:

MAC Learning: A key function performed by VPLS-capable PE routers is to learn the source MAC addresses of the traffic arriving at their access and network ports on a per-service basis. Each PE router maintains a FIB for each VPLS service instance, and learned MAC addresses are populated in the FIB table of the service. The PE routers must maintain separate and distinct FIBs for each VPLS service instance.

Switching: The PE device also needs to switch customer packets based on MAC addresses and forward these packets among all participating PE routers using the LSP tunnels.

Replication: This is key, as well. When a PE router receives a customer packet with a destination MAC address that is not in the FIB (not currently learned), the PE router must replicate (or flood) that packet to all the PE routers that are members of that VPLS service instance. Once the end-station (owner of the destination MAC address) responds, the PE routers learn the location in the network of that destination MAC address and populate the FIB for the service accordingly. From this time forward, packets to this destination are switched directly to the destination, with no replication required. The replication must also be done for customer service packets that are either broadcast or multicast, since the service is a single broadcast domain.

Service Level OAM: Because these PE routers may support thousands of services, they need to be equipped with tools to verify new service and diagnose and troubleshoot existing VPLS service issues related to the data plane, as well as the control plane between participating PE routers and MTU devices on a packet-based network. This is a key function, because carriers are used to a similar set of tools on their ATM and Frame Relay gear.

“Service providers are used to having these tools for ATM and Frame Relay,” says Sunil Khandekar, director of product management for TiMetra. “They want the first line technicians to be able to diagnose a problem. They won’t feel comfortable rolling out a packet-based service without this.”

Discovery: Finally, the last thing that some people argue is necessary on a PE device is an auto-discovery function. This is a process by which one PE router learns which other PE routers are participating in the VPLS. Some vendors like Juniper say this is a critical function of a PE device, while others like TiMetra say this function is unnecessary.

“It’s just not necessary in the PE device,” says Khandekar. “I believe that discovery is more appropriately performed using network management tools rather than overloading the control plane.”

The Players

So who is playing in this market? The typical Ethernet switch and IP routing suspects are all working on solutions. A few of the big names developing VPLS gear are:

Vendors including Atrica Inc., CoSine Communications Inc. (Nasdaq: COSN), Foundry, Juniper, Nortel, and Riverstone say they are already selling pre-standard implementations.

There are also several startups that are involved with developing the standard for VPLS, but have not yet announced a product to support the technology. These include:

The following chart outlines the basic positioning of the players and their products.



Dynamic Table:

Select fields:
Show All Fields
VendorsProductDiscovery SignalingPseudowire SignalingStandard Draft SupportRFC 2547 Support (IP VPNs)Shipping Product