An Introduction to Network Assessment Concepts

Microsoft Unified Communications

Published: December 2010

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft, Office Communications Server, Lync Server, Active Directory Domain Services (AD DS), and MSDN, are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

Table of Contents

Introduction..................................................................................................................................... 2

Network Performance Goals.......................................................................................................2

1 – What is a Network Assessment................................................................................................4

2 – What is a Unified Communications (UC) Network Assessment................................................5

Benefits of an Application-Specific Network Assessment............................................................5

3 – When should you perform a Network Assessment?..................................................................6

4 – What is the Scope of the Network Assessment?......................................................................7

5 – What are the Phases of the Network Assessment?..................................................................8

1 – Discovery............................................................................................................................... 8

Network Infrastructure & Utilization..........................................................................................8

Other Network Infrastructure Considerations...........................................................................9

Quality of Service (QoS)........................................................................................................10

2 – Modeling.............................................................................................................................. 12

Usage Modeling.....................................................................................................................12

Traffic Modeling...................................................................................................................... 13

Additional Considerations......................................................................................................14

3 – Traffic Simulation.................................................................................................................20

A: Limited Deployment...........................................................................................................20

B: Traffic Simulation Tool........................................................................................................21

Additional Considerations......................................................................................................21

4 – Recommendations...............................................................................................................22

6 – What Tools are Available for use?...........................................................................................23

Bandwidth Calculation Tools......................................................................................................23

Summary...................................................................................................................................... 24

2

IntroductionUnified Communications (UC) technologies introduce a new paradigm to data networks due to the real-time nature of these technologies. If the underlying network has performance and capacity issues, UC applications are quick to suffer from this. UC technologies should thus be deployed on data networks which are correctly scaled to accommodate the additional load which these new technologies introduce. Key factors that contribute to a reliable data network are capacity planning and ongoing monitoring. Capacity planning should be an ongoing process of analyzing network load to ensure that a network’s performance meets defined requirements, either current or future, based on projected user-base growth, and to determine whether a given network can accommodate the additional load of new applications and technologies.

The ‘network assessment’ exercise falls within the area of capacity planning - to help you understand the capabilities of your network. As such, a network assessment usually has a specific workload that helps organizations understand the impact of a new technology on their data networks.

The purpose of this document is to provide you with information to allow you to plan for a network assessment with specific reference to Microsoft Unified Communications.

The information provided here will include key indicators about when an assessment should be completed, a recommended approach for such an assessment, and information about available tools.

It is important to ask the following questions and this document will address these in order:

1. What is a network assessment? 2. What is a UC network assessment? 3. When should you perform a network assessment? 4. What is the scope of the network assessment? 5. What are the phases of a network assessment?6. What tools are available for use?

Network Performance GoalsThe characteristics that define the performance of an enterprise network are usually listed as:

Network latency – The time it takes one packet to travel from end to end in one direction.

Inter-arrival packet jitter – The variation in network latency from packet to packet. Packet loss – The percentage of packets that do not arrive at the far end.

Network Conditions Acceptable Quality Optimal Quality

Inter-arrival packet jitter (avg) ≤ 10ms ≤ 5ms

Inter-arrival packet jitter(max) ≤ 80ms ≤ 40ms

Packet loss rate (avg) ≤ 10% ≤ 2%

Network latency (One Way) ≤ 100ms ≤ 60ms

3

With respect to introducing a unified communications system to a network: When we talk about these values in terms of voice traffic, we must understand how they impact a voice call.

Network delay is most likely the easiest to understand. A large delay will sound like you are talking on a two-way radio (half-duplex), where you are talking over the other person, or you have to wait for the other party to finish talking before you can proceed. The generally accepted value for total delay, the delay from your mouth to my ear, is 250 milliseconds (ms) before it starts to interfere with the conversation flow. We will further discuss how we go from 250ms to the 60-100ms network delay mentioned below.

The principle of a voice over IP (VoIP) traffic communication solution is that your voice is encoded from one format to another. In the context of a VoIP system, your voice is encoded from an analog stream into a digital stream.

o The digital steam is then transmitted over the IP network and sent to a remote system or party in the form of network packets.

If one of these packets are lost, you stand to lose the portion of audio contained in that packet, which is usually around 20ms worth of audio data.

o If large numbers of packets are lost, then this will be clear to hear by the receiving party.

The media stack that Microsoft implements in its UC system’s attempts to smooth over the effects of packet loss, but packet loss concealment techniques cannot account for high packet-loss situations.

Jitter is really the variation in network delay from end to end. When the packets arrive at the receiving end, they are placed in a jitter buffer and queued for playback. If the variation in delay, jitter is too large, the packets will not arrive in time to be queued for playback. A late-arriving packet that is to be queued for playback will be dropped. The further you get from these goals, the more likely your users are to report poor voice quality.

4

1 – What is a Network Assessment A network assessment is a point-in-time evaluation of an organization’s data networks

to determine capacity and capabilities with respect to current requirements and loads. The evaluation is a process of creating an overall picture of a networks capability and

capacity where:o Tools are used to determine link capacities relative to capabilities.o Interviews are performed to determine business requirements and

dependencies. The output of the assessment allows engineers to determine whether the existing

network can accommodate additional traffic, such as when an organization has a requirement to deploy a new ‘data intensive’ application.

5

2 – What is a Unified Communications (UC) Network Assessment A unified communications network assessment is an application-specific assessment and can be seen as an extension to a standard assessment; whereby application-specific data is injected into the existing data networks in a controlled manner. Performing a UC network assessment can help answer the following question. ”Can my network support real-time traffic related to unified communications technologies?” The UC network assessment will thus assist with the following:

Demonstrate and record the effect of the application-specific data on the existing network.

Simulate and validate specific communication scenarios. Calculate the overall impact to the existing networks based on results recorded. Determine whether existing network capacity should be increased to accommodate the

new application.

An important point to highlight is that an application-specific network assessment usually includes traffic simulation – to understand the impact that the respective application data will have on a given network component, network segment, or the entire network.

Benefits of an Application-Specific Network AssessmentThe first priority for deploying a UC application or system is to ensure the best possible experience to end-users. Performing a UC network assessment helps reduce the risk by ensuring that the data networks are ready to accept the additional application-specific data.

A UC network assessment will assist with the following:

Validate whether a data network has sufficient capacity to carry the additional UC traffic.

Provide a quantitative assessment of current infrastructure metrics that could impact the UC system.

Highlight areas that might impact the ability to deploy the UC system. Reduce the overall deployment risk.

The aim of any UC network assessment is to provide information to answer the following questions:

Is a network ready for the proposed roll out a UC? Are there any networks that need to be upgraded before rolling out a UC? How much UC-specific traffic are users likely to produce? What are the characteristics of my network infrastructure? Are Quality of Service (QoS) policies appropriate for the proposed UC deployment?

6

3 – When should you perform a Network Assessment? There are typically two types of situations that would result in a network assessment:

1. Proactive capacity planning: a. You are planning a new technology deployment within your organization where the

impact of the new technology on the existing data networks is unknown. b. You have a limited production pilot deployment of the new application or system in

place and the requirement is to deploy this to the broader organization.2. Reactive engineering / troubleshooting:

a. An existing application or system, such as a UC system, is deployed and consuming network services but the system is not performing as expected. To help isolate whether the network is related to the system’s under performance, an application-specific network assessment can be performed. This will further assist in validating your initial capacity planning data and models.

7

4 – What is the Scope of the Network Assessment?The scope of a network assessment is typically dictated by the number of physical locations or network segments you need to include in your modeling, evaluation, and testing.

Note that this is not directly proportional to the total number of network segments or physical locations within your organization – but should rather be a representative subset of the network.

For instance, a national bank might have 900 branches, and they categorize their locations based on criteria such as user count and WAN connectivity requirements. If they have five remote location categories, then a typical network assessment would chose two locations from each category for testing.

Another example would be a manufacturer with 300 locations distributed globally. The recommendation would be to once again determine the locations that provide a representative sample. There could be exceptions to these guidelines, such as locations that have non-standard WAN links, unusually high-usage patterns, or remote locations with historically poor connectivity.

8

5 – What are the Phases of the Network Assessment?A network assessment can be split into four distinct phases and each phase depends on information collected from the previous phase. The four phases in order are:

1. Discovery: Understand all aspects of the network infrastructure.2. Modeling: Include both ‘usage modeling’ and ‘traffic modeling,’ where proposed

bandwidth usage is models based on existing usage data and using knowledge of the new systems data requirements to estimate usage requirements of the new system.

3. Traffic Simulation: Use a traffic simulator to apply application specific traffic to the production network. This phase also includes monitor the network segments to understand what impact the simulated traffic will have on the network.

4. Recommendations: Analyze data, and produce a report with recommendations.

Note that the phases described are generic to any type of network assessment performed. For the purpose of this document, additional data is included that is specific to a unified communication-specific network assessment.

1 – Discovery The objective of the discovery phase is to gain a full understanding of all aspects of the network infrastructure, the existing telephony infrastructure, conferencing infrastructure, and details of the planned unified communications application deployment.

Every discovery session is unique, but the end results should similar. You should understand the physical topology of the customer’s network, the size and type of their most common WAN connections, and the current levels of data traffic for each site.

Network Infrastructure & UtilizationTo start, collect information about the core data network infrastructure. Here is a list of discussion topics to guide you through this process:

What is the network topology? Does the implemented wide area network (WAN) use multiple providers?

o Are there known communication issues between these network providers? Are there any single points of failure in the network?

9

Create a list of all WAN Links with the following information: o Link throughput (bi-directional). o Link type (required for encapsulation information). o Document any known bottlenecks in WAN provider networks.

Determine the traffic utilization statistics for :o Average utilization during the busiest hour and should be viewed historically

over a 90-day period. o Peak link utilization which should also be viewed historically over a 90-day

period. Create a list of backup links, along with their respective data rates.

o An important factor is to determine how frequently these backup links are being used.

Other Network Infrastructure Considerations

Virtual Private NetworksThere is no rule that states virtual private network (VPN) connections are not supported to carry real-time data of UC applications. However, the VPN infrastructure should meet the same network performance goals as the rest of the network. The challenge is that many VPNs are not designed with real-time performance in mind.

With reference to Microsoft Office Communications Server 2007 R2 and Microsoft Lync Server 2010:

The recommendation is to use a split tunnel approach to keep UC traffic over the Internet to the Edge Servers.

This will reduce the VPN load and improve the performance of the UC applications.

Note that Microsoft Unified Communications is designed to be secure, where user authentication and media sessions traffic is encrypted.

IPsec Internet Protocol security (IPsec) is a networking technology that is used to secure

machine-to-machine connections on internal corporate networks. The initial IPsec handshake can cause delays that can cause call setup failures and or

mid-call drops. If IPsec is deployed, then the recommendation is to implement policy exemptions. The

following details should be considered:o Define media port range in policy and exempt from IPsec.o Exempt client connections to IP addresses of media terminating servers.o Do not run IPsec (or exempt processes) on media terminating servers.

10

WAN AcceleratorsTraffic shaping, caching, and WAN acceleration technologies should be bypassed for all real-time communications (RTC) traffic. If these are present in the network, pay careful attention to any additional latency these devices might add, even if they are configured to pass RTC traffic.

Now that you understand the physical network topology, you can proceed to investigate how data is prioritized on the network.

Quality of Service (QoS)Information relating to how network Quality of Service (QoS) is implemented approaches, including priority queue sizes, and WAN performance service-level agreements (SLAs) relating to priority queues should be determined.

Here are some topics to assist with this discussion:

What is the end-to-end QoS strategy? Is Differentiated Services Code Point (DSCP) marking implemented? Is traffic prioritized based on TCP/UDP port numbers? What size are the priority queues for each WAN link?

o Note that this could be a fixed size, or a percentage of the respective link.

Does the WAN provider(s) offer guaranteed performance across WAN links?

At this point in the document, we can review some additional concepts relating to network QoS.

QoS ApproachesThere are no defined rules for when to enable traffic prioritization across a network. There is only one way to guarantee quality of service and that is to enforce traffic prioritization end to end. The best way to achieve this is to enable DSCP marking of packets as they leave the respective communication endpoints (PC, phone, etc.). This ensures they receive priority across both the local and wide area networks. This approach gives you the flexibility to treat signaling, voice and video differently.

In practice, this end-to-end approach can be expensive to implement and difficult to maintain. This is why organizations often implement traffic prioritization at the WAN entry point of each location. This re-marking is usually based on the port range of the real-time and associated signaling traffic. The Microsoft media stack allows you to predefine the port range used by real-time media.

There could also be scenarios where you may feel comfortable taking a calculated risk by not implementing any traffic prioritization. Though not recommended, it is a valid option for you to consider. Determining the level of risk of not implementing traffic prioritization is covered later in the topic.

Network QoS Strategies:

11

Implementation Strategy

Additional Data

DSCP Marking Use Group Policy Objects (GPO) to enable traffic from the unified communication to be marked

Ethernet switches must trust DSCP marking from endpoints Should prevent third-party applications from re-marking traffic Prevent rogue machines from connecting to the network and

executing a Denial-of-Service (DoS) attack where the priority queue(s) are overloaded

Port-based Traffic is re-marked based on TCP/UDP port at the WAN ingress points Restrict media to 40 UDP ports

o By default, Office Communicator / Lync clients uses ports in the 1024 to 65535 range so to allow Port Based Prioritization you must define a smaller range and only prioritize the smaller range.

o With Office Communications Server 2007 R2, a minimum of 40 ports is required to enable both audio and video, where these two communication modalities would share ports in this assigned range.

o With Lync Server 2010, we require a minimum of 20 ports for Audio and 20 ports for video.

There is limited risk of network equipment upgradeso Some Ethernet switches do not support DSCP markings, so in

those cases you must upgrade your network equipment.o Since port-based is only used by the router connecting the

respective location to the WAN, do not be concerned about the type of Ethernet switched and whether it provides support for DSCP marking.

Potential issue when a third-party application randomly chooses a defined QoS port-range which results in the data being prioritized

DSCP + Port DSCP marking is implemented via policies Port ranges are restricted via policies (GPO) Confirm that DSCP and port ranges are correct A third-party application randomly using the specified port range will

not be marking with DSCP A third-party marking DSCP would not be using the defined port range

Protocol-based Traffic is re-marked based on protocol (SRTP) at WAN ingress points Requirement is that the network equipment must support deep

packet inspection at ‘line speed’

IP-based Traffic is re-marked based on source or destination IP addresses This approach works for centralized PSTN and conferencing traffic

(GNOC) This approach will not work well for peer traffic scenarios

The WAN ingress strategy is recommended where LAN is optional.

12

A mixed approach of using DSCP marking and port-based works well and means that the distribution layer switch removes the DSCP marking if the port range is incorrect. This will prevent rogue third-party applications from being prioritized on the network.

2 – Modeling

Usage Modeling

Existing Enterprise Voice CapacityUsage modeling is a process of analyzing existing usage data and using this data to deduce the load on the new system.

A key input to usage modeling is reviewing the existing Private Branch eXchanges (PBX) infrastructure capacity. After the discovery sessions, you should gather the following information:

How many PBX’s are implemented, ideally with an inventory of vendor and version? The number of public switched telephone network (PSTN) channels provisioned (E1

= 30 channels, T1 = 24 channels, etc.). The number of inter-site tie connections between PBXs, or whether inter-site calls

are made via the PSTN. The number of users at each location. Usage statistics such as the maximum number of concurrent calls during the ‘busy

hour’.

The information collected in this phase will assist with validating the models used for estimating two of the three major call flows. This data assists with ‘Concurrent PSTN Calls’ and ’Peer Calls’.

Existing Conferencing TrafficIf an existing dial-in conferencing provider is used to provide audio-conferencing services, then you should have access to detailed usage reports used as part of the billing process. This usage data is valuable when used as a tool to assist with the validation of estimation models for dial-in conferencing and general conferencing behavior.

Information that should be collected includes:

Maximum number of conferencing ports used. Average maximum number of concurrent conferences, including the number of

participants when that maximum occurs.

13

Average meeting size. Average meeting duration. Total minutes of conferencing used per day and per month.

Traffic Modeling Modeling traffic is effectively a process of calculating or extrapolating expected data usage of an application based on understanding the data requirements of the application. Usage scenarios can be defined and data calculation can be performed based on the respective scenarios.

However, modeling RTC traffic is only as useful as the information provided. There are certainly some published generic guidelines about utilization levels and user profiles, but they are not a replacement for obtaining accurate information on actual PSTN usage, peer calling, and conferencing usage.

An important point to note is that traffic modeling alone will not guarantee a successful deployment of a new application such as a unified communications application. The recommendation would be to supplement the modeling with the following:

Design / modeling validation by confirming actual utilization levels at specific project delivery milestones

Perform traffic simulation (discussed in the Traffic Simulation section)

