x
Optical/IP

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 2 / 4   >   >>
mdwdm 12/4/2012 | 11:18:06 PM
re: GMPLS Showcased in Demo A year ago I first tried to tell gee that fast provisioning is all about networks connectivity though MEMs switch, and fully routed backplanes.

He kept talking about MPLS, clearly something
he has no clue about.

Geez, why is it so hard to understand that MPLS
is all about QOS, another ATM for circuit
emulation and all the goodies? Even an idiot should understand it by now after trolling
lightreading everyday.

----------------
This "fast provisioning" stuff is irrelevant.
signmeup 12/4/2012 | 11:18:02 PM
re: GMPLS Showcased in Demo straightup wrote:
"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."


This is EXACTLY where we are headed. There is a pressing business need to provide on-demand high-speed transport for limited time slots TODAY. How do you think real-time video transport occurs? Today it occurs by calling a transport provider like Vyvx and having them set up a circuit from point A to point B for a specified amount of time. How do you think the Superbowl gets from the stadium to the network?

This is reality - there is need.

gea 12/4/2012 | 11:18:02 PM
re: GMPLS Showcased in Demo "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."

Well, that's worth thinking about. My original comments weren't really referring to this case...I thought (and still think) that there would be a strong demand for GMPLS to do exactly what it takes humans so long to do now, and down at the good ole' DS1/DS3/STS-3 level.

This would of course assume that the appropriate circuit packs are in place at the endpoints of the circuit (and of course the capacity between those points). But instead of someone manually entering the provisioning commands (even if remotely) to set up a DS3 across mutliple BLSRs (even given a planning tool spat out that set of orders), it would seem to me far more desirable for this to be done automatically.

Your argument is not irrelevant here, though, I suppose. But I would counter-suggest that the reason there's no demand for a month of DS-3 (or OC-48) service cross country, say, is because 1) price and 2)provisioning time. If both came down dramatically (say through the use of GMPLS) then I'd bet you'd see some action. But I could be wrong....
gea 12/4/2012 | 11:18:02 PM
re: GMPLS Showcased in Demo mdwdm wrote...

"Geez, why is it so hard to understand that MPLS
is all about QOS,"

Uh...what on EARTH are you talking about?

The term "MPLS" basically refers to the packet world. It's an additional shim header in a layer-3 packet. It's also a set of control plane protocols used to set up the 'circuits' that are defined by the exchange of the MPLS headers.

GMPLS is almost completely different, and as usual you are mouthing off on a subject you clearly have zero knowledge of. G (see that 'G' there?) GMPLS takes many of the control-plane protocols proposed for use with MPLS and extends them into both the new-ish optical domain as well as SONET (and everything else, for that matter).

So tell me: What does QoS have to do with GMPLS applied to SONET circuit setup/teardown? It's still a circuit, and once the circuit is set up then whatever is inside the circuit will experience the exact same QoS as if that circuit were provisioned by traditional means.

turing 12/4/2012 | 11:18:01 PM
re: GMPLS Showcased in Demo There is a pressing business need to provide on-demand high-speed transport for limited time slots TODAY. How do you think real-time video transport occurs? Today it occurs by calling a transport provider like Vyvx and having them set up a circuit from point A to point B for a specified amount of time. How do you think the Superbowl gets from the stadium to the network?
----------

Good example. One good example. But do you think Fox/Vyvx would trust an automatic protocol to save a few hours of some lacky's time, for millions of dollars in investment?
Don't get me wrong - there are plenty of cases where an automatic protocol makes sense over hand-configuration (routing protocols, for example). But those are for cases where many things change very often - where it literally can't be statically configured.
signmeup 12/4/2012 | 11:18:01 PM
re: GMPLS Showcased in Demo turing wrote:
"Good example. One good example. But do you think Fox/Vyvx would trust an automatic protocol to save a few hours of some lacky's time, for millions of dollars in investment?"

