x
Optical/IP

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?

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?

FiberFan
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?

Giles
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...
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?
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?
FiberFan
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: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?
FiberFan
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
place

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.

RR
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.

Thanks,

Netskeptic




kbkirchn 12/4/2012 | 7:35:09 PM
re: MPLS: Keeping it Real AT&T IP Frame Relay is based on MPLS & Cisco ATM Switches. (Router added for the MPLS functionality, ATM switch provides the transport).

Service Description
http://www.ipservices.att.com/...

Reliability (5 9s)
http://www.att.com/press/item/...

Adding QoS
http://www.nwfusion.com/news/2...
giles0 12/4/2012 | 7:35:13 PM
re: MPLS: Keeping it Real "Anyone knows if the OSPF weights approach have made their way in a real network so far?"

Not that I'm aware of (or at least not in the way the authors proposed - people have been frigging with IGP metrics for years!)

The problem with any metric based approach is how do you handle link failures? Failure conditions are precisely the point at which you need traffic engineering (if indeed you need it at all.)

From what I remember of the paper, and of the debate that followed it on one of the mailing lists (was either [email protected] or [email protected]) the authors didn't address this point. You'd need to write a protocol to distribute IGP metrics around the IGP. That could get very messy...

Giles
giles0 12/4/2012 | 7:35:13 PM
re: MPLS: Keeping it Real "trying to do 50ms restoration using MPLS is a piece of pure BS. good luck to MEF or who ever is proposing it."

why do you think this to be the case?

In the lab I have seen sub 5ms restoration, so even in the infamous real world 50ms should be possible...

The real questions are:

1. How well will it scale? and
2. Do we really need it anyway?

Giles
flanker 12/4/2012 | 7:35:14 PM
re: MPLS: Keeping it Real Here's the scientific poll that provies that MPLS will replace ALL layer two transport protocols within 12 months.

Bow down and worship MPLS!

http://img.cmpnet.com/networkm...
flanker 12/4/2012 | 7:35:15 PM
re: MPLS: Keeping it Real Here'e the scientific poll that provies that MPLS will replace ALL layer two transport protocols within 12 months.

Bow down and worship MPLS!

http://img.cmpnet.com/networkm...
abarbier 12/4/2012 | 7:35:20 PM
re: MPLS: Keeping it Real BT, FT, Telecom Italia, Equant (the one I know directly, but the list is longer and growing).
Services are VPN and EoMPLS. TE on the radar not as a service, but as a tool along with diff-serv MPLS to enforce QoS. Work in progress. Goal: partial (?) replacing of the legacy ATM/FR infrastructure.

On the RRR side in the US Global Crossing has ~7000 TE tunnels.

ab/
ARBoy 12/4/2012 | 7:35:20 PM
re: MPLS: Keeping it Real Name the carrier (PTT) and application necessary for MPLS? What revenue generating services are going to be moved from existing architecture to MPLS. Don't say new services because we've already been down that road.
abarbier 12/4/2012 | 7:35:21 PM
re: MPLS: Keeping it Real "To me MPLS is dead - if the technology invented in 1997 doesn't get deployed by 2001 - there is something seriously wrong about this technology.
John"

_All_ the major PTT in EU are deploying MPLS.

ab/
moneyman 12/4/2012 | 7:35:22 PM
re: MPLS: Keeping it Real > I'd love to see a non-hype "discussion of MPLS
> performance" that does show MPLS vs. standard
> IGP/EGP routing protocols.

->Now MPLS is also a routing protocol, the thing
->just could not stop to grow beyond any
->reasonable proportion.

Not a full routing protocol - the very reasonable
CSPF extensions that have been designed advance
the "state of the art" path computation beyond
an overloaded "weight" metric.
netskeptic 12/4/2012 | 7:35:22 PM
re: MPLS: Keeping it Real > I'd love to see a non-hype "discussion of MPLS
> performance" that does show MPLS vs. standard
> IGP/EGP routing protocols.

Now MPLS is also a routing protocol, the thing just could not stop to grow beyond any reasonable proportion.


Thanks,

Netskeptic
John Casper 12/4/2012 | 7:35:23 PM
re: MPLS: Keeping it Real Skeptic wrote "
there are operational
circumstances sometimes at providers (such as
the legacy structure of the network) that
create problems where MPLS is an easy solution"

1. First, this myth about MPLS being an easy solution.

