MPLS Spurs Metro Ethernet Debate

Last week the Metro Ethernet Forum met in Boston to hash out a draft of technical specifications for deploying Ethernet in the metropolitan area network. The forum addressed areas that are key to making a more heavy-duty version of Ethernet for metropolitan networks: Ethernet Service Definition, Metro Ethernet Reference Model, Ethernet QoS framework, and Ethernet Protection (see MEF Touts Progress).

The issue of "protection" or network resiliency is fast becoming a major focus of debate.

What's surprised some analysts is the extent to which the proposal goes beyond simply aiming for traffic restoration within 50 milliseconds, the standard for legacy Sonet gear. Instead, the draft proposed by the MEF specifically states that MPLS (multiprotocol label switching) should be used to meet this goal. Analysts following the developments of metro Ethernet find this troublesome.

"I thought that their purpose was to define service levels so that carriers could create service-level agreements,” says Scott Clavenna, director of research at Light Reading and president of PointEast Research LLC. "I don’t think their role is to develop a method for doing protection. That’s the job of standards bodies like the IETF and the IEEE."

The meat of the controversy lies in the fact that for Ethernet to be accepted by service providers as a replacement for Sonet, it must provide the same quality and meet all the same standards as Sonet. This is especially critical if Ethernet ever hopes to replace Sonet for carrying voice traffic, for which 50 millisecond recovery times are a must. But this is easier said than done, because Ethernet was designed for local area networks, not large metropolitan networks.

Some service providers argue that MPLS is too complicated to be used for resiliency. They say that protection should be done at lower layers of the ISO stack to reduce complexity.

“I think that using MPLS for protection could be stretching its use,” says Eugene Pisman, a founder and the chief network architect at IntelliSpace, a metro service provider offering Ethernet data services. "It costs hard dollars to provision and buy the hardware to do MPLS. For example, from Riverstone or Extreme, you’d need to buy special blades Then sometimes they are implementing different versions of MPLS. You may get them to interoperate, but it will take work and will probably cost a lot to do.”

Clavenna and Pisman suggest other ways for handling resiliency. Resilent packet ring (RPR) technology is one way. The Resilient Packet Ring Alliance has been working with the IEEE 802.17 working group since last spring to come up with a standard for this technology (see RPR Divided). RPR, which has not been finalized yet, plans to develop a new MAC layer that will provide protection for all ring-based transport, including Ethernet.

Clavenna says that introducing a new signaling protocol like MPLS into the network could cause more problems than developing a new MAC to handle restoration.

But Nan Chen, chairman of the MEF and director of product marketing for Atrica Inc., an Ethernet equipment provider, argues that RPR would require service providers to buy new boxes, which he says will be expensive. He also says that disagreements within that standards body have made it difficult to predict the outcome of RPR (see RPR: RIP?).

"RPR is great for the future," says Chen. "When it’s complete we can take a look at it. Right now, no one is sure if it will be designed for voice traffic. Cisco’s version of DPT isn’t designed for that. Carriers want something they can implement now.”

Pisman agrees that RPR may be too expensive in some instances. He suggests using two technologies: RPR for the metro core, and rapid spanning tree for the access network. Rapid spanning tree is derived from the spanning tree protocol that has been used in local area networks for years. The new, enhanced protocol, which is currently going through the standards process in the IEEE, reduces recovery time to between one and five seconds, down from 30 seconds. While this is still not good enough for voice traffic, it is a huge improvement for service providers looking to provide real-time data services to customers.

Some Ethernet equipment companies are even improving the new rapid spanning tree protocol with one that they say can restore traffic even faster. Riverstone Networks has developed a technology it calls Rapid Ring Spanning Tree, which reduces recovery time to under 400 milliseconds (see Riverstone Rings Rapidly).

Riverstone announced today that France-based CompleTel Europe and South Korean-based Dacom are deploying Riverstone routers with rapid ring spanning tree turned on, to expand their metro Ethernet service offerings.

But the fact of the matter is that neither rapid spanning tree nor rapid ring spanning tree have gotten recovery times down to 50ms, the standard recovery time of Sonet-based voice networks.

