Deploying Microsoft Lync over Wi-Fi #AirheadsConf Italy

Deploying Lync over WiFiJohn Turner, Bala Krishnamurthy

June 11-12

CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

2 #AirheadsConf

Agenda

• Why UC and Wi-Fi?• Challenges with Real Time Media & Wi-Fi• Common Usage Scenarios• Lync over Wi-Fi Multi-Tier Strategy • Wi-Fi Deployment Guidance for Real Time Media• Configuring QoS for Lync• Lync SDN Program• Q&A

CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

3 #AirheadsConf

Why care about UC and Wi-Fi?

• UC is about a communication and collaborative experience anywhere and on any device

• Wi-Fi by default, wired when necessary (in many cases Wi-Fi only)

• Network managers tasked to plan for (data/voice/video) Wi-Fi convergence

• Customers are pushing towards greater real time media over mobile scenarios

• Wi-Fi has become a mainstream wireless technology

4CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

#AirheadsConf

Challenges with Real Time Media & Wi-Fi


#AirheadsConf

Real Time Media

• Streaming vs. Real Time Media– Streaming applications like YouTube, Netflix, etc can utilize large

receive side buffers in order smooth out network delays

– Real Time Media is interactive and requires a high performance network that can sustain continuous up/down stream traffic, with low latency, jitter and packet loss

• Impact to Human Interaction– Human communication starts to get negatively impacted with

latency of more than 250 msec (one way, mouth-to-ear latency)

– Bursty jitter or packet loss over a certain threshold cannot be recovered, and leads to glitches in the audio and video stream

– Audio glitches are very disruptive and lead to a poor user experience


#AirheadsConf

Real Time Media Network Requirements

• Bandwidth requirements (1)

– Audio 50 Kbps to 220 Kbps per stream (incl. IP header and FEC overhead)

– Video 250 Kbps to 4 Mbps per stream

• Jitter – Desired jitter less than 20 msec

• End-to End Network Latency– Desired less than 100 msec (one way)

– Acceptable less than 200 msec (one way)

– Depends on geography

• Packet Loss– Desired 0%, acceptable <2% and not more than 3 consecutive lost packets

• UDP vs. TCP – Both UDP and TCP are supported for Lync 2013 Real Time Media

– UDP is preferred for Real Time Media as TCP recovery (retransmits) is usually too long to be useful


#AirheadsConf

Real Time Media Issues When Running Over Wi-Fi

• Handover Performance– Real Time Media has very different requirements when roaming between

APs then when stationary

– Delayed handovers from “sticky clients” can result in multi-second media breaks for voice/video

– Clients often “stick” to an Access Point (AP) even when the signal strength has deteriorated so far as to be unusable

– And at the opposite extreme, some clients may “ping-pong” rapidly between multiple APs or SSIDs

•Off-Channel Scanning– Background scanning mechanisms are off-channel too long and inconsistent

which may affect media traffic


#AirheadsConf

Real Time Media Issues When Running Over Wi-Fi (cont.)

•Rate Adaption and TX Retries– Existing rate adaption algorithms not well suited for Real Time Media

– May take up too much airtime in retries when used for Real Time Media traffic

•Media Admission Control– Need a mechanism to prevent oversubscription of high priority traffic

– Optimizing available resources via load balancing, steering clients away from congested APs, facilitating good roaming decisions, and avoiding low data rates are preferable to denying new sessions (only used as a last resort)

•SNR and signal strength requirements are different between Real Time Media and data

– Data - SNR better than 25 db and RSSI better than -90 dBm

– Real Time Media - SNR better than 40 dB and RSSI better than -65 dBm


#AirheadsConf

Wi-Fi Deployment Guidance for Real

Time Media


#AirheadsConf

Running Lync 2013 over Wi-Fi

• Data over Wi-Fi

• Devices - Desktops, laptop, slates, mobile smart phones

• Modalities - IM, presence, web conferencing, calendaring

• Real Time Media over Wi-Fi: Fixed

• Additional modalities (includes Lync Data over Wi-Fi) - Voice mail, video conferencing, telephony, audio conferencing

• Nomadic but stationary use of Lync services

• Real Time Media over Wi-Fi: Mobile

• Modalities same as with Lync Real Time Media over Wi-Fi Fixed

