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 3 / 3
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.
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.
<<   <   Page 3 / 3
Sign In