Automating QoS UC SDN Use Case Version 1.2 (February 27, 2014) 1. Introduction Ensuring a high Quality of Experience (QoE) in Unified Communications and Collaboration (UC&C) applications requires proper configuration of Quality of Service (QoS) and Traffic Engineering (TE) on the underlying network. This document describes the use of Software Defined Networking (SDN) to allow UC&C infrastructure to dynamically configure QoS and TE with the goal of ensuring that the QoS and TE configurations match the requirements of the UC&C applications. Dynamically managing QoS and Traffic Engineering involves four different use cases: 1. Dynamic QoS: dynamically mark authorized voice and video traffic with the appropriate QoS markings. 2. Call Admission control: prevent voice and video traffic from exceeding the available bandwidth capacity, and notify applications of changes in available bandwidth so they can adjust selected codecs (e.g. based on policies). 3. Dynamic Traffic Engineering of Bandwidth Capacity for each Class of Service: dynamically adjust the amount of bandwidth associated with various Classes of Service (CoS) to match bandwidth requirements of the corresponding applications. 4. Dynamic Traffic Engineering of Media Paths: route media along a path that is best able to meet performance requirements (rather than along the default least-cost path). This document focuses on Use Case 1 (dynamic QoS). The other three uses cases are presented in different documents. 2. Summary of the Use-Case The Dynamic QoS use case can be summarized as follows: Using a set of UC&C SDN API events an automated QoS system can be constructed for enforcing the authenticity of QoS markings on UC&C end-point traffic entering a network. These API events are exchanged between the UC&C Infrastructure and an Automated QoS Network Service App as shown in Figure 1 below. The Automated QoS Network Service App provides the following functionality: It allows the UC&C infrastructure to request QoS treatment for UC&C traffic. QoS requirements can be expressed using a DiffServ model (traffic prioritization based on class of service) as well as an IntServ model (end-to-end bandwidth guarantees). It maps the QoS treatment as requested by the UC&C infrastructure onto the actual QoS capabilities as provided by the underlying network. For example, it could translate class of 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 1 of 22
service specifications to DiffServ Control Point (DSCP) or Wireless Multi-Media (WMM) markings. It implements policy to regulate access to QoS resources as necessary. For example, multiple UC&C applications or different classes of users may compete for a limited set of low-latency queuing resources. The Automated QoS Network Service App decides how to allocate these resources on a session-by-session basis. UC&C Infrastructure Automated QoS Network Service API Administrator Interface Automated QoS Network Service Application QoS Mapping Policy SDN Controller North-Bound Interfaces SDN Controller Topology Inventory Flow Programming Statistics Network Element Network Element Network Element Network Element Network Element Network Element Network Element Figure 1. Automated QoS Network Service Application Overview The use cases described in this document assume that all UC&C signaling is routed through centralized UC&C infrastructure components and that all interactions between the UC&C system and the Automated QoS Network App are handled by those UC&C infrastructure components. While the architecture presented here does not preclude UC&C endpoints from interacting directly with the Automated QoS Network Service App, such interactions introduce a number of security and scalability concerns that are outside the scope of this document. This document specifies the interactions between the UC&C infrastructure and the Automated QoS Network Service App. The details of how the Automated QoS Network Service App provides its functionality are implementation-specific and outside the scope of this document. Note that the Automated QoS Network Service App in turn leverages north-bound interfaces exposed by the SDN Controller. Specification of the SDN Controller north-bound interfaces is out of scope for this document although the use case presented in this document may provide input into the requirements for the SDN Controller north-bound interfaces. The Automated QoS Network Service solution delivers the following value for UC&C: QoS is secured by emulating the same QoS security lockdown model as used in the legacy VoIP VLAN construct but from a UC&C converged endpoint. The SDN QoS solution does not rely on VLAN technology, but does support VLANs. Allows for automated QoS polices (including when clients are mobile and fluid). Simplifies and lowers the cost of deploying QoS. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 2 of 22
Does not rely on ongoing manual network audits or network assessments. Supports heterogeneous switch and routers environments. Mitigates QoS misconfiguration due to human error. 3. Problem Description In today s enterprises most companies have evolved their voice Time Division Multiplexing (TDM) PBX systems into a Voice over IP (VoIP) model. With this paradigm shift VoIP depends heavily on the Quality of Service (QoS) configured correctly within an enterprise s network as VoIP uses a statically multiplexed packet based model for the optimization of bandwidth. It has been recommended by industry standardization to separate the different Classes of Services (CoS) using a Differenced Services (DiffServ) model in which VoIP uses an Expedited Forwarding (EF) Per-Hop Behavior (PHB) so that the delivery of real-time interactive media traffic like VoIP is separated from other classes of services. As each Network Element (NE) between source and destination forwards the VoIP packet, an EF queue emulates a physical wire where the delay to an outbound link can be no greater than one packet buffer depth, as shown in Figure 2: Ingress Rate < Egress Rate EF Network Element Strict Priority Queue Committed Defined Rate Input Link AF Drop High CS3 Drop Med Drop Zone Drop Low Committed Rate Queue Committed Rate Queue Committed Rate Defined Committed Rate Defined Scheduler Output Link Best Effort No Rate Defined Figure 2. Network Element with Expedited Forwarding Queue Other Per-Hop-Behaviors implemented by network elements may include Assured Forwarding (AF) and Class Selector (CS). Assured forwarding allows network operators to provide assurance of delivery as long as the traffic does not exceed some commited data rate. Class Selector provides backward compatibility with network devices that use the Precedence field in the TOS byte of the IPv4 header to mark priority traffic. The Per-Hop Behavior of a packet entering the network element is determined by the DS field of the IP header which contains a 6-bit Differentiated Services Code Point (DSCP) value. For example, the DSCP for Expedited Forwarding behavior is 46. Deploying VoIP on enterprise 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 3 of 22
networks requires creation of QoS policies to correctly mark DSCP values for real-time voice traffic. In the last decade as VoIP technology got pervasively deployed, a security model was evangelized by most industry networking companies in which voice was separated from other network traffic using a VLAN model. This lock down model puts voice and data traffic on separate VLANs and only traffic from the voice VLAN is marked for Expedited Forwarding behavior, as shown in Figure 3. PSTN Voice Traffic 802.1P Classifier Behavioral Aggregate Classifier for EF and BE Traffic Voice VLAN Voice VLAN EF Queue Access Switch Marked by switch as Expedited Forwarding (EF) for 802.1p and DSCP VoIP IP PBX Data Server Data Traffic Scheduler for EF and BE Traffic with Mappings form DSCP to 802.1p Scheduler for EF and BE Traffic Data VLAN BE Queue Data VLAN Data Terminal Marked by switch as Best Effort (BE) for 802.1p and DSCP Secured Non-Secured Figure 3. VLAN-Based QoS Model for VoIP This model was designed so that only disparate, purpose built VoIP handsets could gain admittance to the voice VLAN based on a VoIP device credential owned by the voice administrator (i.e.: no user device could gain access to the voice VLAN). This deployment model was ubiquitously prescribed by networking vendors for various reasons, including the ability to mitigate malware and to prevent Denial of Service (DoS) attacks on the mission critical VoIP service. Unfortunately, with the evolution of VoIP to Unified Communications and Collaboration (UC&C) the above secure VoIP model has become problematic. Since converged UC&C endpoints support many modalities using a single connection, voice, video, and data are now typically converged over a single network interface, which precludes the use of dedicated voice VLANs for securely applying QoS markings to VoIP traffic. Some UC&C endpoints attempt to address this issue by applying QoS markings to voice and video traffic as it enters the network from the endpoint device. However, most enterprise networks will not trust QoS markings applied by endpoints and network policies remark untrusted traffic to Best Effort as shown in Figure 4: 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 4 of 22
PSTN 802.1P Classifier Behavioral Aggregate Classifier for EF, AF & BE Traffic Marked by UC&C endpoint for WMM and DSCP Voice - Expedited Forwarding (EF) Video Assured Forwarding (AF) Data - Best Effort (BE) Scheduler for EF, AF & EF Traffic with Mappings from DSCP to 802.1p if Wi-Fi needed Access AP Switch UC&C Infra Voice, Video & Data Traffic (802.1p and DSCP Marked) Scheduler for EF, AF & EF Traffic with Mappings from DSCP to 802.1p Scheduler for EF, AF & BE Traffic Voice, Video & Data Traffic (802.1p and DSCP Marked) Remark QoS for Untrusted Traffic to Best Effort Data Terminal Marked by UC&C endpoint for DSCP Voice - Expedited Forwarding (EF) Video Assured Forwarding (AF) Data - Best Effort (BE) Figure 4. Challenges with Today s QoS Model for Unified Communications Other advanced QoS techniques rely on Deep Packet Inspection (or DPI) to classify traffic based on its contents and apply QoS markings based on this classification. Unfortunately, these techniques are increasingly unreliable because of a growing trend to encrypt all calls and signaling traffic end-to-end by default. To address these challenges, alternate approaches to assign QoS polices at the ingress of the network are required. This document describes an approach that provides a similar quality of experience as used with voice VLANs, but without relying on VLAN technology. With the approach described in this document, QoS markings are no longer applied based on static VLAN tags but instead are based on dynamic flow parameters such as IP address and port information. These flow parameters are specified dynamically by the UC&C infrastructure at call setup time via an application programing interface (API) exposed by an Automated QoS Network Service App to the UC&C application. In this use case, the static ingress VLAN tag used to determine which QoS markings to apply is replaced with a dynamic voice flow specification. Note that in either case, the rest of the network would be pre-provisioned to trust the QoS markings dynamically applied in the network edge via SDN. No attempt or requirement is made to dynamically apply QoS markings to the network elements in the network core (this is something an Automated QoS Network Service App could implement, but is outside the scope of this document). The next section describes the interactions between the UC&C infrastructure and the Automated QoS Network Service Application in detail. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 5 of 22
4. Use-Case Interactions As explained in Section 2, the QoS approach presented in this document relies on an Automated QoS Network Service Application for enforcing the authenticity of voice and video traffic entering a network and for ensuring correct QoS markings on that traffic. The Automated QoS Network Service Application interacts with an SDN Controller to obtain information about the entire network topology. It uses topology information to identify the network elements through which voice and video traffic for specific sessions enters the network. The Automated QoS Network Service App also interacts with the SDN Controller for configuring QoS polices on individual network elements dynamically. These QoS policies can be invoked and retracted in almost real time speeds. Detailed interactions between the UC&C infrastructure and the Automated QoS Network Service App will be illustrated using the sample network topology as shown in Figure 5: SDN Controller with Automated QoS Network Service App Access Switch AP Wi-Fi Branch 2 Access Switch Branch 1 Figure 5. Sample Topology for Automated QoS Use Case The following presents the detailed flow and logic for managing QoS policies in this topology. We start with the basic use case where QoS is programmed on physical network elements within a single administrative domain. We discuss handling of UC&C signaling traffic as well as UC&C media traffic. We then briefly touch on more advanced scenarios that involve Network Address Translation (NAT), virtual networks, roaming endpoints, etc. Note that the flows below assume that a human operator has programmed the initial QoS policies for a given network to remark all traffic entering the network into the Best Effort (BE) CoS. Dynamic QoS for UC&C Signaling Traffic Dynamic QoS for UC&C signaling traffic is handled as follows: 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 6 of 22
1. When UC&C Infrastructure starts up, it authenticates with the Automated QoS Network Service App to establish a secure API connection. 2. The UC&C Infrastructure then interacts with the Automated QoS Network Service App to request that UC&C Signaling traffic is processed using the appropriate Class of Service. In response, the Automated QoS Network Service App programs an additional QoS policy on the network elements to ensure that UC&C signaling is marked using a higher prioritization CoS. UC&C signaling traffic is identified using the well know transport and port numbers used by the UC&C signaling protocol. The QoS policy can also include the IP address(es) of the UC&C infrastructure to make sure that only signaling traffic sent to the UC&C infrastructure receives preferential treatment. Figure 6 below shows a UC&C system that uses SIP over SSL as the signaling protocol. SIP over SSL uses TCP on port 5061. This SIP traffic is remarked by the signaling traffic QoS policy with Class Selector 3. SDN Controller with Automated QoS Network Service App create_policy Mark SIP Signaling CS3 AP Wi-Fi Access Switch Branch 2 Access Switch Branch 1 Figure 6. Creating a QoS Policy for UC&C Signaling Traffic Note that the UC&C Infrastructure may install bandwidth limits on the signaling traffic (based on estimated message traffic) to mitigate Denial of Service attacks in in the signaling CoS. 3. When a user starts the UC&C user agent, that user agent exchanges signaling traffic to register with the UC&C infrastructure. Using the QoS policy previously installed by the Automated QoS Network Service App, this UC&C signaling traffic between the user agent and the UC&C infrastructure is remarked to a higher priority class (in this example CS3). The UC&C infrastructure can optionally install additional policies to treat signaling traffic from authenticated or known users at an even higher priority. 4. When a user initiates a UC&C session, its user agent exchanges signaling protocol messages with the UC&C infrastructure to request the start of a session. Using the QoS policy 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 7 of 22
previously installed by the Automated QoS Network Service App, this UC&C signaling traffic between the user agent and the UC&C infrastructure is remarked to a higher priority class (in this example CS3) In response to a request to initiate a session, the UC&C Infrastructure further exchanges signaling protocol messages with the UC&C endpoint destination as specified by the session initiator. Leveraging the same QoS policy, this signaling traffic also receives the appropriate priority treatment. Figure 7 shows the SIP signaling traffic and its associated QoS treatment as applied by the Automated QoS Network Service App. SDN Controller with Automated QoS Network Service App AP Wi-Fi CS3 CS3 CS3 CS3 CS3 BE BE CS3 CS3 Branch 2 CS3 Access Switch CS3 Branch 1 Figure 7. Automated QoS Treatment of UC&C Signaling Traffic 5. Once a session has been established, the UC&C endpoints involved in that session may exchange additional signaling messages to manage the session or to terminate the session. Just like the initial session setup messages, these signaling messages will receive priority treatment as specified by the QoS policy. Dynamic QoS for UC&C Media Traffic Whereas QoS policies for UC&C signaling traffic are pre-programmed by the Automated QoS Network Service App as a persistent policy at start-up time, QoS policies for UC&C media traffic are programmed dynamically in response to session initiation requests. This section describes the control flows involved: 1. The UC&C user agents involved in a session exchange messages through the UC&C infrastructure to negotiate the media flows involved in the session as shown in Figure 7. Note that most UC&C sessions involve multiple media flows: a. Interactive sessions require at least two flows (one flow in each direction). 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 8 of 22
b. Sessions may involve more than one media type (e.g. video or presentation data as well as audio). c. Multiple streams of the same media type may be involved (e.g. stereo audio, or presentation video as well as live camera video). The UC&C user agents involved in the session start exchanging these media flows as soon as the session has been established. Unlike signaling traffic, media traffic may not necessarily be routed through the UC&C infrastructure and media traffic may be sent directly between the user agents using a peer to peer model. 2. Each of the media flows associated with a UC&C session can be uniquely identified using a 5 tuple consisting of the flow s source IP address, destination IP address, network protocol, source port, and destination port. The UC&C infrastructure extracts this 5-tuple for each of the flows from the signaling messages exchanged by the UC&C user agents involved in the session. Once the UC&C infrastructure has extracted information about the set of flows involved in the session, it instructs the Automated QoS Network Service App to create the necessary QoS policies to ensure that these flows receive the appropriate QoS treatment as shown in Figure 8. Requests to create QoS policies include the following information for each of the flows: a. The 5 tuple that uniquely identifies the flow b. A set of parameters that specify which QoS treatment each flow should receive. Depending on the latitude of the interface, different types of parameters may be relevant as will be discussed below. Note again that media traffic may start flowing before the UC&C infrastructure has informed the Automated QoS Network Service App of these media flows (and consequently before the Automated QoS Network Service App has programmed any QoS policies on the relevant network elements). Media traffic does not block while waiting for the associated QoS policies. As a result, media traffic will initially get processed by the network elements without QoS treatment and will be forwarded as Best Effort traffic as shown in Figure 8. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 9 of 22
SDN Controller with Automated QoS Network Service App create_session Branch 2 AP Wi-Fi Access Switch BE BE BE BE BE Access Switch BE Branch 1 Figure 8. UC&C Request to Apply QoS Treatment to Media Traffic 3. In response to a QoS policy request, the Automated QoS Network Service App does the following: a. It determines the ingress and egress network elements for the media flow(s) specified by the 5 tuples in the QoS policy request b. It installs the appropriate QoS policies on these network elements based on the QoS parameters contained in the policy requests. Note that this may involve translating QoS-related parameters into specific DSCP markings. The specifics of how such translation is handled is vendor and implementation-specific and outside the scope of this document. As soon as the Automated QoS Network Service App programs the QoS Policies associated with the media flows, the ingress switches apply the new policy and retag the media flows from the Best Effort CoS to the CoS as specified in the QoS policy (typically EF CoS). All traffic originating from end points that contain the 5 tuple addressing of the media stream will get remapped correctly to the right QoS policy. Figure 9 shows how the Automated QoS Network Service App programs QoS policies on the ingress and egress network elements for the media flows which results in Expedited Forwarding (EF) treatment for those flows. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 10 of 22
SDN Controller with Automated QoS Network Service App Mark Media Traffic EF Branch 2 Access Switch AP EF Wi-Fi EF EF BE EF EF Access Switch EF BE Branch 1 Figure 9. Automated QoS Treatment of Media Flows 4. Once the session is over the UC&C infrastructure sends a request to the Automated QoS Network Service App to remove the associated QoS policies from the network elements. In addition, the Automated QoS Network Service App will automatically delete all QoS policies when it loses connectivity with the UC&C infrastructure. And finally, an aging function can be invoked so that QoS policies can be deleted if no traffic is detected after a certain period of time. The main value of the Automated QoS Network Service App is that the network is locked down from malicious tampering with the EF queue and only authentic VoIP media flows are allowed in the EF queues regardless if the UC&C end point(s) are simultaneously running voice, video and data from a single converged network interface and/or is mobile. Note that even with authenticated endpoints, the network may still be susceptible to Denial of Service attacks if the endpoints themselves become compromised or if authenticated endpoints are spoofed (e.g. on wireless access points). Mitigating those types of DoS attacks is outside the scope of this document. Updating QoS Policies While QoS policies are created at the start of a session, there is also a need for the UC&C infrastructure to update policies in the middle of a session to make sure that the SDN controller has the correct information about the network-related aspects of the call at all times. For example, if a call gets put on hold, media will no longer be transmitted. In that case, the UC&C infrastructure could inform the SDN QoS System that bandwidth consumption will be zero while the call is on hold so the network can behave more efficiently. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 11 of 22
Asynchronous Updates So far, we have discussed QoS treatment requested by the UC&C infrastructure at the start of a session. Occasionally, it may be necessary for the Automated QoS Network Service App to change the QoS treatment applied to flows in the middle of a session. For example, starting a new high-priority session may require reallocation of bandwidth resources that were previously assigned to lower-priority sessions. When the Automated QoS Network Service App changes the QoS treatment of a session, it needs to notify the UC&C infrastructure managing that session of those changes. This is done by sending asynchronous events from the Automated QoS Network Service App to the UC&C infrastructure. These asynchronous events contain information about the updated QoS treatment of the session. In response to such events, the UC&C system may take various actions as appropriate, for example: Changing audio and/or video codecs to optimize user experience within the constraints of the new QoS treatment. Turning video calls into audio-only calls. Terminating the session altogether (e.g. if the new QoS treatment cannot deliver an acceptable user experience). In addition, the UC&C infrastructure may signal QoS changes to the UC&C endpoints. For example, wireless endpoints may need negotiated QoS information so they can mark traffic with the appropriate WMM markings. Handling Network Address Translation Network address and port translation (NAT) introduces a number of complications that need to get handled: 1. Each NAT domain likely corresponds to a separate SDN domain as well. This means that in order to configure QoS in an end-to-end fashion, federation between these SDN domains is required. 2. When identifying flows using network information, the API needs to clearly specify pre-nat or post-nat information depending on which domain is handling the flow. Network Address Translation introduces the requirement for federation between Automated QoS Network Service Apps in different domains. Interface specifications for federation are outside the scope of this document. Handling Roaming Endpoints The Automated QoS Network Service App needs to correctly handle roaming endpoints on wireless networks: Many wireless networks organize multiple access points into a single layer 2 domain. In such environments, roaming endpoints do not introduce any new QoS requirements. In other wireless networks, endpoints may roam between access points that are in different Layer 3 domains, but endpoints maintain the same IP address using Mobile IP or roaming tunnel technologies. In such environments, the Automated QoS Network Service App may 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 12 of 22
need to be roaming-aware so it can correctly account for the tunnel between the roaming endpoint and its anchor networks. Endpoints that roam between different mobile (4G/LTE) and wireless (Wi-Fi) networks will require different IP addresses on the different network interfaces, and the UC&C application may establishing a new make-before-break UC&C sessions and then terminate any prior existing UC&C sessions. New QoS treatment will be applied when the UC&C infrastructure establishes the new call, and no extra requirements are put on the Automated QoS Network Service Application. In addition, if roaming within an SDN domain fails the Automated QoS Network Service App should be notified and may need to send an error to the UC&C infrastructure. Programming Flows on Virtual Networks The interactions in the previous section apply to campus networks where SDN Controllers control physical networks. In data centers, however, physical network edge switches are rapidly being replaced with virtual switches bundles with hypervisor software. To ensure isolation between multiple tenants or applications sharing the same physical infrastructure, virtual switches are often interconnected using virtual overlay networks that encapsulate virtual switch traffic inside a set of tunnels running on the physical underlay. Virtual overlays complicate the Dynamic QoS use case, since QoS markings are applied at the edge to application packets, which then end up as payload encapsulated inside the virtual overlay tunnels. To ensure proper QoS treatment, SDN controllers must ensure that the QoS markings on the payload are transferred to the packet headers of the tunnels that encapsulate the payload. Two approaches are possible to ensure that QoS markings are transferred from the virtual overlays to the physical underlays in a secure manner: Deploy one controller that manages both the physical underlay as well as the virtual overlay Deploy two separate controllers, one for the virtual overlay and one for the physical underlay. These controllers must establish a trust relationship between them that allows them to communicate in an east-west fashion. 5. Operations In order to support the flows outlined above, the Automated QoS Network Service App needs to support a number of operations. These operations can be defined based on at least two different viewpoints: 1. A session point-of-view that makes the Automated QoS Network Service App aware of sessions that are admitted on the network and specifies the appropriate QoS treatment for those sessions. 2. A policy point-of-view that exposes functionality to manage QoS policies directly. Session-Based Model Session-based operations inform the Automated QoS Network Service App of sessions (and their associated flows) that are admitted on the network. These operations are initiated by the UC&C 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 13 of 22
infrastructure and sent to the Automated QoS Network Service App. Session-related operations follow a standard CRUD (create/read/update/delete) model where each of the operations takes a session parameter that uniquely identifies the session on the network. This session parameter contains the media flows for the session and the associated treatment that specifies how the UC&C infrastructure would like the SDN controller to handle these flows. In the context of this document, the treatment will typically refer to the requested QoS treatment that the UC&C infrastructure would like to be applied to the flows, but we expect the same model to apply to security and traffic engineering policies as well. When specifying the requested QoS treatment, the UC&C system will indicate for each flow the application class for the flow (the DiffServ treatment of the flow) and the amount of bandwidth required for the flow (the IntServ treatment of the flow). Using this model, the UC&C infrastructure requests DiffServ treatment by specifying the application class from the set of alternatives specified in the Automated QoS Network Service App API. It is then up to the Automated QoS Network Service App to translate application classes into the network QoS parameters such as DSCP points. The specifics of this translation are outside the scope of this document, but will take into account requirements for limiting latency, for limiting jitter, and limiting packet loss. Using this model, the UC&C infrastructure will not be able to directly program the low-level QoS markings that are to be used for the flow. While allowing applications to program DSCP markings on flows may be attractive for maximum flexibility, it relegates decisions about QoS markings to the UC&C layer, which implies that QoS policies are managed in that layer. This may not be the best approach when multiple UC&C systems are deployed and QoS has to be managed across those multiple UC&C systems. In that case, it is preferred to manage QoS policies in the Automated QoS Network Service App. Each operation returns a response that indicates whether the request was successfully executed or not. In case of a failure, an error code is returned that indicates the nature of the error. In case of successful execution, the SDN Controller returns information about the actual treatment that was applied to the flows in the session. Note that the actual treatment may differ from the requested treatment because of policies in the Automated QoS Network Service App or because the weakest link in the flow may prevent the requested treatment from being applied. Therefore, the Automated QoS Network Service App will return the actual QoS treatment that was applied. In addition, the information contained in the response may include low-level network information that cannot directly be programmed by the UC&C infrastructure, but that may be required by UC& endpoints to take optimal advantage of the configured network QoS parameters. For example, UC&C infrastructure may need to know exact DSCP control points programmed on the network elements so these can be mapped to Wireless Multimedia Extensions (WMM) markings on Wi-Fi networks. In addition, this allows the UC&C infrastructure to configure a trusted UC endpoint (e.g. an IP phone) to use this DSCP value for its media and avoid the need for static configuration of UC&C endpoints. Aside from requests initiated by the UC&C infrastructure, the Automated QoS Network Service App can also send events asynchronously to the UC&C infrastructure to notify UC&C systems of changes in the underlying network. For example, as described earlier, starting a new highpriority session may require reallocation of bandwidth resources that were previously assigned to lower-priority sessions. The Automated QoS Network Service App notifies the UC&C 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 14 of 22
infrastructure of changes in allocated bandwidth or QoS treatment through asynchronous events. These events include the same information as what is returned in response to a request initiated by the UC&C infrastructure. Based on this discussion, the session-based model includes the following requests: session_start(session) This request allows the UC&C infrastructure to signal the start of a session to the Automated QoS Network App. The session argument includes the requested QoS treatment for this session. session_read(session) The UC&C infrastructure uses this request to obtain information about a specific session from the Automated QoS Network Service App. session_update(session) The UC&C infrastructure uses this request to inform the Automated QoS Network Service App of updated session attributes. session_end (session) The UC&C infrastructure uses this request to inform the Automated QoS Network Service App that a session has ended. In addition, the session-based API includes the following asynchronous event: session_changed(session, reason) An asynchronous notification that is sent by the Automated QoS Network Service App to inform the UC&C infrastructure that QoS treatment of a session has changed. Policy-Based Model Whereas the session-based model operates on sessions that group multiple media elements, each with associated flows, the policy-based model operates directly on flows. Using this model, the UC&C infrastructure requests that the Automated QoS Network Service App install policies on the network to apply specific QoS treatment to groups of flows, independent of whether these flows are part of the same session or not. This makes a policy-based model more appropriate for long-lived flows such as the flows associated with signaling traffic. Like the session-based model, the policy-based model uses create/read/update/delete operations as follows: policy_add(policy_element) The UC&C infrastructure uses this request to create a new QoS policy in the Automated QoS Network App. The policy argument includes the requested QoS treatment for the flows specified in the policy. policy_read(policy_element) The UC&C infrastructure uses this request to obtain information about a specific policy from the Automated QoS Network Service App. policy_update(policy_element) The UC&C infrastructure uses this request to request that the Automated QoS Network Service App update attributes associated with a specific policy. policy_delete(policy_element) 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 15 of 22
The UC&C infrastructure uses this request to remove a specific QoS policy from the Automated QoS Network Service App. 6. Information Model Session-Based Information Model Operations that communicate information about the sessions admitted on the network include the information elements shown in Figure 10. Note that the tree representation in this figure is intended to show a hierarchical breakdown of the top-level session element (as opposed to a set of tables in a relational database). In this figure, information elements that are linked into the tree using dashed lines are optional. In addition, individual fields that are shown in blue are optional as well. Session Element Start time Session ID Group ID User Media Media Media User Element User name User ID Media Element Flow User ID QoS Requested QoS Granted Age-out Timer Flow Element IP address type Source IP address Source IP port Dest. IP address Dest. IP port Transport Granted QoS Actual class DSCP Actual bandwidth Requested QoS Application class Avg. bandwidth Min bandwidth Max bandwidth Figure 10. Session-Based Information Model The following describes each of the sub-elements in detail: Session Element This section describes information elements sent by the UC&C system to the Automated QoS Network Service App. Each of the requests sent to the app includes an information element related to the session as a whole. In the information model presented here, a session refers to a connection between two user agents. These user agents could be end-user devices (such as VoIP phones, UC&C soft clients, telepresence systems, etc.) or infrastructure components (such as audio bridges, multipoint control units (MCUs), video routers, gateways, etc.) Using this model, a multi-party call or conference is represented by multiple sessions, one for each participant in 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 16 of 22
the conference, since each conference participant establishes a separate session with the conference bridge. Sessions belonging to the same multiparty conference share the same group field that uniquely identifies the conference. Detailed session information is as follows: Name Type Cardinality Description Start Time Timestamp 1 Time when the session started. Session Session ID 1 Uniquely identifies the session. This can be used for grouping media elements that belong to the same session. Group Group ID 1 To support conference calls consisting of multiple sessions. User User Element 0..2 Optional media elements describing one or both of the users involved in the session to allow SDN controllers to implement userbased policies. Media Media Element 1.. n Information element describing the various media flows in the session and the corresponding QoS treatment. User Element Information elements related to each of the users associated with a session. Name Type Cardinality Description User Name String 1 String name that uniquely identifies the user. User ID String 1 User ID that uniquely identifies the user. Media Element Information elements related to each of the media flows associated with a session and the corresponding QoS treatment. Name Type Cardinality Description Flow 5- Tuple 1 5-Tuple that uniquely identifies the flow. User ID String 1 To correlate this flow with the user from whom this flow originates. QoS Requested QoS Granted Requested QoS Element Granted QoS Element 1 Desired QoS treatment for this flow. 1 Applied QoS treatment for this flow Age-out Timer Timer 0..1 Optional timeout value that specifies how long the flow can be inactive before the SDN controller determines to remove it. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 17 of 22
Flow Element The following information elements uniquely identify flows: Name Type Cardinality Description IP Address Type IPv4 or IPv6 1 Specifies whether IPv4 or IPv6 is used. Source IP IP Address 1 Source IP address for the flow Source Port IP Port 1 Source IP port for the flow Destination IP IP Address 1 Destination IP address for the flow Destination Port IP Port 1 Destination IP port for the flow Transport Transport Type 1 Transport protocol used for the flow Note that for video, some packets may be more important than others, e.g. the base layer in H.264 SVC (Scalable Video Coding). If different QoS treatment is required for different layers in a given video stream, the UC&C infrastructure needs to use several network flows with different UDP or TCP ports for the different layers to allow the Automated QoS Network Service App to uniquely identify and differentiate between these layers. QoS-Related Information Model When specifying the requested QoS treatment, the UC&C system uses the Requested QoS information element as follows: Name Type Cardinality Description Class Application Class 1 Application class for the specified flow Avg Bandwidth Number 1 Average bandwidth used by the flow (in kb/s) Min. Bandwidth Max. Bandwidth Number 0..1 (Optional) minimum bandwidth required by the flow (in kb/s) Number 0..1 (Optional) maximum bandwidth allowed for the flow (in kb/s) Application Class The Application Class Information Model is as follows: Name Type Cardinality Description Value Enumeration [ Interactive Voice Interactive Video Interactive Multimedia Broadcast Video Streaming Multimedia 1 Interactive Voice - Enterprise Voice, IP Telephony, Audio Conferencing (sensitive to latency, jitter, packet loss) Interactive Video - Real-time video conferencing, Telepresence (sensitive to latency, jitter, packet loss) Interactive Multimedia Desktop Sharing, 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 18 of 22
Signaling Transactional Bulk Data Best Effort Scavenger ] Virtual Collaboration, interactive multi-player gaming Broadcast Video Broadcast/multicast video, video surveillance (typically one-way video, sensitive to packet loss) Streaming Multimedia Streaming video, streaming audio, YouTube, Pandora (typically uses client-side buffering and can retransmit lost packets) Signaling - Call Signaling (e.g. SIP, H323) Transactional - Latency sensitive data applications Bulk Data - Email, file transfers, software updates, and backups Best Effort - Default service Scavenger - Low priority traffic, below best effort In response to these requests, the Automated QoS Network Service App sends responses back to the UC&C infrastructure that contain the Granted QoS treatment applied to each of the flows. These information elements look as follows: Name Type Cardinality Description Actual Class Application Class 1 Actual class for the specified flow DSCP Number 1 DiffServe Code point for the flow in decimal Actual Bandwidth Number 1 Actual bandwidth allocated for the flow (in kb/s) Return Codes Information Model Information returned by the Automated QoS Network Service App to the UC&C infrastructure may contain: 1. Errors to indicate a failed operation. 2. Reason to provide context to asynchronous events. Errors and reasons both use the Return Code information Model: Name Type Cardinality Description Return Code Enum 1 Standard return code Return String String 1 Human-readable string providing additional context Additional Considerations The Session-Based Information Model may need to take additional considerations into account: 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 19 of 22
1. The information model may need to include an element that indicated whether silence suppression is being used so that the bandwidth parameters can be handled accordingly. 2. Is there a need to specify that multiple media streams need to remain synchronized? 3. Is there a need to specify that different media flows need to take the same path? 4. Is there a need to specify that packet order is important and needs to be maintained (e.g. to compensate for lack of jitter buffer)? Policy-Based Model The policy-based information model is very similar to the session-based model, with the following exceptions: 1. There is no longer a need for per-session-related information elements. Instead, policies apply directly to flows. 2. Flow-related media elements need to allow for ranges and wildcards in IP address and IP port fields. The resulting information model is shown in Figure 11. As before, optional fields are shown in blue. Flow Spec Element IP address type Policy Element Flow spec QoS Requested QoS Granted Src. IP addr. range Src. IP port range Dest. IP addr. range Dest. IP port range Transport Requested QoS Granted QoS Actual class DSCP Actual bandwidth Application class Avg. bandwidth Min bandwidth Max bandwidth Figure 11. Policy-Based Information Model Specific information elements are as follows: Policy Information Element Policy Information elements specify the group of flows to which the policy applies and the requested QoS treatment for this group of flows. The information elements to specify requested and granted QoS treatment are identical to those used in the session-based information model. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 20 of 22
Name Type Cardinality Description Flow Flow Spec 1 flow specs that identify the flow ranges to which the policy applies QoS Requested QoS Granted Requested QoS Element Granted QoS Element 1 Desired QoS treatment for this policy. 1 Applied QoS treatment for this policy. Note that in this model, it is possible to specify overlapping flow ranges. How the Automated QoS Network Service App resolves overlapping ranges is an implementation issue and outside the scope of this document. Flow Spec Information Whereas Flow information elements uniquely identify individual flows, Flow Spec Information elements identify groups of flows by allowing wildcards and ranges when specifying IP addresses and ports: Name Type Cardinality Description IP Address Type IPv4 or IPv6 1 Specifies whether IPv4 or IPv6 is used for this flow range Source IP Range Source Port Range Destination IP Range Destination Port Range IP Address Range 1 Source IP address range for the flow IP Port Range 1 Source IP port range for the flow IP Address Range 1 Destination IP address range for the flow IP Port Range 1 Destination IP port range for the flow Transport Transport Type 1 Transport protocol used for the flow Note that with this information model, different flow specs are required for IPv4 and IPv6 ranges. It is not possible to mix IPv4 and IPv6 in the same flow spec. Different transport types also require different flow specs. For example, if the policy allows both UDP and TCP signaling (TLS), different flow specs are required: one for UDP and one for TCP. The Requested QoS Information Element is as follows: Name Type Cardinality Description Class Application Class 1 Application class for the specified flow Avg Bandwidth Number 1 Average bandwidth used by the flow (in kb/s) Min. Bandwidth Number 0..1 (Optional) minimum bandwidth required by the flow (in kb/s) 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 21 of 22
Max. Bandwidth Number 0..1 (Optional) maximum bandwidth allowed for the flow (in kb/s) In response to these requests, the Automated QoS Network Service App sends responses back to the UC&C infrastructure that contain the Granted QoS treatment applied to each of the flows. These information elements look as follows: Name Type Cardinality Description Actual Class Application Class 1 Actual class for the specified flow DSCP Number 1 DiffServe Code point for the flow Actual Bandwidth Number 1 Actual bandwidth allocated for the flow (in kb/s) 7. Authors Manfred Arndt Rajiv Kambli Thenu Kittappa Chris Lauwers Pascal Menezes Shambhu Rai Dale Tonogai Hewlett-Packard Company Aspect Software, Inc. Aruba Networks, Inc. Ubicity Corp. Microsoft Sonus Shoretel, Inc. 2/27/2014 Copyright UC Interoperability Forum, 2014 Page 22 of 22