MPLS Fast Reroute Gains Momentum

Riverstone Networks Inc. (Nasdaq: RSTN) is the latest in a growing list of routing companies to support Fast Reroute as part of its Multiprotocol Label Switching (MPLS) virtual private networking (VPN) offering, helping edge the technology closer to becoming the de facto industry standard for using MPLS to provide resiliency in telecom networks (see Riverstone Adds Resiliency to MPLS).

Riverstone is joining big names like Cisco Systems Inc. (Nasdaq: CSCO), Juniper Networks Inc. (Nasdaq: JNPR), and Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7) that have also announced support. Cisco and Avici even demonstrated interoperability last month at Isocore, which runs an independent internetworking lab in McLean, Va.

Even though all these vendors are already shipping products with the technology baked into their systems, it has not been officially standardized. This is not surprising, considering that some implementations of MPLS such as RFC 2547, the draft that defines Layer 3 MPLS VPNs, has not been standardized yet either. Riverstone’s announcement, along with the support of the other major routing vendors, shows that the technology is clearly becoming the industry standard for MPLS resiliency with or without the blessing of the Internet Engineering Task Force (IETF).

“Fast Reroute definitely has the most traction in the vendor community and interest from service providers,” says Mark Bieberich, senior analyst at Yankee Group. “Fast Reroute brings service providers closer to the point where they can provide reliability over IP with the same attributes as TDM services like voice."

But Fast Reroute isn’t the only solution being considered by the IETF when it comes to MPLS resiliency, says Bijan Jabbari of Isocore. Protection switching is another proposal on the table. Unlike MPLS Fast Reroute, which detects an outage and simply routes traffic around it within 50 milliseconds, protection switching also identifies the outage and then signals the nodes so that packets are sent along a different path. Protection switching could potentially offer better network scaleability for resiliency.

“The difference is that fast reroute is a local protection, whereas protection switching takes the nodes into consideration,” says Jabbari.

Whether it's protection switching, fast reroute or a combination of both, adding some sort of resiliency to MPLS is important because it is one of the many reasons incumbent carriers have not deployed MPLS in a big way yet. They are afraid of losing the benefits of Sonet protection, which restores connectivity within 50 milliseconds. The problem with MPLS is that basic IP mechanisms can take several seconds to discover an outage, find an alternative path, and begin rerouting traffic. Fast Reroute supposedly can restore a link within 50 to 60 milliseconds.

But Fast Reroute is not without its problems. Some experts argue that for a large network, it’s difficult to scale and deploy a network based on it. Why? Fast Reroute requires alternate paths to be predefined so that when an outage occurs, traffic can switch over to another MPLS path. Last week, Cisco announced a tool that would automatically calculate these paths (see MPLS Fast Reroute Gets a Boost).

Fast Reroute will likely be a hot topic of discussion at this year’s MPLS 2002 conference in Washington, D.C., October 27 to 29th.

— Marguerite Reardon, Senior Editor, Light Reading
www.lightreading.com Movers and shakers from more than 100 companies – including Riverstone Networks – will be speaking at Lightspeed Europe. Check it out at Lightspeed Europe 02.

Page 1 / 7   >   >>
skeptic 12/4/2012 | 9:32:22 PM
re: MPLS Fast Reroute Gains Momentum But Fast Reroute is not without its problems. Some experts argue that for a large network, itGÇÖs difficult to scale and deploy a network based on Fast Reroute. Why? Fast Reroute requires alternate paths to be predefined so that when an outage occurs, traffic can switch over to another MPLS path

This isn't necessarly true. The standard has
two forms of fast rereoute. And one of them
doesn't require predefined alternate paths.

The IETF has "one" standards document for
fast reroute, but still has two different
approaches within the document.
Consultant 12/4/2012 | 9:32:17 PM
re: MPLS Fast Reroute Gains Momentum Skeptic,

