Exploring The State Of SDN & UC Integration

As I prepared for the talk on software-defined network (SDN) APIs for UC I gave last week at Interop, I decided it was time to find out what developments had occurred since I first encountered SDN-UC integration at the Open Networking Summit in 2013.

At that event, HP and Microsoft had a neat demonstration of dynamic QoS in which the Microsoft Lync controller informed an HP SDN controller that a voice call was starting between two endpoints. The HP SDN controller then applied QoS to the devices in the path between the endpoints. When the call completed, the SDN controller removed the QoS configuration from the network.

Since then, I have seen similar demonstrations of dynamic voice call QoS from more vendors. OK, so I see wider vendor acceptance, but what about new functionality?

Defining the Use Cases
I found that an International Multimedia Telecommunications Consortium (IMTC) working group is defining a set of use cases for SDN and UC integration. On this Web page you'll find several videos that explain the use cases, as well as a link to a nice whitepaper, "Automating Unified Communications Quality of Experience using SDN," that describes a number of SDN and UC use cases.

The use cases fall into several major categories:

SDN & UC Integration Architecture
The IMTC working group had the insight to create an architecture that can handle multiple UC applications. In fact, some of the applications that might need to request QoS resources may not be UC applications at all.

Non-UC Applications
The applications that might connect to the QoE Services Controller don't necessarily have to be UC applications. A hospital, for example, might want to provide priority treatment to bedside monitoring traffic. I would certainly want to have my bedside health monitoring traffic get priority treatment over a few packets in a voice call. (Note: Bedside monitoring typically is low bandwidth and its use is not likely to cause a significant problem to voice, even if the voice traffic were to be dropped.)

The critical point is that only the QoE Services Controller knows how much bandwidth is allocated to the priority queue and how much of that bandwidth is being used by multiple consumers. This intermediate, or middleware controller, is best equipped to control access to the common network resource pool (in this case, priority queue bandwidth). Of course, something has to determine that one application's traffic has priority over another application's traffic, and that's where the Application Policy component comes into play.

It's All About Policy
An organization can have a wide range of policies for handling priority queue oversubscription. Using automated CAC, should the SDN controller deny a call, playing a fast busy signal or delivering an "all circuits are busy" audio message to the calling endpoint? Or should the SDN controller admit the call, but mark the traffic as lower priority, perhaps even best effort? What happens when that call has bad quality and someone complains? Marking down traffic to a lower priority and creating calls with poor quality is going to create troubleshooting problems.

Going back to the hospital example, should the bedside monitoring traffic get priority over voice traffic? Who makes this decision? This certainly sounds like a good place for a policy.

What about traffic engineering? Should the SDN controller direct traffic of a given type over a different path? How should that path be computed (via the Shortest Path First algorithm, or by some other mechanism)?

All these decisions are reflected in the administrator-defined policy through the QoE Services Controller NBI. The policy definition application will likely be GUI-based, communicating with the QoE Services Controller via the NBI interface.

A longer verson of this article appeared on NoJitter.