Author: Steve Schiemann
1.) SDN Definition and Short History
2.) Considerations Before Deploying
6.) Command-line/PowerShell options
8.) Troubleshooting and Data Collection
9.) Other Resources
SDN Definition and Short History
What is Software Defined Networking?
At a high level, SDN uses open protocols (XML in our case) to apply software control to network hardware. This hardware/firmware can receive and understand application-specific data, and make adjustments to optimize network traffic.
Consider this a primer for the Skype for Business Software Defined Networking Application Programming Interface. Later versions are simply called the Skype for Business SDN Interface.
There is no programming involved with installation/configuration. It provides an interface to a third-party network controller or monitoring application. The controllers are made by Cisco, Aruba, Nectar, HP, or other providers.
The SDN API sends Lync/SfB diagnostic data, Quality of Experience to the controller(s), which then can optimize network traffic and security. Administrators can view records of Unified Communications call quality, or even see a problem in real time and address it quickly. The controllers themselves can respond to media stream quality data, and prioritize network traffic for real-time vs. non-real-time data, UC-related data vs. web browsing data. Lync/SfB media steams are encrypted, but the SDN API allows the controllers to see what type of media stream is involved, and adjust the network accordingly, per policies, without seeing the data contents.
The Microsoft Skype for Business SDN Interface is a RESTful (Representational state transfer) interface through which subscribed systems ("subscribers", a.k.a. the third-party controllers) receive active call data, and the end-to-end measured quality of media streams.
Big Picture: Software Defined Networks began in the mid-1990s-early 2000’s, A.K.A “Active Networking”. AT&T had one of the first implementations of this idea. The Microsoft Lync/SDN API is one of many SDN Applications written by various vendors for other applications.
Considerations Before Deploying
1.) We recommend that installation/configuration is done in a lab first.
2.) Microsoft recommends using the latest version of the SfB SDN Interface that is compatible with Lync/SfB Servers, and the third-party controllers. What version does the controller manufacturer recommend?, so if a particular schema is needed, perhaps a later version of the SDN Interface can be used with a non-default schema
3.) Is this a new deployment, or perhaps an upgrade from a previous version? Read the Help and Release notes that come with each version of the Interface.
Version 1.0 was released in 2012, and 1.2 was released in late 2013. Neither of these versions are publicly available now. Versions 2.1.1, 2.2, 2.4, 2.4.1, and 3.0 are in use by customers today.
Version 3.0 just released on Feb 2, 2017 https://www.microsoft.com/en-us/download/details.aspx?id=54685&WT.mc_id=rss_alldownloads_all It is not compatible with Lync 2010.
Improvements in later versions include but are not limited to sending in-call quality updates as opposed to just begin/end-call updates, fully load-balanced and redundant pools, SDN Managers shared database, move some computations from Listener to Manager. Check the release notes for each version for more information. The release notes are available in the same group of download files for each SDN version.
Versions prior to 3.0 work with Lync 2010, 2013, and SfB 2015
Whatever operating system the Lync Server Front End servers use will be used by the API, since one component (Listener) is required to be installed on all FE servers.
Conceptually, the Skype for Business SDN Interface consists of the following components:
· The Dialog Listener that captures signaling and quality observations about media traffic between Skype for Business endpoints.
· The SDN Manager that collects the data from one or more Dialog Listener and distributes to third-party network management systems.
· A data store that maintains the shared state among all SDN Managers in a single pool. The data store could be a SQL database, Redis, or local memory cache.
· One or more subscribers, generally network management systems, also known as network controllers, or ITPro tools that support a RESTful web service to receive and analyze the call- and media-quality data posted from the SDN Manager.
The data flow looks like this:
Clients → (Front Ends / Lync Dialog Listener (LDL)) → Lync SDN Manager (LSM) → third-party controller
There should be a Listener on each front-end server (FE) to receive data from users homed on them, and one or more Managers to send (XML) data to the controller. The diagram below shows the Skype for Business/Lync clients in the upper left, sending data to the Listener component which is installed on each FE. The Listeners then send data to the Manager(s), who send it on to the controllers (Network Management System).
For the most part, customers install each component on appropriate servers, configure it, and it just works. The primary configuration steps are done in the installation wizard; some environments may require more customization.
Pre-installation tasks include but are not limited to planning your deployment (how many listeners/managers?), Activating QoE recording, setting up DNS service location record, setting up a database (Redis, or SQL), and/or installing certificates.
We recommend that you run SkypeforBusinessSDNManager.msi before you run the SkypeforBusinessDialogListener.msi. This will ensure that the SDN Manager is running and ready when the Dialog Listener attempts to connect to the SDN Manager.
You should install SDN Manager on a separate application server to maximize the performance of the Skype for Business Server front end.
Installing LDL and LSM on same FE is not recommended, but in a lab environment it can work.
Screen shots and details of Manager (LSM) component setup can be found at https://msdn.microsoft.com/en-us/library/office/dn785203.aspx.
Screen shots and details regarding the Listener (LDL) component can be found at https://msdn.microsoft.com/en-us/library/office/dn785202.aspx.
You can use the command line or PowerShell to view or modify SDN settings, or even perform unattended setup.
Details regarding command line options are described at https://msdn.microsoft.com/en-us/library/office/mt148356(v=office.16).aspx. Below is an example of changing the submituri parameter via command line. I customized my installation path, so yours may not be exactly the same.
The ‘p’ means “put” or change something, the ‘l’ means listener, “sfb.contoso.com” is where a standard edition or enterprise pool is referenced, and “submituri=…” is the parameter being changed. This change is saved in the database being used by the API, not the config files used by LSM or LDL components. Earlier versions used the config file for everything. Config file parameter are still important but are not now used for Listener, Subscriber and Manager configuration.
C:\Program Files\Microsoft Skype for Business Server\Microsoft Skype for Business SDN Manager 3.0>sdnmanager p l sfb.contoso.com submituri=http://webapps.contoso.com:9333/LDL
Response code: SUCCESS Detail: Merged 1 parameters, Timestamp: 2017-02-27T17:22:45.7550618Z
Response code: SUCCESS Detail: TimeStamp: 2017-02-27T17:22:45.7550618Z
<Configuration Version="2.0" culture="en-US" Kind="Listener" Identifier="SFB.CONTOSO.COM">
Details regarding PowerShell options can be found at https://msdn.microsoft.com/en-us/library/office/mt642927%28v=office.16%29.aspx/ Version 2.4 and later have the option of using Powershell cmdlets. Here is an example of using PS to get Manager (LSM) settings from my Standard Edition SfB 2015 Server:
PS C:\Users\Administrator.CONTOSO> Get-CsSdnManager -SdnPoolUri http://localhost:9333/Settings
<Configuration Version="2.0" culture="en-US" Kind="Manager" Identifier="DEFAULT
Our data store (SQL, Redis, or local cache) only maintains configuration data, and info for all concurrently ongoing calls. So the databases should be fairly small, relative to the call volume. No historical data is preserved.
Regarding the Manager component, from the SDN API 2.2 help file, SkypeForBusiness_SDNInterface_2.2.chm
"The SDN Manager is also a lightweight Windows service that we recommend you run on a separate virtual or hardware application server that uses Windows Server 2008 or later… The SDN Manager is responsible for processing the various events received from the Dialog Listener. It maintains state of the individual real-time streams—including whether the stream has started, ended, updated, and more in the associated data store (either Redis, local cache, or SQL Server database)—and sends the resulting XML data to the configured data receivers. The SDN Manager requires .NET Framework 4.5 or a later."
“Performance Benchmarks” are found in the SkypeForBusiness_SDNInterface_2.2.pdf that was downloaded with the 2.2 API. They have not changed for later versions:
Sample machine configuration:
Stand-alone SDN Manager server: Windows Server 2012 R2
CPU: 8 Cores, 8GB of memory
Hard drive: 1 TB
From the SkypeForBusiness_SDNInterface_2.2.chm that is downloaded with the API,
Applies to: Lync Server 2010 | Lync Server 2013 | Skype for Business 2015
Version 2.2 of the Skype for Business SDN Interface was tested in a production environment and in lab setups but no formal scalability testing has been conducted. Nevertheless, the following performance data should give you an idea what you can expect. Please consider these numbers as example only.
- A pool of three SDN Manager servers can support the traffic from 48 Skype for Business front-end servers, with separate REDIS/SQL clustered DB servers. This configuration may be able to support up to 80,000 users in one continent.
- Memory consumption is fairly low and stable.
- Sample machine configuration:
- Stand-alone SDN Manager server: Windows Server 2012 R2
- CPU: 8 Cores, 8GB of memory
- Hard drive: 1 TB
- In lab scenarios, we execute load of 400 audio calls per minute against two front-end servers and two SDN Manager instances. These topologies consist of virtual machines only with not more than two cores and 8 GB of memory each.
- Bandwidth includes the RTCP stream, which may use a different port.
If a pool configuration is used around a database, the SQL Server is expected to be production level server with state-of-the art memory and CPU. Similarly, a REDIS cache server must be configured to handle the load.
Troubleshooting and Data Collection
Logging is on by default, but debug logging can be enabled via the config files for each component. The config file for the Listener component is found by default at C:\Program Files\Microsoft Skype for Business Server\Microsoft Skype for Business Dialog Listener\ DialogListener.exe.config. The Manager component config file is at C:\Program Files\Microsoft Skype for Business Server\Microsoft Skype for Business SDN Manager\SDNManager.exe.config.
To enable debug logging, search for the <loggingConfiguration> section and make appropriate changes to entries under the component elements.
For example, change the switch value from “Off” to “All”.
<add switchValue="Off" name="Debug">
<add name="LNEAppLog" />
Basically, you want to verify that the listener is getting data from the clients, and sending it to the manager. Then, verify that the manager is sending data to the subscriber (controller) in the correct format. That’s it.
The SDN API is quick and easy to install in a lab. As previously mentioned, both components can be co-located on an FE server.
Info on listener logging:
Info on manager logging:
Getting ready to install Skype for Business SDN Interface
Software-Defined Networking: An Overview for Unified Communications
Software-Defined Networking: The New Norm for Networks
Open Networking Foundation (ONF)
The International Mulitmedia Telecommunications Consortium
The Road to SDN: An Intellectual History of Programmable Networks
This writing is not intended to cover advanced topics. I hope it is useful to those new to the SfB SDN Interface. The Help that comes with each version of the Interface is extensive, and covers most questions that customers have about the product. But if your questions are not answered, open a support ticket and we’ll be glad to help.