SDxCentral
Join Log In
SD-WAN 5G Edge 1 IoT SDN NFV Containers Cloud Security AI Data Center Storage APM/NPM Open Source

Log In to SDxCentral

Log in with your email? Forgot your password?
  • Newsletters
  • eBriefs
  • Podcasts
  • Webinars
  • Videos
  • Directory
  • White Papers
  • Resources
  • Use Cases
  • Support

Join SDxCentral and get information tailored to your particular interests everyday.

Join
Sponsored:
Dell EMC Citrix Riverbed

Networking > SDN > SDN Definitions > What is Cisco OpenFlow?

What is Cisco OpenFlow?

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.

What is Cisco OpenFlow?

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.

Related Definitions

What is an OpenFlow Controller?
SDxCentral Daily News

Join your Peers! Subscribe to SDxCentral's Newsletter

Subscribe to Get the Daily News!

Related Definitions

  • What is Intent-Based Networking?
  • What is Software Defined Networking (SDN)? Definition
  • What Is an Operations Support System (OSS)? Definition
  • What is a Spine Switch?
  • What are Leaf Switches?
  • What is Software Defined Compute? - Definition
  • What is the Software Driven Cloud Networking?
  • What is SDN Orchestration (SDN Policy Orchestration)?
  • Understanding the SDN Architecture - SDN Control Plane & SDN Data Plane
  • Software-Defined Networking Tutorial - The Basics
  • What Is Cisco Application Centric Infrastructure (or Cisco ACI or Cisco SDN)? Part 1
  • What is the OpenDaylight Project (ODL)?
  • What are SDN Northbound APIs (and SDN Rest APIs)?
  • What are SDN Southbound APIs?
  • What are SDN Controllers (or SDN Controllers Platforms)?

About SDxCentral

  • Newsletters
  • About Us
  • Contact Us
  • Work With Us
  • Editorial Team
  • Careers
  • Legal
  • Support

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDxCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.

© 2012-2019 SDxCentral, LLC, All Rights Reserved. SDNCentral™, the SDNCentral logo, SDxCentral™, SDxCentral logo, SDxNews™, SDxTech™, SDx™, the SDx logo, and DemoFriday™ are trademarks of SDxCentral, LLC in the U.S. and other countries.

  • Terms of Service
  • Privacy