Here’s the man driving unified communications (UC) SDN at Microsoft: Pascal Menezes, principal program manager of the Skype and Lync UC product group. As chair of the UC SDN Technical Group within the UCI Forum and vice-chair of the Northbound Interfaces (NBI) working group at the Open Networking Foundation (ONF), Pascal has a unique vantage point to observe the growing integration between UC and SDN. Here, he explains how having the right SDN controls and APIs can improve the performance and robustness of unified communications applications.
To set some context, can you give us an overview of the efforts you’ve been spearheading both within and outside Microsoft?
The central issue I’m working on with today’s information systems can be summarized simply: Applications and networks don’t talk to each other in a meaningful way. This means that we make customers buy expensive network equipment to do all kinds of stuff on a box-by-box basis, like deep packet inspection (DPI) to infer which applications are running and also to figure out how they are performing, causing a lot of complexity and a much higher TCO [total cost of ownership]. I have been involved in internetworking for almost 30 years and have witnessed internetworking evolution since the mid-80s. In my opinion, while we have made great progress optimizing the original internetworking paradigm, we are still living in the dark ages. We have not delivered on a paradigm shift of applications and networks working together collaboratively to provide network automation and agility for application service delivery.
With regard to UC, what do you see as the biggest challenges today in the infrastructure?
Menezes: Voice is the old world, and UC is the new world, which is more about a rich multimodal environment of seamless communication and collaboration, from anywhere at any time (IM, presence, voice, video, data collaboration, web conferencing, etc.) We hear from enterprises that UC provides an incredible productivity boost, and this is causing a global retooling from the traditional voice PBX paradigm.
However, UC is based on real-time media over an IP network, which is very dependent on the network performing smoothly — a poor network begets a poor UC end-user experience.
We find that 60 to 80 percent of poor UC end-user experiences, like bad audio quality, are caused by the network. This is due to the fact that traditional internetworking has poor visibility into real-time traffic, because most enterprise-grade UC systems use encryption for security, making DPI difficult and unreliable. QoS and traffic engineering are complex. They’re easily broken and requirew brute-force, static policies that must match application server settings. Intermittent UC problems are tedious to diagnose, especially for softphones and BYOD scenarios like user-provided mobile devices.
However, it’s not only about UC real-time media requirements, but the nature of how people are using UC — on mobile devices, in public networks, integrated with our business applications — all of which are rapidly outstripping the capabilities of the traditional 30-plus-year-old internetworking paradigm.
How do you expect to address these challenges, and where does SDN come into play?
Menezes: What if an application could communicate the requirements of multimedia sessions just as a session is being established? What if an application that is experiencing a quality degradation could also signal this in real time to the network so that the network can automatically heal itself (if it is the cause of the poor application performance)? What if a congested network could dynamically adjust latency-sensitive applications to a higher QoS priority or inform a video application to use a higher-compression codec, all without impacting the end-user experience? What if applications and networks can marshal all the elements needed, from intrusion detection through firewall traversal, load balancing, and admission control, so instead of having dozens of brittle configurations spread among multiple network devices and vendors, you have a single orchestration engine?
This is where UC SDN comes in. We think of SDN as a major paradigm shift in which applications talking to centralized software control planes will re-define the network (a video of this can be found here). This is in stark contrast to how people manually provision networks today, on a box-by-box basis via cryptic command-line interfaces — the complexities here are showing how quickly enterprises can deploy and take advantage of new applications like UC.
Can you walk me through an example of how UC and SDN could work together within an enterprise?
Menezes: Sure. Let’s take QoS and traffic engineering as an example.
We find that configuring and maintaining QoS within an enterprise is a large operational expense that has tremendous impact to latency-sensitive, real-time media like voice and video. Look at the diagram [below], which describes all the steps to configuring QoS. Now, this diagram depicts all the UC and QoS coordination that needs to take place. However, once completed, it does not stop here, as it needs to be continuously maintained. Each network element along the path has to be provisioned and maintained with the correct QoS settings; otherwise, real-time media traffic could be impacted during even short-lived congestion periods that tend occur frequently due to the bursty nature of TCP/IP.
That is the real heart of the issue. End users experience voice and video calls working perfectly some days, while on other days they complain that the voice and video quality is horrible. After brute-force investigation, we find that someone has misconfigured, upgraded or replaced some network element (a switch or router, for example) and never provisioned it correctly for QoS.
We call this configuration drift. Coupled with smartphones, mobility and Wi-Fi, traffic-engineering a network fabric the traditional brute-force way is not economical and has tremendous impact on UC as an application. As users with softphones move about the building while on video/VoIP calls, traditional internetworks don’t have the capability to automatically traffic-engineer themselves.
In your mind, why is UC a good early use case for the NBI in an SDN framework? Do you believe QoS to be fundamental to any NBI?
Menezes: When folks think of NBIs, most think of network service applications or virtualization orchestration tools. However we see NBIs as a rich ecosystem of SDN applications for which powerful abstraction models can be created.
UC as an end-user application can stack on top of and program network service applications like QoS, traffic engineering, diagnostics, IDS/IPS, and firewalls, thereby truly enabling end-user applications to communicate with networks. What makes UC so unique is that most of its real-time media flows are interactive and are long-lived (lasting minutes or hours). Many UC endpoints also collect real-time performance statistics that can provide actual call-quality-metric feedback to the network as to how well it is doing. When UC communicates to an SDN network service application, it can communicate to a myriad of them simultaneously and for different scenarios such as the ones I mention above.
We do not see UC SDN used for just QoS, but for a multitude of scenarios for which we are just scratching the surface. Each month, I meet with vendors that come up with new scenarios for consuming a UC SDN NBI. It is truly a platform for innovation in which we get power and open abstraction layers by stacking NBIs on top of each other [see diagram below].
How do you see a controller arbitrating between multiple applications all asking for the highest QoS? Aside from this, what hard problems still need to be researched and resolved?
Menezes: Notice [in the previous diagram] where the policy decision and provisioning resides. It is within the network service application layer, so that a network administrator can provision the desired “high-level” arbitration policies into their network. Then, the network service application uses those rules for how to handle contention as in the case of QoS.
However, as I said, QoS is just one scenario, and there will be many other scenarios each having their own policies, in terms of how an administrator may want that SDN network service application to operate for their organization.
The hard problem at this point is to get the industry to agree upon and define open NBI standardization, as we at Microsoft have real partners shipping real UC SDN products today that interoperate with Lync. However, as SDN network service applications mature, we don’t have NBIs that are open industry standards. This means that an SDN network service application that is running separately from the SDN controller would have to talk to a variety of vendor-specific, proprietary NBIs to each different manufacturer’s SDN controller, which complicates development and deployment. Also we don’t yet have standardization for a UC SDN NBI, which is what we are working on within the UCI Forum in concert with the ONF NBI working group.
How much of this is currently being worked on by the standards bodies? What role do you play?
Menezes: The UCI Forum has created a technical task group to figure out how to allow UC applications to communicate to the network. It is called the UC SDN task group and has a liaison agreement with the ONF NBI working group to work together to solve this. I am the chair for the UC SDN task group and vice-chair for the ONF NBI working group, which allows the two organizations to have a common resource to synchronize activities.
The UCI Forum UC SDN task group just finalized our first use case, which is in automating QOS [see here for the document, "Automating QoS."] Follow-on use cases involve scenarios that I’ve described above, including traffic engineering, automating diagnostics, security, and Wi-Fi. The UCI Forum and ONF NBI have a liaison agreement between each other in which the UCI Forum will define UC SDN use-cases and have the ONF NBI define the domain-specific NBI (such as the UC SDN NBI). Once defined, we hope to have a UCI Forum certification program in place to ensure interoperability.
What are the next steps in achieving the vision you laid out? How can interested parties get involved?
Menezes: First, get your networking and UC vendors to join and participate in the UCI Forum and ONF (to learn more about the UCI Forum, please complete the online interest form or join here). Second, include UC SDN capabilities in your RFP or RFI, because even if you don’t start implementing today, you’ll want a company who has a plan and vision here. Third, ensure your company is working well in the standards bodies, because getting a solution that’s “SDN-like” but doesn’t interoperate is just going back to the same old way of doing things — locking in companies to proprietary solutions — and our applications and users won’t go back to the dedicated hard-phone and landline model of yesterday.
We are witnessing the birth of applications programming networks in which internetworking can get launched into the 21st century from the almost 30-plus-year-old paradigms of traditional internetworking. Get involved and be part of the revolution any way you can!