UC and SDN: Applications Controlling Networks
The recent Microsoft Lync Conference in Las Vegas drove home the important point that there’s more to software defined networking (SDN) than the hope of a cheaper router. Spearheaded by Pascal Menezes, Principal Program Manager in the Skype and Lync Strategic Relations and Solutions group at Microsoft and Manfred Arndt, Distinguished Technologist at HP (both companies are board level founders of the UCI Forum), the program featured a number of sessions dealing with the various impacts of SDN on the UC user experience (UX).
Given that UC deals with applications (i.e. Layer 7) and SDN deals with networks (Layer 3 and below), many people struggle to grasp the relationship. The truth is that up until now, applications and networks have largely operated independently of one another, with the result being complexity, difficult set-up, unpredictable outcomes, and problems in troubleshooting. These problems impact UX, particularly in the real time voice and video services that are key to UC. According to Mr. Menezes, network issues are at the heart of 60 percent to 80 percent of quality of experience failures.
So why is it so hard to get applications and networks to work together smoothly? The basic problem is that real time voice and video place special demands on IP networks. To be a little more specific, real time traffic needs quality of service (QoS) features to minimize latency, packet loss, and jitter (the variation in packet-to-packet delay). Data is not as time sensitive as real time traffic, and it can use TCP along with IP to recognize and retransmit lost packets. The time frames for voice and video are far more demanding, and if packets are lost, the process of detecting and resending them would take so long that they would have no relevance to the conversation; that’s why voice and video use UDP rather than TCP.
As it stands today, providing decent voice and video performance requires that QoS features be pre-provisioned so the packets are provided an appropriate path to travel over; that “pre-provisioning” is easier said than done. Network engineers must first ensure that voice and video packets have appropriate header marking (i.e. “Diff Serv Control Point” or “DSCP”settings) that identify them to the network as voice or video. Then all of the switches and routers along the path must be set to recognize those DSCP settings and to allocate the appropriate priority to each packet.
In practice, the job is even more challenging. As it turns out, DSCP settings are a Layer 3 (i.e. “IP”) function. There are other QoS mechanisms like 802.1p and Wi-Fi Multi-Media (WMM) that operate at Layer 2. At each juncture where the QoS mechanism shifts, a network engineer must populate a table that maps each DSCP setting to the appropriate equivalent 802.1p or WMM setting; then they have to remember to do it in the other direction, too! Of course if later someone tinkers with the router settings anywhere along the route, those priority fields might be stripped off, QoS disappears, and users start getting poor voice or video quality.
For QoS to deliver in such an environment, every element from the client through all of the switches, routers, Wi-Fi controllers, and carrier services must be set correctly (“manually”), and nothing can change. Further, the overall process works primarily in private networks with little visibility into carrier-provided services. Given the dynamic nature of enterprise networks, it’s easy to see this is a house of cards.
The difference with UC SDN is we provide a mechanism whereby the application can tell the network, specifically the SDN network controller, that it needs to set up a voice or video connection (including such things as how much bandwidth it will require), and the SDN controller can in turn pass the necessary instructions to the network elements (i.e. switches, routers, WLAN controllers, etc.) to automatically provision the appropriate QoS for that connection.
As one can see that’s a pretty big job, but fortunately, the essential elements for SDN have already been put into place. The Open Networking Foundation (ONF) has been at work developing a protocol called OpenFlow that allows SDN network controllers to send instructions to network elements. Last year, the ONF set to work on what they call the “Northbound Protocol” allowing things like UC controllers (i.e. the servers that make connections in a UC environment) to talk directly to the SDN controller.
By allowing the application through the UC controller to talk directly with the SDN infrastructure, one can eliminate the complexity, inflexibility, and inherent unpredictability of network pre-provisioning, and deliver a network service that responds dynamically to the needs of the users.
In a nutshell, that’s what UC SDN is about, allowing applications to order specific types of connections from the network. Beyond QoS provisioning and network diagnostics, the UC SDN capabilities are expanding to support services for streaming, gaming, and other applications. Going forward, the UCI Forum is looking to extend the UC SDN capabilities into call admission control, traffic engineering, automated diagnostics, security, firewall and WLAN orchestration. Essentially, the longer term program is to extend those application-driven controls throughout the network infrastructure.
While those initiatives will take longer to develop, the UC SDN program signals an important leap forward. After decades where networks and applications essentially operated independently of one another, by providing this key linkage, we can finally have an environment where the complex multimedia services required in a UC solution can be provisioned automatically.
The networking industry has been struggling to come to grips with what SDN will mean and where its impact will be felt. While most of that conversation has centered on cheaper routers and data center networking, the UC SDN takes the conversation in a new and potentially far more interesting direction. While it does involve some tricky technology, in the end, the big impact will be user experience and making high quality voice and video calls a predictable outcome in UC.
UCI Forum will be at Enterprise Connect March 17-20 in Orlando. An open reception is taking place March 17 from 6:30-7:30 p.m. to discuss the formation of a Unified Communications Enterprise User / Interest Group. Those interested in attending should register here. Also at EC, Pascal Menezes, Chair of the UCI Forum UC SDN Task Group and Principal Program Manager for Skype / Lync Partner Engineering at Microsoft will be presenting a session on UC and Software-Defined Networking (SDN) on Wednesday, March 19 at 2:30-3:15 p.m. Details are available here.
Organizations interested in joining UCI Forum in this work can go to the Forum's "Join" page.
Also on UCStrategies.com on this topic: