The Skype for Business Software Defined Networking SDN Interface

The Skype for Business Software Defined Networking SDN Interface

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 http://ift.tt/2m0FEpd 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).

 

 

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 http://ift.tt/2m0yrpa.

Screen shots and details regarding the Listener (LDL) component can be found at http://ift.tt/2mDpZ3b.

 

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 http://ift.tt/2m0BIoK. Below Here 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 FilesMicrosoft Skype for Business ServerMicrosoft Skype for Business SDN Manager 3.0>sdnmanager p l sfb.contoso.com submituri=http://ift.tt/2mD3Fqr

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://ift.tt/2m0tbSy;

<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 http://ift.tt/2mDe1a2 Version 2.4 and later have the option of using PowerShell commandlets (SDNManager Powershell). Here is an example of using PS to get Manager (LSM) settings from my Standard Edition SfB 2015 Server:

PS C:UsersAdministrator.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 FilesMicrosoft Skype for Business ServerMicrosoft Skype for Business Dialog Listener DialogListener.exe.config. The Manager component config file is at C:Program FilesMicrosoft Skype for Business ServerMicrosoft Skype for Business SDN ManagerSDNManager.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:

http://ift.tt/2mD72xF

Info on manager logging:

http://ift.tt/2m0wPfi

Other Resources

Getting ready to install Skype for Business SDN Interface

http://ift.tt/2mD3204

Software-Defined Networking: An Overview for Unified Communications

http://ift.tt/2m0AF7W

Software-Defined Networking: The New Norm for Networks

http://ift.tt/1bNXvX9

Open Networking Foundation (ONF)

http://ift.tt/1beHI6y

The International Mulitmedia Telecommunications Consortium

http://www.imtc.org/

The Road to SDN: An Intellectual History of Programmable Networks

http://ift.tt/2aX5xGW

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.

via Skype for Business News Aggregator Full Article

download file now

Continue reading ...

The External Memory Interface as an Educational Tool

The External Memory Interface as an Educational Tool

In a recent email conversation with an engineer I ended up discussing the advantages of an external memory interface (EMI) over general purpose I/O (GPIO) on a microcontroller for the purposes of education. This short piece comes from that discussion.

The question posed was this:

"What advantages does an external memory interface have over driving a peripheral with GPIO?"

... which immediately brings out the question, what do I mean by an external memory interface and what do I mean by GPIO?

General Purpose Input Output (GPIO)
This typically refers to a pin of the chip which is not necessary for any of the operations of the chip but is available to a system designer using the chip. Put another way if none of the GPIO are used then the chip will function just fine. The pins are under software control and can be turned into either inputs allowing data to be read from the outside world or outputs pushing data to the outside world.

External Memory Interface
In modern digital computer architecture the standard method of connecting a processor core to the outside world is with a memory interface. This is typically formed from an address bus, a data bus (either bi-directional or two uni-directional ones) and some control lines to indicate whether data is being written or read.

Normally this is present inside the chip but forever hidden from the designer inside and only a few designs allow it to be exposed. Those that do allow extra RAM or ROM memory to be added to the fixed amount of a normal microcontroller design.

Engineering Advantages of EMI

Direct memory mapped busses has a couple of advantages over GPIO so, as usual, it depends what you are doing as to whether you care (typical engineers comment!). Here are the two main differences:

1. Native machine code access. Grants speed, reduced code size and I would guess lower power? No extra instructions to drive the GPIO and turn the bus around to slow you down. Simply create pointers and data structures as usual and prod the linker to place them in the external chips. Or use explicit addresses.
2. Code execution from external memory. Related to the above.

1. is only an issue when speed is at stake, really. Code size isnt that big a problem most of the time and the software wrapper around GPIO wont be very large. Certain ADCs and DACs (usually video or software radio) pretend to be SRAM for extremely quick access and would really require this method of access to function effectively.

2. only matters if you have run out of on-chip non-volatile memory and have to move sections of your program off chip.

[Just speculating re. 2. code execution: you could change the compiler to emit instructions to drive a GPIO for data memory accesses in a certain range. However I cant work out how to do a native instruction fetch from the external memory without a little code in internal flash copying it to an area of RAM first. Perhaps a block copy strategy held in flash as a bootloader type thing could minimize the pain of this if it was invoked as appropriate by a compiler or linker? Note that in the world of computers I have discovered that someone has always built an implementation of just about every whacky idea. If you know of a system that uses this paradigm then please let me know. PCs dont count.]

In a final summary if you are accessing a data storage area or a peripheral occasionally and dont care about 1. or 2. then a simple software wrapper around GPIO would do just fine and be relatively efficient. I would guess 3 to 5 times slower?

Educational Advantages of EMI

From an educators point of view when teaching computer architecture and interfacing and EMI is gold in terms of hammering what is happening inside all general purpose computers into the heads of students. I mean simply this basic idea:

"A CPU issues an address onto the bus with control signals and writes or reads data."

This very basic idea is surprisingly poorly understood by many students as it is completely hidden from them inside micros or PCs. In many EE or even CompE courses the students never actually physically observe it in action or build their own peripheral and code software to drive it. As long as it remains a mental exercise a substantial portion of the students will not really understand it and without understanding it their ability to understand computers and software suffers.

Myself and colleagues (past and present) have gone to great lengths to try to give them some practical experience at it - I first encountered a softcore PIC in an FPGA used to expose its pipeline and memory and databusses for the students to observe and extend. We moved to an Atmel part (an ATmega128) with a real external memory interface instead when it became available. Multiplexed address + data but designed so it could drive an 74 series 8 bit latch to generate the full bus. Much improved from our softcore PIC! We would set them the task of mapping an 8k SRAM and an 8 bit input and 8 bit latched output into the memory map of the microcontroller.

I am looking forward to developing similar exercises with a more advanced external memory interface (called the EBI, external bus interface) found on Fujitsu FM3 ARM Cortex M3 based microcontrollers. It has the following neat features, and is really designed to drive FLASH memories transparently which is no mean feat:

• It does have an external wait input which could prove very useful
  for custom peripherals.
• It has a basic SRAM mode with configurable timing for read and write strobes.
• It can transparently split and rebuild data from 32 bit to bus widths 8 bits (or 16)
  on the fly by issuing the correct sequential addresses.
• It can natively drive various types of FLASH memory including NAND block erase and NOR page reads etc. while pretending to be normal memory to the software.

download file now

Continue reading ...

The Skype for Business Software Defined Networking SDN Interface – NextHop…Your reso urce for

The Skype for Business Software Defined Networking SDN Interface – NextHop…Your reso urce for

http://ift.tt/2m0DxSD

[skypeforbusiness]

Filed under: Uncategorized

via Skype for Business News Aggregator Full Article

download file now

Continue reading ...