x
Optical/IP

MPLS VPNs: The Talk of Supercomm

Virtual private networks (VPNs) based on Multiprotocol Label Switching (MPLS) technology look to be heating up, based on early signs from gear-makers talking up their announcements for the upcoming Supercomm 2002 trade show.

Today, Laurel Networks Inc. and Riverstone Networks Inc. (Nasdaq: RSTN) each announced enhanced support for both Layer 2 and Layer 3 MPLS VPNs in their current products.

Laurel Networks, a startup developing an edge router for the metro core, announced that it would be supporting Layer 3 MPLS VPNs. The software upgrade is an enhancement that has been planned since the product’s inception and will complement the Layer 2 MPLS VPN capability the box already supports (see Laurel Moves to Phase Three). The new software begins testing next month, says Steve Vogelsang, cofounder and vice president of marketing for Laurel.

Layer 3 VPNs allow service providers to offer customers private tunnels through public Internet Protocol (IP) networks using MPLS tagging. The implementation is based on the Internet Engineering Task Force (IETF) request for comments (RFC) 2547 (see VPNs Grow Up ). While MPLS VPNs make up only a small fraction of the total VPN market, they account for about 95 percent of all MPLS deployments, says Kevin Mitchell, an analyst with Infonetics Research Inc.. Several large carriers like AT&T Corp. (NYSE: T), Equant (NYSE: ENT; Paris: EQU), WorldCom Inc. (Nasdaq: WCOM), and NTT Communications Corp. are deploying network-based Layer 3 MPLS VPNs (see Service Providers Jump on VPNs).

Laurel is far from being the first edge router player to announce support for both types of MPLS VPNs. All of its main competitors, including Cisco Systems Inc. (Nasdaq: CSCO), Juniper Networks Inc. (Nasdaq: JNPR), and Unisphere Networks Inc., have announced support for both Layer 2 and Layer 3 MPLS VPNs on their boxes. So what makes Laurel different? Vogelsang says that because the router has a distributed architecture that performs routing functions on every line card, it can scale much higher than these other routers.

For example, the company claims that it can route up to 4 million VPN routes and provide up to 1,600 virtual routers. Virtual routers give carriers the ability to dedicate routing resources and routing tables to a given customer.

On paper, Laurel’s claims seem impressive. Unisphere, whose MRX product is very similar to Laurel’s ST200 Service Edge Router, says its tests show it can handle 500,000 VPN routes, although theoretically, the company claims, it can scale up to 1.5 million. And in terms of virtual routers, Unisphere says there is no theoretical limit, but it admits it has only tested up to 1,000 virtual routers on its current generation of ERX and MRX routers.

Juniper says it can handle more than 500,000 routes, and its largest installations currently run more than 1,000 virtual routers over all interface speeds without packet loss. Cisco was unavailable for comment.

(Juniper announced this morning that it is acquiring Unisphere: See Juniper Nabs Unisphere for $740M).

Laurel hasn’t officially announced a customer yet, but several sources say the company has deployed several boxes in Cable & Wireless PLC (NYSE: CWP). It’s not known whether C&W is testing the Layer 3 MPLS VPN capabilities.

Riverstone is also announcing more MPLS VPN capabilities for three of its routers -- the RS 38,000, RS 8,000, and RS 8,600. The company says it will be shipping a new line card that supports Layer 2 VPN support for packet-over-Sonet (POS) transport in June. It has already been shipping line cards that support Layer 2 MPLS VPN tunneling over Ethernet for several months. Like most other vendors in the market, Riverstone supports the “Martini” and “Kompella” IETF drafts for Layer 2 MPLS VPNs. These draft standards define ways for creating VPN tunnels using MPLS tagging over any transport protocol. Martini addresses encapsulation, while Kompella addresses MPLS signaling.

While the standards call for MPLS tunneling over any protocol, vendors still must map the encapsulated traffic to the transport medium like Ethernet, POS, or Asynchronous Transfer Mode (ATM). Most vendors have already agreed on ways to map traffic over Ethernet or POS; more work is being done on ATM and Frame Relay.

Vendors like Unisphere, Juniper, and even Riverstone implemented the Layer 2 VPN service over Ethernet first. Unisphere says it will offer Layer 2 MPLS VPN support over POS sometime later this year, but so far it hasn’t seen much customer demand for the technology. Ethernet switch vendor, Foundry Networks Inc. (Nasdaq: FDRY) began by supporting the POS interface, but will be adding Ethernet soon. Extreme Networks Inc. (Nasdaq: EXTR) claims that it can handle both. Cisco was again not available for comment.

For the equipment vendors, supporting multiple flavors of MPLS VPNs is important because it broadens their potential customer bases. Service providers all build their networks differently. As some incumbent players start using Ethernet to connect buildings together in metropolitan regions, it becomes important for equipment vendors to support Layer 2 MPLS VPN over Ethernet.

But in order to create an end-to-end Layer 2 VPN service using MPLS, service providers also need gear that will support Layer 2 MPLS VPNs over POS, because connections between metro regions generally use Sonet. POS support is especially important in cable networks, which tend to use IP over Sonet in their network cores. A POS solution is needed in order to map the MPLS traffic over those core backbones.

