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 -- 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 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
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.
What Happens If the Network Fails?
How do the applications get informed of network failures? Let's say that everything is running well, but that a network failure takes out a link. The result is that bandwidth on a path is now significantly reduced. How does the network now tell the application about the change so that the application can take appropriate action?
The UC applications can potentially switch to lower bandwidth codecs. Or the UC controller can decide that some calls need to be terminated, as decided by the policies defined by the application and network administrators. For UC QoS, networks require some sort of mechanism for providing feedback from the network to the applications. Think of this as a closed-loop control system, which is something that rarely exists in networking.
Looking Forward
The IMTC is coming out with another whitepaper in the near future to describe some of the NBIs. I am not part of the consortium so I don't know exactly what will be in it. However, based on the above description, we can talk about what we need.
We should create innovative feedback mechanisms and policy definition mechanisms so that we can gain some experience with them. Experimenting will help us build better systems. Let's make mistakes now, while they are relatively inexpensive to make (at least relative to making these same mistakes in widely deployed production systems).
As software engineer Fred Brooks noted in his book of essays, The Mythical Man-Month, "The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. ...Hence plan to throw one away; you will, anyhow." So I recommend building some throwaway examples from which we can learn.
We should create the middleware controllers with the intent that they are separate from both the SDN control systems and from the applications. Define a set of NBIs that seem to work well with our current state of understanding, knowing that we'll be forced to replace them with new NBIs that account for things that we learn with the first versions.
The application APIs will need to be bidirectional so that applications can learn what the network knows and react accordingly. We will need to try to understand what the policy mechanisms might need to look like to provide the desired level of control.
Of course, we'll get it wrong at first. Discard that version and build it better the second and then the third time around. By the time we get to the fourth version, we should have something that's very usable. I'm looking forward to the upcoming IMTC whitepaper and moving forward.
