Cisco OpenFlow is Cisco’s implementation of OpenFlow. OpenFlow is considered the first software-defined networking (SDN) standard, as an open communications protocol in SDNs that enables the SDN Controller to interact with the forwarding plane (switches, routers, etc.) and adapt the network to be responsive to real-time traffic and business requirements.
Cisco has announced support for OpenFlow in the following Cisco products:
- ISR, ASR, Nexus, and Catalyst Product Lines – several switching/routing products that work within OpenFlow SDN environments.
- Cisco Open Network Environment (ONE) Software Controller – designed to control the network across both Cisco and non-Cisco, OpenFlow-enabled switches to streamline operations, limit costs, and provide a more agile infrastructure.
- Cisco One Platform Kit (onePK) – a package of proprietary APIs created by Cisco to enable organizations to create applications to meet their needs.
Cisco has also introduced an alternative protocol to OpenFlow, called OpFlex, which was announced at the Interop conference in April 2014. Seeing limitations in OpenFlow’s approach, Cisco created OpFlex as an alternative.
The Difference in Cisco OpenFlow and OpFlex Control Plane Approaches
There are two main approaches to the SDN control plane on the market right now – Imperative and Declarative:
- Imperative describes a centralized SDN Controller that acts as the brains for the SDN environment; the controller receives requests from applications, via a northbound application program interface (API), and dictates downstream to the forwarding plane how the switches/routers need to be configured to answer the needs of the application. There is the potential for the centralized controller to become a bottleneck and a single point of failure in the network, which different implementations attempt to address.
- Declarative describes a model where the SDN Controller declares what the application needs and sends that message to the network fabric for the switches and routers to determine how to meet the application’s requirements. A declarative control plane allows for more distributed intelligence; it sets a central policy but gives power to network nodes to make more decisions about how to execute said policies.
OpenFlow supports an Imperative control plane, with no control/intelligence embedded in the data path. Instead, the SDN Controller provides all the instructions to the switches/routers and tells them how to move packets. OpFlex supports a Declarative control plane, focusing on centralizing the policy and then pushing out some of the intelligence to the data path. Cisco’s Application Centric Infrastructure (ACI) and Application Policy Infrastructure Controller (APIC) support this approach.
Like OpenFlow, OpFlex is designed for communications between a central controller and network devices but has a different way of distributing the message. While OpenFlow centralizes the network control plane on a controller and can push commands down to OpenFlow enabled network devices. OpFlex centralizes policy control and relies on traditional and distributed network control protocols to push commands down.
Cisco’s Conflicted View of OpenFlow
Cisco has had a back and forth relationship with OpenFlow, in part due to the dynamic SDN environment and the changing needs of users, working to support both OpenFlow and alternatives.
However, OpenFlow limits an SDN Controller’s ability to verify that switch flow tables are configured within the expected rules. Because of the centralized nature of OpenFlow, special care must also be taken to avoid denial of service (DoS) in applications.
OpFlex may reduce the potential for the SDN Controller to become the bottleneck of the network. The idea is that by pushing out some of the intelligence to the devices, the network can sustain itself if something happens to the SDN Controller, supporting greater resiliency, availability, and scalability.