SDN Essentials - Part 1

What’s Software Defined Networking (SDN)?


Software Defined Networking (SDN) is a new approach to designing, building and managing networks. The basic concept is that SDN separates the network’s control (brains) and forwarding (muscle) planes to make it easier to optimize each.

In this environment, a Controller acts as the “brains,” providing an abstract, centralized view of the overall network. Through the Controller, network administrators can quickly and easily make and push out decisions on how the underlying systems (switches, routers) of the forwarding plane will handle the traffic. The most common protocol used in SDN networks to facilitate the communication between the Controller (called the Southbound API) and the switches is currently OpenFlow.

An SDN environment also uses open, application programmatic interfaces (APIs) to support all the services and applications running over the network. These APIs, commonly called Northbound APIs, facilitate innovation and enable efficient service orchestration and automation. As a result, SDN enables a network administrator to shape traffic and deploy services to address changing business needs, without having to touch each individual switch or router in the forwarding plane.

The SDN Framework

SDN is Not OpenFlow

Often people point to OpenFlow as being synonymous with SDN, but it is only a single element in the overall SDN architecture. OpenFlow is an open standard for a communications protocol that enables the control plane to interact with the forwarding plane. It must be noted that OpenFlow is not the only protocol available or in development for SDN – for example, the Open Networking Lab (ON.Lab) will soon release an open source Network OS, called ONOS.

The Benefits of SDN

With a centralized, programmable network that can automatically and dynamically address changing requirements, SDN can:

• Reduce CapEx: reducing the need to purchase purpose-built, ASIC-based networking hardware and supporting pay-as-you-grow models to eliminate wasteful overprovisioning.
• Reduce OpEX: enabling algorithm control of the network, through network elements that are increasingly programmable, that makes it easier to design, deploy, manage and scale networks. The ability to automate provisioning and orchestration not only reduces overall management time, but also the chance for human error to optimize service availability and reliability.
• Deliver Agility and Flexibility: helping organizations rapidly deploy new applications, services and infrastructure to quickly meet their changing business goals and objectives.
• Enable Innovation: enabling organizations to create new types of applications, services and business models that can create new revenue streams and more value from the network.

What is OpenFlow?

OpenFlow is considered the first software-defined networking (SDN) standard. It defines the open communications protocol in SDNs that enables the Controller to interact with the forwarding plane and make adjustments to the network, so it can better adapt to changing business requirements. With OpenFlow, entries can be added and removed to the internal flow-table of switches and potentially routers to make the network more responsive to real-time traffic demands.

Any device that would like to participate in this environment must support OpenFlow with a standardized interface. This interface exposes the internal workings of the device, which enables the Controller to push down changes to the flow-table. Once the devices are OpenFlow-enabled, network administrators can use them to partition traffic, control flows for optimal performance, and start testing new configurations and applications.

Flow-Table Entries that can be Manipulated in an OpenFlow Switch

OpenFlow Message Samples

There are a variety of Messages that OpenFlow can relay between the Switch and the Controller. They include:

• Messages sent from the Controller to the Switch – initiated by the Controller to manage or inspect the state of the switch. These messages may contain information on “Features,” “Configuration,” “Modify-State,” “Read-State,” “Packet-Out,” or “Barrier.”
• Asynchronous messages – sent from the switch to the Controller without the Controller initiating the request. These messages may contain information on “Packet-In,” “Flow-Removed,” “Port Status,” or “Error.”
• Symmetric messages – that are not initiated by either the Controller or the switch, but are a part of a vibrant SDN environment. These messages may include “Hello,” “Echo,” or “Experimenter,” information.

History of OpenFlow

The OpenFlow concept originated in 2008 at Stanford. Version 1.0 of the OpenFlow Switch specification was released in December of 2009. Since that time, it has gone through multiple revisions, with the latest released in April of 2013.

The specifications cover the components and basic functions of the switch and the way the OpenFlow protocol will manage it via the Controller.  OpenFlow is currently being driven by the Open Networking Foundation (ONF).

Since its release, multiple companies have announced OpenFlow support.  While OpenFlow is the most well-known of SDN Protocols, it is not the only one available or in development – for example, the Open Networking Lab (ON.Lab) will soon release an open source Network OS, called ONOS.



What are SDN Controllers?

An SDN Controller in a software-defined network (SDN) is the “brains” of the network. It is the strategic control point in the SDN network, relaying information to the switches/routers ‘below’ (via southbound APIs) and the applications and business logic ‘above’ (via northbound APIs).  Recently, as organizations deploy more SDN networks, the Controllers have been tasked with federating between SDN Controller domains, using common application interfaces, such as OpenFlow and open virtual switch database (OVSDB).

An SDN Controller platform typically contains a collection of “pluggable” modules that can perform different network tasks. Some of the basic tasks including inventorying what devices are within the network and the capabilities of each, gathering network statistics, etc. Extensions can be inserted that enhance the functionality and support more advanced capabilities, such as running algorithms to perform analytics and orchestrating new rules throughout the network.

Two of the most well-known protocols used by SDN Controllers to communicate with the switches/routers is OpenFlow and OVSDB. Others protocols that could be used by an SDN Controller is YANG or NetConf. Other SDN Controller protocols are being developed, while more established networking protocols are finding ways to run in an SDN environment. For example, the Internet Engineering Task Force (IETF) working group – the Interface to the Routing System (i2rs) – is developing an SDN standard that enables an SDN Controller to leverage proven, traditional protocols, such as OSPF, MPLS, BGP, and IS-IS.

The type of protocols supported can influence the overall architecture of the network – for example, while OpenFlow attempts to completely centralize packet-forwarding decisions, i2rs splits the decision making by leveraging traditional routing protocols to execute distributed routing and allowing applications to modify routing decisions.

A Little History

A current battle is raging between networking vendors, who want to provide their own SDN Controllers to orchestrate their own equipment (and potentially other vendors’ networking equipment), and Open Source Controllers designed for all vendors to support.

The first SDN Controller was NOX, which was initially developed by Nicira Neworks, alongside OpenFlow. In 2008, Nicira Networks (acquired by VMWare) donated NOX to the SDN community (it was open sourced), where it has become the basis for many subsequent SDN Controller solutions. Nicira then went on to co-develop ONIX with NTT and Google; ONIX is the base for the Nicira/VMware Controller and rumored to be the base for the Google WAN Controller. While ONIX was originally supposed to be opened up, the parties later decided not to make it Open Source.

There are, however, a variety of Open Source Controllers under development, from POX to Beacon, which is one of the most popular. Started in early 2010, Beacon is a Java-based OpenFlow Controller licensed under a combination of the GPL v2 license and the Stanford University FOSS License Exception v1.0. Other SDN Controllers of note include Trema (Ruby-based from NEC), as well as Ryu (supported by NTT). You can see a full list of Open Source projects here.

Floodlight was forked from Beacon – it was made available under an Apache 2.0 license and formed the basis of one of the early commercial Controllers from Big Switch Networks. Note, NEC’s ProgrammableFlow Controller was actually the first commercial SDN Controller on the market, and it was NOT derivative of any of the Open Source Controllers.

Subsequently, vendors, such as Cisco, HP, IBM, VMWare and Juniper have jumped into the SDN Controller market with their own offerings. The original HP, Cisco, and IBM Controllers are all based off Beacon, and now have moved toward OpenDaylight. Juniper SDN Controller became a part of their product portfolio when they acquired Contrail; it is available in both Open Source and commercial versions.

OpenDaylight SDN Controllers

On April 8, 2013, the open-source foundation, OpenDaylight, which is part of the Linux Foundation, was announced. This Controller is Java-based, and derived from the original Beacon design. It supports OpenFlow and other southbound APIs (such as Cisco OpFlex) and includes critical features, such as high-availability and clustering.

An OpenDaylight Controller is implemented solely in software and is kept within its own Java Virtual Machine (JVM), but it can be deployed in a variety of production network environments. In conjunction with its SDN Controller, OpenDaylight Project released its first code, Hydrogen, which offered three different editions for users. In September 2014, OpenDaylight Project unveiled its second code release, Helium. Both code releases are open frameworks for network programmability to enable SDN for any size networks. Companies like Cisco and Brocade are shipping their own OpenDaylight Controllers, including Cisco’s Hydrogen-based Extensible Network Controller and Brocade’s Helium-based Vyatta Controller. Extreme Networks has also said it will release an SDN Controller under OpenDaylight software.

As a challenge to OpenDaylight Controllers, On.Lab created the Open Networking Operating System (ONOS) Controller to be open sourced, but it hasn’t been. Companies supporting it include AT&T, Microsoft, HP, Ericsson, NTT, Ciena and Extreme Networks.