Cisco Unified Videoconferencing Solution Reference Network Design (SRND)
Multi-Zone WAN Case Study
Downloads: This chapterpdf (PDF - 438.0KB) The complete bookPDF (PDF - 2.74MB) | Feedback

Multi-Zone WAN Case Study

Table Of Contents

Multi-Zone WAN Case Study

Network Topology

Network Design

Quality of Service (QoS)

Call Admission Control

Dial Plan

Zone Prefixes

Service Prefixes

E.164 Addresses and H.323-IDs

Video Infrastructure


Multi-Zone WAN Case Study


Last revised on: October 30, 2009

 

This chapter provides an example of a typical WAN multi-zone model deployed in an enterprise environment.

In this case study, the enterprise is a health care provider with locations spread across the United States. Five locations currently use ISDN-based videoconferencing. The enterprise has a T1 to each site and would like to install new H.323 videoconferencing units and utilize their existing WAN bandwidth. Each site contains a minimum of three video units, and the enterprise has standardized on 384 kbps as their call data rate. The enterprise requires multipoint calls as well as the ability to call off-net to their clients.

Network Topology

Currently the enterprise in this example has five sites in the United States, consisting of Sacramento CA, Los Angeles CA, Dallas TX, Columbus OH, and Chicago IL. Each site connects back to Columbus, the headquarters, with a T1 link. The bandwidth utilization on all the connections is low. The enterprise has just upgraded their WAN routers at remote sites to Cisco 2851 routers to support voice, video, and data in the near future. The headquarters is connected with a T1 line to the internet. Currently, all videoconferencing units are directly connected to an IMUX with three BRI lines, allowing bonded 384-kbps calls. The Columbus site contains an H.320 multipoint control unit (MCU) with three PRI lines supporting multipoint calls among the sites. Some remote specialists use a public gatekeeper on the internet to reach the health care provider. Figure 9-1 illustrates the current IP network, and Figure 9-2 illustrates the current videoconferencing network.

Figure 9-1 Current IP Network

Figure 9-2 Current Videoconferencing Network

Network Design

The network outlined in the previous section is a classic WAN multi-zone model. There is sufficient WAN bandwidth, and each site contains three or more video terminals. In this network, a gatekeeper and border element are located at each site. Directory gatekeeper services are configured, and Hot Standby Routing Protocol (HSRP) is used for gatekeeper redundancy at the Columbus site. Quality of service (QoS) and call admission control (CAC) need to be configured in the network to ensure video quality. Firewall security is used to connect to the internet, and the border element is the trusted device through the firewall.

Quality of Service (QoS)

End-to-end QoS is a key factor in a successful deployment. The enterprise in this example has decided to use an H.323 video terminal that supports marking of IP Precedence. The Columbus, Sacramento, and Dallas sites have upgraded to Catalyst  6500 switches. In these three sites, LAN QoS will be configured; the remaining three sites will support LAN QoS when the switches at those sites are also upgraded. All video units will be connected to 10/100 Ethernet ports.

All video terminals, gateways, and MCUs are configured to mark IP Precedence 4. In Columbus, Sacramento, and Dallas, trust boundaries are set on the Catalyst 6500 switches. Video gateways and MCUs are also installed in Columbus, Sacramento, and Dallas. For gateways and MCUs that do not support IP Precedence, IP Precedence is marked and a trust boundary is set on the Catalyst 6500 ports to which the gateways and MCUs are connected. Gateways are also installed in Los Angeles and Chicago.

Priority queues are configured on all WAN routers and are provisioned for 920 kbps. This guarantees that bandwidth is available for two 384-kbps calls. An access list entry is also added on the WAN router to set the entrance criterion for the priority queue. Only video traffic received from the border element is admitted to the priority queue.

The gatekeeper at each site is configured to use the local border element for all inter-zone calls. The border element rewrites IP Precedence 4 and provides a single access point to the configured priority queue.

For more information regarding network QoS, refer to the Enterprise QoS Solution Reference Network Design Guide, available at http://www.cisco.com/go/designzone.

Call Admission Control

Call admission control (CAC) must be implemented for inter-zone calls, and it is also a good idea to configure CAC for intra-zone calls. Enabling CAC for inter-zone calls guarantees that the bandwidth limits provisioned on the priority queues are not exceeded. If the provisioned bandwidth for the priority queue on the WAN route is exceeded, all video calls in the queue will be affected. The gatekeeper at each site contains the following three bandwidth statements for CAC.

bandwidth total {default | zone <zone-name>} <bandwidth-size>
bandwidth remote 1536
bandwidth session default 768

It is important to note that the bandwidth is calculated in half-duplex mode, so the call data rate must be doubled. A 384-kbps call is represented as 768 kbps in the bandwidth statements. The bandwidth total command allows administrators to limit the bandwidth within a single local zone, or for all local zones by adding the default statement. The remote bandwidth (available bandwidth to and from any remote zone) is limited to 1536 kbps, or two 384-kbps calls. The bandwidth per session is limited to 768 kbps, or one 384-kbps call.

Figure 9-3 illustrates QoS and CAC points for Columbus, Figure 9-4 illustrates QoS and CAC points for Dallas and Sacramento, and Figure 9-5 illustrates QoS and CAC points for Los Angeles and Chicago.

Figure 9-3 QoS and CAC for Columbus

Figure 9-4 QoS and CAC for Dallas and Sacramento

Figure 9-5 QoS and CAC for Los Angeles and Chicago

Dial Plan

When deciding on a dial plan, it is always a good idea to start with the incoming PSTN call routing. In our example, we have created five zones that all contain video gateways. DID is used to route incoming calls to video terminals. IVR is used to route calls from the video gateways in Columbus, Dallas, and Sacramento, to their local MCUs. If, for some reason, one or more of the zones in our example did not contain a gateway, IVR for routing all incoming PSTN calls would have been a better choice.

Zone Prefixes

The zone prefix for each zone is based on the local area code. Area codes are unique, and users are familiar with the numbering structure. In our configuration there is a single zone in each site, so the zone prefixes are based on area codes. If more than one zone were required in a single area code, longer zone prefixes could be used. (Refer to Zone Prefix Design, page 6-7.) The zone prefixes in this network are:

Columbus = 614

Sacramento = 916

Dallas = 972

Chicago = 847

Los Angeles = 213

Service Prefixes

Service prefixes must be configured for all MCUs and video gateways. As described in the chapter on Dial Plan Architecture, it is a good idea to reserve a block of numbers for video gateways and a block of numbers for MCUs. In this case, the enterprise has chosen to standardize on 384-kbps calls; this makes service prefixes for gateways very simple. The obvious choice would be to use 9 for all PSTN calls, but that would cause routing problems in the Sacramento and Dallas zones. The Sacramento zone prefix is 916, and overlapping gateway service prefixes and zone prefixes will cause routing problems. There are two options; reserve another block of numbers other than 9*, or use a service prefix such as 9#. In this case, we have chosen 9# for PSTN access in all zones. Any time a user tries to access the WAN, the dial string will start with 9#.

For MCU service prefixes, 8* is reserved, and the zone prefix is appended to associate it with the zone in which the MCU resides. The MCU service prefix in the Sacramento zone is 9168*, and in Los Angeles it is 2128*. Table 9-1 lists the service prefixes chosen for different types of calls on the MCU. (These service prefixes are used in every zone, and the zone prefix is appended.)

Table 9-1 MCU Service Prefixes 

Service Prefix
Data Rate
Number of Parties
Video Format
Continuous Presence

83

384 kbps

3

H.261

No

84

384 kbps

4

H.261

Yes

85

384 kbps

5

H.261

No

89

384 kbps

9

H.261

No


E.164 Addresses and H.323-IDs

The carrier provides E.164 addresses for this enterprise. Because DID has been chosen for incoming PSTN routing method, the enterprise will order blocks of DID numbers with each PRI line. Each video terminal is assigned a valid DID number for its E.164 address. In Columbus, there are 24 video terminals, and thirty DID numbers are ordered with the PRI line for Columbus. (The extra six numbers are for expansion.) In Los Angeles and Chicago, DID numbers off the BRI lines will be used as E.164 addresses. (See Video Infrastructure, for the video components at each site.)

H.323-IDs are based on the name of the conference room where the video system resides. Since the video terminals may be moved from room to room, H.323-IDs will not be used for dialing. The enterprise is using a global address book that will display all of the IP video terminals on the network. Users can choose to dial from the address book or manually enter the E.164 address of the unit being called. Figure 9-6 illustrates the Dial plan in Columbus.

Figure 9-6 Dial Plan for Columbus

Video Infrastructure

When deciding on location and number of video components, it is important to understand the enterprise's needs. This enterprise made it clear that less than ten percent of all video calls were off-net calls. The number of video calls placed daily ranges from 10 to 15, and most calls are multipoint. For this reason, the enterprise decided to go with video gateways at each site and MCUs in Columbus, Dallas, and Sacramento. The following sections list the video components for each site. All IP video calls for the enterprise are received at the headquarters.

Columbus

IP Video Terminals, 24

The current 24 H.320 video systems are over three years old and will be replaced with new H.323 group systems that support IP Precedence.

MCUs, 4

The four MCUs will be configured in a stack, allowing one set of service prefixes to be shared by all four MCUs.

Video Gateway PRI, 1

A single PRI gateway will be installed with 30 DID numbers that will be assigned to the IP video terminals. All 10 digits will be passed to the gateway by the carrier, allowing each video terminal to register with a 10-digit fully qualified E.164 address. IVR will be enabled and used for PSTN access to MCU conferences. One DID number will have to be reserved for IVR calls.

Sacramento

IP Video Terminals, 6

The existing six H.320 video systems are over three years old and will be replaced with new H.323 group systems that support IP Precedence.

MCU, 1

A single MCU will be located on the Sacramento campus for local, on-site multipoint calls. The Sacramento campus is in the process of adding another building and possibly adding two or three additional IP video terminals. The MCU will also allow multiple video terminals to participate in an off-campus multipoint call while consuming the bandwidth of only a single call. This will be done by cascading a Sacramento MCU conference with a Columbus MCU conference.

Video Gateway, 1

A single PRI gateway will be installed with 10 DID numbers that will be assigned to the IP video terminals. All 10 digits will be passed to the gateway by the carrier, allowing each video terminal to register with a 10-digit fully qualified E.164 address. IVR will also be enabled and used for PSTN access to MCU conferences. One DID number will have to be reserved for IVR calls.

Dallas

IP Video Terminals, 10

The existing 10 H.320 video systems are over three years old and will be replaced with new H.323 group systems that support IP Precedence.

MCU, 1

A single MCU will be located on the Dallas campus for local, on-site multipoint calls. The MCU will also allow multiple video terminals to participate in an off-campus multipoint call while consuming the bandwidth of only a single call. This will be done by cascading a Dallas MCU conference with a Columbus MCU conference.

Video Gateway, 1

A single PRI gateway will be installed with 15 DID numbers that will be assigned to the IP video terminals. All 10 digits will be passed to the gateway by the carrier, allowing each video terminal to register with a 10-digit fully qualified E.164 address. IVR will also be enabled and used for PSTN access to MCU conferences. One DID number will have to be reserved for IVR calls.

Los Angeles

IP Video Terminals, 4

The existing four H.320 video systems are over three years old and will be replaced with new H.323 group systems that support IP Precedence.

MCU, 0

Los Angles will not have a local MCU.

Video Gateway, 1

A single BRI gateway will be installed with four BRI lines. Each video terminal will receive a DID number from one of the BRI lines. IVR will not be enabled on the gateway.

Chicago

IP Video Terminals, 3

The existing three H.320 video systems are over three years old and will be replaced with new H.323 group systems that support IP Precedence.

MCU, 0

Chicago will not have a local MCU.

Video Gateway, 1

A single BRI gateway will be installed with three BRI lines. Each video terminal will receive a DID number from one of the BRI lines. IVR will not be enabled on the gateway.

Figure 9-7 illustrates the video components and dial plan for the new IP video network.

Figure 9-7 Dial Plan for Example Video Network