Interop 2014: News and trends from the Interop conference
A comprehensive collection of articles, videos and more, hand-picked by our editors
LAS VEGAS -- Cisco unveiled a new southbound SDN protocol based on its Application Centric Infrastructure products at Interop. It will submit the technology to the IETF for standardization.
Like OpenFlow, Cisco's OpFlex protocol is designed for communications between a central controller and network devices, but its scope is very different. While OpenFlow SDN centralizes the network control plane on a controller, OpFlex-based SDN only centralizes policy control. It relies on traditional, distributed network control protocols to finish the job.
The SDN control plane: Imperative versus declarative
Cisco claims there are two types of SDN control planes: imperative and declarative. A declarative control plane makes all the decisions about how traffic will traverse the network. Cisco likens an imperative control plane to an airport baggage handling system, where all the intelligence is centralized. Baggage handlers see codes on luggage and know which conveyor belt to drop it on.
A declarative control plane allows for more distributed intelligence. It sets central policies, but it allows network nodes to make more decisions about how to execute those policies. Cisco likens this to an airport control tower. The tower tells a jet to land and the pilots do the rest.
While OpenFlow is designed for an imperative control plane, Cisco said OpFlex serves a declarative control plane, such as the one relied upon by its Application Centric Infrastructure (ACI), which comprises Cisco's new Nexus 9000 switch family and its Application Policy Infrastructure Controller (APIC).
OpFlex serves Cisco's claim that complete centralization of the control plane in SDN doesn't scale, said Bob Laliberte, senior analyst with Milford, Mass.-based Enterprise Strategy Group. "Cisco's approach is to centralize policy but distribute intelligence and control. OpenFlow keeps adding versions and setting up labs that test and push the scalability [of an imperative control plane]. But other people [believe] we should go with a little bit of distributed control."
OpFlex helps take declarative statements from APIC policy control and interprets them at the switch layer, said Brad Casemore, research director for Framingham, Mass.-based IDC.
"You need a switch that's capable of doing that interpretation. That means a switch needs intelligence. Cisco is betting that this model will support how [it has] built [its] business until now."
OpFlex is an extensible protocol that uses "abstract, rather than device-specific, policies; … definitions that are [written in] XML or JSON," said Mike Cohen, director of product management for Cisco. "The goal is to support devices, including virtual switches, physical switches and network services."
OpFlex implementation: Pushing beyond a Cisco-only network
To participate in an OpFlex-based network, hardware and software vendors will have to implement an OpFlex agent on their platforms. Cisco is building an open source OpFlex agent for Open vSwitch as a reference architecture. "The agent will be able to speak policy and have a platform layer that can attach to different devices. It will be reusable across devices," Cohen said.
Cisco is also working with OpenDaylight to build open source OpFlex interfaces for its controller, as well as a group policy application programming interface (API). IBM, Plexxi and Midokura are also contributing to this work on top of OpenDaylight, Cohen said.
"The goal is to continue to evolve the concept of policy in the open source community and maintain compatibility with what we're doing with APIC and ACI," he said.
OpFlex opens ACI to a wider array of network services partners Cisco's Nexus 9000 switches are both hardware- and software-engineered to work within an ACI implementation. Several infrastructure companies committed to integrating their own products with ACI when Cisco announced it last November.
"I think there was an API that existing ACI partners had written to that was a little bit more lightweight," Laliberte said. "OpFlex will be a little bit more effort [for partners], but it will provide great policy benefits."
OpFlex broadens that potential integration beyond the partner ecosystem. Any company could theoretically adopt OpFlex to allow its products to participate in ACI. Several ACI partners have already committed to supporting OpFlex on their products, including F5 Networks, Citrix, Microsoft, IBM, Red Hat, Canonical and Embrane.
OpFlex will also provide a path for the rest of its Nexus switches to participate in ACI, which answers complaints from many customers who are concerned about investment protection for the Nexus 7000 and 7700.
The Nexus 1000v virtual switch will support OpFlex early on. Its SourceFire security appliances will also get early OpFlex support. Cisco will add Nexus 7000 support and ASR-9000 support to "configure tenant behaviors on them and how they interact with a WAN environment," Cohen said. "We're looking at bringing it to the rest of the Nexus switching line, as well."
"The really interesting dynamic will be about this application policy and how it's conveyed to the whole infrastructure, not just the switches, but compute and storage, as well," Casemore said. "This will be the bigger story."
Cisco has always hinted that the policy control model of ACI would mirror and converge with the infrastructure management and orchestration innovations it introduced in its server products, the Unified Compute System (UCS). Over time, OpFlex will integrate with UCS, Laliberte said.
"That's a pretty powerful story," he said. "You've got this ability to automate and deliver that level of control for applications through server, storage and network across virtual and physical environments."
Cisco will demonstrate OpFlex at Interop this week. It will release a free and open source implementation of OpFlex in the third quarter of 2014.