Export (0) Print
Expand All

Deploying Office Communications Server 2007 R2 Using the Supported DiffServ Service Types

Communications Server 2007 R2

Office Communications Server 2007 R2 is designed to use Differentiated Service (DiffServ) types to provision audio and video communications to all unified communications (UC) enabled users on its supporting network. In most cases, deploying DiffServ with a Communications Server 2007 R2 deployment requires additional administrative configuration to ensure that the DiffServ implementation is compliant with the network that is hosting Communications Server2007 R2. The Windows server and client operating systems supported by Communications Server 2007 R2 provide the DiffServ policy implementations to ensure compliance for the default DiffServ audio and video service types on most networks, along with most of the enterprise level tools that are needed to troubleshoot and complete the Communications Server 2007 R2 DiffServ implementation.

Author: Michael Adkins

Publication date: September 2010

Product version: Office Communications Server 2007 R2

Differentiated Services (DiffServ) is a mechanism that is designed to help ensure Quality of Service (QoS) for network aware applications that need a compliant way to send and receive prioritized information across an IP network. DiffServ adds Differentiated Services Code Point (DSCP) markings to the IP traffic. These DSCP values are decimal numbers that represent the different levels of delivery for IP traffic that Diffserv can provide. Communications Server 2007 R2 supports the DiffServ delivery standards for use with audio/video conferencing. DiffServ support in Communications Server 2007 R2 enables you to prioritize the flow of audio and video traffic.

Communications Server 2007 R2 supports the following DiffServ types for audio and video:

  • SERVICETYPE_CONTROLLEDLOAD for video communications

  • SERVICETYPE_GUARANTEED for audio communications