Riverstone has announced that Cox Communications Inc. (NYSE: COX) is currently testing its blade.

Whether it’s at Layer 2 or Layer 3, enterprise customers are asking for more IP-based MPLS VPNs to connect remote workers, branch offices, or mobile users together. And as demand grows, so are the offerings from equipment vendors.

— Marguerite Reardon, Senior Editor, Light Reading
http://www.lightreading.com For more information on Supercomm 2002, please visit: Supercomm Special
LightGaugeGuitarString 12/4/2012 | 10:22:07 PM
re: MPLS VPNs: The Talk of Supercomm There is a difference between the VRF (RFC 2547 VPN's segment of the RIB) and a Virtual Router. Cisco, Juniper, and others' implementation of VRFs share route processing tasks.

A true virtual router implementation should have completely separate route processing tasks. Some implementations do this on a common route processor, some dedicate route processors.

Why should people care? Because as soon as the service model extends beyond an Intranet application (including integrated Internet Access), a simple VRF implementation won't cut it.

LGGS
cbhushan 12/4/2012 | 10:22:04 PM
re: MPLS VPNs: The Talk of Supercomm i undestand the concepts of layer 2 and layer 3 MPLS VPNs, but as a user why shoud I use layer 2 vs layer 3 VPNs? Do I care?

Can some body explain this to me from a user point of view and from carrier point of view
metroman 12/4/2012 | 10:21:58 PM
re: MPLS VPNs: The Talk of Supercomm The main difference between these approaches is the way it might affect a user's current infrastructure. (There are actually 2 points of view here as the user could well be a carrier.)

As an "enterprise" user I would normally be looking for one of 2 things, either a services that offers what I have today (Frame, ATM L2 service) but with greater scalability and cheaper CPE or I will be looking for the Carrier to enhance my service by taking control of IP routing on my behalf. If as an enterprise you are happy to manage your routing or you have non-IP protocols to carry in your VPN then L2 VPNs are a good choice. BEWARE though that most L2 implementations today are Point-to-Point only and therefore lack L3 VPNs Multipoint capability. Drafts such as draft-lasserre-tls and the merged draft-lasserre-vkompella offer a path to multipoint L2 VPNs. So if you want an L2 service like your Frame Service but with more capacity and you have a carrier that implements multipoint capabilities then L2 VPNs are a good bet. Check true scaling limits though before your sign on the dotted line.

From a User POV if you are a Carrier you actually might see Point to Point L2 VPNs as quite an attractive proposition as all you want is a way of creating paths from A to B to carry your customer traffic. As it is protocol agnostic you can view the link as a fibre or lambda connection over which you can run your IGP/BGP peers and neighbours. Carriers might not like another carrier running their routing for them, making L2 VPNs attractive. Some Carriers will be attracted by L3 VPNs though as they want to have ultimate control of their routing through BGP peering policies into/out of the L3 VPN.


From the carriers POV operating L2 and L3 VPNs are quite different animals. L2 VPNs are simple to implement and require little or no changes to the IGP/BGP implementation, unless you have multiple areas and wish to run Traffic Engineering, but this is the same for both types of VPN. (Traffic Engineering between IGP areas is not something that any Router vendors offer as far as I know... I might be wrong.) With L3 VPNs the carrier will have to take into account that not all traffic is IP and therefore they may be cutting out a portion of the market if they go for IP VPNs only. (Remember today that 85% of WAN bandwidth is still Frame Relay based and therefore has the advantage of being L2 in nature.) There are also considerable issues with BGP design that need to be taken into account with L3 VPN network design. Once solved though these carriers will have multipoint topology capability and greater IP topology management capabilities to offer their customers.

My viewpoint would be that for the reasons above carriers should implement both in order to attract all of these types of customers. However some carriers will want to differentiate themselves by only offering one type.
Say_Yes_2_MPLS 12/4/2012 | 10:21:50 PM
re: MPLS VPNs: The Talk of Supercomm In addition to the differences correctly pointed out by metroman, there is another important difference that I would like to point out. Current L2 services (e.g. Frame Relay/ATM) are dictated by the technology, i.e. ATM services are offered over an ATM network. However, with L2 MPLS VPNs it is possible to offer a range of different L2 services over a single or mixed L2 infrastructure, e.g. it is possible to offer ATM services over an Ethernet network.

An example of how a carrier might use L2 MPLS VPNs is to migrate some of its ATM customers from its ATM network over to its IP/MPLS network. This would allow the carrier to maximise its investment in its IP/MPLS network and allow the customer to use the same CPE device.

A new Greenfield Operator could potentially roll out a cheap Ethernet network (cheap referring to CAPEX costs as compared to ATM equipment) and offer G«ˇATM likeG«÷ services in competition with an ILECs ATM services.

However, these service propositions are based on QoS claims made by vendors such as Cisco who advertise things like G«ˇATM likeG«÷ quality of service with reference to L2 MPLS VPNs running over Ethernet. These QoS guarantees (as far as I know) have not been independently verified and at the moment there arenG«÷t any real world large-scale L2 MPLS VPN deployments that I know of.

L2 MPLS VPNs sound excellent on paper but it is yet to be seen if they offer the SLA guarantees vendors claim (which many doubt they ever will).

If L2 MPLS VPNs did prove to have G«ˇadequateG«÷ QoS garauntees then they would be an excellent technology for a new Greenfield Operator to use. However, they could pose a problem for carriers - how would these new services be priced without impacting on current lucrative ATM/Frame service offerings?

A carrier could consider only using L2 MPLS VPNs to offer new services as not to lower the value of its existing (ATM/Frame) services. One such new service would be transparent LAN services (where the provider network acts like an Ethernet bridge) as described in drafts by Lasserre/V.Kompella and K.Kompella. However there are scalability issues with these drafts (which are currently being worked on in the IETF) and are there any customers out there that really want create large flat L2 networks?

I believe that L2 MPLS VPNs are an exciting proposition but there are still too many unknowns to draw any conclusions as to whether they will be successful or not.
beltway_light 12/4/2012 | 10:21:43 PM
re: MPLS VPNs: The Talk of Supercomm > There is a difference between the VRF (RFC 2547
> VPN's segment of the RIB) and a Virtual Router.
> Cisco, Juniper, and others' implementation of
> VRFs share route processing tasks.

agreed. cisco and juniper mpls/vpn VRFs don't
represent a "normal" virtual router concept.

> A true virtual router implementation should have
> completely separate route processing tasks. Some
> implementations do this on a common route
> processor, some dedicate route processors.

But there is no definition on "true" virtual
router either. Should each virtual router have
its own CPU? its own memory segment? its own
configuration database? wouldn't that become
a "physical router"? I understand some vendors
even go further to have each linecard as a
"virtual" router. Then how scalable will that
be? Will all the ISPs happy with max of 16
virtual routers in a physical box? I guess not.
by the name "virtual", it implies there will be
some resource sharing on the router. Good virtual
routers should scale to a reasonable number
while offer enough resource protection between
the virtual entities.

> Why should people care? Because as soon as the
> service model extends beyond an Intranet
> application (including integrated Internet
> Access), a simple VRF implementation won't cut it.

any example to show good service models?
CarrierClass 12/4/2012 | 10:21:36 PM
re: MPLS VPNs: The Talk of Supercomm G«£Like most other vendors in the market, Riverstone supports the G«£MartiniG«• and G«£KompellaG«• IETF drafts for Layer 2 MPLS VPNs. These draft standards define ways for creating VPN tunnels using MPLS tagging over any transport protocol. Martini addresses encapsulation, while Kompella addresses MPLS signaling.G«•
________________________________________________


This is article is incorrect as it does not give a full explanation.

Riverstone supports the Martini encapsulation draft G«ˇdraft-martini-l2circuit-encap-mpls-04.txtG«÷ and supports G«ˇdraft-lasserre-vkompella-ppvpn-tls-00.txtG«÷ which is co-authored by Vach Kompella and Marc Lasserre (who actually works for Riverstone).

Different vendors support different drafts. Juniper for example supports the drafts G«ˇdraft-kompella-ppvpn-l2vpn-01.txtG«÷ and G«ˇdraft-kompella-ppvpn-vpls-00.txtG«÷ authored by Kireeti kompella (who actually works for Juniper).

The Lasserre/V.Kompella draft uses LDP for signaling whereas the K.Kompella drafts recommend BGP. These are competing drafts in the Provider Provisioned Virtual Private Networks (ppvpn) group.

When people say that vendor X supports the Kompella draft, they are usually referring to the draft(s) by K.Kompella, not to the drafts by Lasserre/V.Kompella, which are generally referred to as the Lasserre drafts. It would have been more acceptable to write G«£Riverstone supports the G«£MartiniG«• and G«£LasserreG«• IETF drafts for Layer 2 MPLS VPNs.G«•

The Martini Encapsulation draft belongs to the Pseudo Wire Emulation Edge to Edge (pwe3) working group and is used in both the Lasserre/V.Kompella and K.Kompella drafts (with modifications). It does not define encapsulation methods for ANY transport protocol. It does however provide encapsulation methods for the following: Frame Relay, ATM AAL5 CPCS Mode, ATM Transparent Cell Mode, Ethernet, Ethernet VLAN, Cisco HDLC, PPP, and SONET/SDH Circuit Emulation Service (CEM).

As well as addressing signaling, K.Kompella authors a number of other drafts which address other aspects of L2 VPNs, such as G«ˇdraft-kompella-ppvpn-dtls-01.txtG«÷ which addresses Mac address learning scalability issues by suggesting a de-coupled PE model.

Keeping up to date with whatG«÷s happening in the IETF working groups is difficult due to the number of new drafts being submitted and changes to existing drafts being made on a regular basis. However, a fuller explanation should be given to ensure readers are not misled.

Thanks.
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE