x
Optical/IP

MPLS Vendors Demo Fast Reroute

Yesterday, Isocore, an independent testing facility in McLean, Va , hosted its third public interoperability demonstration where it tested for the first time a new Internet Engineering Task Force (IETF) draft of MPLS Fast Reroute, a technology that brings Sonet-like protection to Multiprotocol Label Switching (MPLS) networks (see MPLS Fast Reroute Gains Momentum).

Cisco Systems Inc. (Nasdaq: CSCO), Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7) and Juniper Networks Inc. (Nasdaq: JNPR) participated in the test using specifications from a draft written by George Swallow of Cisco, which combine work from two other drafts on Fast Reroute. The test focuses on link protection and did not include node protection mechanisms. Cisco and Avici had tested an earlier Fast Reroute draft for link protection in August.

Ixia (Nasdaq: XXIA), Spirent plc (NYSE: SPM; London: SPT), and NetTest provided the testing equipment.

The importance of the demo is twofold. For one, this is the first time that all three core routing vendors have tested this feature together. And second, it is an important step forward in developing this critical feature for MPLS.

“The idea behind doing these demos is to show certain technologies working today,” says Bijan Jabbari, president of Isocore. “But we need to work further to make sure all the features are standardized. And I think that this process will help facilitate that.” The test bed included IP core routers from three vendors: Avici’s TSR, two Cisco GSR 12404s, and Juniper’s M10. The way it was set up was that traffic entered the network at the CoSine Communications Inc. (Nasdaq: COSN) IPSX3500, which was used as the access router. It routed traffic to the Cisco GSR. The Cisco GSR then routed it to the Juniper M10, which routed it onto another Cisco GSR. When the cable was disconnected between the Cisco GSR and the Juniper M10 router, the Fast Reroute mechanism kicked in and rerouted the traffic to the Avici TSR, which was connected to the GSR and M10. Is that clear? The network restoration occurred in roughly 5 milliseconds, well within the current Sonet standard that requires 50 milliseconds restoration. Restoration in the demo has consistently run within 10 milliseconds, says Jabbari.

The reason the restoration is so quick is because the traffic is rerouted locally. There is no signaling protocol that propagates through the network to let the next hop know packets are coming, making the failover time to an alternate path extremely fast, says Don Troshynski, senior systems engineer for Avici.

The demonstration itself was not terribly exciting to watch. In fact, most of the observers didn’t even realize the test was going on until it was over. Even Tony De La Rosa, product manager for Ixia, who was running the demonstration and explaining what was happening, hadn’t realized that the line between the routers had been disconnected. Interestingly enough, this seems to be the point of demonstrations showing off reconvergence technologies. The point is to show restoration occurring so quickly that there is no noticeable loss of service.

“Restoration time can fluctuate within a certain range,” says Amrit Hanspal, product manager for MPLS and QOS at Cisco. “As long as you keep it below 50 milliseconds, it’s alright. And even then some applications will be fine if the restoration time is longer. Call signaling is usually dropped after 1 or 2 seconds.”

The vendors involved in setting up the network and the test have been working together on this project for the past few months, dedicating two full days to setting up the demonstration prior to its public debut. The work that was done to get this implemented will go a long way in helping these vendors further define the standard, says Loa Andersson, chief architect for Utfors AB.

“From an IETF perspective this is a pretty good basis for developing the protocol design,” he says. “It’s still early days for this feature, and this a good way to work out the problems early on.”

Andersson says that from a service provider perspective, this demonstration could highlight problems that he would look for when implementing the feature in his company’s own test bed.

Heidi Tse, a backbone engineer for WorldCom Inc. (OTC: WCOEQ), says that these demonstrations are important to a degree, but she emphasizes that carriers must still test the gear themselves.

“We don’t want to be a vendor’s guinea pig,” she says. “But you also have to understand that this is not a sophisticated test, and we would have to test it much more in depth ourselves if we were going to implement this feature. Still, tests like this are important because it will help move the standard along and we all need the standard before we do anything.”

Isocore also demonstrated yesterday interoperability for label switched path (LSP) protection using gear from Marconi plc (Nasdaq/London: MONI). And it demonstrated provisioning of Layer 3 MPLS/BGP (Border Gateway Protocol) and Layer 2 Draft Martini virtual private networks using gear from Cisco, CoSine Communications Inc. (Nasdaq: COSN), Foundry Networks Inc. (Nasdaq: FDRY), Extreme Networks Inc. (Nasdaq: EXTR), Lucent Technologies Inc. (NYSE: LU), and Redback Networks Inc. (Nasdaq: RBAK).

Jabbari says Isocore plans to conduct more interoperability tests next year. Specifically, he would like to test node detour in MPLS fast reroute in addition to the link protection that was demonstrated already. But he says he must wait for all the vendors to have a working implementation of that spec before a test can be designed. Andersson and Tse will likely be tuning in again to that one.

“Node protection is on my Christmas wish list,” says Andersson. “But we need to take one thing at a time. I’m glad they’ve got the link protection working. Now they can move on to the node protection.”

— Marguerite Reardon, Senior Editor, Light Reading
www.lightreading.com
<<   <   Page 2 / 16   >   >>
BobbyMax 12/4/2012 | 9:26:00 PM
re: MPLS Vendors Demo Fast Reroute The tests do not tell any thing. The restoration and alternative routing capabilities can be reliabily tested in a large size network. The carriers will never deploy MPLS in the entire network because of the performance problems associated with MPLS.
techstud 12/4/2012 | 9:26:00 PM
re: MPLS Vendors Demo Fast Reroute Tera,

