Moving Voice and the Network to Software
By allowing Lync to leverage SDNs, Microsoft and HP could be changing the game.
Last week at the Open Networking Summit 2013, Microsoft, which has been working hard to move "voice" into software (operating on industry standard hardware) demonstrated its commitment to also assisting in moving networking functions into software (also operating on industry standard hardware). Microsoft and its partner HP demonstrated the ability of Lync (using specialized proof of concept extensions), along with the OpenFlow Software Defined Network (SDN) controller on HP hardware, to dynamically allocate QoS, bandwidth and other network characteristics in real-time.
My colleague Phil Edholm has a detailed No Jitter writeup of what was shown and how it works here. Another colleague, Dave Michels, provides another good summary in his UC Strategies article entitled "UC SDN PoC by HP and MS". (Perhaps also winning the award for most abbreviations and acronyms in an article title.) Phil and Dave did an excellent job of covering the demonstration details.
I spent 30 minutes talking with Jamie Stark, Senior Product Manager at Microsoft, about what this could potentially mean for UC and why businesses should care.
Jamie made it clear that the demonstration was using a new API that has so far been made available to only a small number of partners. These partners are working closely with Microsoft in "proof of concept" (POC) mode. Pascal Menezes, Senior Program Manager of the Lync Partner Engineering Group at Microsoft, is tasked with managing this "depth" program. As part of this program, lots of bi-directional feedback between Microsoft and the SDN partners is expected. This feedback and various POCs are expected to cause the existing API to evolve.
From a business perspective, allowing UC applications like Lync to talk directly to SDNs improves the prospects for effective and high-quality communications. Lync can ask the end-to-end network to provide the necessary "packet prioritization" (QoS or CoS) in order to deliver reliable video and audio. Beyond quality, Lync could ask SDN devices to ensure the proper firewall ports are open and available, effectively ensuring security on demand.
Anyone who has deployed a large UC-over-IP solution understands that ensuring end-to-end QoS today requires extensive configuration and testing. Lync, like all UC IP solutions, is totally reliant on the underlying network in order to deliver communication services. Lync and SDN offer a future where the complexity of initial and ongoing network and firewall configuration is greatly reduced. In this new world, the costs of moves, adds and changes (MACDs) is likely to be much less, and the risk associated with change is likely also greatly reduced.
Further, while this feature was not part of last week's demonstration, a SDN can provide information back to an application such as Lync. This would allow Lync to properly set user expectations ahead of an important communication session. For example, ahead of an important video call, Lync could potentially let the user know that the wireless network is unable to guarantee HD video quality and perhaps even go so far as to suggest the user "plug in" to a wired network jack. In my experience, UC adoption is greatly improved when proper user expectations are set and then met.
From a competitive perspective, Microsoft enabling Lync as an application that supports the SDN movement potentially represents an attempted "one-two punch" directed at Cisco. First Microsoft works to disrupt voice by making "voice" a feature of its UC Lync software platform, and then Microsoft works to accelerate Software Defined Networks, further commoditizing the network hardware that generates substantial revenue for Cisco. Of course, it is far too earlier to understand if this type of demonstration poses any threat to Cisco or other traditional network hardware providers; however, it is certainly interesting to see the areas into which Microsoft is willing to expand and extend its Lync platform.
Eric Krapf recently wrote about "Questioning the Basics" as the communication and collaboration industry changes and as new technologies enable new capabilities. In his Article, Eric refers to a very topical article by Sorrell Slaymaker that suggests "As UC evolves, how a network is designed must evolve too." I contend that applications such as Lync participating directly with SDN, as demonstrated by HP, are showing us where this evolution is headed.
These are early days for SDN, but last week we saw a glimmer of the great, shining opportunity a more standardized software-driven network switching and routing platform can offer.
Do you see Software Defined Networking as fundamentally changing UC? Please comment below or share your thoughts with me via twitter >@kkieller
Follow Kevin Kieller on Twitter and Google+!
Kevin Kieller on Google+
Follow Kevin Kieller on Twitter and Google+!