“Right now there is nothing available that gives service providers 50ms restoration for Ethernet,” says Chen. “But using the MEF framework they will be able to.”

Still, other companies that are members of both the MEF and RPR Alliance say there is room for all of these technologies.

"MPLS wont solve every problem over night," says Gady Rosenfeld, director of strategic marketing for Corrigent Systems. “There are good things about it, and it is good to use for certain things like providing protection at higher layers, like between ring meshes. But RPR can be easier, cheaper, and simpler than MPLS for protection at lower layers. We plan to use both.” — Marguerite Reardon, Senior Editor, Light Reading
Page 1 / 3   >   >>
HarveyMudd 12/4/2012 | 7:25:30 PM
re: MPLS Spurs Metro Ethernet Debate MPLS is not likely to be deployed by the carriers here in the US or abroad. Some carriers may deploy it in certain parts of the for the purposes of traffic engineering and provoiding redundant routing.
linkv 12/4/2012 | 7:35:09 PM
re: MPLS Spurs Metro Ethernet Debate Gladys... good points, with one exception, "RPR
has a long way to to achieve even sub-second..."
I beg to differ; we've been shipping for almost
a year and consistently demonstrate 10-12ms
protection for TDM and packet data. That's live,
real customer traffic.


Luminous Networks, Inc.
rjmcmahon 12/4/2012 | 7:36:11 PM
re: MPLS Spurs Metro Ethernet Debate It's ironic that many in this industry don't get that "connection-less" is the 'thing' with internetworking - not ATM emulation (on routers or L3 switches).

For a large distributed information system, which talks packets, pcm samples, mpeg frames, scsi blocks, sometimes a connection is need and sometimes it is not.

Agreed 100% that the proprietary boundry is where the man made battles of differentiation will occur. In the case of the RRs, market forces caused the locomotives to be limited to their proprietors tracks while the box cars were standardized.

rriicc 12/4/2012 | 7:36:29 PM
re: MPLS Spurs Metro Ethernet Debate MPLS/VPN (2547b) across AS boundaries, across ISP networks; that's the scaling problem with MPLS as a VPN technology. The scalability is not about how many VRs or "mpls-routes" a PE can carry.
MPLS is in this sense the same thing as ATM and FR: it's connection-oriented.
MPLS is useful for TE within an AS - just like ATM. And TE is basically patching the lack of load and QoS sensitive routing protocols.
MPLS/VPN doesn't give any QoS for an individual VPN without diffserv (EXP..) and TE(MPLS). That is, if the LSPs aggregate multiple VPN traffic flows, PE-to-PE, which is the main proposal.
The security (P=private in VPN) is same as ATM (private pipe), who are happy with that when cryptographic security is available at fairly low cost? Running IPsec (tunnel mode) in MPLS/VPN is really silly - it's putting a VPN inside the MPLS/VPN.
It's ironic that many in this industry don't get that "connection-less" is the 'thing' with internetworking - not ATM emulation (on routers or L3 switches).
Gigaboy 12/4/2012 | 7:37:24 PM
re: MPLS Spurs Metro Ethernet Debate Great concept. Shall we start with multipoint TLS with in the metro or inter metro.
Man (no pun intended)like a bad girlfreind this protocol just grows on you.
drag 12/4/2012 | 7:37:34 PM
re: MPLS Spurs Metro Ethernet Debate MPLS will definitely have its place but primarily as a service enabler and L2 scalability enhancer (eg. L2 transport stuff)

MPLS VPNs do scale to realistic limits for 99% of VPN requirements. I mean, most edge devices will support around 200k+ routes total, that's more than enough for most apps. Again, apply some realism to the situation, how often would you really have the full table + 100000's of VPN routes on the same PE router? This whole scalability argument of MPLS VPN is quite sad... what's the best answer so far? Oh yes lets return to the wonderful world of L2 with all it's inherent *grin* scalability...

The complexity is not really related to MPLS directly it applies to QoS and TE in general and equally applies to IP, ATM etc. Whatever way you cut it these things are inherently more complex no matter what the protocol.


