SDN Essentials - Part 3

Click Here for SDN Essentials - Part 1

Click Here for SDN Essentials - Part 2


What is Cisco OpenFlow?


Considered the first software-defined networking (SDN) standard, OpenFlow is 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.

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 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.

OpenFlow supports an Imperative control plane, with no control/intelligence embedded in the data path; rather the controller provides all the instructions to the switches/routers and tells them how to move packets.

• Declarative describes a model where the 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.

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.

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.

How OpenFlow Works

Traditionally, switches/routers are responsible for both the high-level decisions (control) on the route each packet will take, as well as the actual forwarding (data path) of that packet to its next destination. In an SDN environment, the high-level decisions are moved into a separate controller and OpenFlow is used to communicate those decisions to the switches/routers to execute.

The switches/routers maintain a flow table that tells them how they should handle different types of packets (e.g. matching rules and actions to specific traffic). When the switch/router receives a packet type it hasn’t seen before, it will communicate with the Controller, via OpenFlow, to get a decision on how it should be handled. The Controller can make decisions ad hoc on how different packets should be handled; it may modify, remove or push out new rules to the flow table (with a configurable lifespan).

The Differences Between Cisco OpenFlow and OpFlex

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.

One of the big advantages of OpenFlow is the level of control it offers developers of network control software, which promotes rapid service introduction and customization. Network operators can implement features they want in software they control, rather than having to collaborate with a vendor to put a plan into motion. These benefits are part of OpenFlow’s rapid growth and status as a SDN standard.

However, OpenFlow limits a 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 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 controller, supporting greater resiliency, availability, and scalability.


What is Cisco OpFlex?

Cisco OpFlex is a southbound protocol in a software-defined network (SDN) designed to facilitate the communications between the SDN Controller and the infrastructure (switches and routers). The goal is to create a standard that enables policies to be applied across physical and virtual switches/routers in a multi-vendor environment.

Overview of Cisco OpFlex

On the surface, Cisco OpFlex sounds a lot like OpenFlow, an open standard that enables the Controller to interact with the infrastructure, however, it is quite different in terms of the scope of its capabilities. While OpenFlow centralizes all the network control functions on the SDN controller, Cisco OpFlex focuses primarily on the policies. The creators of OpFlex believe this focus will remove the potential for the controller to become the bottleneck of the network, supporting greater resiliency, availability and scalability, by pushing some of the intelligence out to the devices, using established networking protocols.

Basically, policies are defined within a logical, centralized policy repository in the controller, and the OpFlex protocol is used to communicate and enforce those policies within a set of distributed policy elements on the switches/routers/etc. The protocol allows bidirectional communication of policy, events, statistics and fault information, so potential adjustments can be made to address changes in the environment.

To work, an OpFlex agent must be embedded in the switches/routers/etc. to support the Cisco OpFlex protocol. As a result, Cisco is working on an open source OpFlex agent that can be used across platforms. Microsoft, IBM, F5, Citrix, RedHat, Canonical, Embrane and AVI Networks have already committed to embedding this agent in their solutions.

In April of 2014, Cisco submitted OpFlex to the Internet Engineering Task Force (IETF) standardization process. Several industry leaders are actively working with Cisco on the standardization process, including Microsoft, IBM, Citrix, and SunGard Availability Services to increase adoption and accelerate innovation with the Cisco OpFlex protocol.


What is the Cisco ONE Controller?

What is the Cisco ONE Controller?

Companies are adopting cloud, mobility, and social networking initiatives to take advantage of the agility, scale and efficiencies they can provide. In order to effectively roll out many of these new applications and services to create a better user experience and increase employee productivity, there needs to be stronger connections between the application software and network infrastructure.  It’s this need that has driven the need for software-defined networking (SDN).  Having a programmable network can help streamline management tasks, while optimizing network actions for applications running on shared infrastructures.

The Cisco Open Network Environment (ONE) is a programmable framework that allows users to customize and hone the value of a more intelligent network and is key component of Cisco SDN Strategies.  The Cisco vision for ONE is being folded into Cisco’s Application Centric Infrastructure (ACI) strategy and nomenclature.  Cisco ONE was a keystone advance in Cisco’s software-defined networking (SDN) model, and is made up of three components as part of a multi-faceted approach:

• Controllers and agents: a production-ready OpenFlow controller and OpenFlow agent.
• Programmatic Interfaces: a strong collection of application programming interfaces (APIs) that are exposed directly on switches/routers to support existing OpenFlow requirements.
• Virtual network overlays: a suite of products that delivers virtual overlays, virtual services, and resource orchestration capabilities in the data center.

The Cisco ONE Controller was released in 2013, representing a major milestone in Cisco’s execution and delivery of the ONE framework. It’s a software package that acts as an interface between northbound and southbound APIs. It supports the SDN-standard OpenFlow.

 Cisco’s ONE Controller Use Flow Chart

Cisco ONE Controller customers can use the hundreds of APIs, in Cisco’s One Platform Kit (onePK), to access the data inside their network. OnePK exposes existing features and capabilities within Cisco’s switches and routers. It can integrate with PyCharm, PyDev, Eclipse, IDLE, NetBeans, among others, and support languages such as Java and Python.

When released, Cisco announced three applications for the Cisco ONE Controller:

• Network slicing: most often linked with multi-tenant networks, which allow a single instance of the software to run on a server for multiple distinct customers, the Controller can slice the network to “carve” new, separate pathways,

• Network tapping: similar to Big Switch’s Big Tap product, the ONE Controller uses flow-based network matching to recreate traffic for external monitoring,

• Custom forwarding: applies specific changes to selected traffic, such as setting dynamic quality of service (QoS) policies or manual path selections.

Cisco describes the ONE Controller as unlike other OpenFlow Controllers because it delivers many production ready capabilities, including troubleshooting features, role-based access control, and topology-independent forwarding.

What is a Cisco Nexus Switch?

Resources in the data center can be scattered and silo’d, making it an incredibly complex environment that is time consuming to manage and maintain and difficult to alter and scale to meet changing needs. The network simply hasn’t kept up – as compute and storage architectures are increasingly virtualized, enabling services to be rapidly added to the network and scaled, administrators are struggling to ensure the network is able to match the flexibility of the environment.

Software-defined networking (SDN) is designed to alleviate some of these issues by centralizing the control of the network in software to enable network services to be quickly and simply deployed to match a rapidly changing, highly virtualized environment. There are a variety of solutions on the market designed to support this virtualized data center.

The Cisco Nexus Switch product line provide a series of solutions that attempt to make it easier to connect and manage all these disparate data center resources. Leveraging the Cisco Unified Fabric, which unifies storage, data and networking (Ethernet/IP) services, the Nexus Switches create an open, programmable network foundation built to support a virtualized data center environment.

First announced in January 2008, the Unified Fabric of the Nexus Switches was designed to provide all servers with access to all network and storage resources, while eliminating the need for parallel storage and computational networks. The objective was to simplify deployments and ensure consistent networking across physical, virtual, and cloud environments to deliver:

• Business and IT Agility: flexible, highly available fabric that supports dynamic resource allocation, changing traffic patterns, complex workloads, and scalability within and across data centers.
• Simplified Operations: consistent policies and services that are built directly into the fabric and aware of the virtualized environment simplify the delivery and management of network functions in converged, virtualized and cloud environments.
• Efficiencies: consolidated, multi-protocol solutions, with a single point of management for the LANs and SANs, minimizes disruptions to existing infrastructure and operations.

All switches in the Nexus range run the modular NX-OS firmware and operating system. Building on Cisco’s IOS, NX-OS combines the company’s storage area network (SAN) OS from its SAN switching lines with its IOS routing code. This modular design allows for fault containment and automatic recovery, so processes can be started, stopped, and upgraded, even without human intervention.

Nexus Switches provide a quick and dependable switching infrastructure aimed at giving users the high performance needed for the virtualized environment in next-generation data centers. They offer continuous system operations and transport freedom, I/O consolidation, as well as the delivery of advanced networking capabilities, such as high availability, hitless In-Service Software Upgrades (ISSU), etc.

Design and Architecture of Next-Generation Data Center with Cisco Nexus Switches

Cisco Nexus Switch Series At-a-Glance