A traffic modeling exercise will state that a given data network infrastructure could support X kilobits per second (Kbps) of real-time media traffic between, for instance, Site A and Site B.

The modeling exercise further indicates that X Kbps of traffic equates to Y PSTN calls and Z users in a conference.

The methodology used allows you to estimate that X Kbps is the total traffic value – but it must be noted that this is still only an estimate.

Traffic modeling is more an art than a science. Most consultants that are tasked with performing traffic modeling will use several usage models that will provide a likely range of peak usage values, or maximum concurrency rates. For example, audio conferencing maximum concurrency rates could range from 1% to 5% depending on the model used. These numbers will also vary depending on the selected usage profile, such as whether you consider your users to be light or heavy users of a specific communication modality.

There are some industry rules that should act as red flags during the planning process.

No more than 30% of any link should be occupied by real-time traffic at any given time. If the average busy hour traffic plus the estimated real-time traffic levels are higher than

100% of the link speed. o You cannot deploy a UC application without impacting the overall performance

of the data network.

When network discovery and usage modeling has been completed, there should be sufficient information to provide a picture of whether the current network is engineered to support the additional traffic being part of the proposed UC system. From the Discovery phase, we determined the Average busy hour

14

utilization for links, as well as the Peak utilization for each link, and from the Usage Modeling, we estimated the Total volume of UC traffic on each network link included in the modeling.

Additional ConsiderationsDuring the traffic modeling process you must take the following concepts into consideration.

Call-Flow ScenariosWithin any IP-based UC solution, certain characteristic call-flow scenarios exist and affect the result of traffic modeling along with traffic simulation. Scenarios include peer-to-peer calls, conference calls, and PSTN/PBX calls. Each scenario has different media paths and must be modeled and or simulated to determine the future load requirements. There will be other call-flow scenarios with the solution, namely those of remote users, or federated communications, but these will be discussed separately. Let us look at each of these calls flows in turn:

Peer-to-Peer Calls

A peer-to-peer call is any communication session between two UC endpoints. These calls originate and terminate on UC endpoints within your corporate network. A peer-to-peer session is characterized by call control signaling being relayed centrally

through the UC infrastructure, either with Office Communications Server 2007 R2 or Lync Server 2010, and the real-time media is exchanged between the two endpoints.

Note that the media is not traversing any central point or relay such as a conferencing server.

Within Microsoft Unified Communications systems such as Office Communications Server 2007 R2 and Lync Server 2010, a peer-to-peer voice session uses wide-band RTAudio as first choice.

Conference Calls

A conference call is a communication session that originates on a UC endpoint, but terminates on an Audio/Video conferencing server.

15

During a conference, multiple sessions will terminate on the A/V conferencing server. The characteristic of a conference call is where the media is exchanged between the UC

endpoint and the A/V conferencing server. Within Microsoft Unified Communications systems such as Office Communications

Server 2007 R2 and Lync Server 2010, a conference call session uses G722 for audio as first choice, but can also use other audio codecs such as Siren or G711 depending on the specific scenario.

PSTN / PBX Calls

Within the context of a Microsoft unified communications system, a PSTN call is any communication session that originates on a UC endpoint but will terminate on a Mediation Server for onwards relay to a PSTN Gateway or a qualified IP PBX.

Based on the implemented call routing, the PSTN gateway could either relay the call to a PSTN endpoint or a PBX endpoint.

If a qualified IP PBX is implemented, then the Mediation Server can communicate directly with the IP PBX.

In Office Communications Server 2007 R2 the Mediation Server will relay both the media and signaling traffic to the next hop gateway or PBX.

In Lync Server 2010, a new feature was introduced, known as ‘media bypass,’ and allows the Lync client endpoint to bypass a Lync Mediation Server – where media traffic is sent directly to a qualified PSTN gateway or IP PBX.

Codec InformationTo correctly estimate likely traffic levels, you must understand the bandwidth used for different call- flow scenarios. The media traffic bandwidth usage can be challenging to calculate due to the number of different variables, such as codec usage, resolution (for video), and activity levels. The bandwidth usage is a function of the codec used and the activity of the stream, both of which vary between scenarios. The following table lists the audio codecs commonly used in Microsoft Lync Server 2010 communications software scenarios.

Audio Codec Bandwidth

Audio codec RTAudio Wideband

RTAudio Narrowban

d

G.722 G.711 Siren

Scenarios Peer-to-peer

Peer-to-peer, PSTN

Conferencing

PSTN Conferencing

Audio payload bitrate (KBPS)

29 11.8 64 64 16

Bandwidth audio payload, IP header, Ethernet Headers, UDP, RTP and SRTP (Kbps)

57 39.8 95.6 92 47.6

Bandwidth audio payload, 86 51.6 159.6 156 63.6

16

IP header, Ethernet Headers, UDP, RTP, SRTP and forward error correction (Kbps)

The bandwidth numbers in the previous table are based on 20ms packetization (50 packets per second), and for Siren and G.722 include the additional secure real-time transport protocol (SRTP) overhead from conferencing scenarios and assume the stream is 100% active. Forward error correction (FEC) is dynamically used when there is packet loss on the link to help maintain the quality of the audio stream.

For video, the codec is always RTVideo. The bandwidth required depends on the resolution, quality, and frame rate. For each resolution, there are two interesting bit rates:

Maximum payload bitrate This is the bitrate that a Lync 2010 endpoint will use for resolution at the maximum frame rate supported for this resolution. This value is interesting because it allows the highest quality and frame rate video.

Minimum payload bitrate This is the bitrate that a Lync 2010 endpoint will use for a resolution of approximately one frame per second. This value is interesting so that you can understand the lowest value possible in cases where the maximum bitrate is not available or practical. For some users, one frame per second video might be considered an unacceptable video experience, so use caution when considering these bitrates.

Video Resolution Bandwidth

Video codec RTVideo RTVideo RTVideo RTVideo

Resolution Main Video CIF

Main Video VGA

Main Video HD

Panoramic Video

Maximum video payload bitrate (Kbps)

250 600 1500 350

Minimum video payload bitrate (Kbps)

50 350 800 50

Video FEC is included in the video payload bitrate when it is used so there are not separate values with video FEC and without video FEC.

Endpoints do not stream audio or video packets continuously. Depending on the scenario, there are different levels of stream activity which indicate how often packets are sent for a stream. The activity of a stream depends on the media and the scenario, and does not depend on the codec being used.

In a peer-to-peer scenario: o Endpoints send audio streams only when the users speak.o Both participants receive audio streams.o If video is used, both endpoints send and receive video streams during the

entire call.

In a conferencing scenario:

17

o Endpoints send audio streams only when the users speak.o All participants receive audio streams.o If video is used, only two endpoints send a video stream at a time (the active

speaker and the previous active speaker).o If video is used, all participants receive video streams.

The following table shows stream activity levels based on measurements of customer data.

Scenario Media Estimated stream activity (%)

Peer-to-peer sessions Audio 61

Peer-to-peer sessions Main video CIF 84

Peer-to-peer sessions Main video VGA 83

Peer-to-peer sessions Main video HD 80

Peer-to-peer sessions Panoramic video 74

Conferencing Audio 43

Conferencing Main video CIF 84

Conferencing Main video VGA 83

Conferencing Main video HD 80

Conferencing Panoramic video 74

PSTN Audio 65

In addition to the bandwidth required for the real-time transport protocol (RTP) traffic for audio and video media, bandwidth is required for real-time transport control protocol (RTCP). RTCP is used for reporting statistics and out-of-band control of the RTP stream. For planning, use the bandwidth numbers in the following table for RTCP traffic. These values represent the maximum bandwidth used for RTCP and differ between audio and video streams because of differences in the control data.

RTCP Bandwidth

Media RTCP maximum bandwidth (Kbps)

Audio 5

Video 10

For capacity planning purposes, the following two bandwidths are of interest:

Maximum bandwidth without FEC o The maximum bandwidth that a stream will consume, including the typical

activity of the stream and the typical codec used in the scenario without FEC.

18

o This is the bandwidth when the stream is at 100% activity and there is no packet loss triggering the use of FEC.

o This is interesting for computing how much bandwidth must be allocated to allow the codec to be used in a given scenario.

Maximum bandwidth with FEC o The maximum bandwidth that a stream consumes, including the typical activity

of the stream and the typical codec used in the scenario with FEC. o This is the bandwidth when the stream is at 100% activity and there is packet

loss triggering the use of FEC to improve quality. o This is interesting for computing how much bandwidth must be allocated to

