SDN controllers

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:

• Routers and switches and other network devices behind them. SDN controllers uses APIs or protocols (such as OpenFlow or NETCONF) to communicate with these devices. This communication is known as southbound.
• Upstream switches, routers or applications, and the aforementioned business logic (via APIs or protocols). This communication is known as northbound. An example of a northbound communication is a BGP session between a legacy router and SDN controller.

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:

SDN Controller	Chassis based switch
Supports any switch hardware	Supports only specific switch line cards
Can scale out, unlimited number of switches	Limited to number of physical slots in the chassis
Supports high redundancy by multiple controllers in a cluster	Supports dual management redundancy, active standby
Communicates with switches via southbound protocols such as OpenFlow, NETCONF, and BGP PCEP	Use proprietary protocols between management module and line cards
Communicates with routers, switches and applications outside of SDN via northbound protocols such as BGP, OSPF, and direct API	Communicates with other routers and switches outside of chassis via standard protocols such as BGP, OSPF or APIs

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.

POX is hosted at http://github.com/noxrepo/pox

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:

Active open source SDN controller	Non-active open source SDN controllers
Floodlight	Beacon
OpenContrail	FlowER
OpenDaylight	NOX
LOOM	NodeFlow
OpenMUL
ONOS
POX
Ryu
Trema

OpenDaylight

OpenDaylight started in early 2013, and it was originally led by IBM and Cisco. It was a new collaborative open source project. OpenDaylight is hosted under Linux Foundation and it draws support and interest from many developers and adopters. OpenDaylight is a platform to provide common foundations and a robust array of services for SDN environments. OpenDaylight uses a controller model that supports OpenFlow as well as other southbound protocols. It is the first open source controller capable of employing non-OpenFlow proprietary control protocols, which eventually lets OpenDaylight to integrate with modern and multi-vendor networks.

The first release of OpenDaylight was in February 2014 with the code name Hydrogen, followed by Helium in September 2014. The Helium release was significant because it marked a change in direction for the platform that has influenced the way subsequent controllers have been architected. The main change was in the service abstraction layer, which is the part of the controller platform that resides just above the southbound protocols, such as OpenFlow, isolating them from the northbound side and where the applications reside.

Hydrogen used an API-driven Service Abstraction Layer (AD-SAL), which had limitations, specifically it meant the controller needed to know about every type of device in the network AND have an inventory of drivers to support them.

Helium introduced a Model-driven service abstraction layer (MD-SAL), which meant the controller didn't have to account for all the types of equipment installed in the network, allowing it to manage a wide range of hardware and southbound protocols.

The Helium release made the framework much more agile and adaptable to changes in the applications; an application could now request changes to the model, which would be received by the abstraction layer and forwarded to the network devices.

The OpenDaylight platform built on this advancement in its third release, Lithium, was introduced in June of 2015. This release focused on broadening the programmability of the network, enabling organizations to create their own service architectures to deliver dynamic network services in a cloud environment, and craft intent-based policies.

The Lithium release was worked on by more than 400 individuals, and contributions from Big Switch Networks, Cisco, Ericsson, HP, NEC, and so on, making it one of the fastest growing open source projects ever. The fourth release, Beryllium, came out in February of 2016 and the most recent fifth release, Boron, was released in September 2016.

Many vendors have built and developed commercial SDN controller solutions based on OpenDaylight. Each product has enhanced or added features to OpenDaylight to have some differentiating factor. The use of OpenDaylight in different vendor products are:

• A base, but also sell a commercial version with additional proprietary functionality-for example: Brocade, Ericsson, Ciena, and so on
• Part of their infrastructure in their Network as a Service (or XaaS) offerings-for example: Telstra, IBM, and so on
• Elements for use in their solution-for example: ConteXtream (now part of HP)

Open Networking Operating System (ONOS), which was open sourced in December 2014, is focused on serving the needs of service providers. It is not as widely adopted as OpenDaylight; ONOS has been finding success and gaining momentum around WAN use cases. ONOS is backed by numerous organizations including AT&T, Cisco, Fujitsu, Ericsson, Ciena, Huawei, NTT, SK Telecom, NEC, and Intel, many of whom are also participants in and supporters of OpenDaylight.

