Pascal Menezes is chair of the International Multimedia Telecommunications Consortium (IMTC) unified communications (UC) SDN Task Group, a UC Strategies Experts, vice-chair of the Open Networking Foundation (ONF) northbound interface group, advisory director to MEF, and former vice-chair of Wi-Fi Alliance’s (WFA) newly formed Wi-Fi Mobile Multimedia Task Group.
SDxCentral: We’ve spoken in the past about the role of SDN in unified communications and collaboration (UC&C) systems. Seems like the industry and IMTC are continuing to make progress on this front. In some of the early POCs, we saw SDN being used to provision paths with the right QoS for UC&C connections, and then subsequently SDN being used to dynamically follow endpoint clients as they moved around in the network. Can you tell us what’s new on the UC&C and SDN front?
Menezes: There have been so many advancements in the UC&C and SDN front that I am so delighted to be part of this great initiative. Just this past year, the ONF took the first IMTC use case specification Automating Unified Communications Quality of Experience (QoE) Using SDN and released an official standardized Real-Time Media northbound interface (NBI) specification with reference code. Then we spun up an open source project called Project Aspen under the ONF open source SDN GitHub. NEC took the IMTC Automating Unified Communications Quality of Experience (QoE) use case spec, the ONF Real-Time Media NBI technical spec, and the ONF Real-Time Media reference code and built out an open source version using OpenDaylight as the SDN Controller. NEC then deposited this into Project Aspen and now, we have a real open source working implementation of automating UC&C quality of experience.
But it gets even better. During the SDN and OpenFlow World Congress held in Germany this past October, Fabian Schneider, NEC’s top SDN research scientist, demonstrated Project Aspen to the show attendees. Project Aspen was such a hit that it won Best of Show. A great video of the demo can be found here. One interesting thing about this award is that it got voted on by show attendees and not judges, which we feel is a strong testimonial of the important work that IMTC and ONF are driving. We firmly believe the power of UC SDN transforms the industry by not only helping lowering the cost to deploy UC&C, but also making it much easier to manage these deployments, or any other real-time media application for that matter.
Now if that wasn’t enough, IMTC has just released a follow-on use case specification called automating diagnostics using SDN, which builds on top of our previous Automating Unified Communications Quality of Experience specification. They are complementary use case scenarios that work together.
So on this automated diagnostics service, can you explain what it does and why is it needed?
Menezes: The main goal is to improve the user experience by collecting the metrics needed to identify the source of issues and automatically resolving them when possible. The IMTC automated diagnostics SDN spec describes how to leverage an SDN network and open standard NBI to combine pertinent network element information along with UC&C session metrics in real-time, thereby providing comprehensive visibility and automated problem resolution for all voice, video, and desktop sharing sessions in-flight or any period thereafter.
Think about how often users experience a poor quality voice or video session and then blame the UC&C application, when it was really the network causing the issues. Modern, real-time codecs try their best to recover from network impairments, but there is only so much an application can do when the network becomes congested or slows down. The automated diagnostics SDN use case describes how to automate root cause analysis without requiring highly trained IT admins, complex diagnostic tools or costly probes everywhere. It does this by correlating detailed per session UC&C metrics with network topology information and using analytics to figure out why and where a call went bad. Not only can it help pinpoint specific network segments responsible for a poor call, but it can also help diagnose end-point devices to see if they are the source of bad calls due to issues like an old WiFi driver, excessive noise caused by cheap headsets or microphone placement issues. If you could imagine how time consuming and tedious it is to troubleshoot poor quality calls — especially for large-scale deployments — then one can appreciate the compelling benefits of an automated diagnostic system.
Why can’t this be achieved today with traditional network management solutions?
Menezes: Today IT administrators typically rely on network counters/statistics, distributed probes, and synthetic traffic tools to diagnose UC&C quality problems.
When using statistics and counters a network management system typically monitors all relevant interfaces on the network and do so at sufficiently large intervals to avoid scalability challenges (excessive monitoring may overload the monitoring server, network or other resources of the network elements). As a result, traditional network counters and statistics are not granular enough to effectively diagnose individual UC&C quality problems since it does not track the path of active UC&C sessions, nor does it collect enough relevant data at the proper frequency.
Probes provide more detailed monitoring about the voice and video quality experienced by end-users. They do so by passively inspecting voice and video traffic on specific network segments. Probes then use this to extract quality-related parameters such as latency, jitter, MOS scores, etc. While at first glance probes might look like an adequate solution for UC&C monitoring and diagnostics, they suffer for a number of reasons. The effectiveness of probes for root-cause analysis is dependent on where and how many probes are deployed. Ideally, probes should be deployed at every router and switch port in order to get pinpoint accuracy. This is unlikely to happen since the cost to deploy probes adds an increased capital cost to the adoption and deployment of UC&C applications. Finally, probes may not be able to detect and analyze encrypted UC&C media flows which further reduces their effectiveness.
Synthetics is an active testing process that generate “artificial” test traffic that simulates voice and video sessions with the goal of analyzing and predicting the quality and capacity that can be expected between specific network locations and paths being tested. While synthetics are quite useful for capacity planning and network pre-assessment, synthetics are most commonly used during the UC&C installation process or during off-peak hours when they are not likely to interfere with live production traffic. Using synthetics to help diagnose problems can exacerbate the problem. A less intrusive and more real-time mechanism is required to address the fine-grain diagnostics requirements of UC&C applications.
What are the key benefits to using this Automated Diagnostics approach with SDN? What does SDN allow that is valuable to the network operator?
Menezes: The benefit of UC SDN is that it provides visibility to assist with root cause analysis of UC&C quality issues. It can also automate problem resolution without requiring dedicated probes, synthetics, etc. UC&C applications inform the Automated Diagnostic Service (ADS) in the form of a real-time media NBI (i.e.: UC SDN API), with a rich set of quality information whenever new UC&C sessions are being setup, torn down, and when quality problems occur. This enables the following interactions:
- Targeted Network Data Collection: The ADS interacts with UC&C applications to track UC&C sessions that are active on the network. It leverages SDN Controllers to obtain topology and path information for these sessions. It can selectively monitor the network interfaces along these paths. This targeted monitoring addresses some of the scalability constraints of traditional network management tools.
- UC&C Data Collection: The ADS interacts with UC&C applications, using the UC SDN API, to collect metrics that provide a comprehensive end-to-end view of the quality of active and completed call sessions. These metrics are more effective than those that could be collected from using only probes, because these metrics are available from any point of the network, not just the network segments with probes.
- Automated Problem Reporting: Based on information about session quality and their paths, the ADS can correlate network-centric metrics (examples are throughput and packet loss) with application-centric metrics about voice and video quality to provide a comprehensive view of the overall health of the system.
- Fine-Grain Network Data Collection: The ADS receives notifications from UC&C applications that indicate it should perform more detailed analysis of a given session. This may be in response to session quality thresholds being exceeded for a given session or set of endpoints. In response to these notifications, the ADS can increase the frequency at which network counters and statistics are being polled, or request more detailed metrics from the network controller. The goal is to pinpoint the exact network interface, link, or devices contributing to the quality issue.
- Automated Problem Resolution: Additionally, the ADS may interact with other UC SDN components to automatically resolve quality issues such as using the Dynamic Traffic Engineering functionality (described in the previous IMTC use case) to reroute a UC&C session experiencing quality issues around a congested link.
Can you provide a quick overview as to the automated diagnostics architecture and how it would fit in an infrastructure?
Menezes: As shown in Figure 1 below, the automated diagnostics service includes the following functional modules:
- Session Monitoring: this module tracks active session on the network and collects the relevant quality metrics for these sessions using the following two submodules:
- UC&C Data Collection: this module interfaces with UC&C applications to collect diagnostics information from the associated applications and corresponding endpoints.
- Network Data Collection: this modules interfaces with network elements to collect diagnostics information from the associated network interfaces.
- Problem Resolution: this module is responsible for identifying root causes of quality problems and resolving issues if possible. Note that this module could interact with the Automated QoE SDN service if necessary to invoke the Dynamic Traffic Engineering functionality when needed.
- Data Repository: this module is responsible for storing all session quality and monitoring-related data collected by the ADS.
- Analytics: this module provides an analytics engine or similar system to try and identify specific patterns or trends that are a likely source of quality issues or may perform data correlation to identify and categorize known issues for more efficient troubleshooting.
- Policy: this module allows Administrators to create the desired policies and custom thresholds for the session monitoring, data collection, and analytics modules.
By interacting not only with the network but also with the UC&C applications, via the UC SDN API, the ADS is in an excellent position to not only diagnose the root cause of problems but also to automatically correct certain types of problems. The ADS can provide network and endpoint error resolution. The idea of an end-user application communicating with a SDN enabled network empowers powerful automation and agility not currently possible in legacy networks.
While this follow-on IMTC automated diagnostic using SDN use case specification is new, there are several vendors with commercially available solution including Aruba, a Hewlett Packard Enterprise company, and Nectar, which offers a subset of this UC SDN diagnostics functionality for use with Microsoft Skype for Business (formerly known as Lync). The benefit of having an open standard specification is that it will help drive multi-vendor interoperability and much broader adoption of UC SDN and NBI’s across the industry.
How does someone get involved in these efforts?
Menezes: If you are an SDN vendor, service provider, manage provider or an IT professional operating a UC&C environment and passionate about solving these types of issues, I recommend getting involved by joining IMTC and contributing to the IMTC UC SDN Activity Group. We need all hands on board to help us define additional more advanced use cases, like federation and security related scenarios that provide even more automation and agility especially as service providers and enterprises move into SDN and NFV cloud-scale architectures.