If you operate a private ATM campus network or metropolitan-area network, a Multi-protocol Label Switch Layer 2 VPN could be a cost-effective, high-speed alternative.
If you’re buying frame relay or ATM from a service provider, in the next year to 18 months you may see lower-cost Ethernet-based offerings built on MPLS Layer 2 VPN technology.
Service providers are expected to leverage the transparent connectivity of MPLS Layer 2 VPNs to offer features such as remote-server management, off-site storage and even voice over IP.
All this is being made possible because the Internet Engineering Task Force (IETF), through its Provider Provisioned VPN (PPVPN) and Pseudo-Wire Emulation Edge to Edge (PWE3) working groups, has focused on defining standards that leverage MPLS for creating VPNs.
In particular, a set of documents known as the Martini drafts has won the support of nearly a dozen vendors and piqued serious interest among several service providers, including Level 3 Communications Inc., Cable and Wireless PLC, IntelliSpace Inc. and Telseon Inc.
Although no standards have yet been defined by the working groups, many vendors have already implemented the Martini drafts, with additional implementations in the works. Cisco Systems Inc., Extreme Networks Inc. and Riverstone Networks Inc. announced support for Ethernet-based MPLS Layer 2 VPNs last spring. Last fall at NetWorld+Interop, Foundry Networks Inc. and Laurel Networks Inc. joined in and participated with Cisco, Extreme and Riverstone in interoperability testing of Ethernet across an MPLS network compliant with Martini encapsulation.
Atrica Inc., Juniper Networks Inc., Nortel Networks Corp., TiMetra Inc. and Tenor Networks Inc. are among the other vendors also tracking Martini and related drafts. All plan to roll out implementations in the first half of this year. While initial announcements have centered on Ethernet, there also is broad support among vendors for ATM and frame relay encapsulations.
Soon, enterprise customers and service providers will be able to transport a range of Layer 2 traffic types across an MPLS backbone, opening the door for a variety of applications and services.
The enterprise play
Financial services firms, universities and government agencies in particular are expressing interest in MPLS VPNs as a way of upgrading their private ATM-based campus and MANs.
These organizations are looking to Ethernet for the bandwidth they need to scale their current campus and MANs, but are reluctant to give up the bandwidth management, quality of service (QoS) and reliability aspects of ATM. By deploying Ethernet over an MPLS infrastructure, they can get many of the characteristics of ATM — including traffic management, fast failover and QoS’ on lower cost, higher performance equipment.
MPLS Layer 2 VPN technology is appealing because it lets companies extend LANs beyond a building without having to set filters on routers or configure LAN emulation over ATM, says Sam Halabi, vice president of architecture at Extreme.
On the service side
Telseon, IntelliSpace and others offer Ethernet-based MAN services, but several factors have limited the success of these services, including a lack of geographic reach. Metropolitan Ethernet also has been limited to service providers with optical infrastructures, says Azhar Sayeed, IP MPLS Manager in Cisco’s IOS Technologies Division. MPLS Layer 2 VPN technologies based on the Martini approach addresses these issues.
Using Martini technology, anyone with a routed infrastructure can offer Ethernet services. The same goes for frame relay and ATM. Service providers focused on IP could add frame relay and ATM simply by modifying the edge of their networks, where the Martini-style encapsulation takes place, and turning on MPLS in their network core, if they haven’t done so already.
Level 3 and the U.K.’s Storm Telecommunications Ltd. are solving the “reach” problem by offering international Ethernet LAN extension services based on Martini technology. In January, Level 3 began commercial deployment of Ethernet over MPLS services based on the Martini drafts. The company’s large-enterprise customers can use the service to connect 802.1Q virtual LANs (VLAN) across a wide area, initially encompassing the U.S. and Europe. Likewise, Level 3 service provider customers, such as Yipes, can use it to offer expanded Ethernet coverage to their end customers.
Level 3Os services support multiple VLANs per customer Ethernet port connected, letting multiple point-to-point virtual circuits be established over the same port. Level 3 is offering service-level agreements for the service based on availability, latency and packet delivery.
Pricing, in the form of monthly recurring charges, is based on a combination of port and VLAN charges and aggregate usage. In early spring, Level 3 expects to expand its MPLS Layer 2 VPN support to encompass ATM and frame relay.
Last fall, Storm announced its International Ethernet Service. Based on the Martini drafts, the service was initially rolled out in Europe, with a connection to New York due to go online early this year. Storm is offering customers bandwidth in 1M-bit/sec increments and what it calls premium service guarantees (including 99.99 percent availability and round-trip times between the U.S. and Europe of less than 80 msec).
On the MAN front, Telseon sees MPLS Layer 2 VPN technology enabling its customers to more seamlessly connect their LANs. Currently, Telseon restricts customer use of Ethernet media access control addresses and VLAN tags to avoid conflicts with its internal network operations. However, by using the Martini approach, Telseon will be able to fully encapsulate customer traffic, eliminating the need for such restrictions.
Telseon and IntelliSpace see opportunities for expanded services offerings based on MPLS Layer 2 VPNs. With a fully transparent service such as the Martini approach allows, service providers can offer storage services and server management that appear as an extension to the customerOs network. MPLS Layer 2 VPNs also let metropolitan providers ensure the strict QoS guarantees needed to support applications such as VoIP, especially in converged infrastructures, says Carlo Lalomia, IntelliSpace’s co-founder and CTO.
For enterprise customers, using such services should require little — if any — change at their premise. The customer premises equipment (CPE) essentially sees the provider’s equipment as a Layer-2 device, such as an Ethernet VLAN switch or a frame relay switch. As Ethernet-based services expand, more corporations will find they simply can use an Ethernet switch to interconnect to their service providers. In some cases, a service provider may want the MPLS virtual circuits to begin at the CPE, which would require an MPLS-capable router on the premises.
Because MPLS Layer 2 VPNs are virtual circuit-based, they are as secure as other virtual circuit- or connection-oriented technologies, such as ATM. And because the Layer 2 traffic is carried transparently across the MPLS backbone, information in the original customer traffic — such as class of service markings and VLAN IDs – remains unchanged. Companies that need to transport non-IP traffic (such as legacy IPX or other protocols) may find Layer 2 VPNs the best solution. Layer 2 VPNs also may appeal to corporations that have private addressing schemes or prefer not to share their addressing information with service providers.
At this time, the Martini approach supports point-to-point connections only, although work on multipoint is proceeding. One IETF draft (Lasserre) already defines multipoint services for Ethernet and is supported by Riverstone and several other vendors. Work is also ongoing to automate some aspects of Layer 2 VPN provisioning, so that network operators only have to provision one rather than both ends of the connection. Several vendors indicated they are working to make Ethernet-based MPLS Layer 2 VPNs as easy to provision as VLANs.
Petrosky is an independent technology analyst in San Mateo, Calif. She can be reached at mary@mpetrosky.com.
Layer 3 MPLS VPNs
Network-based VPN (RFC 2547)
L3 managed by service provider.
Service provider has visibility into customer routing, though customer can use either globally unique or private addressing (at some burden to service provider).
Limited to IP.
Independent of underlying L2 technology.
Layer 3 MPLS VPNs
Network-based VPN (RFC 2547)
L3 managed by service provider.
Service provider has visibility into customer routing, though customer can use either globally unique or private addressing (at some burden to service provider).
Limited to IP.
Independent of underlying L2 technology.
How it works: Layer 2 VPNs
With Multi-protocol Label Switching Layer 2 VPNs based on the Martini approach, a customer’s Layer 2 traffic is encapsulated when it reaches the edge of the service provider network, mapped onto a label-switched path, and carried across a network.
This Layer 2 VPN technique takes advantage of MPLS label stacking, whereby more than one label is used to forward traffic across an MPLS infrastructure. Specifically, two labels are used to support MPLS Layer 2 VPNs: One label represents a point-to-point virtual circuit, while a second label represents the tunnel across the network.
The current Martini drafts define encapsulations for Ethernet (port-based and virtual LANs [VLAN]), ATM (ATM Adoption Layer Type 5 and cell formats), Frame Relay, Point-to-Point Protocol and High-level Data Link Control.
Other drafts are being developed that fine-tune support for specific traffic types. The Fischer draft (which vendors such as Alcatel and Nortel support) provides an alternative encapsulation for ATM.
Once traffic is encapsulated, the ingress Label Switch Router (LSR) assigns it a virtual circuit label. This label identifies the VPN, VLAN or connection end point (equivalent to a Frame Relay Data Link Connection Identifier, for example); the egress LSR uses the virtual circuit label to determine how to process the frame. Control protocols, including the MPLS Label Distribution Protocol and Border Gateway Protocol, are used to set up the emulated virtual circuits.
For its part, the tunnel label determines the path a packet takes through the network – that is, LSRs in the network core use the tunnel label for packet forwarding. Numerous emulated virtual circuits can be carried in a single tunnel, which aids in scalability.
Vendors are supporting a variety of MPLS protocols, including Label Distribution Protocol and Resource Reservation Protocol-Tunneling Extension, for tunnel setup.