as the previous poster said - mpls hyping serves two objectives for established vendors - 1) keep new entrants busy by making them implement useless mpls stuff that will unlikely be ever completed given their limited resources (eventhough it is unlikely to be ever used on those machines) and 2) sell new "mpls" capable gear by confusing dumb operators by repeatedly telling them its "NEW". Cisco needs to sell tons of mpls add=on cards to old atm switches.

Think of it who will make most money by hyping mpls, and who gets to loose most? small vendors have no choice but get caught in cleverly laid trap.

How many small companies died simply by wasting too much resources on mpls feature development just be able to say to the operators that they have mpls (even though most operators have no plan to use it real networks except for their lab set ups)?
beowulf888 12/4/2012 | 9:25:59 PM
re: MPLS Vendors Demo Fast Reroute dreamer:
In the scenario you presented, how does SONET ensure that the failover between ports on both switches happens at the same time? I guess I just don't see how there is any difference between MPLS FRR and SONET APS. Can anyone explain?

best regards,
--Beo

dreamer101 wrote:
"The proper test is to only cut the RX cable. The RX side will detect the failure. It will generate Sonet AIS to the TX side on the same port. Depending on the length of the TX cable, the other side may take a while to receive AIS. Obviously, if the TX cable is a few thousand miles long, it will take a while to switch over. How does MPLS FRR ensure that the port is switchover on both side at about the same time???"
sgan201 12/4/2012 | 9:25:56 PM
re: MPLS Vendors Demo Fast Reroute Hi,
Read GR-253 or any basic Sonet book. Sonet APS has K1 and K2 bytes that hand shake and synchronize this..
sgan201 12/4/2012 | 9:25:56 PM
re: MPLS Vendors Demo Fast Reroute Hi tera,
There is a big difference between asking for something and actually willing to buy it..
Who has actually pay big bucks for MPLS equipment??
Don't you know by now designing equipment by RFP is a sure way to failure??
rationalMind 12/4/2012 | 9:25:55 PM
re: MPLS Vendors Demo Fast Reroute beowulf888 wrote:
dreamer:
In the scenario you presented, how does SONET ensure that the failover between ports on both switches happens at the same time? I guess I just don't see how there is any difference between MPLS FRR and SONET APS. Can anyone explain?

best regards,
--Beo

dreamer101 wrote:
"The proper test is to only cut the RX cable. The RX side will detect the failure. It will generate Sonet AIS to the TX side on the same port. Depending on the length of the TX cable, the other side may take a while to receive AIS. Obviously, if the TX cable is a few thousand miles long, it will take a while to switch over. How does MPLS FRR ensure that the port is switchover on both side at about the same time???"
---------------------------------------------------------

FRR and APS are very different in a number of ways. For one FRR doesn't involve multicasting traffic on both the working and protect lines while APS does. And this point is moot to dreamer's criticism. Also, SONET is bi-directional by nature while MPLS is not (I know you can signal bi-directional LSPs). So, I think dreamer's criticism are not irrelavant as you are not comparing apples to apples. Also, uni-directional SONET APS (I think more widely used than bi-directional APS) doesn't behave the way dreamer described.

Prizm 12/4/2012 | 9:25:54 PM
re: MPLS Vendors Demo Fast Reroute The proper test is to only cut the RX cable. The RX side will detect the failure. It will generate Sonet AIS to the TX side on the same port.

Bzzzz! Sorry, wrong answer.
AIS is only propagated in the same direction as the failure. This does not apply in this case since the router is Path Termination Equipment.
What the router should do is send RDI (remote defect indication) on its Tx port.
rationalMind 12/4/2012 | 9:25:54 PM
re: MPLS Vendors Demo Fast Reroute Typo Alert:

I wrote:
So, I think dreamer's criticism are not irrelavant

Should be:
So, I think dreamer's criticisms are irrelavant
spotlight 12/4/2012 | 9:25:54 PM
re: MPLS Vendors Demo Fast Reroute
AIS is only propagated in the same direction as the failure. This does not apply in this case since the router is Path Termination Equipment.
What the router should do is send RDI (remote defect indication) on its Tx port.

=====================================

If you send the AIS in the same direction it is Uni directional switching and if AIS is sent on the Tx port it is bidirectional switching

About Multicasting, How do you think Extra Traffic is provided ....
imref 12/4/2012 | 9:25:52 PM
re: MPLS Vendors Demo Fast Reroute >RBOC want to buy ATM switch.
>There are only 2 next gen ATM switch start up: >Wavesmith and Equipe..
>Meanwhile everyone waste their money and effort >on MPLS...
--------------

In reality, every RBOC has an RFP on the street for MPLS, they are all considering MPLS for WAN services if they get approval to go beyond their home areas. This is why every vendor under the sun is pushing their MPLS solutions.

In reality, just about every new network being built in places such as Asia and Europe is based on MPLS.

In reality, we're long past the discussion of whether or not MPLS is a useful technology, the market has spoken.

The folks arguing that MPLS is bad because it violates the Internet architecture remind me a bit of those who argued that everything on the Internet should be free. They are following a principle that is no longer relevant, and will lead them to the unemployment line.

Service and technology solution selection should be driven by what will generate the most revenue, or minimize operational costs, period.

MPLS continues to offer real benefit in reducing network cost and complexity, and in enabling IP-based WAN transport services and additional value added services, which is why the vast majority of service providers have deployed it.

Now, can we finally move past the "MPLS is evil" discussion?
<<   <   Page 2 / 16   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE