GMPLS Showcased in Demo

Participants in a multivendor demo at the McLean, Va., offices of Isocore say they've proven that Generalized Multiprotocol Label Switching (GMPLS) can be used to streamline the management and provisioning of multivendor IP/MPLS applications.

This isn't the first GMPLS demo by a long shot. But according to Isocore's Bijan Jabbari, it's a particularly ambitious one. Instead of running GMPLS in isolation, the test was aimed at showing that IP/MPLS applications, including Layer 2 and Layer 3 VPNs and videoconferencing via VPLS, could be managed via GMPLS (see Isocore Validates IP-Optical). Also included were tests of GMPLS interoperability using multivendor implementations of the UNI (user network interface) defined by the Optical Internetworking Forum (OIF).

The live event followed the MPLS 2003 International Conference in Washington, D.C., and the vendors involved were only just starting to wind down late this afternoon. "It's difficult to stop them," quips Jabbari [ed. note: the zany madcaps!]

At least one carrier expressed interest in the proceedings earlier this week. "We already have a lot of transport gear, so we're still in the exploratory phase when it comes to GMPLS," said Christian Noll, research director of science and technology with BellSouth Corp. (NYSE: BLS). "But it's good to see multivendor interoperability testing going on. If we were to go with GMPLS, we'd stay away from any proprietary implementations."

The testbed included an "optical core" of routers and switches that generated optical bandwidth via GMPLS from Cisco Systems Inc. (Nasdaq: CSCO), Fujitsu Ltd. (OTC: FJTSY), Juniper Networks Inc. (Nasdaq: JNPR), Movaz Networks Inc., Sycamore Networks Inc. (Nasdaq: SCMR), and Tellabs Inc. (Nasdaq: TLAB; Frankfurt: BTLA).

Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7) and Tellabs also generated optical traffic using the OIF UNI.

The optical control plane for the IP/MPLS applications was included via gear from Alcatel SA (NYSE: ALA; Paris: CGEP:PA), Extreme Networks Inc. (Nasdaq: EXTR), Foundry Networks Inc. (Nasdaq: FDRY), Laurel Networks Inc., and Redback Networks Inc. (Nasdaq: RBAK) as well as from Cisco, Juniper, and Tellabs.

Also included in the test was software from Furukawa Electric Co. Ltd., NEC Corp. (Nasdaq: NIPNY; Tokyo: 6701) and Japanese carrier NTT Communications Corp.

Test gear used in the demo included the InterWatch platform from Navtel, which, according to Jabbari, was the only tester capable of emulating both GMPLS and MPLS traffic. Testers from Ixia (Nasdaq: XXIA) and Spirent Communications were used for detailed MPLS validation and traffic generation, he says, but only Navtel could offer GMPLS, too.

So what's next? Jabbari is clear there's more testing in store, probably starting in January. "It's still early for carriers to deploy GMPLS," he says. "But to be really ready for when that time comes, we need to be testing now. We've demonstrated that more work needs to be done."

— Mary Jander and Marguerite Reardon, Senior Editors, Light Reading

Page 1 / 4   >   >>
turing 12/4/2012 | 11:18:13 PM
re: GMPLS Showcased in Demo Let's see now... transmission equipment works well and doesn't crash and doesn't need much maintenance/upgrades. Router equipment has frequent software issues and needs upgrades monthly, because it is complex software. So let's take the complex software and put it on transmission equipment!

Yeah, that way we can automate and speed up the provisioning time, because there is soooo much provisioning going on in core transports. And an hour vs. a minute is going to save us lots of money, like $50/hour! (of course we'll have to pay the GMPLS expert $100/hour, but that's good for the economy)

And the operators are sure to trust our automagic protocol for provisioning, vs. the silly user-configured/well-known/easily-debuggable way, because the core transport is not that important anyway... it's a sandbox for testing our latest fad protocol.
gea 12/4/2012 | 11:18:12 PM
re: GMPLS Showcased in Demo Turing:

Well, although I appreciate the sentiment, I don't agree with the conclusions you seem to imply.

Basically, provisioning in the core is a MAJOR problem, and is the main reason it currently takes months for a circuit to be set up.

If the provisioning process could be reliably automated (a big if, I know), then GMPLS provisioning gizmos would sell like....SONET Network elements.

As for QoS, remember that if this is applied to SONET or optical pathways, the complexity/reliability of the GMPLS control plane protocols will have no impact there. It's still a circuit, just it got there via software. Of course, if GMPLS protection capabilities are leveraged, that may be a completely different story, and here I agree with your cisco analogy. I doubt the ILECs of the world will want this function done by software any time soon.
jim_smith 12/4/2012 | 11:18:11 PM
re: GMPLS Showcased in Demo

... is the main reason it currently takes months for a circuit to be set up...

... If the provisioning process could be reliably automated...

Careful... your ignorance is showing...

I'm really excited to find out how GMPLS is going to automate "provisioning"!

Does GMPLS have specifications for operational robots that will deploy the plugins?

Does GMPLS use Woodoo-Over-Witchcraft (WOW) to automagically manufacture hardware so that service providers don't have to wait for weeks to get equipment from the vendors?

gea 12/4/2012 | 11:18:10 PM
re: GMPLS Showcased in Demo "I have provisioned circuits in a small backbone"

What kinds of circuits?

In a worst-case scenario imagine provisioning a DS3 across 7 dual-node-interconnected BLSRs.

Of course, some of the tools needed to spit out the provisioning orders shields the user from SOME thinking, but this can still be a very tricky proposition.
turing 12/4/2012 | 11:18:10 PM
re: GMPLS Showcased in Demo --------
Basically, provisioning in the core is a MAJOR problem, and is the main reason it currently takes months for a circuit to be set up.

Yes, I have heard that, but it confuses me. I have provisioned circuits in a small backbone, and it didn't take long to do the config part. What took long was getting the hardware in place (if we needed more), and getting to the right owner/admin. Once they were in place and verified the authorization of the job it got done in minutes.

GMPLS won't solve the ownership model problem, or the hardware part (obviously).
gea 12/4/2012 | 11:18:10 PM
re: GMPLS Showcased in Demo "Careful... your ignorance is showing..."

Uh...how many central offices have YOU been in?

How many NEs have you personally had to configure?

Have you ever attempted to provision dual-node interconnected SONET rings?

Let's forget YOUR ignorance and just concentrate on GMPLS for SONET provisioning.

Theoretically, this would just be a software load w/o the need for extra hardware.

Don't think that just because your knowledge of GMPLS and provisioning is limited to merely rejecting marketing hype that mine is the same.

If GMPLS can live up to its promises, get standardized, AND integrate with existing OSSs (suh as TIRKS), it will experience widespread, wildfire adoption. I'll grant those are enormous ifs, but the market is clearly there.
straightup 12/4/2012 | 11:18:09 PM
re: GMPLS Showcased in Demo Think: the reason why provisioning takes months is not because it takes months of continuous labour... it is because for carriers are unwilling to invest the money in equipment for large capacity circuits before they have a signed order. If the equipment was already there, the provisioning wouldn't take months!

For GMPLS to improve the economics, the carriers have to have enough volatility in demand such that provisioning is a larger share of the overall cost. For services that have contract lengths measured in years, a provisioning cycle of months is reasonable. Until customers start ordering STS-48s for 8 hour sessions, GMPLS has no business case. Chock it up as a misread of the real factors at play.
turing 12/4/2012 | 11:18:09 PM
re: GMPLS Showcased in Demo ------
What kinds of circuits?

Access lines (DS3) through one sonet ring (I assume a BLSR ring) to cisco, and trunk side OC-3 and higher through Nortel Optera ring to Nortel/Bay BCNs. I didn't touch the sonet ring part - that was done by the sonet gear owner. And the Nortel optera I did my half and someone else did their half.
road__runner 12/4/2012 | 11:18:07 PM
re: GMPLS Showcased in Demo Straightup, you said it man.

This "fast provisioning" stuff is irrelevant.

Software tools already exist to provision circuits in minutes AFTER THE EQUIPMENT AND NETWORK IS ALREADY IN PLACE. GMPLS cannot fly in a network if one doesn't exist and if one does exist then services can be turned up quick enough even today without GMPLS.
jim_smith 12/4/2012 | 11:18:06 PM
re: GMPLS Showcased in Demo "Let's forget YOUR ignorance and just concentrate on GMPLS for SONET provisioning."

My my... aren't we ticked off...

"I'll grant those are enormous ifs, but the market is clearly there."

Yes... also, there is a market for a "cancer cure".

I hope you read the other posts. As you can see, other people are also "ignorant" like me.
Page 1 / 4   >   >>
Sign In