• Originate, consume and terminate Lync services while on the move


#AirheadsConf

Wi-Fi Deployment Guidance

Enterprise Infrastructure Recommendations

• Deploy 802.11ac APs AP-225 or AP-205• Enterprise Wi-Fi controller with thin enterprise grade APs or

standalone APs• Implement WPA2 in Enterprise Mode• Fast BSS transition support (OKC and/or 802.11r)• Configure for load balancing across AP’s• QoS/WMM Planning

• Ability to classify and prioritize Lync traffic (SIP-TLS) in the presence of lower priority data traffic

• Implement QoS throughout wired and wireless infrastructure to prioritize voice and video

• Implement QoS/WMM with EF queue for WMM Voice

• Enable WMM on APs for QoS. Enable QoS on Lync servers and clients

• Enable power saving mechanisms


#AirheadsConf


Enterprise Infrastructure Recommendations• RF Planning

• Deploy APs featuring dual (concurrent) 2.4 GHz and 5 GHz operation with 3x3 configuration and 1 Gbps backhaul

• 2.4 GHz band - drop 802.11b support, limit 802.11n support to 20 MHz channels

• 5 GHz band - if available, enable “RF band steering” to move dual-band client devices to 5GHz RF, use 40 MHz channel

• Support for RF auto radio management of channel and signal strength

• Capacity Planning• Deploy applicable AP density for required coverage and capacity but keep signal

levels better than -65dBm and SNR better than 40dBm (association and roaming probe responses should have SNR better than 25dBm)

• Deploy sufficient number of APs for seamless coverage

• Design for capacity based on # of clients in coverage area

• Plan for overlapping AP coverage (redundancy) as required

• In large conference rooms deploy multiple APs


#AirheadsConf


Enterprise Physical Infrastructure Recommendations• Physical cell deployment

– Open space design is different from walled office designs

• RF Coverage – Ubiquitous Wi-Fi coverage is required!

– Signal strength in coverage footprint (-65dBm or better)

– Surveys– Baseline

• Spot Testing

• Walkthrough testing

• Roaming with Lync Client session calls

– Periodic surveys to ensure baseline performance remains consistent


#AirheadsConf


Enterprise Client Recommandations• Enterprise class devices (e.g. tables, laptops)

• BYOD is a reality so be prepared

• Mobile devices supporting dual band• Real Time Media optimized/certified NIC and drivers

• Manage NIC driver versions

• Note: When on battery power drivers tend to reduce Wi-Fi device power

• High-quality dual band NIC with at least 2x2:2 configuration

• Support for radio resource management (802.11k)


#AirheadsConf

Configuring QoS for your Lync deployment


#AirheadsConf

DiffServ QoS Model

Precedence Level

DiffServ Marking

ToS Name Description

7 DSCP 56 (CS7)

Network Control

Reserved for IP routing protocols

6 DSCP 48 (CS6)

Internetwork Control

Reserved for IP routing protocols

5 DSCP 40 (CS5)

CRITIC/ECP Express Forwarding (EF)

4 DSCP 32 (CS4)

Flash Override Class 4

3 DSCP 24 (CS3)

Flash Class 3

2 DSCP 16 (CS2)

Immediate Class 2

1 DSCP 8 (CS1)

Priority Class 1

0 DSCP 0 (Default)

Routine Best Effort

Drop Precedence

Class 1 Class 2 Class 3 Class 4

Low DSCP 10 (AF11) DSCP 18 (AF21)

DSCP 26 (AF31)

DSCP 34 (AF41)

Medium DSCP 12 (AF12) DSCP 20 (AF22)

DSCP 28 (AF32)

DSCP 36 (AF42)

High DSCP 14 (AF13) DSCP 22 (AF23)

DSCP 30 (AF33)

DSCP 38 (AF43)

Assured Forwarding

Scheduler

Drop

High

Drop

Med

Drop

Low

Drop Zone

EF

AF

CS3

Best Effort

Committed Rate Queue


INPUT

OUTPUT

Strict Priority Queue

Ingress Rate < Egress Rate

Committed RateDefined



No RateDefined

Expedited ForwardingDiffServ Marking

Description

DSCP 46 (EF)

low delay, low loss and low jitter


#AirheadsConf

Expedited Forwarding (EF) Behavior

Scheduler

Drop High

Drop Med

Drop Low

Drop Zone

EF

AF

CS3

Best Effort



INPUT

OUTPUT






No RateDefined


#AirheadsConf

Expedited Forwarding (EF) Behavior

Scheduler

Drop High

Drop Med

Drop Low

Drop Zone

EF

AF

CS3

Best Effort



INPUT

OUTPUT






No RateDefined

QoS engineering has to be managed consistently end-to-end, or it can have a dramatic negative impact to all real-time voice and video traffic


#AirheadsConf

Todays IP Phone QoS Model

Marked by switch asBest Effort (BE) for 802.1p and DSCP

Data VLAN

Marked by switch asExpedited Forwarding(EF) for 802.1p and DSCP

VoIP

DataTerminal

BE Queue

Access Switch

EF Queue

Data VLAN

Voice VLAN

Voice VLAN

Scheduler forEF and BE Traffic

Behavioral Aggregate Classifier For EF and BE Traffic

Scheduler forEF and BE Trafficwith Mappings form DSCP to 802.1p

DataTraffic

VoiceTraffic

Data Server

IP PBX

802.1PClassifier

PSTN

Non-Secured

Secured

IP Phone QoS is Secured


#AirheadsConf

Todays UC&C QoS Model

Marked by Lync endpoint for DSCP• Voice - Expedited Forwarding (EF)• Video – Assured Forwarding (AF)• Data - Best Effort (BE)

DataTerminal

Access Switch

Scheduler forEF, AF & BE Traffic

Behavioral Aggregate Classifier For EF, AF & BETraffic

Scheduler forEF, AF & EF Traffic. with Mappings from DSCP to 802.1p

Voice, Video &Data Traffic(802.1p and

DSCP Marked)

802.1PClassifier

PSTN

Lync

Voice, Video &Data Traffic(802.1p and

DSCP Marked)

Scheduler forEF, AF & EF Traffic. with Mappings from DSCP to 802.1p if needed

AP

Wi-Fi

Marked by Lync endpoint for WMM and DSCP• Voice - Expedited Forwarding (EF)• Video – Assured Forwarding (AF)• Data - Best Effort (BE)

Remark QoS for Untrusted traffic to

Best Effort

One of the biggest issues for Lync is that Network Elements are misconfigured for QoS and/or network policies remark untrusted traffic to Best Effort

Result is poor Lync experience for voice and video


#AirheadsConf

Automated QoS and TE

UC / Application Admin

Time in Weeks

Ongoing Monitoring &

Troubleshooting

Identify traffic

classes

Configure UDP ACLs

on Switches

Inventory WAN circuit

sizing

What Codecs

?

Remark DSCP for untrusted applications?

Lock down UDP port

ranges used for voice/video

Identify sites

Define Erlang traffic

models

Provision CAC

across sites

Validate SLAs

Ok, ready to start rolling out

Enable DSCP…on all

endpoints

…Network Admin

SDN will reduce cost of deploying QoS, Traffic Engineering and Security for UC


#AirheadsConf

Lync QoS Recommended Guidance


#AirheadsConf

Lync QoS Guidance

• Configure port ranges– Use same media ports across Lync server media roles for same modality type (e.g. audio)

– Use non-overlapping media ports across Lync server media roles for different modality types (e.g. audio vs video)

– Make client audio/video port ranges subset of servers

• E.g. server audio port range = 49,152 – 57,500

• Client audio port range = 50,020 – 50,039

• Configure QoS– Quality of Service Policy on Windows Vista/7/8 and Windows Server 2008 R2/2012

– QoS Packet Scheduler on Windows XP w/ controlled load (video, DSCP 34) and guaranteed service type (audio, DSCP 46)

• Set-CsMediaConfiguration -EnableQoS $True

– Lync Phone Edition is using DSCP 40 for audio (change with Set-CsUCPhoneConfiguration -VoiceDiffServTag 46)

– Lync for Mac 2011 is using CS5 (0x28) for audio and CS3 (0x18) for video

– Lync Mobile clients use hardcoded QoS Values


#AirheadsConf

Lync QoS Guidance

Config upstream QOS Policy for Lync desktop client• For Lync client on Windows 7/8