allow the codec to be used in a given scenario and allow the use of FEC to preserve quality under packet-loss conditions.

The following tables also list an additional bandwidth value, Typical bandwidth. This is the average bandwidth that a stream consumes, including the typical activity of the stream and the typical codec used in the scenario. This bandwidth can be used for approximating how much bandwidth is consumed at any given time by media traffic but should not be used for capacity planning, since individual calls exceed this value when the activity level is higher than average.

The following tables provide these three bandwidth values for the various scenarios.

Audio/Video Capacity Planning for Peer-to-Peer Sessions

Media Codec Typical stream bandwidth (Kbps)

Maximum stream bandwidth without FEC

Maximum stream bandwidth with FEC

Audio RTAudio Wideband

39.8 62 91

Audio RTAudio Narrowband

29.3 44.8 56.6

Main video CIF

RTVideo 220 260 Not applicable

Main video VGA

RTVideo 508 610 Not applicable

Main video HD

RTVideo 1210 1510 Not applicable

Panoramic video

RTVideo 269 360 Not applicable

Audio/Video Capacity Planning for Conferences

19

Media Typical codec

Typical stream bandwidth (Kbps)

Maximum stream bandwidth without FEC

Maximum stream bandwidth with FEC

Audio G.722 46.1 100.6 164.6

Audio Siren 25.5 52.6 68.6

Main video CIF

RTVideo

220 260 Not applicable

Main video VGA

RTVideo

508 610 Not applicable

Panoramic video

RTVideo

269 360 Not applicable

Audio Capacity Planning for PSTN

Media

Typical codec

Typical stream bandwidth (Kbps)

Maximum stream bandwidth without FEC

Maximum stream bandwidth with FEC

Audio G.711 64.8 97 161

Audio RTAudio Narrowband

30.9 44.8 56.6

The network bandwidth numbers in these tables represent one-way traffic only and include 5 Kbps for RTCP traffic overhead for each stream. For video, the maximum video bit rate is used for computing the maximum stream.

You can find this information on TechNet at the following address: Lync Server 2010 – Capacity Planning – Media Traffic Network Usage

Forward Error Correction (FEC) Under certain network conditions, the media stack implemented by Microsoft enables

FEC, which adds some additional redundant encoding and protects against packet loss. Forward error correction is triggered when packet loss is above a certain percentage.

Although FEC does assist in scenarios when overall packet loss is high, it increases the bandwidth required per call, since the payload size doubles for each voice packet.

A correctly engineered enterprise network should never trigger FEC during normal operation.

20

3 – Traffic Simulation During this next phase of the network assessment, we depart from the theoretical exercises based on historical data and projected calculations. These calculations are valuable but might not take physical network conditions into account. During this next phase of the network assessment we will inject actual application-specific data onto the production network in a controlled manner to determine how this additional data will affect the network as well as gain an understanding how the respective application will perform on the current network.

With reference to a UC network assessment: By sending representative RTC traffic through a network, the full readiness picture of the network infrastructure is revealed.

Two options are available to perform traffic simulation:

A: Limited DeploymentWith this option, you must have the minimum required components of the UC system, such as registrars and conferencing servers along with client end-points on the production network. You would then use this limited implementation to simulate usage:

The advantage of using a limited implementation of the UC system is that you can simulate the actual application data and application usage.

o Additionally, the Office Communications Server 2007 R2 or Lync Server 2010 Monitoring server role can be deployed as well. This allows you to gather specific data on the simulated client sessions.

In the case of Office Communications Server 2007 R2 or Lync Server 2010, you can deploy the required version on the production network without integrating the minimum required components into core aspects of the network infrastructure such as the Active Directory Domain Services.

o You have the option to stand up a separate temporary Active Directory Forest to host the servers and application components required to perform your traffic simulation.

Workload simulation would be the most challenging aspect of the simulation process.o The concept would be to write and execute various use-case scenarios, such as

determining the impact of a multi-party audio conference call where multiple remote users join a centrally (conferencing server) hosted conference with ‘x’ number of users connecting from a remote WAN connected location.

o To perform such a test could be challenging since you would need multiple workstations configured on the remote network where ‘test’ users could all connect to the centrally hosted audio conference. Challenges include:

Sourcing and installing the remote workstations Controlling each workstation remotely Generating audio from each end-point to simulate a realistic