MPLS is not an easy solution either to implement or to support or to operate. There is lot of new complexity being added to software and operational layers within the networks. Ask the teams that are writing huge amount of code to make the features work - answer is MPLS protocols are too convoluted and complex. As I don't operate MPLS network so I would leave the support aspect for others.

2. Now to the second myth that the traffic engineering is what every carrier must have and only nothing but optimum solution provided by MPLS is needed.

If you design your network properly and optimize your routing correctly, you would have a fairly nicely balanced network. Given that most networks are built with certain extra capacity, and with knoweledge (or at least the projections for the traffic profiles), optimising the link bandwidth usage to the last byte is often not necessary.

The point I am trying to make is that the near optimum solution is all that you need for a well designed network. Only poorly designed networks will need most optimum solution because here one is trying to mask the bad network design with the patchwork provided by MPLS. In that case, I believe rightly or wrongly, that carriers will be better of spending their dollars on upgrading infrastructure than spending that money on MPLS in search of optimum traffic engineering solution. You can only squeeze so much out of a dry lemon.

For those MPLS warriers, I am not against MPLS per say but I object to totally misguided hype that some folks trying to build around MPLS, and MPLS based solutions (after all there are close to 200 drafts. BTW, I have read quite numbers of them and don't know any who has read all of them!). MPLS traffic engineering may be a useful tool in limited circumstances, but general use of MPLS for just about every thing is misdirected, and carriers that will go blidly without looking for alternative solution will repent their investment a big time.

To me MPLS is dead - if the technology invented in 1997 doesn't get deployed by 2001 - there is something seriously wrong about this technology.

John



moneyman 12/4/2012 | 7:35:23 PM
re: MPLS: Keeping it Real I'd love to see a non-hype "discussion of MPLS
performance" that does show MPLS vs. standard IGP/EGP routing protocols.

russ4br post highlighted some of the authors' (honest) concerns - I'd encourage people to read
the somplete article to look for their more positive conclusions as well.


How have other carriers made the decision to adopt/reject MPLS, beyond buying into marketing hype? Any other numbers-based simulations that you've run across?
russ4br 12/4/2012 | 7:35:24 PM
re: MPLS: Keeping it Real Moneyman,

Wrt to AT&T Research Paper:

This is interesting - below some (biased) snapshots from the text:

"Can a suficiently clever weight settings make OSPF routing perform nearly as well as optimal general/MPLS routing?" Our first answer is negative. [I.C]
A good starting point!

"Our proof is based on a construction where OSPF leads to very bad congestion for any natural definition of congestion" (!!!) [IV]
In most networks - and the proposed AT&T Worlnet network being no exception - IGPs (OSPF, IS-IS) produce SPF-induced congestion (skeptic?).

"A drawback of this approach is that an arc that does not belong to one of the shortest paths from x to t may already be congested, and the modifications of weights we propose will send more flow on this congested arc, an obviously undesirable feature" (!!!) [V.B]
The authors had to adapt their original algorithm in order to reach a reasonable result.

"(...) our results indicate that in the context of known demands, a clever weight setting algorithm for OSPF routing is a powerful tool for increasing a network's ability to honor increasing demands, and that OSPF with clever weight setting can provide large parts of the potential gains of traffic engineering for supporting demands, even when compared with the possibilities of the much more flexible MPLS schemes." [VII]
The authors themselves concede that MPLS is much more flexible when it comes to traffic engineering.

Wrt to cleverness, there are a number of similar methods for MPLS:
- optimize LSP path: recalculate the best MPLS path for RSVP-TE every x seconds/minutes;
- optimize LSP bw: based on a measured avg - adjust RSVP-TE bw reservations

Anyone knows if the "OSPF weights" approach have made their way in a real network so far?


- russ


flanker 12/4/2012 | 7:35:24 PM
re: MPLS: Keeping it Real I dont even see a discussionof MPLS performance in the papaer. It seems to consider various flavors of OSPF and concludes that certain (better) flavors perform comparably to MPLS for the given metrics.
skeptic 12/4/2012 | 7:35:25 PM
re: MPLS: Keeping it Real
The ATT work cited is correct for their
particular set of circumstances and the design
of the ATT network. But be careful about
drawing broader conclusions just based on
that single network example.

I agree that OSPF itself isn't necessary always
the problem, but there are operational
circumstances sometimes at providers (such as
the legacy structure of the network) that
create problems where MPLS is an easy solution
to congestion caused by OSPF.
flanker 12/4/2012 | 7:35:26 PM
re: MPLS: Keeping it Real Moneyman:

I have my doubts as to the import of that paper. It is not at all evident that experiment was designed to exploit MPLS strengths, and the scope of the experiment, especially in consideration of the fact that it is being benchmarked against OSPF (why not an EGP?) is quite narrow.
flanker 12/4/2012 | 7:35:26 PM
re: MPLS: Keeping it Real Well, I guess those tier three (CWP, FON, WCOM) carriers were exaggerating the importance of MPLS in the network mag poll.

http://img.cmpnet.com/networkm...
moneyman 12/4/2012 | 7:35:27 PM
re: MPLS: Keeping it Real In reply to the point that MPLS is better for rerouting around bottlenecks, conside the following study from AT&T Research:

http://citeseer.nj.nec.com/cac...


"Our starting point was a proposed AT&T WorldNet backbone with demands
projected from previous measurements. The desire was to optimize
the weight setting based on the projected demands. We showed that optimizing
the weight settings for a given set of demands is NP-hard, so we resorted
to a local search heuristic. Surprisingly it turned out that for the proposed
AT&TWorldNet backbone, we found weight settings that performed
within a few percent from that of the optimal general routing where the flow
for each demand is optimally distributed over all paths between source and
destination. This contrasts the common belief that OSPF routing leads to
congestion and it shows that for the network and demand matrix studied
we cannot get a substantially better load balancing by switching to the proposed
more flexible Multi-protocol Label Switching (MPLS) technologies.


Gotta challenge those myths, on both sides of the debate!
skeptic 12/4/2012 | 7:35:32 PM
re: MPLS: Keeping it Real Other than hype, there is NOTHING that MPLS does what can't be done better using other existing technologies.
===================

There is one thing. Using MPLS tunnels to
divert traffic around SPF-induced congestion.
It can be done using existing technologies, but
those methods are far worse than MPLS.


netskeptic 12/4/2012 | 7:35:32 PM
re: MPLS: Keeping it Real
> The minute you oversubscribe a stat-mux service
> you've thrown 'true QoS' out the door.

Please, forgive me my ignorance, but the last time I checked CBR was the only class with meaningful QoS supported by ATM and again, last time I checked there were no way to oversubscribe CBR circuits.

Do you complain that ABR and VBR in real life are not supported by ATM, or it is something else ?

Thanks,

Netskeptic


John Casper 12/4/2012 | 7:35:35 PM
re: MPLS: Keeping it Real Other than hype, there is NOTHING that MPLS does what can't be done better using other existing technologies.

The basic idea was good in 1997. But by 2001, it has got attached too many bad ideas. BGP/MPLS VPNs being one of the worst peice of crap being promoted by the vested interests to keep a dead technology alive.

Why would one spend billions of dollars in making a network MPLS capable when one can offer VPNs using other technologies. The whole IETF MPLS session has been hijacked by too many commercial interests unlike the past where mostly people with serious researh interests were involved in the standards process. Most of the drafts in MPLS groups are pieces of junk.

And of course, I wouldn't comment on the noises by commercial mouthpieces of big two in the IP industry to MPLS technology. If they had there way, MPLS is the best technology to signal toasters in American homes, shoe polish machines in airports, and making corn grow in the field!.

It is time industry junk this overhyped, meaningless technology that achieves little at the tremondous extra cost and complexity.

John
gladysnight 12/4/2012 | 7:35:38 PM
re: MPLS: Keeping it Real peter,

i've observed several times here that the "problem" of mapping a packet service over a circuit remains, no matter what you do.

In the 80's we did X.25 over nx64 E1/T1 circuits, in the 90's we did frame over unframed E1/T1 (G.703) and then ATM over 622M and 2.5G, now we're gonna do IP and/or ethernet over a 10G lambda (apparently) and then 40G, too. . . . .

Either way, a lambda switch is a circuit switch, and a wavelength is a circuit. Talk of intelligently "routing" optical packets remains science fiction, to the best of my knowledge.

The "problem" is economic, for sure: you have to stuff the circuit as efficiently as possible so as to remain price competitive in your target market, but you have to not stuff it so much that you, well, stuff it, iyswim.

I don't know what the killer lambda stuffing solution of the noughties will be, but get back to me in 10 years or so and we can discuss it.

I do, like you, doubt that it will be MPLS, except perhaps in the way that 4,000 km's unregenerated 10G Ethernet on single-mode fibre is the same thickwire, non-switched, truly shared-medium copper-based ethernet I used to screw taps into many years ago . . . .

hola!
fiber_r_us 12/4/2012 | 7:35:38 PM
re: MPLS: Keeping it Real Peter:

There is no such thing as "true QoS". QoS is in the "eye of the beholder". QoS means many different things to many different people. It at least includes:

a) Specifying jitter (the variation of delays between successive packets)

