digits 12/5/2012 | 5:17:23 PM
re: Optical Transport Gets an SDN Idea

Glad to see the two companies I have heard talking around this topic -- ADVA and Huawei -- both involved in this process.

This discussion does not need splinter groups... 

thegreenfrog 12/5/2012 | 5:17:22 PM
re: Optical Transport Gets an SDN Idea

The effort to include optical connections with packets is similar to the work done a decade ago with GMPLS (Generalized MPLS)... if the IETF could do it fo rouing without re-inventing the wheel, there is no reason why it can't be done with Open Flow for virtualization. Interesting to see Calient playing with softare control again; some of their staff was involved with defining the IETF RFC's for GMPLS. 

Pete Baldwin 12/5/2012 | 5:17:19 PM
re: Optical Transport Gets an SDN Idea

About splinter groups -- I'd agree, but I have a feeling SDN is going to be rife with them. Maybe not in individual areas like optical transport -- what I mean is, lots of similar individual areas could start wanting their own spins on SDN.

And on top of that, splinter groups really could form.

Case in point: My colleague Rick Merritt at EE Times writes about a Broadcom-led API effort:


[email protected] 12/5/2012 | 5:17:17 PM
re: Optical Transport Gets an SDN Idea

It's not clear to me that SDN is to replace GMPLS, or vice versa. They seem to serve different purposes. First, transport network has a pretty broad definition, including optical, packet etc. Second, transport networks are mostly operated in isolation with some use GMPLS, some use centralized NMS, etc. So it's far from saying multi-network/multi-vendor interop. Most of all, GMPLS (and many other TE-based protocols) is to optimized traffic transport within one particular network.

On the other hand, SDN is to enable services on top of the underlying networks, regardless how each individual network is configured and managed.

For instance, we can imagine an OTT video services that is to connect LTE users to the data center servers over multiple Ethernet, IP and optical networks. SDN would be used here to provision and control bandwidth "links" at application level, while each network may run GMPLS or whatever.

Hope this is making sense.

[email protected] 12/5/2012 | 5:17:16 PM
re: Optical Transport Gets an SDN Idea

Here is the thing: this is all driven by the new services and applications. If the operators deploy a network from a single vendor (a common practice in many transport networks), multi-vendor standardization is nice but secondary. On the other hand, if the operator is to deploy a new service from data centers over multiple networks (and vendor equipment), it becomes essential to produce a common and abstract interface, at the same time, we need to hide the unnecessary underlying network complexity. So it’s to all vendors’ benefit to work together in this area.

fmenard123456 12/5/2012 | 5:17:14 PM
re: Optical Transport Gets an SDN Idea

An idea here: a Light Reading essay entitled 'Carrier Pricing Strategies for Application-Initiated Optical Transport Network Dynamic Capacity Allocations triggered on Multivendor Optical Transport Network Equipment from Software Defined Networking Packet Switching'. F.

[email protected] 12/5/2012 | 5:17:13 PM
re: Optical Transport Gets an SDN Idea

Hahaha! Very cute! But seriously, IMHO, in years to come, the money is to be made from the applications (sitting north of SDN Controller); the network intelligence is from IP and routing protocols (not sure where it sits though :-)); the data transmission efficiency is from the transport gears that continue to innovate in pace with Moore's Law. There are many ways to program network links. OpenFlow is one of the standardized ways in doing so, and requires enhancement to support transport networks. No point to be religious and no point to resist the unavoidable. Happy holiday!

Pete Baldwin 12/5/2012 | 5:17:12 PM
re: Optical Transport Gets an SDN Idea

fmenard:  Add "From Hell" at the end, and I'll start work on it immediately.  :)

Ping brings up a number of good points. Where all the intelligence sits could be an interesting debate as SDN gains momentum.

And who gets to own the value? Ping mentions the applications being where the real money will be -- that's a very common view. And what about the controller, which we're paying so much attention to right now -- does it end up being more of a commodity item?

Lots of questions. It's part of what makes SDN such an exciting area right now.

melao2 12/5/2012 | 5:17:12 PM
re: Optical Transport Gets an SDN Idea

So the idea for SDN on Optical, is for the Backhaul and Metro networks?

What about the longe distance backbones? I always wondered how necessary such intelligence is strictly needed on the backbone side, other than to guarantee resiliency.


On a completelly unrelated note, it is good to see topics about optical network in Lightreading. Going back to the roots of this site...

[email protected] 12/5/2012 | 5:17:08 PM
re: Optical Transport Gets an SDN Idea

IMHO, the SDN architecture we are working on is suitable for many types of transport networks. First, as we all have experienced, one of the key requirements in backhaul and metro is in operation simplicity, where the operators can do point-click to provision the Ethernet and WDM links. Similarly, the key in long-haul backbone is to control the traffic aggregate into those well-provisioned and expensive trunks. In both scenarios, we can use SDN as the glue to bring routing, network planning and policy controls into the operation. IMHO, SDN is not about having the cheapest dumb boxes. Rather, the value is in reducing the operation cost.

Sign In