Lync and Software-Defined Networking
By Jamie Stark, Sr Product Marketing Mgr, Lync
A little-known fact about the engineering team for Lync and Skype is that many of the people came out of the core networking division for Windows Server. While most of the world looks at Lync as a great unified communications software package, underlying its user interface and capabilities are lots and lots of networking protocols. Folks who spend any time with the deployment, configuration, or operations of Lync certainly realize this – there’s a lot going on with the “wire,” whether that’s over the air or on copper.
Networking is very much in the DNA of Lync, so when the industry started rallying around Software-Defined Networking (SDN), we were excited to participate. SDN has been defined in a bunch of ways and I encourage you to explore the topic, but generally you can think of two things. First, separating the low-level network functions into commodity hardware controlled by a software-based platform. Second, having applications inform the software controller of their requirements of the network. This concept started with cloud-scale data centers and has been moving down-market as enterprise network architects realize the power of this model.
SDN’s primary use case has been around ensuring that virtual machines can be managed independently of the underlying network fabric. Here in the Lync organization, we think that unified communications can be a major beneficiary as well. In any UC implementation there are dozens of network elements – from routers to reverse proxies, intrusion detection systems to application delivery controllers, firewalls to session border controllers – that all need to be provisioned and configured correctly for optimal media flow. Instead of having all of these elements configured discretely, SDN provides a model for a single policy-based method of operations, where the application tells the network what needs to happen.
This is a big paradigm shift, and we have jumped in with both feet. Today, we’re releasing the Lync SDN API for free to anyone with a Lync Server deployment. The API provides a REST-ful data stream of information about media flows as they get started. This data can then be fed into an SDN controller to enlighten the network about what needs to happen and where.
We have outlined three primary use cases for this:
Diagnostics. By using the data from the API, network monitoring systems can then correlate between media flows in Lync and activities in the network that may have an impact on quality.
Automatically provisioning Quality of Service (QoS) . When the controller gets information about a media flow starting up, it can instruct the network to assign the appropriate marking to those packets in real time.
Orchestration. Just like it sounds, imagine all the different instruments of the network from layer one to layer seven all singing along in harmony.
In the coming weeks, we will go into more depth around each of these scenarios along with the partners we have been working with deeply through the last year to bring these concepts to a reality. Nectar has a great diagnostics application that consumes the Lync SDN API, and Aruba Networks with their latest release uses the API to inform wireless access and priority. We have a lot to talk about on the industry standards work as well, with both the UCI Forum and Open Networking Foundation working diligently to understand how any application can operate within the SDN framework, and we’ve been leading the discussions on the applicability with UC.
To our customers, we pledge to continue to look to the latest technology and capabilities to advance Lync. This is still the early days of SDN, but we think the opportunity and potential here is undeniable. Finally, please join us at Lync Conference, where we will be talking more about SDN with Lync and how partners and customers are using the SDN API today in their deployments.