The Cisco Nexus 3000 Series Switch is advertised to deliver a comprehensive SDN solution, including support for OpenFlow and Cisco OnePK. The Nexus 3000 is a foundational component of Cisco’s Open Network Environment (ONE) designed to help networks become more open, programmable and application-aware.It offers flexibility, high density and performance for top-of-rack deployments, supporting mobility and tenant isolation with VXLAN. [NOTE- ONE is being folded into Cisco’s Application Centric Infrastructure (ACI) strategy and nomenclature.]

The newest in the line of Nexus Switch is the 9000 series has been introduced to provide the switching foundation for Cisco’s Application Centric Infrastructure (ACI). The ACI architecture is designed to “allow applications to guide networking behavior, using predefined application policies that automate the provisioning of the network, application services, security policies, tenant subnets and workload placement.” NOTE- ONE is being folded into Cisco’s Application Centric Infrastructure (ACI) strategy and nomenclature.

Below is a quick look at the different Nexus Series and their optimal use case:

Evolution of Nexus Switches

What is the OpenDaylight Project?

What is the OpenDaylight Project?


Announced in April 2013, the OpenDaylight Project, hosted by the Linux Foundation, was created in order to advance software-defined networking (SDN) adoption and create the basis for a strong network functions virtualization (NFV). It was created as a community-led and industry-supported open source framework. The aim of the OpenDaylight Project is to offer a functional SDN platform that gives users directly deployed SDN without the need for other components. In addition to this, contributors and vendors can deliver add-ons and other pieces that will offer more value to OpenDaylight.

Although the Linux Foundation hosts the OpenDaylight Project, it doesn’t only run on Linux platforms. It is licensed under the Eclipse Public License (EPL), often chosen for Java-based projects. Using EPL allows OpenDaylight to increase its compatibility with the expansive environment of libraries and third-party components that already have been released under the EPL license. The EPL is an approved open source license, and according to the Free Software Foundation, is a free software license.

OpenDaylight Technical Overview

In February 2014, OpenDaylight announced “Hydrogen,” its first code release. It is made up of 15 projects, all siphoned off into three different editions. The Base Edition of consists of the OpenDaylight Controller (an SDN Controller) and simple functionally to test it — in a nutshell, it’s what everyone needs in order to use OpenDaylight. Upon the release of Hydrogen, developers were already looking toward the next code release: Helium.

Founding members included Arista Networks, Big Switch Networks, Brocade, Cisco, Citrix, Ericsson, HP, IBM, Juniper Networks, Microsoft, NEC, Nuage Networks, PLUMGrid, Red Hat, and VMware. Initial members donated the resources necessary to help create an open source network of groups focused on moving the SDN platform forward. Membership in the OpenDaylight Project now consists of three tiers — Platinum, Gold, and Silver — that all offer different amounts of contribution. Platinum members must commit 10 developers to the project, with only three developers from Gold members.

Despite its founding members, OpenDaylight doesn’t have a single company or group of companies that “lead” the project. Instead, it operates through an open, active community that is available for anyone to join. Requirement for joining is to contribute to the openness of the community, therefore, those who join offer assistance in a variety of areas — from coding to Board of Directors leadership. The latter manages the business aspect of the OpenDaylight, including marketing and operational decisions. There is no monetary requirement to be a part of the OpenDaylight Project.

The Technical Steering Committee (TSC) handles oversight of design and development activities of the OpenDaylight Project. The TSC is also in charge of release dates, release quality standards, technical best practices, monitoring technical progress, meditating technical conflicts between contributors and project leads, as well as managing inter-project collaboration. Anyone who can develop and contribute code can be elected to the TSC, and subsequently voted onto the Board. This allows for contributors with vision to make their mark on the OpenDaylight Project.

OpenDaylight utilizes the open standards that are currently in place, thanks to working with leaders like the Open Networking Foundation (ONF). OpenFlow is a primary example of a SDN protocol supported by OpenDaylight, and as new products are created in the future, the OpenDaylight Project will undertake those standards as well. There is a common understanding within the industry that while OpenFlow is beneficial in several scenarios, SDN is not only OpenFlow or any other single protocol. Therefore, the OpenDaylight Project is intended to configure several SDN interfaces, including, but not limited to, OpenFlow.