Does it really 50 millisecond restoration and will it work in large networks. Moreover, how does it work?
green 12/4/2012 | 9:32:14 PM
re: MPLS Fast Reroute Gains Momentum I read a riverstone's white paper a few months ago about their 50ms recovery and I am very skeptical. they were talking about reducing the timers in the protocols to sub milli seconds to recognize fault. unless they have changed their implementation I am very skeptical that this will scale well.
metroman 12/4/2012 | 9:32:11 PM
re: MPLS Fast Reroute Gains Momentum A profitable approach is (to build on Tony Li comments) to have a mixture of MPLS failover mechanisms, in order to have the appropriate failover pattern for all types of traffic.

MPLS offers hot or cold standby LSPs but can also reconverge with the IGP.

Hot standby LSPs differ from Fast Re-route in that they are protection paths that are pre-signalled end to end to protect a path. Fast Re-Route pre signals detours around each link and node in the path. Failover times can vary though as the end of the path needs to recognise that a failure has occured in order to switch paths.

Cold Standby LSPs paths that are only signalled when the primary path fail. This uses less router resources but increases the failover time again.

It is possible to use the IGP to choose a new Shortest Path for non-engineered LSPs, but you need to wait for the IGP to reconverge and for the MPLS signalling of the path to take place.

Different topologies also lend themselves to different protection methods. For example Fast Re-Route is almost redundant in a ring topology as there is only one possible alternate path for each link or node. Hot Standby LSPs are better in rings.

Tony Li 12/4/2012 | 9:32:11 PM
re: MPLS Fast Reroute Gains Momentum
Yes, it really can do 50msec restoration.

It works by computing lots of alternative paths. Basically, every node in the path needs to compute an alternative path that would reach the
destination if the next link or the next router
is down.

Typically, this path will merge back into the original path after taking a short 'detour'. Each
of these detours is established BEFORE the failure
occurs, so that all that has to happen is that the
router moves traffic from the primary to the detour. The win here is that the router is only
making local changes. That is, it's only modifying
some of its own forwarding state and it doesn't
have to talk to remote systems to redirect the
traffic. Remote signalling requires large delays
even just relative to the speed of light, so you
want to avoid them.

The cost of this, of course, is a lot of extra state in the network, which impinges on scalability. To combat this, you want to be carefull to only use Fast Reroute on high reliability traffic. Using it on all of your best effort traffic would be counterproductive.


sgan201 12/4/2012 | 9:32:10 PM
re: MPLS Fast Reroute Gains Momentum Hi,
Why MPLS do not do something like SPVC in ATM world?? That seem a lot simpler than this fast re-route?? Is it because MPLS has no crankback??
arch_dude 12/4/2012 | 9:32:08 PM
re: MPLS Fast Reroute Gains Momentum Let's please keep our terminology straight. A feature is scalable if the resources required by that feature at each point in the network remain fixed as the size of the network increases.

MPLS fast reroute is scalable. The amount of resources required is fixed for each tunnel that has a fast-reroute alternative. Fast reroute may or may not be a resource hog. It may or may not be usable, or feasible, or complicated. But it is scalable.

Now, certain uses of MPLS don't scale well, since they demand increased resources everywhere when a new user is added anywhere. But this is true for MPLS as a whole, whether or not fast reroute is implemented.
Tony Li 12/4/2012 | 9:31:59 PM
re: MPLS Fast Reroute Gains Momentum

And the only way to begin to address this issue
is to make #3 grow sub-linearly. That is, if the
number of fast reroute LSPs grows as the log of the amount of traffic, then you have a chance of being scalable.

I believe that this is possible, but it requires end user understanding of the scalability issues.

Tony Li 12/4/2012 | 9:31:58 PM
re: MPLS Fast Reroute Gains Momentum
MPLS does not (currently) have crankback. However, it is trivial to implement SPVCs within the specs as they exist today. It's all a matter of signalling from the head end.

Note that SPVCs have a much longer failover time because you have detection, failure signalling, IGP convergence, alternate path computation, and new path signalling.

A fine combination is Fast Reroute for high reliability traffic combined with SPVCs for TE. SPVCs also allow you to reoptimize the LSPs that you're using for Fast Reroute.

Page 1 / 7   >   >>
Sign In