Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.

A Guide To Software Defined Networking (SDN) Solutions

A Guide To Software Defined Networking (SDN) Solutions

This article takes a brief look at how SDN has evolved over the last several years, what it is today and what the available SDN controller are.

Few things have received more press over the last couple of years in the networking arena than software defined networking (SDN). Just like cloud computing, SDN can mean a number of different things, and because it is still so new, the technology is evolving very quickly. 

Software Defined Networking: What It Is And Isn't

The SDN movement as it currently exists is an evolution that started with a basic idea: How do we make the configuration and management of a network quicker and easier. Many large companies have gotten used to a very long provision time between an initial request and a service actually being deployed; typically in terms of days and months not minutes and hours. The simplest definition of what SDN is begins with the separation of the network planes that a device lives on.

Traditionally, a network device can be separated into three different planes:

  • The control plane is responsible for making the decisions as to how a specific packet is handled (for example, should it be forwarded? If so, via which port?). This is commonly done on traditional devices with static routes or via dynamic routing protocols.
  • The management plane is responsible for the management of a device; an example of this would be using telnet or SSH to connect to a device that is then managed through the CLI.
  • The data plane is where the bulk of the device's activity is completed; this includes the actual forwarding of data in a specific port and out a specific port based on a forwarding table or base (FIB).
MORE: Software Defined Networking: Introduction to OpenFlow
MORE: Building A Business Case For Network Virtualization

An example of where the data and control planes exist in a traditional network is shown on the left side of Figure 1 below.

Figure 1: Traditional networking vs software defined networking. Image courtesy of 1: Traditional networking vs software defined networking. Image courtesy of

In SDN architecture there is an abstraction of the control plane from the actual deployed device. This control plane is then placed at a central controller (sometimes a distributed-central controller). The controller is responsible for building the forwarding base and figuring out how a packet should be forwarded through a network. The SDN controller then takes this information and places it in a forwarding table or flow table on the device.

The deployed networking hardware is simply a "dumb" device that is responsible for following the instructions that exist in the table determined by the SDN controller. This separation of the data and control planes is shown on the right side of Figure 1 above. This allows the deployed equipment (routers and/or switches) to be comparable to the devices that are currently deployed in most networks, which reduces the cost of deploying and expanding a network. The management plane is typically left on the device itself so that it is able to be managed mainly for troubleshooting and initial configuration.

  • Southbound API

The interaction between the controller and the deployed device is commonly referred to as southbound application programing interface (API). A common, open standard SDN protocol, and one of the most popular options for southbound APIs is OpenFlow. 

OpenFlow is one option that is commonly used to send commands from the controller to the deployed device. It is not the only protocol available (for example, Cisco's OpFlex actually supplements OpenFlow) but it is the most referenced and the one that has really peaked the interest of the wider networking community. 

  • Northbound API

The opposite of the southbound API is the northbound API, which is labeled in Figure 1 as just API; it involves the communications from a business application to the controller. This is the point where the real meat and potatoes exists for SDN. Anybody with basic knowledge of programming can create an SDN application. The SDN application itself can be written to perform a very large set of potential activities; the most basic of which could be to tell a deployed device to forward a packet with a matching set of contents out a specific interface.

However, the northbound API can be very complex, like providing a Quality of Service provisioned path from one end of a network to another dynamically, then tearing it back down when the application was completed with its network interaction. Another common example would be a firewall or Intrusion Protection System (IPS) application which performs the traditional functions of these hardware devices completely in software and uses the controller to perform the appropriate action on the deployed device.

Network Virtualization And Network Functions Virtualization

Network Virtualization (NV) and Network Functions Virtualization (NFV) are two related technologies within the SDN space.

Network Virtualization is a term that is commonly seen coming from virtualization vendors like VMware, where the technology itself is not dependent at all on physical devices. The easiest way to think about NV is to apply it to the networking equivalent of a virtual machine (VM). A VM is a software abstraction of the functions that use to be associated with a physical machine. In NV, the virtual switch would become an abstraction of a physical switch; the hardware at this point would not be relevant or required depending on the deployment.

Network Functions Virtualization is a term that is used in the carrier space to reference a close to parallel vision to SDN, with the focus being on reducing the deployment costs of services. Instead of relying on a physical hardware appliance to provide a specific function, it would abstract this function to a generic server platform. SDN and NFV are close in their ideas, but have evolved through different paths. SDN evolved through academia and is currently focused mostly on data centers (specifically in the enterprise), while NFV focuses on the provider space.

There is certainly a lot of movement in the SDN market and many different vendors and open source projects are deploying their own vision of what the technology should look like and how it should be implemented. Each SDN vendor of course has its own motives to support a specific vision, and this will be in-line with what best fits into its existing customer bases and major profit centers.

The next page examines SDN solutions, both commercial and open source options that exist today and how they differ in terms of targeting and focus.

Software Defined Networking (SDN) Controllers

Let's take a closer look at some open source as well as commercial software defined networking solutions. Because there is still a lot of flux within the networking community about what role SDN plays and how it should be implemented, we won't compare the SDN solutions. However, we will review some of the more popular free and paid options that are available today and what their place is within the technology.

Open Source SDN Controllers

Open standards are a key component of SDN architecture, and open source SDN controllers have evolved over the years.

  • NOX

There are a large number of open source SDN controllers that have been available for some time. The first highly popular OpenFlow controller was NOX. As with most early technology implementations, it was the initial spark, but it was not heavily implemented or used because of shortcomings with its implementation and development environment; a lot of this had to do with NOX being programmed primarily in C++ and the lack of good documentation.

  • POX

NOX's successor, POX, was built as a friendlier alternative and has been used and implemented by a number of SDN developers and engineers. Compared to NOX, POX has an easier development environment to work with and a reasonably well written API and documentation. It also provides a web based GUI and is written in Python, which typically shortens its experimental and developmental cycles.

  • Beacon

The next big step in open source controllers came with Beacon. Beacon is a very well written and organized SDN controller written in Java and highly integrated into the Eclipse IDE. Beacon was the first controller that made it possible for beginner programmers to work with and create a working SND environment, however it was limited to star topologies (no loops).

  • Floodlight

Next came Floodlight, a fork off of Beacon that is managed by Big Switch Networks. While its beginning was based on Beacon it was built using Apache Ant which is a very popular software build tool that makes the development of Floodlight easier and more flexible. Floodlight has a very active community and has a large number of features that can be added to create a system that best meets the requirements of a specific organization. Both a web based and Java based GUI are available and most of its functionality is exposed through a REST API.

  • OpenDaylight

OpenDaylight is a Linux Foundation collaborative project that has been highly supported by Cisco, Big Switch, and several other networking companies. Like Floodlight, OpenDaylight is written in Java and is a popular, well-supported SDN controller. It also includes exposure with a REST API and a web based GUI. The second release of OpenDaylight (Helium) includes support for SDN, NV (Network Virtualization) and NFV (Network Functions Virtualization) and is intended to be scaled to very large sizes. Like Floodlight it also has a number of pluggable modules (interfaces, protocols, and applications) that can be used to alter it to the needs of an organization. OpenDaylight is a little different from the other offerings because it allows for other non-OpenFlow southbound protocols.

  • OpenContrail

OpenContrail is a Juniper project (Apache 2.0 licensed) that is targeted at providing only NV and NFV. It has an extensive REST API that can be used to configure and display information from the system and is the same exact product that Juniper uses with its own commercial Contrail offering (plus support). As of this writing while a well written product, OpenContrail does not have the following or support compared with OpenDaylight but it is targeted on a smaller overall picture.

Commercial SDN Solutions

There are a number of different commercial SDN controllers that are available, some are strictly software-based and some are hardware-based. While this list is not comprehensive, it covers the major players in the SDN market today.

  • Big Switch Big Cloud Fabric

Big Switch Networks' Big Cloud Fabric combines a number of features to offer a comprehensive SDN replacement for traditional networks. In this case all of the physical switches run a copy of Switch Light, which is Big Switch's switch operating system. The controller functionality is provided by the Big Cloud Fabric controller which performs all control plane functions as it pushes them down to the switches via an extended form of OpenFlow. This solution also offers support for virtual switches through the company's Switch Light vSwitch product. 

Currently this solution is offered in two editions: P-Clos edition (Leaf and Spine physical fabric) and Unified P+V Clos Edition (Leaf and Spine physical and logical). 

  • Plexxi Big Data Fabric

Plexxi's Big Data Fabric solution takes a slightly different approach in its SDN solution. The SDN controller is called Plexxi Control and it works in concert with the Plexxi Switch to manage the forwarding decisions (control plane) of the network. What is different with Plexxi is that the hardware that is being managed is built by the company.

Instead of using the more common Leaf and Spine (Clos) topology, Plexxi uses a simpler two tier design where passive optical interconnects are used to connect together groups of Plexxi switches. This is done via LightRail cables and interconnect ports. This type of topology allows for fewer switches and a much smaller physical plant as the cables that are used provide the same amount of overall throughput via many fewer physical links.

Currently the Big Data fabric solution is offered in three different options: up to 432, 864 or up to 2,448 access ports.

  • Brocade Vyatta Controller

Brocade's Vyatta Controller is another take on SDN this is a high controlled deployment of the Stock (nothing proprietary) OpenDaylight SDN controller. As with the open source version of OpenDaylight, it has wide support from a number of different vendors (physical and virtual) and also provides access to support resources that will help a company implement the solution.

Since Brocade's solution does not implement any non-standard extensions, the customer has the flexibility to choose whatever hardware (physical or virtual) that will best meet the requirements for their specific environment, assuming they like the OpenDaylight solution to begin with.

  • HP Virtual Application Networks (VAN) SDN Controller/Virtual Cloud Networking (VCN)

HP's VAN works in conjunction with OpenStack to provide a comprehensive virtual networking environment. HP's (VCN) application extends on the current capabilities of OpenStack (Neutron) by providing a number of enhancements, including enhanced control of Open vSwitch, support for KVM and VMware ESX hypervisors, support for Distributed Virtual Router (DVR), hardware VTEP support, and more. HP's VAN acts as the central controller for this solution.   

HP's SDN solution will work with a number of different HP OpenFlow enabled switch models and 10 routers along with OpenFlow supporting third-party equipment.

HP's VAN by itself is priced at $499 for 50 nodes and is managed by GP's Intelligent Management Center (IMC).

  • Juniper Contrail

Juniper Contrail is a supported version of Open Contrail, and is targeted at both the enterprise and service provider markets. In enterprise networks, Contrail can be implemented along with an open cloud orchestration and automation platform, like OpenStack, and provides a virtualized network layer including support for switching, routing and networking services over a physical network. In service provider networks, Contrail can be implemented with an Operations and Business Support System (OSS/BSS) and provides NFV functionality. Architecturally, Contrail is comprised of two key components: the Contrail Controller and the Contrail vRouter.

The Contrail Controller sits between an orchestration system (OpenStack) or OSS/BSS system and the networking devices. It is comprised of three software components: Configuration, Control and Analytics. The Configuration component accepts requests from the orchestrator for the provisioning of a VM and the assignment of networking resources. The Control component interacts with the networking elements and directs the provisioning of networking for a virtual machine using the XMPP protocol (not OpenFlow). The Analytics component collects, stores, correlates and analyzes information from the network elements.

The Contrail vRouter is part of the compute note which receives reachability information from the control place and ensures native L3 services for host-based VMs.

  • Cisco Application Centric Infrastructure (ACI)/Application Policy Infrastructure Controller (APIC)

While Cisco has a couple of different SDN solutions available, the one that seems to be getting the most attention is the Application Centric Infrastructure (ACI). ACI is another approach to SDN that is slightly different from the other providers here with some similarities with the Plexxi solution.

As of today, the ACI solution is solely deployed physically through Cisco Nexus 9000 switches. These switches can then be deployed using a Clos architecture to form the ACI fabric. This fabric uses several technologies including IS-IS and VXLAN to calculate the forwarding path for the different connected hosts into the fabric. This forwarding behavior is intended to be completely transparent to the connecting hosts and is almost completely done via hardware.

The Application Policy Infrastructure Controller (APIC) is the central software controller for this solution. However, unlike most of the other solutions, the APIC is not providing the hardware with a description of how to forward traffic within the fabric, it is simply used to define application profiles which are then used to classify traffic coming into the fabric via a number of different techniques, including untagged frames, IEE 802.1Q, VXLAN or NVGRE. It is also important to note that double encapsulation is not performed on any of this traffic within the fabric itself; if a header is required to be used to exit the fabric it is stripped when it enters and it pushed back on when it exits.

ACI is also unique in that it does not use OpenFlow primarily to communicate with the switching equipment. This communication is done primarily using Cisco OpFlex protocol, although OpenFlow is supported. ACI is also complemented with the Open vSwitch Database Management Protocol (OVSDB.)


The one thing that is obvious is that there are a number of different SDN approaches, some more similar to each other than others. Since the ideas themselves are currently in development and many of these products are either in beta testing or have recently been released, it will take some time for the better solutions to rise to the top. Hopefully this article will help you make an informed decision in the SDN direction.

Further Reading:

More on SDN