Executive View of UC SDN – Looking Up

Software defined networking (SDN) is one of the most exciting developments we have seen in the field of packet communications since its inception. The basic idea is to decouple the system that makes decisions about where packets are sent (i.e. the control plane) from the systems responsible for forwarding traffic to their destination (the data plane). The work of bringing this idea to fruition is being driven by the Open Networking Foundation (ONF), a nonprofit trade organization founded by Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo!. One of the key building blocks is the OpenFlow protocol that describes how the control plane, or more specifically the SDN Controller, would talk to the switches and routers that forward the packets.

Last summer, the ONF took an important turn and put together the North Bound Interface Working Group (NBI-WG), charged with providing standards that would allow applications to order services from the SDN Controller, which would in turn use OpenFlow to automatically configure an appropriate path through the network. Two of the companies that have chosen to run with this idea are HP and Microsoft.

HP already has a significant relationship with Microsoft as a key partner for its Lync unified communications (UC) solution, and the two are now collaborating on an important extension for SDN called UC SDN. The idea is to develop an open API so that Microsoft’s Lync Controller (more specifically the Lync Controller’s Front End) can communicate with HP’s Virtual Application Network SDN Controller. While that might sound like a minor issue, it is actually a major step forward with regard to applications dealing with networks.

Packet network requirements have grown more complex with the development of UC. In a UC environment, a single user may order up a variety of point-to-point or multi-point connections for voice, video, text, email, web conferencing, or screen sharing. The challenge is that each of those different connections requires different bandwidth and different quality of service (QoS) attributes. Providing that range of services in a traditional network required that network engineers first populate tables in all of the switches and routers along the route. When each session began, the end device would have to mark all of the packets for that session with the appropriate QoS level, and the switches and routers would then prioritize them according to those markings.

All of this involved a tedious and error-prone set-up process that could be horribly unreliable. The end devices would have to mark the packets for each session stream correctly at the outset, and if someone messed with the switch/router configurations they might wind up mishandling or even stripping off the priority markings altogether. The result would be most noticeable on real time voice and video streams where the quality of the user experience hinges on the network’s being able to minimize delay, jitter and packet loss for those streams.

What the UC SDN API provides is the ability for the application, in this case Microsoft Lync, to direct the network to automatically provision the path for the correct bandwidth and QoS requirements of each session. That also means the network set-up task is essentially eliminated, and the users are essentially guaranteed of getting a properly provisioned path for every session they initiate.

The initial focus of the UC SDN is on QoS, but there are a number of follow-on initiatives in the pipeline. The vision being proposed would expand the scope to include all of the elements in the network, including things like firewalls and intrusion detection systems, as well as switches and routers.

Another initiative looks to automate troubleshooting and network diagnostics. Currently a quality of experience (QoE) report is sent at the end of every call, providing the average mean opinion score (MOS) and average delay, jitter, and loss values for the session. The problem is that the performance is averaged over the entire length of the call, so the user may have experienced a few minutes of terrible voice quality, but the problem is masked by “averaging” the performance. The plan is to include QoE reports throughout the call, and the architecture allows probes at strategic points throughout the network that would read those reports as they passed by, providing the ability to identify the specific section of the path that is causing the problem.

While HP and Microsoft have been the primary drivers for UC SDN up until now, the goal is a truly open, programmable API that that could be used across all UC platforms and SDN implementations. Already WLAN switch manufacturer Aruba has implemented the API, and given the importance of SDN and the impact UC SDN can have on the UC user experience, we anticipate adoption throughout the UC community.

The key message is that applications and networks have operated independently of one another for too long, resulting in needless complexity and unreliability. By allowing applications and all of the elements in network to talk to one another, we can finally make a good quality voice or video connection an expected outcome in UC networks.

This paper is sponsored by HP.