There is some great information out there, and some great presentations  (a ton of great stuff here from LyncConf 2014 definitely take a look) that cover WHAT Software Defined Networking (SDN) IS, but not a lot of good, concise info on installing it and getting it working, at least not ones this blockhead could understand. So this is the purpose of this post. Can a post have a purpose? Its it alive? Does anyone read these? I digress. I plan on treating this post in multiple parts : Part 1 will deal with general overview of SDN and the SDN bits:  (Listeners, Controller, Management console), Part 2 will deal with the installation and configuration of the SDN bits and think a Part 3 will be on verification and using SDN from a network management perspective. i would really like this series of posts to evolve to be a quick and easy collection of SDN info and resources so please contribute, ask questions and point out mistakes I may have made. 


So what is Software Defined Networking?

I have no idea, but it sure does sound cool doesn’t it? 🙂 In a very high-level, general Lync-focused sense, SDN is a mechanism in which Lync and the underlying network infrastructure speak to each other to dynamically improve overall Quality of Service. This is of course a very simplistic, limited definition, but after all it IS the point of the post. Deploying and supporting Microsoft Lync voice can be seen as combat at times, especially when managing user expectations and experiences with Lync voice. SDN can be seen as yet another tool in your arsenal to provide the best Lync experience for your users as is possible. It is always seen as finger pointing and a cop out for the “Lync Guys” to point at the network and say “its your fault”, but according to @nomorephones in NETW300/22:00-ish “Network issues cause 60-80% of poor end-user QoE”. SDN is also a method to minimize the impact of the network on Lync voice quality.


Lync SDN Overview


Source: Lync Conf 2014 NETW300



Source : Lync SDN API 2.0 Release notes.




Source : Lync_SDN_API.chm


Currently, Aruba Networks, as well as HP and Nectar, have SDN capabilities with Lync 2013. I will focus on Aruba in these posts.


There are 4 “building blocks” or components for SDN in Lync 2013:

The Lync 2013 SDN Components-

The Lync 2013 Clients (2010 clients will provide a limited set of data compared to Lync 2013 clients).

Lync Dialog Listener (LDL) – API listener that is installed on the Lync Front End Servers. The LDL sends SDN data to the LSM.

Lync SDN Manager (LSM) – added in the 2.0 SDK. SDN data is sent from the LDL to the LSM. The LSM sends relevant SDN call data to the Network Controller hardware (currently at the end of the call – In call quality updates coming in SDK V2.1).

The Network Controller hardware – Does its thing controlling the Network hardware. 🙂 In this case Aruba.



So we have the basic “flow” as illustrated in the above diagram:

QoE data flows from the Lync clients to the Lync FE\LDL

LDL sends to LSM

LSM sends to Network Hardware. 


Makes a lot more sense to me now….. 

Lync SDN API 2.0 Reference


 Questions? Comments? 


Thanks for reading.