Software-Defined Networking or SDN is a hot topic right now. Learning Tree has a Software Defined Networking course, and industry publications and blogs are full of talk about SDN. But what is really going on right now with SDN, and where is it going?
Webtorials did a survey in October, 2015, you can find the full details here. But to summarize the piece and some of the accompanying reports:
Less than 9% reported running SDN in a production environment, and the percentages reporting production use and lab testing were pretty much the same as the year before. Remember that this comes from people who responded to a survey about SDN, meaning that SDN users are probably much more prevalent in this group than the population at large.
Yes, some big operators like Google and telecommunications carriers like AT&T are using SDN, but right now SDN is largely carrier-only, or at least carrier-mostly.
For most organizations, SDN is not there yet and it’s not coming.
The OpenFlow protocol is a Layer 2 protocol used between an OpenFlow controller and an OpenFlow switch. The device is called a “switch” even though SDN controls data flows in terms of OSI layers 2, 3, and 4 at least, likely, all the way to layer 7 with a unique flow for one running instance of one application.
Business applications communicate with the controller, requesting data flows of specific topology, quality of service, security, and more. The controller creates and controls these flows by communicating with the switch fabric using OpenFlow.
Dan Pitt is the executive director of the Open Networking Foundation, which oversees OpenFlow development. He has said that a goal of OpenFlow as an open protocol is to allow you to buy a controller from one vendor and switching hardware from another. But he says that for now it’s best to buy both from the same company.
A lot of pieces are missing, or at least they lack the functionality many people expect. The OpenDaylight project provides a controller which runs on a Linux host. You get a web dashboard to observe your SDN internet work, but controlling it requires that you write custom code. It isn’t point-and-click.
Nor should it be! A point-and-click human interface makes it easy to do simple things, but gets in the way of controlling a complex and rapidly reconfiguring software-defined network.
An alternative is the Open Network Operating System or ONOS, which has the goal of being the SDN control plane for service providers. Some proponents of ONOS say that OpenDaylight is vendor-driven to further entrench brand-name hardware.
Right now OpenFlow is the standard for the “southbound interface,” the communication between the control plane and the forwarding plane. The “northbound interface” is the communication between the applications requesting specific data flows and the control plane.
There is no standard for the northbound interface traffic. Again, it’s too early, too little going on, there is no visible consensus and not even the appearance of a movement toward one.
There is talk of varying “latitudes” or degrees of how far north along that application—controller channel. A business application needs few details, but tasks like load balancing, firewall implementation of policy, and data loss prevention need access to and control of far more details.
Latitudes are a good idea in the abstract. The worry is that practical implementations will issue conflicting requests.
Survey respondents reported that about half of those using SDN had deployed it in data centers, about 30% in WANs, and about 20% in branch or campus deployments. Data center uses include virtualization, security, and load balancing.
WAN applications tend toward optimization.
Branch and campus uses include QoS or quality of service routing for high-performance media streaming, unifying wired and wireless networking, and role-based access control of data streams.
No one really knows! That keeps this interesting. Check out Learning Tree’s Software Defined Networking course to learn the latest.