Service Provider Networks / (none) /

MPLS to make Ethernet resilient in metro?

Forum endorses specs to use labels to enhance reliability of LAN technology.

By Terri Gimpelson
The Edge, 11/05/01

In an effort to make Ethernet "carrier-class" for metropolitan-area network deployment, the Metro Ethernet Forum is endorsing a technique that utilizes Multi-protocol Label Switching to enhance the resiliency and reliability of the LAN technology.

During meetings this week in Boston, the forum passed a motion to create specifications on use of MPLS labels to bring SONET-like restoration to Ethernet. MPLS, the forum says, can restore Ethernet in 50 msec or less in the event of a failure.

Forum officials are proposing two distinct ways of using MPLS with Ethernet to prevent delays in the event of a failure.

The first, called Aggregated Link and Node Protection (ALNP), addresses local network protection and makes use of MPLS Label Switched Paths (LSP). The second, called End-to-End Path Protection (EEPP), accommodates older network equipment that may not supports MPLS.

Nan Chen, president of the forum, explains that Ethernet, by its nature, uses idle frame transmission to detect failures at the physical layer in a network. This, Chen says, can be done in millisecond increments using ALNP.

ALNP suggests encapsulating payload data in an MPLS label. The MPLS "packet" is then put inside an Ethernet frame for transmission. Each network element can read the MPLS labels and determine packet sequence because the MPLS labels remain unchanged, Chen says.

The destination address of the Ethernet frame lets packets be forwarded to the next hop, while the MPLS labels direct traffic end-to-end. When a fault is detected, the ingress network element automatically reroutes traffic from the primary LSP to a predetermined detour LSP en route to the egress network element.

Each detour LSP can also be used as a primary LSP, Chen says. Bandwidth that would otherwise be reserved for bursting on the primary LSP would be used for detour traffic if there's a failure.

This way, no bandwidth is wasted, he says.

EEPP works much the same way ALNP does. It can be used to route traffic around a failed node or around one that doesn't support MPLS, which is its primary application.

In this case, the ingress network element sends out hello messages to determine which elements on the network do not support MPLS. The ingress network element sends traffic around the nonsupportive network element via the predetermined detour LSP tunnel and simultaneously sends the same traffic along a secondary LSP.

Depending on where the nonsupported node is in the network, sending the traffic along the secondary LSP may speed rerouting, Chen says. The egress network element can determine within 20 msec which traffic to take during the TCP session.

However, this approach may take up to 10 seconds to reroute traffic, depending on how often hello messages are sent out and how many nodes are on the network, Chen says.

He also warns that this method requires half of the network's bandwidth to be reserved for protection, much like SONET.

Chen says EEPP should be reserved as a last resort for protection.

"The forum understands that the mechanism is there for 50 msec of protection," Chen says. "We also know that there has to be a transition period. As people come to know their options, we think most will want to implement 50 msec recovery and there won't be the need for EEPP."

Chen says MPLS-based protection will work on all topologies - ring, mesh or point-to-point. Chen also says MPLS-based restoration can also be applied to voice and video traffic.

Once traffic is encapsulated into Ethernet frames, he says, it can then be prioritized.

The forum expects to release the first draft of its proposal at the next meeting, scheduled for January.

Despite the forum's enthusiasm for MPLS-based restoration, not all analysts are convinced that it is suited for voice and video traffic.

Michael Kennedy, co-founder and managing partner for Network Strategy Partners, says that this proposal, if approved, will certainly make Ethernet more viable in the metropolitan area, but doesn't have any near-term impact on voice services.

"There really isn't a business model out there that gets packetized voice down to where the regional Bell operating companies want to pay for it," he says. "Circuit-switched voice is just better."

Independent analyst Mary Petrosky agrees.

"I'm not sure about how this will affect voice," she says. "I don't know how they're going to shovel voice into Ethernet frames. For data, this is compelling. MPLS is definitely the way to bring robustness and reliability to Ethernet."

Fred McClimans, managing director of Fearless Ventures and a Network World columnist, says voice will eventually come.

"Sure this will help data, but there's still a clear benefit to voice traffic here too," he says.

"This is still in its infancy, and I'm sure there will be future innovations that will improve voice services through the metro, but the forum had to address the fundamentals first, and I think they've made a reasonable step for wider implementation," McClimans says.

"The next logical step is for vendors to address interoperability issues, " he says.