News & Analysis
Comment
iniewski
In a short term there will be thousands of people that will argue that there are ...
Google likes OpenFlow, but many comms vendors don't
Rick Merritt
10/4/2012 4:13 AM EDT
Four steps forward
Today, OpenFlow is just a protocol that lets a software controller on a server speak to a router or switch in the network. To fulfill its vision OpenFlow needs to be much more.
So ONF plans an architecture and framework group to lay out the landscape of just what OpenFlow will and won’t address. “We are trying to paint a better picture of what the whole canvas looks like, where we interface to existing standards outside and what’s in the ONF’s scope,” said Dan Pitt, the executive director of ONF and its only full-time employee.
Separately, ONF announced a work group to define what sort of networks it will address beyond wired Ethernet, where it is defined today. Fiber optic and wireless options are expected to be a focus here with Infiniband one of the technologies often mentioned as a target.
Another group will define a so-called northbound API so developers can build applications on top of OpenFlow controllers—one of the big goals of the movement. “There is a lot of clamor for a northbound API, [but] we have felt it’s at best premature to define [it],” said Pitt.
So the group will take a smaller step forward instead, cataloging existing network APIs to define the landscape. “There are close to 20 commercial, open source and research APIs already,” said Pitt. In the meantime, developers can “build OpenFlow apps now by putting the interface directly in their apps."
All three work groups are in a relatively early state of finalizing their charters and members.
The fourth new work group is perhaps the most interesting of all, and the furthest along so far. It aims to essentially bridge the technical gap between tomorrow’s OpenFlow network controllers running on servers and today’s routers and switches that handle a wealth of protocols typically processed in the proprietary ASICs of the big comms vendors.
The so-called forwarding abstraction group warrants a separate story all of its own. We'll have more on that soon.
Related stories:
Google describes its OpenFlow network
TI, Stanford explore OpenFlow silicon
Experts see promise, threat in SDN, OpenFlow
Today, OpenFlow is just a protocol that lets a software controller on a server speak to a router or switch in the network. To fulfill its vision OpenFlow needs to be much more.
So ONF plans an architecture and framework group to lay out the landscape of just what OpenFlow will and won’t address. “We are trying to paint a better picture of what the whole canvas looks like, where we interface to existing standards outside and what’s in the ONF’s scope,” said Dan Pitt, the executive director of ONF and its only full-time employee.
Separately, ONF announced a work group to define what sort of networks it will address beyond wired Ethernet, where it is defined today. Fiber optic and wireless options are expected to be a focus here with Infiniband one of the technologies often mentioned as a target.
Another group will define a so-called northbound API so developers can build applications on top of OpenFlow controllers—one of the big goals of the movement. “There is a lot of clamor for a northbound API, [but] we have felt it’s at best premature to define [it],” said Pitt.
So the group will take a smaller step forward instead, cataloging existing network APIs to define the landscape. “There are close to 20 commercial, open source and research APIs already,” said Pitt. In the meantime, developers can “build OpenFlow apps now by putting the interface directly in their apps."
All three work groups are in a relatively early state of finalizing their charters and members.
The fourth new work group is perhaps the most interesting of all, and the furthest along so far. It aims to essentially bridge the technical gap between tomorrow’s OpenFlow network controllers running on servers and today’s routers and switches that handle a wealth of protocols typically processed in the proprietary ASICs of the big comms vendors.
The so-called forwarding abstraction group warrants a separate story all of its own. We'll have more on that soon.
Related stories:
Google describes its OpenFlow network
TI, Stanford explore OpenFlow silicon
Experts see promise, threat in SDN, OpenFlow
|
|
|
|
|
Navigate to related information
iniewski
10/5/2012 11:26 AM EDT
In a short term there will be thousands of people that will argue that there are thousands of reasons why OpenFlow can't happen...some be real, some will be invented to protect their businesses...but in a long term simplicity in hardware and protocols might prevail...we have seen this movie played out historically several times in various industries...Kris
Sign in to Reply