b) Specifying latency (the delay from one end of the network to the other)

c) Specifying bandwidth

d) Specifying service availability

When carriers and customers say they "want QoS", the implication is that they want control over these QoS parameters. QoS does NOT mean setting the QOS parameters to some pre-determined fixed values (ala TDM).

If the customer wishes for TDM-type QOS then they should get that and pay the expense that is required to support such a service.

If, on the other hand, the customer has no need for such stringent QOS values (which describes the vast majority of data traffic), then the customer should be able to choose a different set of QOS parameters that meets thier requirements. In such a case, said service should be able to be provided via cheaper infrastructure and at a resulting cheaper price to the customer.

The idea that TDM is the only way to achieve QoS illustrates a mis-understanding of the industry problem at hand: the ability to offer many levels of QoS. TDM provides only one flavor of QOS with rigid values for the parameters and very coarse pre-determined values for bandwidth.

So, there is indeed such a thing as QoS on ATM, Frame Relay, IP, and MPLS networks. This QoS is not the same as TDM; but this is not a bad thing, just different.

Indeed, as you say, "economics rule". This is the whole idea behind being able to adjust the QoS values and offer different QoS levels at different QoS prices.
edgecore 12/4/2012 | 7:35:38 PM
re: MPLS: Keeping it Real !raelc dna duoL

pschurr 12/4/2012 | 7:35:39 PM
re: MPLS: Keeping it Real Am I the only person who knows there is no such thing as QoS in ATM (and IP)? The only true QoS (or Cos) is a dedicated timeslot on a TDM system. Everything else is a fudge. For example, ATM is a stat-mux system that tries to act like a TDM by 'strict' resource allocation. It's not ATM providing the service, it's just the way you allocate resources.

I can (and do) oversubscribe ATM/FR trunks regularly, based on known customer usage and total resource availability. The minute you oversubscribe a stat-mux service you've thrown 'true QoS' out the door. Now you're running with the animals - and you WILL get bitten. Economics rule, not technology.

peter
flanker 12/4/2012 | 7:35:41 PM
re: MPLS: Keeping it Real
'Poll'? Who said anything about a 'poll'? Certainly not me or networkmagazinedotcom.
edgecore 12/4/2012 | 7:35:46 PM
re: MPLS: Keeping it Real Flanker,

Do you have the URL for that poll, I would like to get a copy of it?

Thanks,

EC
ARBoy 12/4/2012 | 7:35:46 PM
re: MPLS: Keeping it Real "That said, WCOM is very happy with IP over MPLS/ATM and frame over MPLS. CW says IP over ATM wastes too much bandwidth (with ATMs overhead) for an int'l network."

I'd hardly base the future of any technology on what either WCOM or CW thinks. They're at the bottom of the gene pool when it comes to SPs. Whether you like it or not, the RBOCs are the present and future leaders.
flanker 12/4/2012 | 7:35:47 PM
re: MPLS: Keeping it Real ...I wish people (especially providers) would stop
using MPLS as a generic term. It would be better
to say MPLS-TE, MPLS-VPNs or
MPLS-fast-restoration...

Granted it is not a true protocol. MPLS biggest problem is the lack of interoperability and the tendency of carriers/vendors to custom configure MPLS for a proprietary network.

That said, WCOM is very happy with IP over MPLS/ATM and frame over MPLS. CW says IP over ATM wastes too much bandwidth (with ATMs overhead) for an int'l network.

skeptic 12/4/2012 | 7:35:51 PM
re: MPLS: Keeping it Real I read a poll elsewhere where ATT, WCOM and CW were asked to prioritize key technologies for them going forward. These are the results:


1) MPLS (ahem)
----------------

Ok, but just saying MPLS doesn't really explain
much of what they want. All of these people can
be saying MPLS but meaning very different things.

I wish people (especially providers) would stop
using MPLS as a generic term. It would be better
to say MPLS-TE, MPLS-VPNs or
MPLS-fast-restoration.

netskeptic 12/4/2012 | 7:35:52 PM
re: MPLS: Keeping it Real Same reply to the two different posts:

> Operators are looking to provide a single
> control protocol over these networks, MPLS is
> the only viable option today.

> I read a poll elsewhere where ATT, WCOM and CW
> were asked to prioritize key technologies for
> hem going forward. These are the results:
> 1) MPLS (ahem)