conferencing scenarioo These challenges are compounded if your use-case scenario is expanded to

include multiple remote locations.

21

B: Traffic Simulation ToolUse a traffic simulation tool to assist with simulation. Simulation tools are designed to be deployed in a stand-alone manner, which means that the respective tool would not require any components of the actual UC system to be in place in order for it to function.

Traffic simulation tools usually have two components; the endpoints that generate and terminate simulated traffic and a management console to configure the endpoints as well as gather data from the end-points.

The advantage of using a traffic simulation tool is that the end-point software usually has the ability to simulate multiple client sessions – therefore reducing the number of remote workstations required.

End-point software can also be configured to simulate a specific workload such as voice and or video as well as randomize the transmissions to better simulate a real-world, end-user scenario.

The disadvantage with respect to Office Communications Server 2007 R2 and Lync Server 2010 is that there currently are no third-party real-time traffic simulation tools that support the Microsoft codecs, such as Microsoft’s Real Time Audio (RTAudio) or RTVideo codecs.

Traffic simulation tools that are available include non-licensed codec’s such as G.711, etc.

o The disadvantage of using a tool that does not use application-specific codecs is that your traffic simulation will accurately reflect the future state.

Additional ConsiderationsAn ideal network provides consistent levels of network latency, jitter, and packet loss. There is no threshold beyond which voice quality will be poor; however, there are some guidelines beyond which users are far more likely to complain about a poor user experience.

Network Conditions Acceptable Quality Optimal Quality

Interarrival packet jitter (avg) ≤ 10ms ≤ 5ms

Interarrival packet jitter(max) ≤ 80ms ≤ 40ms

Packet loss rate (avg) ≤ 10% ≤ 2%

Network latency (One Way) ≤ 100ms ≤ 60ms

Although these traffic simulation tools can generate mean opinion scores (MOS) for each simulated call, in practice we ignore those values in favor of the raw network performance metrics. By looking at network characteristics rather than MOS scores, it is much easier to understand why we talk about generating the traffic equal to the total bandwidth required by specific call flows, rather than the X number of RTAudio calls.

22

To derive the maximum results from any traffic simulation, it should be run for seven consecutive days and operating 24 hours per day.

4 – Recommendations Once the preceding phases are complete the data gathered should reviewed and

analyzed; findings and recommendations should be then be documented.

23

6 – What Tools are Available for use?

Bandwidth Calculation ToolsMicrosoft Consulting Services (MCS) has created a bandwidth planning tool for Lync Server 2010. This tool takes into account changes to conferencing codec, G722, and includes updated usage modeling information, and personas. It also includes modeling for Central Sites, and Branch Sites.

This tool provides a framework for architects, consultants, and administrators to estimate the additional network traffic that a Lync Server deployment will generate.

The tool can be used both by experienced consultants with expert product knowledge and by customers who don’t have specific product knowledge but would like to understand the possible network impacts of a Lync Server deployment.

With little more information than the number of users on a particular site, and keeping all other parameters at their default setting, you can estimate the order of magnitude impact of Lync Server on your network. The defaults assume that your users use all communications modalities and have a medium usage profile.

When the customer user personas and usage models are entered into the Lync Bandwidth Planning Tool, the output will show a detailed breakdown of the capacity requirement per modality. You can then determine whether you need to provide additional network capacity before you deploy Lync Server 2010.

At a glance you’ll be able to see, for each site, whether the estimated bandwidth required is higher than the bandwidth that you have allocated for real time media.

The tool breaks this information down for central sites and for branch sites. For easy reference, the tool also produces a table with video bandwidth removed so you can see how video affects your bandwidth requirements at each site.

Manual Approach: By following the published planning values on TechNet, it is possible to create a simplified traffic estimation based on those values for specific workloads: Lync Server 2010 – Capacity Planning – Media Traffic Network Usage

24

SummaryA network assessment should provide sufficient information to describe a data network infrastructure before the unified communications system is deployed as well as what the impact might be to the network after the deployment.

Performing a network assessment reduces the risk of deploying a unified communications system within an organization and it is important to note that it will not eliminate all risk. At the end of a network assessment, you should be able to understand the challenges associated with the additional traffic the UC system will introduce, identify bottlenecks that may occur on the existing network, and be closer to successfully deploying your chosen unified communications application within your organization.

25