– In Group Policy Editor go to Computer Configuration -> Windows Settings -> Policy-based QoS

– Gpudate.exe /force

– On multi-adapter and/or Workgroup Mode computer set “Do not use NLA”=”1″ under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\QoS

Client Traffic Type

DSCP

Source IP

Destination IP

Protocols

Source port range

Destination port range

Audio 46 Any Any TCP/UDP

50020:50039

Any

Video 34 Any Any TCP/UDP

58000:58019

Any

App Sharing

24 Any Any TCP/UDP

42000:42019

Any

File Transfer

14 Any Any TCP/UDP

42020:42039

Any


#AirheadsConf

Lync SDN Program


#AirheadsConf

Today’s UC&C challenges

• Network issues cause 60-80% of poor end-user QoE

• Poor visibility into real-time traffic– Lync uses encryption by default, making DPI difficult and

unreliable

– Skype tries to hide itself from networks

• Traffic engineering / QoS is complex & easily broken– Requires brute force static policies that must match

application server settings

– Intermittent problems are tedious to diagnose, especially for Softphones and BYOD


#AirheadsConf

Why SDN

• Addresses increasing complexity

• Realize operational efficiencies

• Improves end-user experience

Visibility

Control

Automation

Agility


#AirheadsConf

What is Application Driven SDN

App App App App

SDN Controller Platform

NE

NE

NE

NE

Northbound Interface

Southbound InterfaceAbs

trac

tion

SDN Application• Logic and Network Service

Intelligence

Controller• Centralized Control

System• Global view

Network Elements• Physical or virtual

forwarding path

Applications Programing Networks


#AirheadsConf

“Network Service Application” Driven SDN Model

NetworkElement

NetworkElement

NetworkElement

NetworkElement

NetworkElement

NetworkElement

NetworkElement

SDN Controller Topology Inventory Flow Programming Statistics

Network Service Application

Network Service Logic Policy

SDN Controller North-Bound Interfaces

Administrator Interface


#AirheadsConf

“End User Application” Driven SDN Model

NetworkElement

NetworkElement

NetworkElement

NetworkElement

NetworkElement

NetworkElement

NetworkElement

SDN Controller Topology Inventory Flow Programming Statistics

Network Service Application

Network Service Logic Policy

SDN Controller North-Bound Interfaces

Administrator Interface

Abs

trac

tion

End User App(Ex: UC)

Network ServiceNorth-Bound Interface


#AirheadsConf

UC SDN Architecture


#AirheadsConf

UC SDN Dialog Event


#AirheadsConf

UC SDN Quality Update Event


#AirheadsConf

Basic Architecture and Flow (V2.0)


#AirheadsConf

Redundant Architecture and Flow (V2.0)

ClientLyncClient

Lync FE + LDLLync FE + LDL

PrimaryLync SDN Manager

Secondary Lync SDN Manager

Fault-tolerance, Pools and Fan-Out:

NMS/Network ControllerNMS/Network ControllerNetwork

Controller


#AirheadsConf

Redundant Architecture and Flow (V2.0)

ClientLyncClient

Lync FE + LDLLync FE + LDL NMS/Network

Controller

PrimaryLync SDN Manager

Secondary Lync SDN Manager

Fault-tolerance, Pools and Fan-Out:

NMS/Network ControllerNetwork

Controller


#AirheadsConf

Initial Features Lync SDN API V2.0

• Lync SDN Manager• Basic filtering, aggregation, augmentation,

dispersion (stateful)• No LDL changes. Backward compatibility• Support for primary/secondary redundancy


#AirheadsConf

Architecture V2.1- Coming Out Soon

LFE+ LDLLync FE + LDL Lync SDN

ManagerLync SDN Manager

Load-balancing, pools, state & configuration sharing:

FE + LDLLync FE + LDL

Shared State

Configuration

Configuration

Additional message type:IncallQuality

Database or shared memory cache

NMS/Network ControllerNMS/Network ControllerNetwork

Controller


#AirheadsConf

Lync SDN API V2.1Features

• In-call Quality Updates • Full load-balanced and redundancy pool• State sharing using a database• Simplified configuration and setup of LDL• Internal re-organizing• Move computation from LDL to SDN Manager• Partner requests


#AirheadsConf

Where We Are Today

• Lync SDN API v2.0 Publically Available

• API can be installed on Lync 2010 and Lync 2013

• LDL Must be installed on all FEs

– Continuing to advance the API with partner’s requirements


#AirheadsConf

Lync UC SDN Scenarios


#AirheadsConf

UC SDN Scenarios Being Defined

• Automated Diagnostics: – Pinpoint root-cause-analysis for degraded media calls

• Automating QoS– Dynamically mark authorized voice and video traffic with the appropriate QoS markings.

• Dynamic Traffic Engineering of Bandwidth Capacity for each Class of Service: – Dynamically adjust the amount of bandwidth associated with various Classes of Service (CoS) to match bandwidth requirements of the

corresponding applications.

• Call Admission control: – Prevent voice and video traffic from exceeding the available bandwidth capacity, and notify applications of changes in available bandwidth

so they can adjust selected codecs (e.g. based on policies).

• Dynamic Traffic Engineering of Media Paths: – Route media along a path that is best able to meet performance requirements (rather than along the “default” least-cost path).

• Security DDOS and IPS/IDS orchestration:– Positive identification of authentic media flows to prevent scrubbing

• Firewall orchestration: – Automating pinhole firewall provisioning of dynamic media flows

• Wi-Fi orchestration: – Automating real-time-media flows over Wi-Fi for correct behaviors of STAs and APs for many scenarios


#AirheadsConf

Lync and Aruba SDN Collaboration


#AirheadsConf

Aruba SDN Overview

• Aruba Controller as the consumer of Lync SDN messages– PEF engine and roll based access

– Voice subsystem to collect WiFi statistics

– QOS to mark and prioritize

• SDN acts as a trigger• Additional data from SDN adds correlated data• Flow is unidirectional today


#AirheadsConf

Lync SDN – QoS Flow

1. User establishes Lync call to another device– Call setup is through Lync Front End

server, call is peer-to-peer

2. Lync server sends session information to Controller via SDN API to web services listener

3. Controller uses data for QoS and AppRF visibility– Voice Video Desktop Sharing DSCP

mappings are made in SSID profile

1

3

2


#AirheadsConf

Lync SDN – Collecting call data

1. At the end of each call, participants send Quality of Experience (QoE) data to the QoE server, which is a component of Lync

2. The QoE server reports stats to the controller

3. Controller builds monitoring pages

1

3

2


#AirheadsConf

MS Link Overview


#AirheadsConf

Lync Components

Media for callbackSIPhttps (XML)

Push notification for Windows Phone

Media gateway

Media server Front End server

Reverse proxy

DMZ

WiFi

Internet

Lync push notification

services

Edgeserver

• AD• DNS• Exchange• Front End server• QOE server• Reverse Proxy• Edge Server


#AirheadsConf

Client sign-in Lync 2013

• A record Lyncdiscover.<sipdomain>

Lync client

DNS Server

Front End

Reverse Proxy

Edge Server

Data center 1

Front End

Reverse Proxy

Edge Server

Data center 2

1. Query for Lyncdiscover. <sipdomain>

2. DNS points to Reverse Proxy

3. Client connects to Reverse Proxy

5. Client directly connects to local

4. Returns local Access Edge


#AirheadsConf

Lync Signaling Ports

TCP Port

Lync Internal 5061

Lync External 443

Office 365 443


#AirheadsConf

Understanding Lync Bandwidth Requirements

Lync bandwidth usage is variable but predictable

http://technet.microsoft.com/en-us/library/jj688118.aspxBandwidth Calculator Tool:http://www.microsoft.com/en-us/download/details.aspx?id=19011

Codec Bandwidth

Voice Wideband Audio 91Kbps (MAX) / 39.8Kbps (Avg)

Video 1280x720 h.264 2510Kbps (MAX) / 460Kbps (Avg)

5 person video call (MAX) (5 x 2510) + (91 * 2) = 12.43Mbps

5 person video call (Avg) (5 x 460) + (39.8 * 2) = 2.32Mbps

This represents high end codec use, additional info at:

http://technet.microsoft.com/en-us/library/jj688118.aspx




#AirheadsConf

65

Thank You

#AirheadsConfCONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

Technology

Deploying Microsoft Lync over Wi-Fi #AirheadsConf Italy