I suppose that carriers are looking for unified L2 technology which would allow them to put QoS and VPN services under IP and VOP and be way cheaper than ATM. Sure if MPLS works as advertised it will fit right in, however, this is a BIG if.

Over course of last 10 years I gradually came to the conclusion that there is no extraterrestial life and that technology which looks like BS on paper (e.g. SNMPv2, ABR and VBR over ATM, RSVP, VOIP, COPS, on-line storage, most of the .com, Metro Ethernet) would not deliver in the real world too.

At the same time it takes years and years to burn through say $100mil of VC/Stock Market money and even $1mil spent on PR would generate a pretty noticeable hype level. So, there is no surprise that public (including network operators') vision is so badly blurred.

In my reading MPLS is firmly set in the same BS category, however, jury is still out.

Thanks,

Netskeptic

lightcreeping 12/4/2012 | 7:35:56 PM
re: MPLS: Keeping it Real wow.

This IS news. Congratulations on extolling the vitures of ATM. I'm sure it will roar back and Newbridge will reivent itself!

YT.
metroman 12/4/2012 | 7:35:57 PM
re: MPLS: Keeping it Real Of course a technology is going to look bad if you compare it against the wrong thing.

ATM and Frame networks are Layer 2 point to point services whereas MPLS IPVPNs are Layer 3 Multipoint services. There is no doubt that MPLS IPVPNs will never win this market, because it is not their market.

If you want to have a constructive discussion about the various benefits of Layer 2 services in MPLS then discuss draft-martini. Then you might have an interesting conversation.

The issue is how many customers can I get on to an edge device. Frame and ATM services consistently deliver great scalability, whereas we are only now seeing systems that can deliver Layer 2 MPLS services with any kind of scalability.

Another problem that the market faces is that we are seeing alot of consolidation. This results in disperate network technologies being used to create an end to end service. Operators are looking to provide a single control protocol over these networks, MPLS is the only viable option today.

metroman

flanker 12/4/2012 | 7:35:57 PM
re: MPLS: Keeping it Real I read a poll elsewhere where ATT, WCOM and CW were asked to prioritize key technologies for them going forward. These are the results:


1) MPLS (ahem)
2) massively scalable routers
3) fault tolerant routers
4) SIP
5) short range optics
6) long range optics
7) OC 768

The prize for a technology most likely to sink a company was "all optical switching".


flanker 12/4/2012 | 7:35:57 PM
re: MPLS: Keeping it Real I read a poll elsewhere where ATT, WCOM and CW were asked to prioritize key technologies for them going forward. These are the results:


1) MPLS (ahem)
2) massively scalable routers
3) fault tolerant routers
4) SIP
5) short range optics
6) long range optics
7) OC 768

The prize for a technology most likely to sink a company was "all optical switching".


green 12/4/2012 | 7:35:59 PM
re: MPLS: Keeping it Real trying to do 50ms restoration using MPLS is a piece of pure BS. good luck to MEF or who ever is proposing it.
ARBoy 12/4/2012 | 7:36:00 PM
re: MPLS: Keeping it Real "Looks like ATM and Frame Relay will be around for a long time"

Good post yomama. Who would have believed your statement a year or two ago when it was IP everything? So many of the edge IP vendors gone or going; terabit core routers on the downward spiral; Internet not growing as it was although there are those self-serving vendors who'd have you think otherwise; IP VPN hardly moving. ATM is here and looks to be staying for a while.
yomama 12/4/2012 | 7:36:00 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..
2. SONET and ATM were made for each other except for the cell tax...ATM Rules
3. Automatic Protection Switching is a key factor.
4. Frame Relay is widely deployed and works great and it's cheap...

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..

just my 2Cents..
back2basics 12/4/2012 | 7:36:01 PM
re: MPLS: Keeping it Real Light reading,your piece is incorrect about Newcomb. He is a "former VP of Marketing & Sales of now defunct Ennovate Networks"

I also wonder how the MPLS Forum can continue to have an officer and spokesperson in Newcomb when he is unemployed and may have bad karma for the MPLS Forum.

Hopefully the MPLS Forum doesn't fall prey to Ennovate's fate.

Anyways, MPLS does have some good attributes,but has been too hyped up.

So let's just create a new acronym for MPLS: (MPLS-Many People with Little Success)



netskeptic 12/4/2012 | 7:36:03 PM
re: MPLS: Keeping it Real Ennovate's exec vouching for MPLS health - I could not resist the cuteness of the thing.

Thanks,

Netskeptic
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE