NETWORKING

  • 03/02/2016
    7:00 AM
  • Rating: 
    1 vote
    +
    Vote up!
    -
    Vote down!

SDN: Does Anybody Really Know What It Is?

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.

Network automation

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.

Looking for more hot technology trends? Learn about the Future of Networking at a two-day summit presented by Packet Pushers at Interop Las Vegas, May 2-6. Don't miss out -- Register now!

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.

Terry Slattery will be speaking on SDN for Communications at Interop Las Vegas. Register today to attend Interop, flooring May 2 through 6 in Las Vegas.


Comments

SDN: Does Anybody Really Know What It Is?

Yes, as outlined by ONF back in 2011, a seperation of the control plane from the data plane.

In short it represents a platform for development, now you can either choose a specific vendor flavour or you can Do-it-Yourself, the later representing custom tailoring to your exact requirements.

Does it Apply to You?

The concept of SDN is pretty neat in an era when networking has lost a lot of its "cool" factor in the area of innovation for network architects. However, a lot of the common examples don't apply to a majority of common networks. As an example, I've worked on some sizeable enterprise networks, and they just didn't have multiple connections where software could decide on which path was the best to send data across.

Also, traffic patterns tended not to change outside of business vs. non (normal) business hours. Voice was taken care of via QOS (which basically never kicked in). Along with less traffic do to shrinking client/server models and more use of HTML or even virtual PCs, a lot of 1G, 10G+ networks have been more than adequate. Internal data center networks are a bit different, with most of the issues seen were blade server and "intra/inter-cabinet" connectivity.

Of course big service providers are different, along with the Amazon's of the world. Don't get me wrong, I 'm not anti SDN. But for a lot of state/local governments, small, medium and businesses, SDN is a huge solution looking for a problem that good network design and troubleshooting can resolve.

Re: Does it Apply to You?

Thanks for sharing your view here! You make a good point, and I would agree that for SMBs, SDN probably isn't practical. What do you think would change that?

Re: Does it Apply to You?

For SMB staff, the question is whether or not it's going to help them, or just be another software tool which will also need to be managed. The one thing, that a few network managers I've spoken with have said that scares them, is the idea that the in-house programmers will now be programming the network. It's either that, or learn to program this thing themselves.

I think what is needed is a low maintenance product to drop in which provides a helpful tool to allow network managers to make sweeping or small changes, based on insight/feedback from the network. An easy way to create and deploy a script is great, but when the product takes more work to accomplish a task than a good network manager can complete using the command line, he/she will lose interest - they already have too much on their plate. But a streamlined product that can be truly help with a moderate learning curve, now that would be gold.

Re: Does it Apply to You?

That kind of product would definitely be valuable. In 2014, one of our contributors, Bob McCouch, wrote about waiting for the SDN trickle down effect for the SMB and seeing signs of packaged SDN solutions, citing Big Switch's Big Tap Monitoring Fabric (I think it's just called Big Monitoring Fabric now).

Research shows it's all over the board

At ESG we did some research to figure out what enterprises consider to be SDN, and it's all over the board. Can be control/data plane separation, can be NFV, etc. At the risk of creating too many categories, I think we need to be specific in the future and not wave our hands and just use the term "SDN". If it's network virtualization, then we ought to at least use that term in our discussions.

Re: Research shows it's all over the board

Hi Dan -- Thanks for sharing that research -- interesting results. I wonder if enterprises might have a lot of different interpretations of network virtualization as well?

Good points from everyone

Everyone has good, valid points about SDN. That's one of the reasons why it is so difficult to pin down a definition.

Simply saying that it is the separation of control and data planes isn't sufficient. The UC example I gave couldn't be done if control and data planes are separated but no bi-directional API is provided.

SDN's centralized control system allows a lot of new functionality and path optimization that has not been possible. Technologies like policy-based routing and performance routing can do some of the work, but not with the kind of dynamic nature that a more flexible control system can. SD-WAN is a good example.

We absolutely need better and simpler control systems. New abstractions that simplify networking are needed to replace the current complexity of networking (think MPLS, PBR, and PfR) while providing better control.

Better terminology would certainly help in our discussions about network virtualization technology.
-Terry