[Note: This is the first of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not.  Part 2 | Part 3 | Part 4]| Part 3 | Part 4]

IT departments and lines of business are looking at cloud automation tools and software-defined networking (SDN) architectures to accelerate application delivery, reduce operating costs, and increase business agility. The success of an IT or cloud automation solution depends largely on the business policies that can be carried out by the infrastructure through the SDN architecture.

Through a detailed comparison of critical architectural components, this blog series shows how the Cisco Application Centric Infrastructure (ACI) architecture supports a more business-relevant application policy language, greater scalability through a distributed enforcement system rather than centralized control, and greater network visibility than alternative software overlay solutions or traditional SDN designs.

Historically, IT departments have sought out greater automation as device proliferation has accelerated to overcome the challenges of applying manual processes for critical tasks. About 20 years ago the automation of desktop and PC management was an imperative, and about 10 years ago server automation became important as applications migrated to larger numbers of modular x86 and RISC-based systems. Today, with the consolidation of data centers, IT must address not only application and data proliferation, but also the emergence of large scale application virtualization and cloud deployments, requiring IT to focus on cloud and network automation.

The emergence of SDN promised a new era of centrally managed, software-based automation tools that could accelerate network management, optimization, and remediation. Gartner has defined SDN as "a new approach to designing, building and operating networks that focuses on delivering business agility while lowering capital and operational costs." (Source: "Ending the Confusion About Software-Defined Networking: A Taxonomy", Gartner, March 2013)

Furthermore, Gartner, in an early 2014 report ("Mainstream Organizations Should Prepare for SDN Now", Gartner, March 2014), notes that "SDN is a radical new way of networking and requires senior infrastructure leaders to rethink traditional networking practices and paradigms." In this same report, Gartner makes an initial comparison of mainstream SDN solutions that are emerging, including VMware NSX, and Cisco ACI. There has been some discussion whether Cisco ACI is an SDN solution or something more, but most agree that, in a broad sense, the IT automation objectives of SDN and Cisco ACI are basically the same, and some of the baseline architectural features, including a central policy controller, programmable devices, and use of overlay networks, lead to a useful comparison.

This blog series focuses on the way that Cisco ACI expands traditional SDN methodology with a new application-centric policy model. It specifically compares critical protocols and components in Cisco ACI with VMware NSX to show the advantages of Cisco ACI over software overlay networks and the advantages of the ACI application policy model over what has been offered by prior SDN solutions. It also discusses what the Cisco solution means for customers, the industry, and the larger SDN community.

Requirements for a Policy-Based Infrastructure Automation Solution

Businesses and IT want to deploy, scale, and optimize applications on demand, in minutes, not weeks, to increase business agility and lower operating costs. SDN and related solutions propose to accomplish this through programmatic extensions to the network, so that IT and business policies can for the first time be implemented in software, and the software can automate network administration tasks, reducing the need for manual operations. Programmatic automation of network administration also appeared initially to be the only way to achieve cloud-level scale, supporting tens of thousands of servers and millions of workloads while migrating them on-demand to optimize resource utilization.

Although traditional SDN overlay technology and the more recent Cisco ACI have important differences, both address fundamental architectural requirements for policy-based IT infrastructure automation:

• Centralized policy store and infrastructure controller: In SDN and Cisco ACI, this feature is generally known as the controller (Cisco Application Policy Infrastructure Controller [APIC] for Cisco ACI).
• Programmable, or automated, network devices: All infrastructure devices, such as servers and network nodes, must be able to respond to and implement policies according to commands from the controller. This feature may involve agents running on the device, APIs in the devices themselves, or management hooks to the devices that are implemented in the controller.
• Controller southbound protocol to communicate with the managed or controlled devices and to communicate policy information: Initially, the OpenFlow protocol was used in SDN architecture, and vendors released OpenFlow-compliant switches. In Cisco ACI, OpFlex is the primary protocol used, although other mechanisms for integrating devices into the Cisco ACI policy model are supported. For virtual overlay networks, OpenFlow has also been complemented with the Open vSwitch Database (OVSDB) management protocol to control virtual switches.
• Northbound controller interfaces for integrating higher-level automation solutions on top of the policy and controller framework, including workflow automation tools and analytics: Modern SDN controllers include northbound APIs allowing for the integration of OpenStack or other vendor-specific cloud automation tools. This document compares the capabilities allowed in the Cisco ACI policy model for these orchestration stacks to those of existing virtual overlay solutions.

With these architectural components in mind, in the next article in this series, we will look in more depth at the Cisco ACI architecture and protocols, particularly OpFlex, and see how this enables application polices, as well as comparing it to VMware's NSX protocol, OVSDB.