Apart from open source SDN controllers, there are many commercial, proprietary controllers available on the market. Products such as VMware NSX, Cisco APIC, Big Switch Big Cloud Fabric, HP VAN, and NEC ProgrammableFlow are examples of commercial and proprietary products.

The following table lists the commercially available controllers and their relationship to OpenDaylight:

ODL-based	ODL-friendly	Non-ODL-based
Avaya	Cyan (acquired by Ciena)	Big Switch
Brocade	HP	Juniper
Ciena	NEC	Cisco
ConteXtream (HP)	Nuage	Plexxi
Coriant		PLUMgrid
Ericsson		Pluribus
Extreme		Sonus
Huawei (also ships non-ODL controller)		VMware NSX

Core features of SDN

Regardless of an open source or a proprietary SDN platform, there are core features and capabilities that require the SDN platform to support. These capabilities include:

• Fabric programmability: Providing the ability to redirect traffic, apply filters to packets (dynamically), and leverage templates to streamline the creation of custom applications. Ensuring northbound APIs allows the control information centralized in the controller available to be changed by SDN applications. This will ensure that the controller can dynamically adjust the underlying network to optimize traffic flows to use the least expensive path, take into consideration varying bandwidth constraints, and meet the quality of service (QoS) requirements.
• Southbound protocol support: Enabling the controller to communicate to switches and routers and manipulate and optimize how they manage the flow of traffic. Currently OpenFlow is the most standard protocol used between different networking vendors, while there are other southbound protocols that can be used. An SDN platform should support different versions of OpenFlow in order to provide compatibility with different switching equipments.
• External API support: Ensuring the controller can be used within the varied orchestration and cloud environments such as VMware vSphere, OpenStack, and so on. By using APIs the orchestration platform can communicate with the SDN platform in order to publish network policies. For example, VMware vSphere shall talk to the SDN platform to extend the virtual distributed switches (vDS) from virtual environment to the physical underlay network without any requirement from an network engineer to configure the network.
• Centralized monitoring and visualization: Since the SDN controller has a full visibility over the network, it can offer end-to-end visibility of the network and centralized management to improve overall performance, simplify the identification of issues, and accelerate troubleshooting. The SDN controller will be able to discover and present a logical abstraction of all the physical links in the network, also it can discover and present a map of connected devices (MAC addresses), which are related to virtual or physical devices connected to the network. The SDN controller support monitoring protocols, such as syslog, snmp, and APIs in order to integrate with third-party management and monitoring systems.
• Performance: Performance in an SDN environment mainly depends on how fast the SDN controller fills the flow tables of SDN enabled switches. Most SDN controllers pre-populate the flow tables on switches to minimize the delay. When an SDN enabled switch receives a packet that doesn't find a matching entry in its flow table, it sends the packet to the SDN controller in order to find where the packet needs to get forwarded to. A robust SDN solution should ensure that the number of requests from switches are minimum and the SDN controller doesn't become a bottleneck in the network.
• High availability and scalability: Controllers must support high availability clusters to ensure reliability and service continuity in case of failure of a controller. Clustering in the SDN controller expands to scalability. A modern SDN platform should support scalability in order to add more controller nodes with load balancing in order to increase the performance and availability. Modern SDN controllers support clustering across multiple different geographical locations.
• Security: Since all switches communicate with SDN controller, the communication channel needs to be secured to ensure unauthorized devices doesn't compromise the network. SDN controller should secure the southbound channels, use encrypted messaging, and mutual authentication to provide access control. Apart from that the SDN controller must implement preventive mechanisms to prevent from denial of services attacks. Also deployment of authorization levels and level controls for multi-tenant SDN platforms is a key requirement.

Apart from the aforementioned features SDN controllers are likely to expand their function in future. They may become a network operating system and change the way we used to build networks with hardware, switches, SFPs, and gigs of bandwidth. The future will look more software defined, as the silicon and hardware industry has already delivered their promises for high performance networking chips of 40G, 100G. The industry needs more time to digest the new hardware and silicons and refresh the equipment with new gears supporting 10 times the current performance.

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.