Multiple Paths to Software-Defined Networking

Software-Defined Networking or SDN is making a lot of noise in the press right now (this blog included), yet many are still confused about what SDN is and what is best way to build one. While many enterprises are just beginning to explore this technology, large telcos and cloud service providers are much further along, testing and deploying SDN technologies in production environments.  There are, however, a number of different technologies or approaches that can be used to create a Software-Defined Network. Depending on which vendor you speak to, the answer will vary. I was reminded of this during a recent conversation wtih ConteXtream, an emerging technology vendor in the SDN space that offers a different approach to SDN as outlined below. 

Loosely defined, SDN is about separating the control plane from the forwarding plane. Based on the meetings that I have had, there are several different approaches to accomplish this. They are as follows:

1. Centralized control with OpenFlow connection.  This is probably the most talked about method. The Open Networking Forum and its sponsors have developed an open standards-based API called OpenFlow to allow a centralized controller to access any switch that is OpenFlow-enabled. The idea being that a centralized controller could access heterogeneous switches.  A number of network vendors have announced support for OpenFlow and have OpenFlow-enabled switches. Examples include Brocade, Dell, Extreme,  HP, IBM, Intel, and NEC. Examples of OpenFlow controllers include Big Switch and NEC.
2. Centralized control with either a proprietary or other open (non OpenFlow) connection. This method is very similar to the first one, but instead of leveraging the open standard, it leverages either a proprietary connection between the switch and controller or an open connection but not the OpenFlow API to connect to the switches. Examples of this would be Juniper's QFabric (which was developed prior to OpenFlow) and Arista which uses an open but non OpenFlow approach..
3. Centralized control with virtual switches. In this catagory, no attempt is made to connect directly to the physical switches, but rather to leverage virtual switches to create an abstraction layer above the physical network. This approach is very attractive to cloud service providers with highly virtualized environments. Vendor examples of this type of technology would be ADARA, Nicira. and VMware.
4. Distributed control plane sottware switch. Instead of using a centralized controller, the control plane is  fully distributed along the top of the rack. The idea being to separate the network control from the hypervisor and vSwitch, enabling higher levels of scale and flexibility. ConteXtream is an example of a vendor leveraging this approach.

It is still early in the technology development cycle, and hype cycle, for that matter, so expect to hear more about each of these approaches, or even a combination of them as time progresses and each are given a trial by fire. Enterprise organizations should take some comfort that many of the telcos and cloud service providers are on the bleeding edge of this technology and will help to sort out the viable technologies or better define which technology works best in which environment. That said, it would be prudent for the enterprise to keep a close eye on SDN developement as consolidating data centers, increased use of virtualization, and multi-tenant environments make many large enterprise data centers look a lot more like service provider data centers, and they will be able to learn some valuable lessons from those Telcos and cloud service providers.

*All views and opinions expressed in ESG blog posts are intended to be those of the post's author and do not necessarily reflect the views of Enterprise Strategy Group, Inc., or its clients. ESG bloggers do not and will not engage in any form of paid-for blogging. Click to see our complete Disclosure Policy.