When configured, these DiffServ types are automatically recognized by the Windows QoS Packet Scheduler. The QoS Packet Scheduler's primary duty is to manage the outgoing IP network traffic in a manner that is compliant with the sending application’s DiffServ standard. In this case, the sending applications are Microsoft Office Communicator 2007 R2 and Microsoft Office Live Meeting 2007, Office Communications Servers and Exchange Unified Messaging servers. The QoS Packet Scheduler adds numeric values to the DifferentiatedServicesField field for the designated outbound IP traffic. This process is known as DSCP marking. The next hop on the network path will inspect the IP traffic's DifferentiatedServicesField field for DSCP values and route the IP traffic according to its local configuration for DiffServ. Communications Server default DiffServ configuration uses the following DSCP values:

  • SERVICETYPE_CONTROLLEDLOAD = 0x18 (24 decimal

  • SERVICETYPE_GUARANTEED = 0x28 (40 decimal)

The DiffServ IP prioritization standard was developed with compatibility in mind for two common network traffic prioritization methods:

  • IP precedence: a method for prioritizing legacy layer three IP packets

  • 802.1p: a legacy Ethernet standard that enables layer two switches to prioritize Ethernet frames

What these two methods have in common is the 3 bits they use to define the priority of the IP packet or the Ethernet frame. The IP packet will host these 3 bits for IP precedence as the high-order bits of the 6-bit TypeOfService field, also known as Type of Service (ToS), and the Ethernet frame will host these 3 bits in its 3-bit Priority field, also known as Class of Service (CoS).

The DifferentiatedServicesField field has deprecated the TypeOfService field for use with the IP packet. The DifferentiatedServicesField field consists of 6 bits though it still reserves the 3 high-order bits to define the IP precedence for the IP packet.

The following are the eight values that define IP precedence or priority:

000 = 0 - Routine

001 = 1 - Priority

010 = 2 - Immediate

011 = 3 - Flash

100 = 4 - Flash Override

101 = 5 - Critical

110 = 6 - Internetwork Control

111 = 7 - Network Control

The correlation of the bit values for DiffServ DSCP, IP precedence, and 802.1p are defined as follows:

DSCP = 40

IP precedence = 5

802.1p = 5

The SERVICETYPE_GAURANTEED DiffServ policy, which is used to provide the DSCP markings on the audio portion of the IP audio video traffic, has an IP precedence and 802.1p value of 5.

DSCP = 24

IP precedence = 3

802.1p = 3

The SERVICETYPE_CONTROLLEDLOAD DiffServ policy, which is used to provide the DSCP markings on the video portion of the IP audio video traffic, has an IP precedence and 802.1p value of 3.

How are these defined as DiffServ DSCP values? The IP precedence value consists of the high-order 3 bits in the DSCP field of the IP packet as follows:

011 = 3

101 = 5

However the DSCP field uses 6 bits to define the full DSCP value as follows:

011000 = 24

101000 = 40

This is how the DiffServ DSCP value defines IP precedence for legacy routers and Layer two switches. The remaining 3 bits in the DifferentiatedServicesField field are used to define the queuing standards that can be used to process the flow or flows of the DSCP marked IP traffic. These remaining 3 bits can be updated on a per-hop basis as an Internet Service Provider's (ISP) router inspects the DifferentiatedServicesField field of the IP packet and updates these last 3 bits to meet that vendors IP traffic prioritization for a specific DiffServ flow or flows.

noteNote:
A DiffServ flow consists of an IP source and destination port, a source and destination IP address, and a transport protocol definition.

The IP packet is intercepted by the incoming interface of a supportive vendor's router and is updated from its original value as follows:

011000 to 011010 = low drop probability

011000 to 011100 = medium drop probability

011000 to 011110 = high drop probability

The methodology defined in the previous example allows the finite prioritization of DiffServ-enabled IP traffic according to the service level agreements of the ISP’s customer.

The configurations to enable DiffServ on Communications Server 2007 R2 servers and Microsoft UC clients are different as described in the following list:

  • Enable the Diffserv configuration on the Communications Server 2007 R2 Enterprise Edition or Standard Edition front end servers or Mediation servers by updating the Communications Server 2007 R2 Windows Management Instrumentation (WMI) classes using the local WBEMTest.exe tool. For details, see the Servers section later in this article.

  • Enable the Diffserv configuration on the supported Windows clients that host the Microsoft UC clients software by editing the registry. For details, see the Clients section later in this article.

  • Ensure that all intermediate nodes in the network route (such as firewalls, routers, and switches) are configured to enforce and prioritize IP packets with DiffServ. For details, see the DiffServ Compatibility with Windows Default DSCP Values section later in this article.

To enable DiffServ on the front-end or Meditation servers, do the following:

  1. Enable the use of DiffServ on the audio and video enabled servers for a Communications Server 2007 R2 enterprise by doing the following:

    1. Set the ServerQoSEnabled property to TRUE in the WMI configuration for the front end servers MSFT_SIPPoolConFigSetting active class instance.

    2. Ensure that the Windows Server 2008 operating system or Windows Server 2003 x64 Edition QoS Packet Scheduler is installed and enabled.

    For details, see Enabling DSCP Marking.

  2. Enable the use of DiffServ on the audio servers for an Exchange 2007 SP1 or Exchange 2010 Unified Messaging Server hosted in a Communications Server 2007 R2 environment by doing the following:

    1. Update the server running Windows Server 2003 x64 or Windows Server 2008 registry as follows: HKLM\Software\Microsoft\RTC\Transport\QoSEnabled=1 DWORD

    2. Ensure that that the Windows Server 2008 or Windows Server 2003 x64 QoS Packet Scheduler is installed and enabled.

    For details, see How to Configure Quality of Service (QoS) for Unified Messaging (Exchange 2010) or Configure Quality of Service (QoS) for Unified Messaging (Exchange 2007 SP1).

    noteNote:
    By default, the QoS Packet Scheduler is installed on computers running Windows XP, Windows Vista, Windows 7, and Windows Server 2008. However, by default, the QoS Packet Scheduler is not installed on Windows Server 2003.

Windows XP Professional SP2 and SP3, Windows Vista SP1 and SP2, and Windows 7 x64 and x86 clients are compatible for use with Communicator and Live Meeting 2007.

To enable DiffServ on Windows client computers, do the following:

  • For x86 Windows client computers, set the following registry value to enable DiffServ for Communicator and Live Meeting clients: HKLM\Software\Microsoft\RTC\Transport\QoSEnabled=1 DWORD

  • Ensure that the QoS Packet Scheduler is installed on the supported Windows client computers.

After you apply the steps in the previous section, it’s important to verify that all servers and clients in your Communications Server 2007 R2 environment are sending and receiving the correct DSCP makings during audio/video sessions.

To verify that your configuration is properly set, do the following:

  1. Use Netmon 3.4 to see what DSCP value the Windows QoS Packet Scheduler is adding to the DifferentiatedServicesField in the audio and video IP packet header.

    noteNote:
    In a production Communications Server 2007 R2 environment, server side logging and network captures should not be taken if they are not necessary. They can grow very quickly in size and become unpractical to analyze because of their size.
  2. Use the following display filters in Netmon 3.4 to display the interesting media traffic in your Windows network captures:

    • ProtocolName == "RTP" OR IPv4.DifferentiatedServicesField.DSCP == 0x18

    • ProtocolName == "RTP" OR IPv4.DifferentiatedServicesField.DSCP == 0x28

    noteNote:
    0x18 and 0x28 are the Windows default DSCP values. Remember that any applied DiffServ group policies will change these values.
  3. Use Netmon 3.4 to analyze the Ethernet frame and locate the IPv4 packet information. Find the DifferentiatedServicesField header and check the DSCP information contained in it. Figure 1 illustrates an example. This IPv4 network frame shows that the DSCP is set to 24 (decimal), which is 0x18 (hexadecimal).

    Figure 1. DSCP information produced by Netmon 3.4

    a7745dcd-87e4-4423-8af0-6d4827804969

    You can download Microsoft Network Monitor 3.4 from the Microsoft Download Center.

  4. On a Windows client computer that hosts Communicator or Live Meeting 2007, turn on SIP logging to get the SIP signaling information that defines the network connectivity, such as IP addresses and ports used for media connectivity between UC clients that share audio and video communications on the network. For details about how to gather and analyze logging information in Communicator 2007 R2 and Live Meeting 2007, see Client Logging in Communicator.

    To analyze client logs, download the Office Communications Server Resource Kit tools. Snooper.exe is part of the Communications Server Resource Kit tools and provides a convenient tool to help you analyze client log files generated by Communicator and Live Meeting. For details about Snooper.exe, see Snooper Tool.

  5. Remember that media sharing sessions between two Communicator clients are always peer to peer. It takes three or more parties to start an audio/video conference. By default, Live Meeting 2007 always uses the conferencing features of Communications Server 2007 R2.

  6. Ensure that the outgoing audio/video IP traffic that is captured from a Windows Vista or Windows 7 computer that is running Live Meeting 2007 and has a DSCP marking of 0 in the DifferentiatedServicesField of the IP packets. For details, see “Support for Windows Vista and Windows 7” in the Known Issues section later in this article. For details about configuring a DiffServ policy for Live Meeting 2007 on a Windows 7 computer, see “Windows Server 2008 QoS Based Policy” in the Known Issues section later in this article.

Hardware vendors that support the use of DiffServ types may use default DSCP markings that differ from the defaults of the Communications Server enterprise. This will become apparent in network captures that are taken from the DiffServ enabled UC client. These network captures will show the DiffServ enabled UC client receiving IP traffic that has an incorrect DSCP marking from its peers. The same network capture will show the DiffServ enabled UC client sending IP packets with the correct DSCP marking to its peers as described in the DiffServ and Office Communications Server section earlier in this article. For details, see “DiffServ Compatibility with Windows Default DSCP Values” in the Known Issues section later in this article.

Windows Server 2003 and Windows Server 2008 Active Directory directory services provide several DiffServ group policy settings at the domain and local computer level. These group policy settings enforce the DSCP prioritization of Communications Server 2007 R2 audio and video traffic on a DiffServ enabled IP network. To configure the DiffServ local group policy, use the Local Group Policy Editor (gpedit.msc) on the supported Windows clients and servers.

The following group policy settings configure DSCP for outgoing audio and video IP packets as shown in Figure 2:

  • Controlled Load service type (video)

  • Guaranteed service type (audio)

Figure 2. Service types for configuring DSCP

89a244d6-d0b4-4ddd-bd15-0f1db4044e48

These policy settings will mark the IP header of audio and video traffic between Communications Server servers and computers running Communicator within the enterprise to match the existing network’s DiffServ DSCP configuration for audio and video IP traffic.

This policy ensures that all outgoing audio and video IP packets contain a DSCP marking that matches the designated value of the applied Windows group policies, local computer policy, or registry configuration for DiffServ (Controlled Load service type (video) and Guaranteed service type (audio)).

This policy ensures that all outgoing audio and video IP packets that host a DSCP numeric value that is not supported by the Windows group, local computer policy, or registry configuration for Diffserv (Controlled Load service type (video) and Guaranteed service type (audio)) will be updated to a DSCP value that is compliant to the applied DiffServ group policy.

noteNote:
The policy's DSCP value of conforming packets and DSCP value of nonconforming packets are not effective if the DWORD registry setting QoSEnabled = 1 is missing or set to a value of QoSEnabled = 0 on the Windows computer.

To ensure that a local or domain DiffServ policy is applied, do the following:

  1. Update group policies on client computers. DiffServ local or domain group policies are applied at the level of the computer. Computer level group policies may require a reboot of the computer to ensure that they are correctly applied. If rebooting the computer is not an option, use the following command prompt command to check Active Directory for new group policies that should be applied to the local computer and then applies them.

    C:\>gpupdate /force

  2. To make sure that the local policies for DiffServ are applied to the Windows server or Windows client. Use the Local Group Policy Editor (gpedit.msc) to see if the Controlled Load service type (video) and Guaranteed service type (audio) have been applied to the Windows server or Windows client. See Figure 2 earlier in this article.

  3. Use the Resultant Set of Policies console to make sure that the domain policies for DiffServ, Controlled Load service type (video) and Guaranteed service type (audio), have been applied in Active Directory (Figure 3). To open the Resultant Set of Policies Console, click Start, type rsop.msc in the Search programs and files box, and then press Enter.

    Figure 3. Verify DiffServ policies in Resultant Set of Policy Console

    49f4d7cf-9883-4256-afc5-dd3ebd66e999
  4. Ensure that the recommended hotfixes are applied to the Widows servers and client computers. There are known issues with the QoS Packet Scheduler’s ability to recognize the application of the local or domain group policies for DiffServ. These issues cause the QoS Packet Scheduler not to add the specified DSCP value to the field of the outgoing IP packets that contain audio/video information. These issues must be addressed prior to the deployment of the DiffServ Windows group policies or local computer policy or registry configurations. For details, read the following Microsoft Knowledge Base articles:

DiffServ policies are susceptible to any pre-existing network configurations that include or do not include DiffServ policy configurations. Below is a list of some of the more typical items that can keep Diffserv policies from working properly for the Office Communications server 2007 R2 enterprise.

The default configuration described in the Configuring DiffServ section earlier in this article is great if the hosting network’s DiffServ policies are configured to manage the Windows default DSCP marked IP traffic in the appropriate manner. However, the prioritization and routing of DiffServ enabled IP traffic depends on the DiffServ policies that are applied to hardware devices on the network, such as routers and layer 3 VLAN switches or firewalls. These devices must support DiffServ policies that are configured to analyze and then prioritize IP audio and video traffic based on the Windows default DiffServ DSCP values.

If the supporting network does not use DiffServ DSCP policies or uses DiffServ DSCP policies that are not compliant with the Windows default DiffServ DSCP values, prioritization of the Communications Server 2007 R2 audio and video traffic on the network may fail. Following are some reasons why this type of problem can occur:

  • Use of proprietary DSCP values: The network’s routers or firewalls are designed to use proprietary DSCP values that meet the specifications for a specific hardware vendor’s DiffServ policies.

  • IP packets not prioritized across WAN links: If the network’s Internet routers are not configured with DiffServ policies, they will not prioritize IP packets with DSCP markings. Any DiffServ enabled Communications Server audio and video traffic will not be prioritized as expected.

  • DSCP markings inadvertently updated to 0: The network’s routers or firewalls can be configured with DiffServ policies that exclude the prioritization of DSCP marked IP traffic. This type of DiffServ policy preserves the integrity of existing DiffServ types for SERVICETYPE_CONTROLLEDLOAD and SERVICETYPE_GUARANTEED DSCP markings. In this scenario, the network device will inspect all DSCP marked IP packets and set their DSCP value to 0 to ensure that non compliant IP traffic is not prioritized.

  • Unknown routing costs could be applied due to DSCP markings: The network routers can be configured with DiffServ policies that do not recognize the Windows default DSCP values for audio and video traffic. Because of this, the traffic may be routed using a default route that does not provide an optimal routing cost factor.

  • Dropped IP packets due to DSCP markings: The internal network routers can be configured with DiffServ policies that treat the DiffServ enabled Communications Server audio and video traffic with zero tolerance. In this case the ISP's routers are configured to drop all IP traffic with DSCP markings that do not match the DSCP values of their router's DiffServ policies.

The previous descriptions cover some of the issues that are exposed when the Windows default DiffServ policies for SERVICETYPE_CONTROLLEDLOAD and SERVICETYPE_GUARANTEED are used These descriptions also provide some insight into the limitations that are caused by enabling the prioritization of audio and video IP traffic for use in a Communications Server 2007 R2 enterprise. Overcoming some of these limitations is possible by using Microsoft DiffServ group policies.

The Live Meeting 2007 client will set the DSCP value for SERVICETYPE_CONTROLLEDLOAD to 0 under some circumstances. For details, see Microsoft Knowledge Base article 2029024: QoS enabled Live Meeting 2007 client video DSCP marking might be missing when the Windows client video bit rate exceeds 250 kbps.

The QoS Packet Scheduler on all Windows Vista and Windows 7 client computers will not recognize that the Live Meeting 2007 client's SERVICETYPE_CONTROLLEDLOAD and SERVICETYPE_GUARANTEED DiffServ policies are enabled. Therefore, all outgoing audio and video RTP traffic that is generated by the Live Meeting 2007 client that is running on these versions of Windows will have the default DSCP marking set to 0. Enabling the Controlled Load service type (video) and the Guaranteed service type (audio) Windows group policies as described earlier will not correct this issue.

New to Windows Vista, Windows 7, and Windows Server 2008 are policy-based QoS policies. These group policy objects allow the application of QoS policies. Policy-based QoS settings allow the creation of more definitive QoS policies that meet the specific needs of separate network services. A QoS policy contains:

  • A user defined outbound packet throttle rate

  • A single DSCP value that can be added to the policy

  • The path to and the name of the executable or URL that requires a QoS policy

  • Source and destination IP address and port information

  • TCP- or UDP-specific transport information

noteNote:
The outbound packet throttle rate parameter helps control the burst rate of video traffic that is managed by the SERVICETYPE_CONTROLLEDLOAD DiffServ policy. If the busrt rate of the marshalled video stream exceeds the Killobits per second value that is defined by the SERVICETYPE_CONTROLLEDLOAD DiffServ policy, it could be updated with a DSCP marking of "0".

The ability to define the outbound packet throttle rate provides a secondary resolution for the issue with the Live Meeting 2007 client high video bit rate when hosted on Windows Vista and Windows 7 client computers as described in the Issues with DSCP Markings and the Live Meeting 2007 Client section earlier in this article. This fix will require the definition of a Windows Server 2008 policy-based QoS for the SERVICETYPE_CONTROLLEDLOAD DiffServ policy.

However, the Windows Server 2008 QoS based policy will not be able to provide the full range of functionality for the combination of the SERVICETYPE_CONTROLLEDLOAD and SERVICETYPE_GUARANTEED DiffServ policies. Only one of these DiffServ policies can be supported at a time, because only one DSCP value can be added to a Windows Server 2008 QoS based policy.

This makes the use of just one policy for either SERVICETYPE_CONTROLLEDLOAD or SERVICETYPE_GUARANTEED DiffServ policies per supported Windows client or server a reality. This means that just one Windows Server 2008 policy-based QoS policy for either SERVICETYPE_CONTROLLEDLOAD or SERVICETYPE_GUARANTEED can be shared by the local Live Meeting 2007 client, the local Communicator client, and the Communications Server 2007 R2 server endpoints (Figure 4).

The Windows Server 2008 policy-based QoS can be used for managing either the audio or video outbound IP packets on Windows Vista or Windows 7 client computers that host the Live Meeting 2007 or Communicator UC clients. When used for either audio or video DiffServ policies the Windows Server 2008 policy-based QoS group policy provides an improved method for the application of DiffServ policies.

Figure 4. Policy-based QoS in the Local Group Policy Editor

74f51818-fe63-40ae-b666-aa8728e4a1e3

Communications Server offers the QoS DiffServ feature as a configurable option that may enhance the use of audio and video communications between unified communications clients on the hosting network. The two DiffServ types that can be enabled are SERVICETYPE_CONTROLLEDLOAD (video IP traffic) or SERVICETYPE_GUARANTEED (audio IP traffic). Research is critical prior to a Communications Server 2007 R2 DiffServ deployment to make sure that all expectations of the deployment are realistic. Remember that the DiffServ types cannot guarantee the quality or the efficiency of IP audio and video traffic for a Communications Server 2007 R2 enterprise, but they can coordinate the delivery of IP audio and video traffic in the manner that is expected by audio and video aware applications that span a computer network.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft