Automated QoS Network Service API
The UC Interoperability Forum has recently published version 1.0 of a QoS marking use case for SDN. See the press release for an overview.
The use case has been shown for over a year at the Open Networking Summit and at Enterprise Connect. It is a pretty interesting use case because of the challenges of implementing QoS across an enterprise. There are several interesting situations that SDN simplifies or improves, due to the communication between the SDN controller and the application. I've previously written about some of the examples, but there are other examples highlighted in the Version 1.0 QoS Use-Case specification.
It is a useful document because it incorporates several ideas about the integration of UC and SDN. An interesting concept is the inclusion of an Automated QoS Network Service Application. It is the interface between the UC infrastructure control system and an SDN controller, shown in Figure 1 below. It provides a "middleware" QoS API and policy engine that is independent of the SDN controller as well as being independent of the higher-level application
Figure 1. Automated QoS Network Service Application
What isn't shown is that multiple high-level applications can interface with the Automated QoS Network Service Application. The internal policy engine resolves conflicts within and between applications. Let's examine some examples.
QoS Policy Within an Application
Policies will play a key role in dynamic QoS applications. Let's say that we have anticipated that a remote site (or a part of the network) will need 1 Mbps for voice and video calls. We have determined that this allocation will handle the current volume of calls and leave bandwidth remaining for business applications. After a few months of successful operation, the time comes when the call volume increases to more than 1 Mbps.
In a traditional network implementation, Call Admission Control (CAC) might be used to restrict the number of calls, causing the additional call to be denied. However, in an SDN-controlled network, we should be able to use dynamic QoS to accommodate the call, provided that other applications are not negatively affected.
In the SDN-controlled network, the Automated QoS Network Service Application receives a bandwidth allocation request from the UC&C controller via the Automated QoS Network Service API. The policy must be checked to determine whether to permit the call. One policy might deny any calls that exceed the threshold, emulating the traditional approach. A different policy might allow additional calls, provided that there is available bandwidth. A third business policy might be that the call should be permitted because the calls are more important than other applications.
Another example is the conflict that arises when a voice call starts and a set of video calls is using all the available bandwidth. Voice is commonly handled in the Express Forwarding (EF) queue and is handled before video. But if the video call is for a critical business function, should the voice call be denied, or perhaps handled at a lower QoS setting? We may also see policies that define some endpoints as having greater priority than other endpoints. Dynamic QoS provides a lot more choices than traditional static QoS configuration.
The Automated QoS Network Service Application can also provide feedback to the upper-level application by denying a request for additional bandwidth for a new call. The upper-level application may be able to take action that frees bandwidth so that a subsequent request will succeed. For example, a request to provision another call is denied, so the UC&C controller forces existing calls to switch to lower bandwidth codecs, freeing bandwidth for the new calls.
Similarly, if bandwidth becomes scarce, should video calls be converted to voice-only calls? Should a call that has been converted to voice-only be allowed to resume video if bandwidth becomes available?
We will need to be careful because I can see some of these algorithms causing services to disappear and reappear in a seemingly mysterious manner. This type of feedback from the SDN and Automated QoS Network Service Application is something completely new to networking.
Defining the appropriate policies will be an important function. I expect that a Qos policy library will be developed and that network administrators will simply select the desired policy from the library, perhaps modifying some of the parameters. This will greatly simplify the process of defining and maintaining individual Qos policies.
QoS Policy Between Applications
Of course, there will need to be an overall policy that resolves conflicts between lower-level policies, such as when two applications cause oversubscription of a QoS queue. Which application should receive priority treatment? The network administrators will need to determine how to resolve such conflicts.
QoS Within the Network Core
The core network must still be pre-provisioned for the desired QoS handling. The SDN controller is not generally intended to configure QoS in all devices along the call path. The primary functionality is to perform classification and marking. Once the traffic is properly marked, the network core devices will efficiently forward it.
Complications
Two complications have been identified in the use case: NAT and roaming. Each of these requires changes in the network addresses, which may make flow identification difficult within the SDN. The Automated QoS Network Service Application identifies flows for classification and marking by IP address, transport protocol, and TCP/UDP port numbers, so anything that changes these parameters could affect connectivity.
Summary
The dynamic nature of QoS in an SDN environment will be a big change in networking. We've typically had to implement changes over long time frames. New methods will be needed to monitor applications and their use of the network in order to debug the new policies that will be required. It will take some adjustment on the part of the network and application administrators to make everything work smoothly. The result will be much more adaptable networks that integrate with applications for the best performance of those applications.
