x
Optical/IP

Virtual Private LAN Service

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.

1 of 5
Next Page
CarrierClass 12/5/2012 | 12:10:45 AM
re: Virtual Private LAN Service I was astonished how many inaccuracies there are in this article actually reading the relevant drafts might have been a good starting point! Lightreading owe it to their readers not to give them false information. Here are just a few of the main inaccuracies, to start with, regarding the table of vendors at the end I have a few questions.

(1) What draft specifies the use of LDP as a discovery protocol? I certainly donG«÷t know of any! My guess is that Force 10, Foundry, Laurel, etc. support the Lasserre/V.Kompella draft which describes LDP for signaling so you just thought you would stick it in for discovery as well, even though the drafts doesnG«÷t specify a discovery mechanism.

(2) If Atrica donG«÷t support LDP signaling, how exactly do they support the Lasserre/V.Kompella draft which is based on LDP signaling

I also have several more comments:

LR: G«£VPLS uses Ethernet as the customer handoff, simplifying the LAN/WAN boundaryG«•.

How exactly does Ethernet simplify the LAN/WAN boundary? It certainly doesnG«÷t simplify things from the point of view of the service provider. Traditional WAN technologies like ATM use a device such as an NTE/NTU, which acts as the customer demarcation point. The SP can put a loop on the circuit and prove the circuit works up to the NTU/NTE. If the customer CPE is a switch how can the SP prove the circuit works (at Layer 2) up to the customers switch. There are some proprietary solutions to this but the Ethernet standards do not define any sort of customer demarcation point.

LR: G«£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.G«•

This is incorrect. To start with, to describe a draft as G«ˇDraft KompellaG«÷ is not sufficient as there are two KompellaG«÷s (as stated in earlier articles!) and several drafts. Anyway, the VPLS draft by V.Kompella et al. and the VPLS draft from K.Kompella both offer point-to-multipoint services, not point-to-point services.

LR: G«£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.G«•

This is totally inaccurate, over 20 people within the IETF have recently expressed support for JuniperG«÷s draft by K.Kompella, most of which work for network operators. Only half this number have expressed support for V.KompellaG«÷s draft, most of which are vendors.

LR: G«£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.G«•

Either this is a typo or itG«÷s a serious lack of basic knowledge regarding VPLS. Using routers as CE devices addresses the MAC address scalability issue, not as PE devices. If the CE is a router it only sends frames to the PE with a single source MAC address (its own) as opposed to a switch would send frames with multiple host based source MAC addresses.

LR: G«£VPLS is more easily managed than some of these other approaches,G«• says Ferit Yegenoglu, a director at the independent testing lab, Isocore.G«•

Who is this guy? VPLS is more easily managed than what other approaches? At least you asked someone who has some idea what heG«÷s talking aboutG«™ G«£He (Luca Martini) says one of the biggest issues with VPLS is management G«Ű the multipoint configuration makes it difficult to debug problems.G«•

LR: G«£The Lasserre-V. Kompella draft supports the use of LDP for signaling, but it doesnG«÷t explicitly address pseudowire signaling. The Kompella draft suggests using BGP for signaling as well as discovery.G«•

If LDP isnG«÷t use for pseudowire signaling then what is used to signal? I believe this is probably another typo, it should probably read G«£The Lasserre-V. Kompella draft supports the use of LDP for signaling, but it doesnG«÷t explicitly address discoveryG«•.

LR: G«£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.G«•

Yes this is correct, however, there are more than just vendors in this industry. What about the network operators who will be the ones buying the kit from the vendors? Out of the 20 or so operators that have expressed support for the drafts, only two have expressed any support for the Lasserre/V.Kompella draft, the rest support the K.Kompella draft.
duwenhua 12/5/2012 | 12:09:33 AM
re: Virtual Private LAN Service LR: Lasserre-V. Kompella advocates using MPLS, while Kompella suggests using multiple VLAN tags or Q-in-Q.
Not true. Both Q-in-Q and spoke LSP can be used in Lasserre-V. Kompella draft.
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE