Cisco’s software controller marks its first major step into the emerging market for software-defined networks (SDNs). It embraces both the OpenFlow protocol supporting by the Open Networking Foundation and its own proprietary variant called OnePK.
Proponents of OpenFlow aim to level the playing field for communications systems based on proprietary ASICs, software environments and a jungle of protocols. In their place, OpenFlow aims to create a more open and high-level software environment where network operators and vendors will create and control network features as software applications.
The Cisco controller supports Rest and Java interfaces for programmers writing network applications. The controller then speaks to switches and routers through the OpenFlow or OnePK interfaces.
Cisco says it will support all SDN interfaces including several still in the works, but clearly favors its own OnePK.
“We want to meet developers where they are—this is not a controller tied to any particular technology,” said Shashi Kiran, senior director of data center and cloud networking at Cisco. “OnePK can take advantage of our hardware features [but] OpenFlow needs to work against a more abstract switch model,” he said.
The controller is still in beta testing. Cisco expects it could support Version 1.3 of OpenFlow when the controller is released in the middle of the year.
Rick: I don't think Cisco can have it both ways...they are supporting OpenFlow for PR reasons but clearly push their own technology...it is a loose-loose position they are in in...they need their own ASICs and proprietary system architecture to provide value added and prevent low cost box makers from copying their designs...but the world is going global with openflow and that tide will eventually crush them, they can't compete with Huawei on cost...Kris
I'm not sure I see a conflict between proprietary ASICs and Open Flow. The first is hardware, and the second is software.
High end Cisco routers confront a simple problem: an absolutely enormous amount of packets are being pushed through the network that must be processed and routed. As volume steadily increases, the question becomes "How do you do it fast enough to handle them all?" Cisco's answer is custom hardware designed for the purpose. Can it be done with off-the-shelf commodity hardware? I suspect Cisco might do it to lower their costs if they thought it could.
Ideally, the software level will abstract away the hardware, and if I'm a network engineer defining networks, I don't necessarily know or care what hardware is actually doing the work. I use the same commands and procedures regardless.
OpenFlow backers ultimately want to push all those networking jobs to x86 servers controlled by C++ programs to simplify network management and disrupt the big ASIC-based companies such as Cisco, AlcaLu, Juniper, Ericsson.
It will be a 5-10 year battle methinks.