But they do it today! The difference being is that instead of an packet-based solution, it is a circuit-based one. They already provision short-use circuits across a transport network. It's not a question of how many lackys it takes - they want to remove the lackys completely out of the equation by having the end user "provision" the circuit. For example today if I needed X amount of bandwidth at Y date for Z amount of time, I would call Vyvx to book the service. They would then turn that into a work order for a circuit. A transport provider would then provision a circuit to transport the information. The problem is that today the duration of the circuit is measured in terms of days and not hours. Why? Because it takes that long to provision and unprovision a circuit to use. Now multiply that by 500 circuit requests a day to see how much capacity is being wasted as well as the number of people required to make the system work...

A better way would be to have a so-called "automated" provisioning service where the end user could access a provisioning utility on the web and tell how much bandwidth is required, for how long and from point A to point B. This provisioning system would then generate an automated provisioning request that would build the circuit using GMPLS at the required time, bandwidth, and duration. No more lacky's and no more inefficient ciruit utilization!

Regardless of whether the techologies are ready for prime-time (yes that was a joke..) or not, the business case IS there and people are looking at doing it within the next 1-3 years. Trust me, it makes business sense.



turing 12/4/2012 | 11:18:00 PM
re: GMPLS Showcased in Demo The problem is that today the duration of the circuit is measured in terms of days and not hours. Why? Because it takes that long to provision and unprovision a circuit to use.
-----------

I think I understand everything you're saying, but I still don't get why it takes a control plane protocol to do it. You say Vyvx takes days to provision it, and that they'd rather use a web-based system to automate it. I believe that can be done through automated scripts or better integration of config, but I fear the real slowdown is not the configs - it's the ownership/business process side, and hardware availability (i.e., who would have an OC-48 sitting idle waiting for a once-a-year superbowl that changes location)

Those problems are not solved by a control plane protocol.
gea 12/4/2012 | 11:17:59 PM
re: GMPLS Showcased in Demo "So tell me: What does QoS have to do with GMPLS applied to SONET circuit setup/teardown?"

Wow. Your brain does not work properly...major logical jumps and gaps. Either that or you're trolling me...I'm starting to suspect the latter.

GMPLS can (theoretically) do a LOT of things, in the packet domain, in the optical domain, in the ATM domain (which is where MPLS had it's start, by the way), and in the SONET domain.

My focus here is on where there's a clear and immediate market need: provisioning SONET circuits. When used to provision SONET circuits GMPLS has little to do with QoS.

As for...

"GMPLS is implemented by G709 which wrapps
SONET/whatever."

OK, you clearly know little about what you're talking about. GMPLS is in the CONTROL PLANE. Do you have any clue what this means?

At this point it's obvious I'm wasting my time responding to you. You need to start doing some homework and stop thinking you know something because you read it on a bulletin board or whatever.

rpm23 12/4/2012 | 11:17:59 PM
re: GMPLS Showcased in Demo I agree with all the posts saying fast provisioning may not be a strong enough selling factor\value proposition for GMPLS deployment. One other aspect of GMPLS that does not seem to
have been mentioned is the possibility of
dynamic restoration in case of failures. Such a restoration service, while possibly slower in restoration time, promises to be more capacity efficient than traditional 1+1 or ring type protection mechanisms (20-30% more efficient in studies). On the flip side, CAPEX reduction
(as a result of capacity efficiencies) may not be a burning issue with carriers at this point given excess inventories. But a different aspect of GMPLS that may prove in its value over time.
mdwdm 12/4/2012 | 11:17:59 PM
re: GMPLS Showcased in Demo You are as clueless as ever.

Go do a search on this board, it is you
who said again and again the MPLS (not GMPLS)
is for "dynamic provisioning".

Now for GMPLS, it has provisions to support fast wavelength setup and teardown. It is a optical layer thing and has little to do SONET. In fact, it is meant to do away from SONET.
GMPLS is implemented by G709 which wrapps
SONET/whatever. This bring up another joke from
you: G709 is another SONET.

----------
So tell me: What does QoS have to do with GMPLS applied to SONET circuit setup/teardown?
<<   <   Page 2 / 4   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE