One of the key fundamentals of SDN is disaggregation. Disaggregation of software and hardware in a network and also disaggregation of control and forwarding planes.

The SDN controller is the main brain and controller of an SDN environment. It's a strategic control point within the network and it is responsible for communicating information to:

If you are familiar with chassis based switches such as Cisco Catalyst 6500 or Nexus 7k chassis, you can imagine an SDN network as a chassis, with switches and routers as its I/O line cards and SDN controller as its supervisor or management module. In fact SDN is similar to a very scalable chassis where you don't have any limitation on the number of physical slots.

SDN controller is similar to the role of the management module of a chassis-based switch and it controls all switches via its southbound protocols and APIs.

The following table compares the SDN controller and a chassis based switch:

The first protocol that popularized the concept behind SDN was OpenFlow. When conceptualized by networking researchers at Stanford back in 2008, it was meant to manipulate the data plane to optimize traffic flows and make adjustments, so the network could quickly adapt to changing requirements. Version 1.0 of the OpenFlow specification was released in December of 2009; it continues to be enhanced under the management of the Open Networking Foundation, which is a user-led organization focused on advancing the development of open standards and the adoption of SDN technologies.

OpenFlow protocol was the first protocol that helped in popularizing SDN. OpenFlow is a protocol designed to update the flow tables in a switch. Allowing the SDN controller to access the forwarding table of each member switch or in other words to connect control plane and data plane in the SDN world. Back in 2008, OpenFlow was conceptualized by networking researchers at Stanford University, the initial use of OpenFlow was to alter the switch forwarding tables to optimize traffic flows and make adjustments, so the network could quickly adapt to changing requirements.

After the introduction of OpenFlow, NOX was introduced as an original OpenFlow controller (there still wasn't a concept of the SDN controller). NOX was providing a high-level API capable of managing and also developing network control applications. Separate applications were required to run on top of NOX to manage the network. NOX was initially developed by Nicira networks (which was acquired by VMware, and finally became part of VMware NSX). NOX was introduced along with OpenFlow in 2009. NOX was a closed source product, but ultimately it was donated to the SDN community, which led to multiple forks and sub projects out of original NOX. For example, POX is a sub project of NOX, which provides Python support. Both NOX and POX were early controllers. NOX appears an inactive development, however POX is still in use by the research community as it is a Python-based project and can be easily deployed.

NOX apart from being the first OpenFlow or SDN controller also established a programming model that is inherited by other subsequent controllers. The model was based on processing of OpenFlow messages, with each incoming OpenFlow message triggering an event that had to be processed individually. This model was simple to implement, but not efficient and robust and couldn't scale.

Nicira along with NTT and Google started developing ONIX, which was meant to be more abstract and scalable for large deployments. ONIX became the base for Nicira (the core of VMware NSX or network virtualization platform) and there are rumors that it is also the base for Google WAN controller. ONIX was planned to become open source and donated to the community, but for some reasons the main contributors decided to not do it, which forced the SDN community to focus on developing other platforms.

Starting in 2010, a new controller was introduced. It was called the Beacon controller and it became one of the most popular controllers. It was born due to the contribution of developers from Stanford University. Beacon is a Java-based open source OpenFlow controller created in 2010. It has been widely used for teaching, research, and as the basis of Floodlight. Beacon had the first built-in web user-interface, which was a huge step forward in the market of SDN controllers. Also it provided an easier method to deploy and run compared to NOX. Beacon was an influence for design of later controllers after it; however, it was only supporting star topologies, which was one of the limitations of this controller.

Floodlight was a successful SDN controller that was built as a fork of Beacon. Big Switch networks are developing Floodlight along with other developers. In 2013, Beacon popularity started to shrink and Floodlight started to gain popularity. Floodlight had fixed many issues of Beacon and added lots of additional features, which made it one of the most feature rich controllers available. It also had a web interface, a Java-based GUI, and it also could get integrated with OpenStack using the quantum plugin. Integration with OpenStack was a big step forward as it could be used to provide networking to a large pool of virtual machines, compute, and storage. Floodlight adoption increased by evolution of OpenStack and OpenStack adopters. This gave Floodlight greater popularity and applicability than other controllers that came before. Most of the controllers that came after Floodlight also supported OpenStack integration.

Floodlight is still supported and developed by community and Big Switch networks, and it is a base for Big Cloud Fabric (the Big Switch's commercial SDN controller).

There are other open source SDN controllers that are introduced such as Trema (ruby-based from NEC), Ryu (supported by NTT), FlowER, LOOM, and the recent OpenMUL.

The following table shows the current open source SDN controllers:

SDN use cases

This topic is very crucial, as in many cases stakeholders think why do they have to invest in SDN? What can SDN provide that the legacy network cannot? That's a valid question to ask.

There are multiple good use cases where SDN can add value:

• A network operating system: The SDN platform can act as a network operating system, providing packet delivery to other applications. SDN is a platform and allows other applications to drive, use the network for their specific requirements. Always remember that SDN doesn't do any packet delivery on its own, but it requires SDN applications (many of them) to define how packets needs to get delivered in a network.
• Network Access Control: One of the SDN use cases is NAC. The SDN controller can identify the newly connected devices and checks what this new device is, and what it needs to access and push the flow settings back to the SDN enabled switches. This method eliminates the use of 802.1x and VLAN assignments.

This diagram illustrates the use of SDN to enforce Network Admission Control (NAC) :

• Anycast applications: Anycast applications are referred to as distributed systems, which are built with multipole service nodes in a network. For example, streaming servers and file and object servers. With the change of the way application servers are built to a scale-out model, most modern service applications architecture is based on a distributed scale out model that all operates independently. An SDN platform is able to deliver the user requests to the closest, or better saying the best service node of an application. Other than being close there are other parameters such as load, bandwidth, and data availability. As an example an object storage platform might have multiple service nodes distributed in different location in the network and all working at the same time, using a single IP address. SDN networks will be able to understand where the service nodes are located (connected to which switch at what port) and will route the client requests to a particular network node that is considered as its best choice based on different parameters.
• Integration with private cloud (VMware, OpenStack): With increased use of VMware vSphere and OpenStack in data centers, the need to integrate the network with cloud infrastructure is increasing. An SDN network can get integrated with cloud application and provide the ability to create virtual networks, tenant isolation, and even create overlay networks using VXLAN. Also it can support service chaining to insert L4-L7 services.

The controller is the key component to integrate with cloud application via APIs.

• Virtual CPE and virtual CE: In a service provider environment, normally service providers install a dedicated router in each customer premises, which is always a rigid expensive box forced to clients. With the introduction of SDN, many service providers found this momentum and started using the opportunity window in order to build their SDN CPE, moving out from a dedicated router, replacing it with a commodity hardware (x86), which can run multiple virtual machines for network functions virtualization (NFV). AT&T and NTT have been successful in this area while others such as Verizon are also building their portfolio. Using SDN, the service provider will be able to use an edge SD-WAN enabled virtual machine to connect the customer to the network.

Another change in WAN and SD-WAN is the increase of reliability of consumer grade Internet connections. Many organizations prefer to use multiple cheap, high bandwidth Internet links instead of using an expensive limited bandwidth MPLS connection from their service provider. To answer this trend, which leads to popping up of SD-WAN products and vendors, service providers started to standardize a provisioning method of delivering an MPLS link and a (or more) Internet links to clients, which is called local Internet breakout. SD-WAN utilizes the local Internet breakout to build a secure tunnel to service provider networks and runs an SDN software with enough intelligence to understand what traffic should be routed via MPLS and via the Internet link.

SD-WAN is currently started to boom and there are many vendors such as Silver Peak, Riverbed, VeloCloud, Citrix, and so on, providing competitive and interesting products to enable enterprises to reduce their WAN costs and increase the quality of services.

• Service providers: In a service provider network where there are multiple geographical routers to provide backbone connectivity to clients, an SDN enabled network allows injecting and overriding the policies over the provider routers. In service provider networks the southbound protocols are normally BGP-PCEP, which is being promoted and used in many SP proof of concept installations. With SDN, a service provider will be able to override the MPLS or BGP decisions and route the specific traffic in a different way other than what has been determined by routing protocol. Cisco has done some progress in this area, remember that Cisco is one of the contributors to OpenDaylight and in fact the ODL web interface (Next) is donated by Cisco. You can find the Cisco service provider SDN example here:

https://github.com/CiscoDevNet/opendaylight-sample-apps

https://developer.cisco.com/site/opendaylight/discover/odl-at-cisco/build-apps-on-top-of-odl/

Core differentiator between SDN controllers

Although the SDN concept is still young and it is still within the hype, as you realized there are multiple SDN controllers and platforms available on the market. The available solutions in the market have different features and capabilities, which you need to understand before deciding on which controller or platform to choose and build your network on it. There are also products that use the marketing buzz words of SDN and try to pitch a legacy solution, which you need to be careful while evaluating them.

I have collected some key differentiators of SDN platforms and will take you through each as follows:

• Fabric or overlay: This is one of the most important attributes to look at and make the decision. Overlays are also considered as key drivers for network virtualization. Overlays are not dependent on underlay networks, meaning an overlay SDN can build an overlay SDN on top of a mesh IP underlay. Looking at SDN products in the market, some of them are basically an overlay, such as VMware NSX and Juniper Contrail. On the other hand the SDN fabric products are a full SDN aware underlay, which means that the SDN controller can communicate with all SDN switches in the network and control and program their flow and CAM tables. Solutions such as Cisco ACI and OpenDaylight are examples of a full fabric SDN platform.
• Open source versus proprietary: This attribute should only be important if you are considering extending the controller or have proprietary modifications specific to your business. In general and based on our studies, service providers are more interested in open source solutions as they use their tools and resources to productize and provide an SDN as a service to their customers. AT&T and NTT are good examples of service providers who took OpenDaylight and build their offerings based on that.

On the other hand, enterprises are interested in commercial and business supported products with specific SLA and support levels. Enterprises use SDN to run their business better. They are not interested to downgrade their network from a legacy L2/L3 to an SDN platform with no business case. Based on our studies, many enterprises have looked at and adopted Cisco ACI, VMWare NSX, and Big Switch Big Cloud Fabric, which are good commercial SDN platforms. When looking at commercial products, you need to always be careful about the vendor lock-in and find a solution that lets you scale and expand or even change your controller without impacting the switches in the network.

Openness in the SDN platform doesn't mean that you will be supported by the community. Commercial SDN controllers are based on OpenDaylight and are supported by companies such as Brocade and they are all open source as well as commercially supported.

• Application ecosystem and maturity of northbound APIs: SDN don't forget that an SDN platform doesn't work without SDN applications. SDN controller is a platform to run SDN applications. Without SDN applications the network doesn't forward any packet. A very basic SDN application is L2 switching, where you need to load and run the L2 application on a controller in order to have the very basic L2 switching (MAC learning) on your network. This may seem funny for some readers that the SDN has no built-in features; however, you should think that SDN is a methodology; it's a platform that allows you to build network applications and decide how you want the network to forward, route, or drop the packets.

Going back to our topic, while looking for an SDN solution you should consider choosing a SDN controller that provides a rich, complete, and developer friendly application environment. Many SDN platforms support Yet Another Next Generation (YANG) language, which is used for data modeling and also it is used as payload for NETCONF protocol.

• Where to deploy: You should consider your main use cases and compare against the capabilities and features of the SDN controllers in the market. For example, a controller designed for a campus network is not a good fit for a data center application. Or an SDN platform that doesn't have any plugin or capability to integrate with OpenStack is not a good fit for deploying in a OpenStack environment.

You should take into consideration your business use cases to find the best fit platform and controller for your business.

• Compatibility, reliability, and maturity of the platform: Although the SDN platform is a game changer in networking world, but it is still in its early stages and it's hard to find a solution that is deployed and worked for couple to years or find strong case studies. This is one of the key show stoppers for many enterprises trying to find a SDN solution that has a proven track record and has been deployed with multiple clients. CIOs and procurement look for proven solutions that have been used or certified.

Even standard protocols such as OpenFlow or OVSDB have different implementation between vendors and they might not be compatible with each other (for example, an OpenFlow switch from vendor A may not be compatible with an SDN controller from vendor B). These are challenges that require your attention prior to deciding which SDN platform you are going to live with.

• Smoothness of integration into orchestration platforms: Almost every commercial controller and many open source controllers provide OpenStack support in the data center. If you have a data center deployment and have picked a specific cloud management or orchestration platform (OpenStack, VMware vRealize, CloudStack, or others), check with the vendor or evaluate the open source distribution to ensure seamless integration into your orchestration environment.
• Integration with cloud and orchestration platforms: Nowadays almost every private cloud platform is built on VMware or some flavor of OpenStack or CloudStack. The SDN platform in data centers needs to integrate with OpenStack of VMware vSphere, and you need to check and ensure the level of integration and capabilities of the SDN solution with your choice of orchestration platform. Normally in data center environments, the SDN platforms provide direct integration with VMware vSphere and the SDN solution becomes part of the VMware virtual network and virtual distributed switches. The same applies to OpenStack and SDN solutions that will integrate with OpenStack via some kind of plugin (such as ML2 or other kinds of integrations).

If you are planning your SDN platform for a campus topology you need to check with your orchestration and policy tool about the integration with the SDN platform. Many SDN platforms provide such orchestration and tools along with their products; however, if you are using a specific orchestration tool you need to ensure how it is going to integrate with your SDN platform.

• Open APIs: Regardless of being open source of a proprietary closed source solution, you need to ensure that the SDN platform provides some kind of open APIs for integration with other tools. Other tools such as monitoring, orchestration tools, billing, abstract UIs, compute and storage tools, and so on. Normally APIs are not considered as a critical factor to make decisions and normally there is no day zero requirements for APIs, however, after deployment of the SDN platform slowly you will realize the requirement for integration with other systems. A very basic example is the cloud providers, where they need to have a single web interface for customers in order to create their tenant networks, subnets, and service insertion.
• A customer should be able to use the web interface of the platform to design and build his virtual network, add virtual routers, firewalls, and load balancers in their network while it is isolated and doesn't disturb other tenants or user traffic.

You should understand that the SDN market is still in its early stages. OpenDaylight has helped to change the landscape and also other open source projects such as ONOS OpenContrail and Calico which are mainly driving use cases is service provider networks.

You need to find the real need for going the SDN way and understand the capabilities of each SDN platform to make the correct decision. Remember in order to move to SDN you don't need to migrate everything and throw away your whole legacy network, No, you can build a SDN network for a POD (in a data center) or a building (in a campus) or a path (in a service provider).

Current SDN controllers

In this section, I'm putting the different SDN controllers in a table. This will help you to understand the current market players in SDN and how OpenDaylight relates to them:

Vendors/product	Based on OpenDaylight?	Commercial/open source	Description
Brocade SDN controller	Yes	Commercial	It's a commercial version of OpenDaylight, fully supported and with extra reliable modules.
Cisco APIC	No	Commercial	Cisco Application Policy Infrastructure Controller (APIC) is the unifying automation and management point for the Application Centric Infrastructure (ACI) data center fabric. Cisco uses APIC controller and Nexus 9k switches to build the fabric. Cisco uses OpFlex as the main southbound protocol.
Ericsson SDN controller	Yes	Commercial	Ericsson's SDN controller is a commercial (hardened) version OpenDaylight SDN controller. Domain specific control applications that use the SDN controller as a platform form the basis of the three commercial products in our SDN controller portfolio.
Juniper OpenContrial /Contrail	No	Both OpenContrail is open source, and Contrail itself is a commercial product.	Juniper Contrail Networking is an open SDN solution that consists of Contrail controller, Contrail vRouter, an analytics engine, and published northbound APIs for cloud and NFV. OpenContrail is also available for free from Juniper. Contrail promotes and uses MPLS in data centers.
NEC Programmable Flow	No	Commercial	NEC provides its own SDN controller and switches. The NEC SDN platform is one of the choices of enterprises and it has lots of traction and some case studies.
Avaya SDN Fx controller	Yes	Commercial	Based on OpenDaylight, bundled as a solution package.
Big Cloud Fabric	No	Commercial	Big Switch networks solution is based on the Floodlight open source project. Big Cloud Fabric is a robust, clean SDN controller and it works with bare metal white box switches. Big Cloud Fabric includes Switch Light OS, which is a switch operating system that can be loaded on white box switches with Broadcom Trident 2 or Tomahawk silicons. The benefit of Big Cloud Fabric is that you are not bound to any hardware and you can use bare metal switches from any vendor.
Ciena's Agility	Yes	Commercial	Ciena's Agility multilayer WAN controller is built atop the open-source baseline of the OpenDaylight Project-an open, modular framework created by a vendor-neutral ecosystem (rather than a vendor-centric ego-system) that will enable network operators to source network services and applications from both Ciena's Agility and others.
HP VAN (Virtual Application Network)	No	Commercial	The building block of the HP open SDN ecosystem, the controller allows third-party developers to deliver innovative SDN solutions.
Huawei Agile controller	Yes and No (based on editions)	Commercial	Huawei's SDN controller that integrates as a solution with Huawei enterprise switches.
Nuage	No	Commercial	Nuage Networks VSP provides SDN capabilities for clouds of all sizes. It is implemented as a non-disruptive overlay for all existing virtualized and non-virtualized server and network resources.
Pluribus Netvisor	No	Commercial	Netvisor Premium and Open Netvisor Linux are distributed network operating systems. Open Netvisor integrates a traditional, interoperable networking stack (L2/L3/VXLAN) with an SDN distributed controller that runs in every switch of the fabric.
VMware NSX	No	Commercial	VMware NSX is an Overlay type of SDN, which currently works with VMware vSphere. The plan is to support OpenStack in the future. VMware NSX also has a built-in firewall, router, and L4 load balancers allowing micro segmentation.