Exploring the State of SDN & UC Integration
The early progress has been good but we need to keep up the pace of innovation.
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:
- Dynamic QoS – where the UC controller informs the SDN controller of new calls so that the SDN controller can dynamically configure QoS classification and marking at the network edge for call handling, as mentioned above. Vendors have been demonstrating this functionality for several years.
- Automated call admission control (CAC) – upon receiving notice of a new call from the UC controller, the SDN controller tells the UC controller that a new call cannot be admitted to the network due to a lack of adequate QoS resources. The most likely cause would be insufficient bandwidth of the appropriate QoS class at some component along the path between source and destination. This functionality requires communications from the SDN controller back to the UC controller.
- Automated traffic engineering – where the SDN controller sends UC traffic over selected paths that support the desired traffic characteristics. To perform this function, the SDN controller needs to program the network to perform policy-based routing of the UC traffic.
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 -- and I'll talk more about that later in this post.
In the architecture shown below, two UC applications are communicating with the SDN controller. A Quality of Experience (QoE) Services Controller within the SDN controller arbitrates among multiple applications requesting the same network services. It is the entity that knows if the priority queue can handle another call. While the QoE Services Controller sits within the SDN controller in this schematic, that doesn't necessarily have to be the case. It could be a separate middleware controller that interfaces between the applications and the SDN controller's North-Bound Interface (NBI).
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.
Click to the next page for a look at QoS policy and a look ahead