Military nations demonstrate their power by testing nuclear weapons. Pure play networking vendors display their power in the SDN ecoystem by releasing Controllers. ~Anonymous
I sat in today on Cisco’s Webcast on OpenFlow and the ONE Controller. Cisco CTO, and Engineering and Chief Architect, David Ward spoke at length of this announcement. Ward is also the Chair of the Technical Advisory Group of the Open Network Foundation (ONF). The webcast featured two use cases – in the Enterprise (Indiana University) and in the Service Provider (NTT Communications) arenas.
A typical OpenFlow Controller, or Switch as defined by the standards, would interface to the Data Plane via OpenFlow Configuration Protocol, OF-Config, (persistent across reboots) and OpenFlow Protocol (mechanism for adding and deleting flows). But OpenFlow is just a part of SDN.
In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats. – ONF Website
The goal of Cisco’s ONE Software Controller is to enable flexible, application-driven customization of network infrastructure. It includes the onePK toolkit – an SDK for developers to write custom applications to solve their business needs. So, a ONE Controller could speak to other vendor devices via the OpenFlow standard or it could speak to Cisco devices via the onePK southbound API. At least that is what the diagram shows – onePK and OpenFlow are side-by-side. However, during the webcast Q&A, it was stated that onePK is an infrastructure that includes support for multiple abstraction protocol; onePK includes Openflow. This is probably semantic.
One of the features described is network slicing. It is intended to provide more than just L2 or L3 segmentation. It is more like a form of multi-tenancy. The way it was described on the call, instead of making decision based on just ‘shortest path’, network slicing can enable the controller to differentiate based on lowest cost path, highest bandwidth path, and latency. At a demo at Cisco Live in London, latency was tweaked and the Controller was able to compute a different path accordingly.
Another feature presented by Cisco in ONE Controller is of hybrid mode SDN, in which network operators can use SDN for specific flows and traditional integrated CP/DP (i.e. classical routers or switches) for the remaining traffic
What are the ramifications of this release on the SDN ecosystem? Well, although the new open source consortium Daylight supposedly does not include Cisco onePK on Day 1, it is very likely it will be included in about six months. Cisco has announced platform support roadmaps for the Platform APIs (onePK platforms), Controller Agents, and Overlay Networks such as VXLAN Gateway. Some of these won’t be available until Q3 of this year. That sounds just about the right time for a vendor to provide an end-to-end solution for Daylight. If a pure play hardware networking vendor, such as Cisco, can provide a free open source controller, it will be able to kill the competition from many SDN startups. For example, take Floodlight, the open source OpenFlow controller that was developed by Big Switch and is sold on a freemium licensing model. If ONE Controller is given away for free, why would a customer use Floodlight?
In other words, in Daylight there is no need for Floodlights!