Software-defined networking can mean many things, depending on your view.
I can imagine a tune set to Chicago’s classic “Does Anybody Really Know What Time It Is?” but adapted to SDN. I was a delegate at the recent Networking Field Day 11, where we had time for several delegate forums in which we discussed topics for a few minutes. Our first topic was “What is SDN?” With so many different views on what constitutes SDN, are we like the blind men who were feeling an elephant and describing the beast?
In this post, I’ll cover some of the different ideas of what SDN is, and offer my own view.
Many people equate SDN with network automation. Is SDN simply a mechanism for rapid network configuration? There are any number of network automation tools, such as Puppet, Chef, and Ansible. I once had a smart network engineer tell me that, in his opinion, if network management had succeeded, then the whole SDN thing wouldn’t have happened. I disagree, because SDN is much more than automating network configuration. While it is certainly a component, I don’t think that automation, by itself, is SDN.
Integration with applications
One of the more compelling examples of SDN is the integration of the network and applications. The integration allows applications to request a desired level of service from the network via an application programming interface (API) call to the network controller. The network controller returns an affirmative or negative response so that the application can take appropriate action.
A simple example is a unified communications system (the application) establishing a voice call and the network controller participating in call admission control. The UC controller asks the network controller for dedicated bandwidth between the endpoints. If the bandwidth is available, the network controller can return an affirmative reply and the call takes place. If bandwidth is unavailable, the UC controller can then either deny the call or perhaps take another action, such as changing existing calls to lower bandwidth codecs.
In another scenario, the network can inform an application when a link fails or when a new link comes up. The applications can then react to the change in bandwidth.
Network automation helps with application integration because automated changes can be used to allow the network to respond to application requests. Dynamic QoS definitions can support changes in application use.
More granular forwarding plane control
SDN is frequently associated with granular packet forwarding control. When the network can control the path of each flow, application flows can be directed over the best path for each application. Real-time applications can use a low-latency path while bulk data applications can use a high-bandwidth path. You can think of this as dynamic policy-based routing. SD-WAN is an example of this technology.
Security is enhanced because the network controls the path of each flow. The network doesn’t forward packets without a forwarding rule in place. The rules are created based on network policies that are defined by the network administrator.
SDN is many things
Overall, I think SDN encompasses all of the above. We are exactly like the blind men and the elephant. What we see in SDN depends on our experience, our background, and how we envision the future.
Disclosure: My travel to #NFD11 was covered by the vendors indirectly. I was otherwise not compensated for my attendance.