Cisco's ONE Controller Debuts; Targets SDN
February 04, 2013
Cisco today announced details about its Open Network Environment (ONE) Controller, a keystone in Cisco's software-defined networking (SDN) architecture. The ONE Controller is a software platform that serves as an interface between network hardware in one direction (southbound) and third-party applications (northbound).
Cisco says its controller will support both the OpenFlow protocol and a set of proprietary APIs, a package it calls the One Platform Kit (onePK), which contains hundreds of APIs to expose existing features and capabilities within Cisco's switches and routers. Cisco says the new controller will ship in the first half of 2013.
- Smarter Process: Five Ways to Make Your Day-to-Day Operations Better, Faster and More Measurable
- Bring Salesforce.com Alive with Your Key Business Processes: Register Now
- Virtualization and Cloud Computing : Optimized Power, Cooling, and Management Maximizes Benefits
- Part 1 Whitepaper - Why Use Big Data for Cyber Security? A Practical Guide Big Data Security Analytics
Cisco has been slower to market with an SDN controller than traditional competitors such as IBM and NEC, both of which have released controller products. HP and Juniper have also announced, but not shipped, their own controllers.
There are several reasons for Cisco's slow pace. The simple fact is that while the SDN movement has generated a significant amount of discussion, it has yet to generate any significant customer demand. For another, Cisco has dominated the market for decade with autonomous networking, so it's easy to assume the company is assuring current profits by resisting change.
Cisco also announced three applications for the controller. If you have been following the OpenFlow/SDN discussion, you won't be surprised by the applications that Cisco offers, which are similar to those offered or announced by other vendors such as HP and Big Switch Networks.
1. Network Slicing: This application uses dynamic network provisioning to "carve" new pathways out of existing networks; it's most commonly associated with multitenant networks.
2. Network Tapping: This application uses flow-based network matching to duplicate traffic for external monitoring, and is similar to Big Switch's Big Tap product.
3. Custom Forwarding: As with Network Slicing, Custom Forwarding applies specific modifications to selected traffic, such as setting dynamic QoS policies or manual path selections.
Cisco says these applications are in use today by customers building proof-of-concept networks, suggesting that Cisco wants us to know these are real applications, not just announcements.
Controller support within the Cisco hardware product range is very limited. Only the ASR 1000 and ISR G2 routers and the Nexus 3000 will get onePK support in the first half of this year. OpenFlow support will be limited to the Catalyst 3000 (that is, not Cisco silicon). However, software devices such as the CSR1000V and Nexus 1000V get early support.
Much of the value in a centralized controller-based SDN architecture comes from a controller's northbound APIs, which allow applications to communicate with the controller and request network services. Cisco has announced REST and Java-based northbound APIs for its controller.
Previously, Cisco stated its intention to "meet developers wherever they are" and offer APIs once standards and market consensus had been reached. However, developers are also looking to Cisco to commit to a platform before the developers put resources to development projects. The announcement of northbound APIs from Cisco may be the commitment developers need. Cisco claims that its ONE Controller is the "industry's most extensible controller architecture," indicating APIs will certainly change and Cisco plans to be ready for those changes.
Today there are no standards for northbound APIs, though there has been talk of efforts. Recently, I received a tip that HP, IBM and Cisco may be setting up a consortium to build consensus and direction for northbound APIs. That the Open Networking Foundation, which oversees OpenFlow standards, hasn't been able to get organized is disappointing. That said, standards can be built in many ways, and a joint effort among vendors with transparent and open processes could work equally well for customers.
Next Page: Controller Commitment Issues