MPLS: Keeping it Real

BOSTON – At the Next Generation Network (NGN) conference here this week, supporters of multiprotocol label switching (MPLS), a next-generation networking standard, gave an update on the status of the technology. The conclusion is that MPLS isn't dead, but it is in dire need of a focus.

Since 1997 MPLS has been heralded as the mother of all networking protocols, which would one day make true voice, video, and data convergence a reality. Over the past four years that idea has morphed into proposals calling for MPLS to do virtual private networking (VPN), intelligent optical switching, and 50-millisecond restoration in Ethernet networks. In short, is has become the answer for almost every problem facing the carrier networks.

Many in the industry are worried that this unfocused, catchall approach is simply a reinvention of ATM (see Poll: Is MPLS BS?).

"MPLS is made up of some of the best and worst aspects of our industry," said John McQuillan, co-chair of the NGN conference. “It goes to show that the urge for a do-it-all protocol is still there. But I think we have to resist that urge, since if you look at the history of developing such a protocol you see it hasn’t been successful.”

During a panel presentation and discussion on Thursday, Robert Newcomb, vice president of marketing for the MPLS Forum and former vice president of sales and marketing for Ennovate Networks, acknowledged that MPLS could not be all things to all networks, as he highlighted the current realities of MPLS successes.

“MPLS may not be able to solve every problem in the network,” said Newcomb. “But by this point it could probably solve world hunger." (Appreciative chuckles ensued.)

At a high level, MPLS was originally supposed to bring predictability and reliability to an IP network to differentiate classes of service so that carriers could provide service-level agreements (SLAs) and quality of service (QOS). It also aimed for the convergence of multiple and existing services over the same network. The ultimate promise was that it would also bring operational savings to carriers implementing it, by automating the way bandwidth connections are set up and torn down.

These lofty expectations took root in the development of three key areas: traffic engineering, VPN implementations, and QOS. The question posed at the conference was how well MPLS achieved those goals. The answer is a mixed one.

On the one hand, it has made significant progress in the development of traffic engineering, enabling carriers to automate more efficient provisioning of connections within their networks. Carriers using MPLS for such purposes include big carriers like UUNet and AT&T Corp. (NYSE: T). Several others like Cable and Wireless (NYSE: CWP), Qwest Communications International Corp. (NYSE: Q), and Verizon Communications Inc. (NYSE: VZ) have announced that they plan to deploy MPLS.

Carriers are also starting to use MPLS for VPNs, which allow corporations to set up secure links through public IP-based networks. While Newcomb, who worked for an IP VPN startup,n which has since gone out of business, admits that VPNs haven’t taken off with the gusto that had been anticipated, he says it's now one of the key areas of focus for the MPLS Forum. The number of customers using MPLS-VPNs is still small. Providers like Global One, which launched its VPN service in April 2000; Bell Canada, which started deployments in April 2001; and WorldCom Inc. (Nasdaq: WCOM), which started offering the service in May 2001 have only signed up a few hundred customers each for their services. This pales in comparison to the tens of thousands of Frame Relay customers.

“We haven’t seen as many VPN deployments as we thought we would,” said Newcomb. “I’m not saying that MPLS VPNs are non-existent, they just aren’t on a global scale of deployment yet.”

As for MPLS being used for quality of service, deployments also haven’t taken off yet. In fact, few if any carriers are using MPLS QOS to provide services to customers.

Like other developing technologies, MPLS has had some growing pains. The process of turning it into a standard has been slow. Currently, there are only 10 ratified RFCs from the Internet Engineering Task Force (IETF), the standards body working on the technology. And there are more than 200 proposals. This means that only five percent of the proposals submitted have gone through the standards process.

Because of the lack of standards, there is a lack of interoperability among different vendors’ gear. Companies like Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7), Cisco Systems Inc. (Nasdaq: CSCO), and Juniper Networks Inc. (Nasdaq: JNPR) have all demonstrated interoperability in research labs; but in reality, carriers deploying MPLS are sticking with single vendors.

The slowdown in capital spending has also slowed down development, because carriers are loath to invest in new technologies in the midst of a recession in their industry.

“I’ve heard more about Frame Relay this week than I have in the past three years,” said McQuillan during his wrapup session at the end of the conference. “It’s a good example of a connection-oriented network, and that seems to be what carriers want and need.”

And, of course, there are the political obstacles that dog every technology. Infighting within the IETF and among other groups like the Optical Internetworking Forum (OIF) and Metro Ethernet Forum, which also have vested interests in MPLS, has contributed to the lack of focus and slow pace of development.

And yet with each passing day, more and more companies dream up different uses for MPLS. The optical equipment companies want to see the development of Generalized MPLS (GMPLS), which will bring packet intelligence to wavelength switching. Metro Ethernet companies want to morph the Layer 3 protocol into a Layer 2 protocol so that they can use it for providing VPNs. They also hope to use MPLS as a way to provide 50 millisecond restoration, a requirement for any network hoping to replace a Sonet-based network. And voice-over-IP vendors push for voice over MPLS. While Newcomb and others involved in the MPLS Forum agree that there are many uses for MPLS, they urge companies to remain focused.

“I don’t mean to be overly critical of MPLS,” said McQuillan. “But I think they should just pick an application and just go with it.”

— Marguerite Reardon, Senior Editor, Light Reading
http://www.lightreading.com Want to know more? This very topic is the subject of a couple of sessions at Lightspeed Europe,Light Reading’s annual conference, on December 4-6, 2001, in London. Details: Signaling in Optical Networks and MPLS: Just Another Marketing Bandwagon?

<<   <   Page 5 / 5
netskeptic 12/4/2012 | 7:35:08 PM
re: MPLS: Keeping it Real > AT&T IP Frame Relay is based on ...

???? It all looks like a honest application of
circa 1996 IP switching idea - routers would never be as fast as ATM switches. Naturally, MPLS does make sense to introduce IP services into legacy ATM network.

However, the quesiton to answer is does MPLS make any sense in router network ? In my view it does not.



random-reading 12/4/2012 | 7:35:00 PM
re: MPLS: Keeping it Real
As with any restoration scheme, the following
steps must be taken:

1. A mechanism to detect failure in the first

2. An alternative path is setup

3. Traffic is switched to the alternative path

All 3 must be achieved within 50ms. To reduce
the restoration time, 2) can be reduced to 0 by
setting up an alternative path even before the
primary fails. 3) can be accomplished very
quickly. So 1) is the bottleneck.

For MPLS over SONET, the time restoration time
is the SONET failure detection time, which has
to do with OAM signalling. For MPLS over Ethernet,
the minimum time is Etherent failure detection,
which is still on the drawing board.

I am curious about the claimed 5ms restoration,
under what condition was it achieved. I suspect
that it is neither economical, nor scalable.

FiberFan 12/4/2012 | 7:34:48 PM
re: MPLS: Keeping it Real RR, You make some nice points.
I think the key issue that is lost in some of these discussions is the network architecture/design being used. Pure meshed designs in the MAN won't scale and will cause the delay in your issue #1 (failure detection mechanism). Many of the pure ethernet plays (or even POS) still require an overlay (on SONET or the like) and it could be hub and spoke (single point of failure) or a mesh (scaling and latency issues). My research has led me to believe the 802.17 standard has the best hope for low latency, low jitter, sub 50ms MAN designs. The ring(s) would then be connected to backbone routers which could have pre-determined, back-up LSPs defined for protected services (VPN, IP Video, etc.).
This seems like the most practical and perhaps more importantly, scalable solution for end to end IP services. ATM just doesn't have the right answers....

Your thoughts?
vnowoslawski 12/4/2012 | 7:34:45 PM
re: MPLS: Keeping it Real Do you think 802.17 will ever become a technology which has broad support of the telecom vendors. It seems to be driven by a single major vendor.
FiberFan 12/4/2012 | 7:34:20 PM
re: MPLS: Keeping it Real vnowoslawski-
I feel very strongly that 802.17 is gaining broad support from telecom vendors. All of them are looking for a cost competitive way to aggregate metro edge traffic. It must be both IP and TDM friendly (and efficient) but simple enough for easy and quick provisioning. The single major vendor you refer to is Cisco and their DPT (with spatial reuse) protocol. This is a very router centric approach in a market that carriers want to be very layer 2 like. I haven't spoken to a single RBOC that actually wants to add more routers to their networks. Too complex and way too expensive. Virtually every other member of the 802.17 has taken the opposite view of Cisco (Cisco's food chain of chip vendors aside). They are working more towards a "carrier friendy" (i.e. TDM and IP) standard. I think you'll see more carriers getting involved as we head toward the critical home stretch (between now and next fall). Everything up until now has been hype and posturing. It should get interesting.
Your thoughts?
vnowoslawski 12/4/2012 | 7:34:11 PM
re: MPLS: Keeping it Real I hope so. We do not need more hype.
Q: Is 802.17 looking at using multiple light paths in the ring? And how is QoS going to be handled by 802.17?
majid 12/4/2012 | 7:33:48 PM
re: MPLS: Keeping it Real > Looks like ATM and Frame Relay will be around
> for a long time. A couple of issues:
> 1. ATM provides true QOS.

True, but since applications are written for TCP/IP and since ATM was deliberately designed to be IP-hostile (I remember ATM's inventors speaking contemptuously of IP as a legacy protocol back in the 80s), ATM's QoS is only useable for PVCs, e.g. in a VPN environment. Frame Relay is actually better indicated in this application, except that high-speed frame relay interfaces are not commonly available.

Remember that one of MPLS' original briefs was precisely to allow ATM's QoS features to be accessed using IP signalling protocols, thereby bypassing ATM's braindead Q.2931/B-ICI/whatever that carry heaps of obsolete ISDN and telephony legacy. Mapping RSVP to ATM SVCs could solve the chicken and egg problem but is a non-starter given RSVP's lack of traction in the marketplace.

> 2. SONET and ATM were made for each other
> except for the cell tax...ATM Rules

Well, SONET was built for TDM voice and PDH leased line service only, ATM was added later. In an IP/ATM/SONET stack, there is one layer too many (I personally think it is SONET, because SONET VCs are so expensive to provision, and that it makes more sense to run ATM over dark fiber, at least until lambda routed networks can replace ATM PVCs).

> 3. Automatic Protection Switching is a key
> factor.

ATM PNNI can actually restore faster than SONET. PNNI can restore in 9ms vs. 50ms for SONET.

> 4. Frame Relay is widely deployed and works
> great and it's cheap...

And doesn't carry a cell tax...

> I've been hearing for the last 3 years about
> the all optical IP Network..it is a great
> concept..but it's needs a lot more work..

True, but ATM hasn't proven to be a scalable infrastructure for the public network either as OSS issues at the interfaces between providers like connection admission policy management, billing and so on are not addressed (then again, neither are they for MPLS so far).

Even in the one area where ATM has a compelling advantage over IP, carrying packet voice, ATM's proponents' arrogant assumption that PSTN switches and SS7 would adapt themselves to ATM instead of the other way round led to the paradoxal situation where VoIP standards are much more advanced that VoATM, even though it is the worst conceivable way to carry voice over a packet network.

Probably the brightest spot for ATM is that it is the ideal technology for places where there are stringent regulatory requirements for equal access, e.g. for unbundled Cable/DSL services, as is the case in Europe and would be in the US if the RBOCs didn't buy venal politicians' acquiescence to maintaining their monopoly. ATM thus moves from a core to an edge technology...
giles0 12/4/2012 | 7:33:38 PM
re: MPLS: Keeping it Real "For MPLS over SONET, the time restoration time is the SONET failure detection time, which has to do with OAM signalling. For MPLS over Ethernet,
the minimum time is Etherent failure detection,
which is still on the drawing board."

you'll find that both GigE and POS interfaces will generally respond virtually instantaneously to loss of light from the far end. It's not that hard to detect, after all!

Sure, there are other conditions (degradation of signal etc.) under which detection will take longer, and yes these are undefined as yet for Ethernet, but in my experience most link failures are caused by backhoes or disconnected fibre patches - either of which will result in loss of light.

"I am curious about the claimed 5ms restoration,
under what condition was it achieved. I suspect
that it is neither economical, nor scalable."

In the lab - pulling cables etc.

But I don't see what that has to do with whether this is economical or scalable?

FiberFan 12/4/2012 | 7:33:14 PM
re: MPLS: Keeping it Real vnowoslawski,
Sorry for my delayed response- had a lot on my plate. Anyhow,

802.17 isn't specifying multiple lambdas, that's more of a vendor's implementation. 802.17 is a MAC layer that should, if properly done, provide a layer 2 protocol that could run over any physical medium (SONET, etc.). It would add the necessary intelligence to support packet rings and hopefully, synchronization.
Although QOS has been discussed as part of the standard, I think it's going to be a vendor/customer choice as to what types of QOS (and COS) they want to provide.

Hope this helps.

Your thoughts?

<<   <   Page 5 / 5
Sign In