SDN architectures

ADVA Mixes OpenFlow With Optical

ADVA Optical Networking has run an experiment using OpenFlow to control wavelength-switched networks, showing that the software-defined networking (SDN) technology has some usefulness at the optical layer.

The software involved is truly an experiment and not a product. It was run by ADVA and the University of Essex , on ADVA's FSP 3000 system, as part of the project called OpenFlow in Europe, Linking Infrastructure and Applications (Ofelia).

OpenFlow is typically discussed as a Layer 2 technology. The trick in ADVA's experiment was to keep the protocol informed of optical-layer issues that OpenFlow wasn't built to handle -- such as having to consider whether a certain wavelength color is already passing through a particular node.

Why this matters
The promise of OpenFlow is a simpler and more flexible way to control networks, starting with the separation of the data and control planes. Interestingly, optical-networking vendors did this years ago with generalized MPLS (GMPLS).

But GMPLS comes from the telecom world, whereas OpenFlow is what's hot in data centers and research networks. Hence, those circles are showing interest in seeing what OpenFlow can do in other contexts, such as the optical network, says Jörg-Peter Elbers, ADVA's vice president of advanced technology.

More generally, vendors are trying all kinds of experiments with OpenFlow; you can see a few racks' worth of them at Interop , which is ending Thursday afternoon in Las Vegas. (ADVA isn't within 500 miles of Interop; executives spoke with Light Reading from Germany on Wednesday.)

For more

— Craig Matsumoto, Managing Editor, Light Reading

digits 12/5/2012 | 5:33:31 PM
re: ADVA Mixes OpenFlow With Optical

Bring together the telco and IT worlds and it's going to throw up potential for the networks of the future.

So far all I have heard about OpenFlow (from those that are not pure evangelists) is that it's likely to be restricted to the data center, but this shows that down the line there are other real possibilities.

The Only Way Is Essex? Didn't know ADVA was a fan...

wildcard22 12/5/2012 | 5:33:29 PM
re: ADVA Mixes OpenFlow With Optical

Yes it might sounds like GMPLS, but it is such a different mechanism, architecture and purpose.

See a paper here that compares GMPLS to OpenFlow/SDN



Pete Baldwin 12/5/2012 | 5:33:28 PM
re: ADVA Mixes OpenFlow With Optical

"Why OpenFlow/SDN Can Succeed Where GMPLS Failed"

Nice title.  :)  I'll give this a read -- thanks, wildcard.

rhr 12/5/2012 | 5:33:22 PM
re: ADVA Mixes OpenFlow With Optical Craig, I notice you and LR are writing much about OpenFlow, which I'm reading with interest but I've still to understand just what is it about the concept that is causing it to get such interest?-á

Optical-networking vendors have been running with generalized MPLS (GMPLS) for a while now, as you say, and while it is being employed and benefiting operators it gets limited mention. Also interesting, no?

And thanks for the links, Wildcard22. I'll read with interest.
chechaco 12/5/2012 | 5:33:17 PM
re: ADVA Mixes OpenFlow With Optical

I find "GMPLS failed" claim to be, well, uneducated. OpenFlow applied to wavelength provisioning, IMHO, is not much different from the Path Computation Element (PCE) that generates explicit paths that are signaled by RSVP's EROs. And GMPLS had separation of data and control planes since its day one.

Pete Baldwin 12/5/2012 | 5:33:14 PM
re: ADVA Mixes OpenFlow With Optical

rhr- Phil has a nice, blunt blog about it:


rhr 12/5/2012 | 5:33:13 PM
re: ADVA Mixes OpenFlow With Optical Thanks
wildcard22 12/5/2012 | 5:33:10 PM
re: ADVA Mixes OpenFlow With Optical


checacho, rhr,

There are 3 reasons why I call GMPLS a failure:

1) Just because every transport vendor has implemented a GMPLS-like control plane does not make it a success. No one uses it - see for example this article from last year - note the -  couple of wavy-handed "sort ofs."


2) Using a management system to manually trigger  an RSVP path setup is an extremely limited and  vendor-propriety (non-interoperable) mechanism for using GMPLS. I would not call this kind of use a "sucess" but I can see why some (for example, the vendor) might call it so.

3) Finally the whole point of GMPLS was to make the transport network dynamic and respond  to service needs. In that it was supposed to work with packet-networks (IP/MPLS) - unified control plane and all. But IP networks will not touch GMPLS/UNI/ASON etc. Here there is total failure.

Two other things I'd like to clarify -- 

A) SDN is not just the separation of data and control planes (blog about this coming soon)

B) PCE is not SDN -- it can be an application that sits above the controller in an SDN framework -- but it does not replace it 



Sign In