The Skype for Business Software Defined Networking (SDN) Interface
Published May 20 2019 05:21 PM 3,031 Views
Brass Contributor
First published on TECHNET on Mar 08, 2017
Author: Steve Schiemann


Contents:


1.) SDN Definition and Short History

2.) Considerations Before Deploying

3.) Versions

4.) Architecture

5.) Installation/Configuration

6.) Command-line/PowerShell options

7.) Performance

8.) Troubleshooting and Data Collection

9.) Other Resources

10.) Conclusion

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.


Short History


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? Keep in mind that there are various schemas available in the interface for compatibility purposes , 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.


Versions


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.


Architecture


Components


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.


Data Flow


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).



image


Installation/Configuration


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 .


Command-line/PowerShell options


You can use the command line or PowerShell to view or modify SDN settings, or even perform unattended setup.

Command Line


Details regarding command line options are described at https://msdn.microsoft.com/en-us/library/office/mt148356(v=office.16).asp x. 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">

<parameter key="submituri">http://webapps.contoso.com:9333/LDL</parameter>

<parameter key="alternativeuri"></parameter>

<parameter key="clientcertificateid"></parameter>

<parameter key="submitqueuelen">1000</parameter>

<parameter key="maxbackoff">30</parameter>

<parameter key="maxdelaylimit">5</parameter>

<parameter key="maxopen">100</parameter>

<parameter key="maxretry">100</parameter>

<parameter key="maxretrybeforefailover">10</parameter>

<parameter key="requester">sfb.contoso.com</parameter>

</Configuration>


PowerShell


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

" LastModified="2017-02-24T22:02:05.9356561Z">

<parameter key="calltimeout">1.00:00:00</parameter>

<parameter key="endedtimeout">00:00:15</parameter>

<parameter key="invitetimeout">00:03:00</parameter>

<parameter key="maxcachesize">20000</parameter>

<parameter key="qoetimeout">00:00:05</parameter>

<parameter key="timeouthandlerperiod">00:00:10</parameter>

<parameter key="hidepii">True</parameter>

<parameter key="applicationsharing-AppliedBandwidthLimitAcceptable">500000</parameter>

<parameter key="applicationsharing-AppliedBandwidthLimitOptimal">1000000</parameter>


Performance


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.

Performance benchmarks

  • 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">

<listeners>

<add name="LNEAppLog" />

</listeners>

</add>



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:

https://msdn.microsoft.com/en-us/library/office/dn439303.aspx

Info on manager logging:

https://msdn.microsoft.com/en-us/library/office/dn775151.aspx


Other Resources


Getting ready to install Skype for Business SDN Interface

https://msdn.microsoft.com/en-us/library/office/dn785199(v=office.16).aspx

Software-Defined Networking: An Overview for Unified Communications

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/OFC-B343

Software-Defined Networking: The New Norm for Networks

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnor...

Open Networking Foundation (ONF)

http://www.OpenNetworking.org

The International Mulitmedia Telecommunications Consortium

http://www.imtc.org/

The Road to SDN: An Intellectual History of Programmable Networks

https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf

Conclusion


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.
2 Comments
Version history
Last update:
‎May 20 2019 05:21 PM
Updated by: