I attended the Open Networking Summit this year to learn more about SDN (software-defined networks) and to make contact with people who are working on it. There was an interesting demonstration in the exhibit hall by HP, in conjunction with Microsoft, as described by Phil Edholm in his post last week.
What is so interesting about this demo? I think that the implications around QoS are the most interesting. You should take a minute to read Phil's blog.
What the Demo Shows
HP used their OpenFlow switch with an HP SDN controller to control the network. Microsoft had its Lync video conferencing running on a pair of systems. Lync communicated to the SDN controller that a call was being placed between the two systems. HP's Lync controller configured the network to handle the traffic flow with the appropriate QoS treatment. As Phil notes, the network didn't have to do deep packet inspection to classify and mark the packets. The application told the network what to expect and what quality of service was needed for the new flow.
This demonstration is one of the first real examples I've seen of an Application-Controlled, Software Defined Network. In this case, Lync communicates with HP's SDN Controller to request specific traffic handling between two video systems. Phil goes on to describe several advantages of the system.
The Agile Network
We won't have to have fixed bandwidth reservations and fixed QoS treatment across the network. There is more to SDN than avoiding deep packet inspection or routing packets according to the type of service that they need. It is more than central management of device configurations.
A baby-step in the continuum of agile networking is the ability to quickly make configuration changes across the network. In the HP/Microsoft demonstration, the QoS policy is implemented at the controller, not at each router and switch, making it easier to update. Instead of a configuration management system that pushes fixed QoS policy configurations to all network equipment, the SDN controller QoS policy is updated, and is then applied to new calls.
Policies can also be more detailed and complex than what exists in today's network equipment. Consider time-based policies that are implemented during certain times of the day, or a policy that allows for more low-bandwidth calls than high-bandwidth calls. In a way, the functionality starts to look like a merger of call admission control (CAC) and QoS.
SDN and the agile network can dynamically adapt to changing conditions. Phil talks about a link failing, or picking a path optimized for a given type of flow. But what if the dynamics on the network were due to additional calls? For example, when a video call starts, and it exceeds the video bandwidth policy, it could get denied (CAC) or it could get best-effort treatment (QoS Mark-Down).
Let's say that the call is allowed to proceed with best-effort treatment. Then, when one of the other calls ends, the network could adapt by upgrading the treatment of packets in the previously marked-down call. Therefore, like a CAC system, when a new call starts, the network can make sure that it doesn't impact the other calls that are in progress. And unlike, CAC, when bandwidth becomes available, the network can provide that capacity back to applications so that they run better, or it can provide better quality, as in the case of using a higher-bandwidth codec.
Network-to-Application Communications
What can the network tell the applications? With the right APIs, the network can inform the call controller that the network can only provide a certain level of service to a call. Let's take the case where the network bandwidth for real-time traffic (the EF--Express Forwarding queue) is nearly exhausted. The network might request that the call controller force the use of a lower-bandwidth codec for a new call. I don't see that in today's networks.
But what about a business in which the incoming calls are the primary revenue generation source? Retail call centers are a good example. Each additional call into the call center is an important potential source of more revenue. Instead of assigning fixed bandwidth allocations and fixed codec selection, the SDN controller might tell the call controller to force all calls to a lower bandwidth codec to make room for new calls. More calls translate into more revenue. This kind of agility is not available in today's networks.
You might claim that this example is contrived and that bandwidth is cheap enough that simply adding bandwidth is a better solution. I would probably agree, on the principle that more bandwidth is likely a simpler solution than the complexity involved in designing and maintaining an application that talks to an SDN controller. However, it is an example of the type of thing that can be done with SDN that is not possible in today's networks. I am sure that we will eventually think of other examples that are more compelling and cannot be solved so simply.
Summary
SDN is very new, and it is just now starting to become apparent what its impact will be in the world of unified communications and collaboration. There will be new methods for configuring and managing networks and for handling real-time communications on the networks of the future. The capability that I describe above is still a few years away, but it is the direction that the industry is heading. It isn't too soon to start thinking about how SDN might be used to competitive advantage, and plan for the transition when the capabilities are "production quality."