dark_light 12/4/2012 | 7:37:35 PM
re: MPLS Spurs Metro Ethernet Debate I do still see a place for mpls in the man and edge arena, especially for the VPN arena. While it may not scale well to huge porportions, it does allow for flexibility that other technologies do not, especially in areas of mixed topologies and multiple users on the same network. The biggest hurdle is it requiring new equipment, and you're right, why put a complex tunneling and qos system in when you can get your bandwith nirvana in the near future.
netskeptic 12/4/2012 | 7:37:38 PM
re: MPLS Spurs Metro Ethernet Debate to drag.

It will be real nice to keep separate networks for voice, it is quite possible that all attempts to have unified networks fail and this will be the only available choice. However, I suppose it will not happen in the next 5-10 years.

It will be nice to have no pipe throughput problems and hence no QoS - just 2 levels of diffserv and big buffers. Again, it is quite possible that this will be the end of it - data only network with abundance of both bandwidth, siwtching capacity and buffers. And again people now are serious about WRED - I suppose it is a clear indicator that there are years and years until bandwidth abundance nirvana.

And guess what - I do not see place for MPLS in the picture, which ever way the development will turn. If there are no bandwidth problems - simple
forwaridng will do it, if there are bandwidth problems MPLS is not equiped to help anyway.

BTW, I am observing the saga of IP/TAG/MPLS switching since 1995 and the persistence of the people who are trying to find a problem which could be solved by this technology does not stop to amaze me:

1. It was intended to solve forwarding problems at DS3, fast ether and OC-3. Hardware improvements in forwarding engines made it completely irrelevant.

2. It was supposed to solve VPN problems, it happen that MPLS based solution would not scale.

3. It was supposed to provide QoS and VoIP nirvana, it happen that DiffServ would the only available service with substantial problems on inter-carrier borders.

4. It was supposed to provide fast switching to
the redundant path, SONET already does it for years and years.

5. Now we are going to run ethernet on top of it - frankly I cannot think about more ridiculous idea - I suppose this signifies the logical end of the road for IP switching.


flanker 12/4/2012 | 7:37:38 PM
re: MPLS Spurs Metro Ethernet Debate The merits aside, the simple fact of the matter is that MPLS is up, running and being proven (or refined) every day. Cisco has already published off-the-shelf technical literature.

Where is RPR?
drag 12/4/2012 | 7:37:41 PM
re: MPLS Spurs Metro Ethernet Debate why not use both RPR/802.17/SRP/DPT/whatever + MPLS or Ethernet+MPLS depending on your situation?

MPLS is mostly a service driver these days in my opinion.

You're really trading off whatever 50ms means to you versus cost and complexity of MPLS-TE protection mechanisms. Either way, keep your Ethernet in the last mile to the customer to keep the CPE cost/complexity down. No need for STP on this single L2 hop. (also ask yourself how much fibre is really in rings between customer buildings?? Most is star wired back to the CO along the same route the copper is in or if the local utility was smart they wired it back to the local utility point). From a cost perspective RPR fit between POPs for the most part, unless heaven forbid we get a standard and economies of scale start kicking in...

On the topic of QoS, now even with someone having only 2 queues and someone else having 8 queues who cares at 10G speeds? Low latency is low latency everything else is everything else... we're not still having "time to clock a packet to the wire" or "how deep is the pass through buffer" arguments are we? How many of us would actually care to configure more than 2 QoS classes anyway when we have 10G speeds? Or even OC48 for that matter? Rememeber that one of the attractive features of Ethernet is that you get the large extra bandwidth for the same price or less, to remove complexity (like QoS) from your network. I would argue that 2 priorities are probably enough. Now someone will probably try and explain to me the difference between ATM CBR and VBR-rt or why we had to have a 6 bit field for the DSCP because 3 wasn't enough...

Face the fact that we will *never* shoehorn legacy TDM voice into packet based networks in the true spirit of if it aint broke don't fix it.

Many of the comparisons of Ethernet/RPR/MPLS and the highly abused layers of the OSI stack remind me of the same arguments between SONET/ATM/MPLS/IP - apples and oranges everwhere.

Wouldn't it be great if Cisco release SRP on Ethernet looking/priced interfaces instead of bungled into SONET!!! That would throw a few writers into a tailspin!!

I digress...


Page 1 / 3   >   >>
Sign In