Practice Scenario 3: Span Engineering Dial Plan Worksheet

Enhancing and Extending an Existing Plan to Accommodate VoIP

There are many ways that you can enhance and extend an existing numbering plan to accommodate the VoIP network. All of these ways require careful planning and consideration. This section discusses two of these ways: number normalization and technology prefixes. First, consider number normalization.

Number Normalization

Number normalization is a technique where dial strings can be modified to match the expected dial string length of the next hop device. For example, when a router passes a dial string to a PBX, the router should pass the number of digits that are meaningful to the PBX. Similarly, if a router passes a dial string to the PSTN, the router might need to add digits (for example, a 1, an area code, and an office code) to the dial string. Consider the topology in Figure 5-14, whose configuration is provided in Table 5-7. When site E (703555....) dials 7275550199, the full ten-digit dialed string is passed through the Centrex to the router at site D. Router D matches the destination pattern 7275550199 and forwards the ten-digit dial string to router A. Router A matches the destination pattern 727555...., strips off the matching 727555, and forwards the remaining four-digit dial string to the PBX. The PBX matches the correct station and completes the call to the proper extension.

Table 5-7. Router Digit Stripping Comparison

Calls in the reverse direction are handled similarly. However, because the Centrex service requires the full ten-digit dial string to complete calls, the plain old telephone service (POTS) dial peer at router D is configured with digit stripping disabled. An alternate solution involves enabling digit stripping and configuring the dial peer with a six-digit prefix (for example, 703555), which results in forwarding the full dial string to the Centrex service.

Technology Prefixes Applied

Another method, called technology prefixes , allows you to include special characters in the called number. These special characters (most commonly designated as 1#, 2#, 3#, and so on) are prepended to the called number on the outgoing VoIP dial peer. The gatekeeper then checks its gateway technology prefix table for gateways that are registered with that particular technology prefix. Technology prefixes also identify a type, class, or pool of gateways.

Voice gateways typically register with technology prefix 1#, H.320 gateways with technology prefix 2#, and voice mail gateways with technology prefix 3#. Multiple gateways can register with the same type prefix. When this happens, the gatekeeper makes a random selection among gateways of the same type.

If the callers know the type of device that they are trying to reach, they can include the technology prefix in the destination address to indicate the type of gateway to use to get to the destination. For example, if a caller knows that address 7275550111 belongs to a regular telephone, the caller can use the destination address of 1#7275550111, where 1# indicates that the address should be resolved by a voice gateway. When the voice gateway receives the call for 1#7275550111, it strips off the technology prefix and routes the next leg of the call to the telephone at 7275550111.

You can enter technology prefix commands on gateways and gatekeepers in two places, depending on how you want to design the technology prefix decision intelligence:

• The gateway VoIP interface

• The gateway dial peer

You can implement this type of digit manipulation and management of dialed numbers in various ways, depending on the infrastructure of the network. All of the components , including the gatekeepers, gateways, Cisco CallManagers, PBXs, key systems, and other systems, might need to be included in the process.

Accounting for Caller Mobility for 911 Services

To understand how VoIP networks can provide the location and telephone number for 911 services, you need to understand the basic component functions. The basic components of 911 services are as follows :

• Automatic number identification (ANI) ANI is the calling-party number that is included with each call to identify where the call originated. Often, in a business environment, the original ANI might be changed by the service provider at the first switch to reflect the billing number of the company instead of reflecting the calling number of the original party. Discussions with the service provider need to ensure that the original ANI is transmitted with all calls. Internal extensions or private numbering plans require mapping or translation for outbound ANI.

• Automatic location identification (ALI) The ALI database contains the records that map telephone numbers to geographic locations. The ALI database resides in the service provider network. Updates to the ALI database are submitted any time there is a move, add, or change event in a telephony network. Updates can require up to 48 hours to take effect, thereby making dynamic ALI updates unsuitable in a mobile environment.

• Public safety answering point (PSAP) The PSAP is the answer point where an emergency call is terminated . Calls are directed to specific PSAPs based on the geographic location of the call origination point.

• Emergency response location (ERL) ERL is the location from which an emergency call is placed. In a network where VoIP mobility is common, the ANI of the calling telephone does not always identify the location of the emergency because the callers retain the same extension regardless of where they are actually located. The ERL is used in mobile environments by associating ports and devices to an ERL group. The recommendation is to define an ERL group for each floor in a building, each unit in a hotel or motel, or each tenant in a multitenant building.

• Emergency location identification number (ELIN) An ELIN is a NANP telephone number used for routing an emergency call to the appropriate PSAP. In a mobile environment where the ANI is the mobile extension of the user , the ELIN is substituted for the ANI when the call is sent to the PSAP. This substitution enables the PSAP to record the calling number and be able to call the number back if the need arises. Each ERL has a unique ELIN associated with it. When a mobile caller logs into the VoIP phone, the ELIN for the call is determined based on the ERL with which the port is associated.

• Master street address guide (MSAG) MSAG is a database maintained by a government agency. This database maps geographic locations to the PSAPs responsible for handling emergency calls for those locations.

• Selective router A selective router is a dedicated 911 switch in the service provider network that routes 911 calls to the appropriate PSAP based on the calling number. This approach is different from normal call routing, which routes calls based on the called number. When a call is routed to the selective router, the router looks at the ANI and determines which PSAP to send the cacell to.

• Centralized automated message accounting (CAMA) A CAMA is an analog truck that connects a customer switch directly to the selective router in the service provider network. A CAMA trunk carries 911 calls only. It does not carry other user calls.

• Cisco Emergency Responder (CER) CER is an application that automatically tracks and updates moves and changes of equipment, thereby removing this burden from the administrative staff and providing cost savings. Through a real-time, location-tracking database, the Cisco Emergency Responder also allows emergency personnel to identify locations of 911 callers. The Cisco Emergency Responder works in conjunction with Cisco CallManager.

It is critical that the network designer understand and adhere to local, municipal, state, and federal laws regarding compliance to 911 requirements.

The following sections describe 911 call processing in nonmobile and mobile environments.

911 Call Processing in a Nonmobile Environment

Figure 5-15 shows an environment where telephony end devices remain in their permanent location.

The call illustrated in Figure 5-15 is processed as follows:

1. The emergency call originates from the device with the ANI of 555-1234.

2. The call is routed via Cisco CallManager to the main PSTN gateway at the company's headquarters.

3. The PSTN gateway either routes the call directly to the selective router via the CAMA trunk (if present) or routes the call via the normal PRI connection to the CO switch.

4. The CO switch retains the original ANI and does not replace it with the billing number.

5. The CO switch routes the call to the selective router.

6. The selective router queries the database to determine which PSAP is responsible for the location of the ANI.

7. The selective router routes the call to the PSAP.

8. The PSAP queries the ALI database to determine the exact location of the caller.

911 Call Processing in a Mobile Environment

Cisco Emergency Responder (CER) is used to dynamically update location information for mobile users. In Figure 5-16, the user with extension 1000 is normally located at 123 N. Main St. but is working on a project with a team at headquarters, which is located at 125 N. Main St. The emergency call is placed by the user of extension 1000 at the 125 N. Main St. location.

The call shown in Figure 5-16 is processed as follows:

1. The user with extension 1000 logs into a VoIP phone plugged into a switch that is configured for ERL 2.

2. The ERL 2 has ELIN 555-5679 associated with it.

3. The CER queries Cisco CallManager to determine when new users log into a VoIP telephone. Cisco Emergency Responder queries Cisco Catalyst switches to determine the port that the user is plugged into.

4. The CER determines the ELIN based on the ERL configuration for the port.

5. The CER replaces the original ANI of 1000 with the ELIN of ERL 2 (which is 555-5679) and forwards the call to the gateway connected to the PSTN.

6. The CO switch routes the call to the selective router.

7. The selective router queries the database to determine which PSAP is responsible for the location of the ANI.

8. The selective router routes the call to the PSAP.

9. The PSAP queries the ALI database to determine the exact location of the caller.

Practice Scenario 4: Numbering Plan for Span Engineering

To confirm your understanding of numbering plan issues, this practice scenario revisits the Span Engineering network. Specifically, you will answer questions regarding Span Engineering's Chicago airport and London locations.

Chicago Airport Location

The Span Engineering Chicago airport location (referred to as ORD) uses the number range of 630-555-5000 through 630-555-5999. Before the start of the VoIP migration, all employees at ORD are connected to each other and to the PSTN through the local PBX. The first phase of migration consists of moving a small group of ten users off the PBX and onto the VoIP infrastructure. The ten users who are to be migrated use the extension range of 5100 through 5110. Define the new numbering ranges that will be used for connectivity to all staff at ORD:

ORD numbering range(s) for PBX: ________________________________

ORD numbering range(s) for VoIP phones: ________________________

London Location

Span Engineering collaborates with several companies in London, England. The telephone number range to reach the London facilities is 7946-0300 through 7946-0350. The area code for London is 020, and the country code is 44. All calls that originate in the United States and are destined for international carriers must begin with the international access code of 011. This access code must be followed by the country code, the area code, and the local telephone number.

The internal code within Span Engineering for dialing London locations is 2 plus a four-digit extension, which is the last four digits of the telephone number. Define the requested dialing patterns for users located at ORD who are dialing the London offices, based on a call from ORD to London extension 0344:

Number dialed by ORD staff: _____________________________________

Number that needs to be sent to the PSTN to complete the overseas call: ___________________________________________________________

Practice Scenario 4: Solution

The correct answers for the Chicago airport location scenario follow:

• ORD numbering range(s) for PBX: 630-555-0000 through 630-555-5099 and 630-555-5111 through 630-555-5999

• ORD numbering range for VoIP phones: 630-555-5100 through 630-555-5110

The correct answers for the London location scenario follow:

• Number dialed by ORD staff: 20344

• Number that needs to be sent to the PSTN to complete the overseas call: 0114402079460344

Calculating Bandwidth Requirements

Because WAN bandwidth is probably the most expensive component of an enterprise network, network administrators must know how to calculate the total bandwidth required for voice traffic and how to reduce overall bandwidth consumption.

This section describes, in detail, VoIP bandwidth requirements. You learn about several variables affecting total bandwidth and the method of calculating and reducing the total required bandwidth.

CODEC Payload Bandwidth Requirements

One of the most important factors for the network administrator to consider while building voice networks is proper capacity planning. Network administrators must understand how much bandwidth is used for each VoIP call. With a thorough understanding of VoIP bandwidth, the network administrator can apply capacity-planning tools.

Following is a list of CODECs and their associated bandwidth:

• G.711 The G.711 pulse code modulation (PCM) coding scheme uses the most bandwidth. G.711 takes samples 8000 times per second, each of which is 8 bits in length, for a total bandwidth of 64,000 bps.

• G.726 The G.726 adaptive differential pulse code modulation (ADPCM) coding schemes use somewhat less bandwidth. While each coding scheme takes samples 8000 times per second like PCM, G.726 ADPCM uses 4, 3, or 2 bits for each sample, thereby resulting in total required bandwidths of 32,000, 24,000, or 16,000 bps.

• G.728 The G.728 low-delay code excited linear prediction (LDCELP) coding scheme compresses PCM samples using codebook technology. It uses a total bandwidth of 16,000 bps.

• G.729 The G.729 and G.729A conjugate structure algebraic code excited linear prediction (CS-ACELP) coding scheme also compresses PCM using advanced codebook technology. It uses 8000 bps of total bandwidth.

• G.723 The G.723 and G.723A multipulse maximum likelihood quantization (MPMLQ) coding schemes use a look-ahead algorithm. These compression schemes result in a required bandwidth of 6300 or 5300 bps.

The network administrator should balance the need for voice quality against the cost of bandwidth in the network when choosing CODECs. The higher the CODEC bandwidth is, the higher the cost of each call across the network will be.

Impact of Voice Samples and Packet Size on Bandwidth

Voice sample size is a variable that can affect total bandwidth used. A voice sample is defined as the digital output from a CODEC digital signal processor (DSP) encapsulated into a protocol data unit (PDU). Cisco uses DSPs that output samples based on digitization of 10 ms worth of audio. Cisco voice equipment encapsulates 20 ms of audio in each PDU by default, regardless of the CODEC used. You can apply an optional configuration command to the dial peer to vary the number of samples encapsulated. When you encapsulate more samples per PDU, the total bandwidth is reduced. However, encapsulating more samples per PDU comes at the risk of larger PDUs, which can cause variable delay and severe gaps if PDUs are dropped. Table 5-8 demonstrates how the number of packets required to transmit one second of audio varies with voice sample sizes.

Table 5-8. Impact of Voice Samples

Using a simple formula, it is possible for you to determine the number of bytes encapsulated in a PDU based on the CODEC bandwidth and the sample size (20 ms is the default):

Bytes_per_Sample = (Sample_Size * CODEC_Bandwidth) / 8

If you apply G.711 numbers, the formula reveals the following:

Bytes_per_Sample = (.020 * 64000) / 8

Bytes_per_Sample = 160

Notice from Table 5-8 that the larger the sample size, the larger the packet, and the fewer the encapsulated samples that have to be sent (which reduces bandwidth).

Data Link Overhead

Another contributing factor to bandwidth is the Layer 2 protocol used to transport VoIP. VoIP alone carries a 40-byte IP/User Datagram Protocol/Real-Time Transport Protocol (IP/UDP/RTP) header, assuming uncompressed RTP. Depending on the Layer 2 protocol used, the overhead could grow substantially. More bandwidth is required to transport VoIP frames with larger Layer 2 overhead. The following illustrates the Layer 2 overhead for various protocols:

• Ethernet II Carries 18 bytes of overhead: 6 bytes for source MAC, 6 bytes for destination MAC, 2 bytes for type, and 4 bytes for cyclic redundancy check (CRC)

• Multilink Point-to-Point Protocol (MLP) Carries 6 bytes of overhead: 1 byte for flag, 1 byte for address, 2 bytes for control (or type), and 2 bytes for CRC

• Frame Relay Forum Standard 12 (FRF.12) Carries 6 bytes of overhead: 2 bytes for data-link connection identifier (DLCI) header, 2 bytes for FRF.12 header, and 2 bytes for CRC

Security and Tunneling Overhead

Certain security and tunneling encapsulations also add overhead to voice packets and should be considered when calculating bandwidth requirements. When using a virtual private network (VPN), IP Security (IPSec) will add 50 to 57 bytes of overhead, a significant amount when considering the relatively small voice packet size. Layer 2 Tunneling Protocol/generic routing encapsulation (L2TP/GRE) adds 24 bytes. When using MLP, 6 bytes will be added to each packet. Multiprotocol Label Switching (MPLS) adds a 4-byte label to every packet. All these specialized tunneling and security protocols must be considered when planning for bandwidth demands.

For example, many companies have their employees telecommute from home. These employees often initiate a VPN connection into their enterprise for secure Internet transmission. When deploying a remote telephone at the employee's home using a router and a PBX Off-Premises eXtension (OPX), the voice packets experience additional overhead associated with the VPN.

Calculating the Total Bandwidth for a VoIP Call

CODEC choice, data-link overhead, sample size, and RTP header compression have positive and negative impacts on total bandwidth, as demonstrated in Table 5-9.

Table 5-9. Total Bandwidth Required

To perform the calculations, you must consider these contributing factors as part of the equation:

• More bandwidth required for the CODEC requires more total bandwidth

• More overhead associated with the data link requires more total bandwidth

• Larger sample size requires less total bandwidth

• RTP header compression requires significantly less total bandwidth

Consider a total bandwidth calculation for Span Engineering. The company is implementing VoIP to carry voice calls between all sites. WAN connections between sites will carry both data and voice. To use bandwidth efficiently and keep costs to a minimum, voice traffic traversing the WAN will be compressed using the G.729 CODEC with 20-byte voice samples. WAN connectivity will be through a Frame Relay provider.

The following calculation is used to calculate total bandwidth required per call:

Total_Bandwidth = ([Layer_2_Overhead + IP_UDP_RTP Overhead + Sample_Size] / Sample_Size) * CODEC_Speed

Calculation for the G.729 CODEC, 20-byte sample size, using Frame Relay without Compressed RTP (cRTP) is as follows:

Total_Bandwidth = ([6 + 40 + 20] / 20) * 8000

Total_Bandwidth = 26,400 bps

Calculation for G.729 CODEC, 20-byte sample size, using Frame Relay with cRTP is as follows:

Total_Bandwidth = ([6 + 2 + 20] / 20) * 8000

Total_Bandwidth = 11,200 bps

Effects of Voice Activity Detection on Bandwidth

On average, an aggregate of 24 calls or more might contain 35 percent silence. With traditional telephony voice networks, all G.711 voice calls use 64 kbps fixed-bandwidth links regardless of how much of the conversation is speech and how much is silence. In Cisco VoIP networks, all conversations and silences are packetized. Voice activity detection (VAD) can suppress packets containing silence. Instead of sending VoIP packets of silence, VoIP gateways interleave data traffic with VoIP conversations to more effectively use network bandwidth. Table 5-10 illustrates the type of bandwidth savings VAD offers.

Table 5-10. The Impact of VAD on Required Bandwidth

Note

Bandwidth savings of 35 percent is an average figure and does not take into account loud background sounds, differences in languages, and other factors.

Note

For the purposes of network design and bandwidth engineering, VAD should not be taken into account, especially on links that carry fewer than 24 voice calls simultaneously .

Various features, such as music on hold (MOH) and fax, render VAD ineffective . When the network is engineered for the full voice call bandwidth, all savings provided by VAD are available to data applications.

VAD is enabled by default for all VoIP calls. Not only does VAD reduce the silence in VoIP conversations, but it also provides comfort noise generation (CNG). In some cases silence might be mistaken for a disconnected call. CNG provides locally generated white noise to make the call appear normally connected to both parties.

Span Engineering LLC is assessing the effect of VAD in a Frame Relay VoIP environment. The company plans to use G.729 for all voice calls crossing the WAN. Previously, it was determined that each voice call compressed with G.729 uses 26,400 bps. VAD can reduce the bandwidth utilization to approximately 17,160 bps, which constitutes a bandwidth savings of 35 percent.

Practice Scenario 5: Span Engineering Voice Bandwidth Requirement

Span Engineering is planning to carry intrasite VoIP calls across the LAN at each site. The company plans to use the G.711 CODEC with a 30 ms voice sample for voice coding. Your task is to calculate how much bandwidth per call will be required to implement the design specifications.

1. Calculate the voice sample size in bytes, given that the CODEC will be G.711 with a 30 ms sample size.

   _______________________________________________________

2. Calculate the bandwidth per call for the G.711 call, including Ethernet overhead.

   _______________________________________________________

3. Calculate the bandwidth per call, reflecting a 35 percent VAD savings.

   _______________________________________________________

Practice Scenario 5: Solution

1. Calculate the voice sample size in bytes, given that the CODEC will be G.711 with a 30 ms sample size.

   Bytes_per_Sample = ( Sample_Size * CODEC_Bandwidth ) / 8

   Bytes per sample = (.030 * 64,000) / 8

   Bytes per sample = 240

2. Calculate the bandwidth per call for the G.711 call, including Ethernet overhead.

   Total_Bandwidth = ([Layer_2_Overhead + IP_UDP_RTP Overhead + Sample_Size] / Sample_Size) * CODEC_Speed

   Total bandwidth = ([18 + 40 + 240] / 240) * 64,000

   Total bandwidth = 79,467 bps

3. Calculate the bandwidth per call, reflecting 35 percent VAD savings.

   Total bandwidth = Bandwidth ( Bandwidth * 35%)

   Total bandwidth = 79,467 (79,467 * .35)

   Total bandwidth = 51,653 bps

Cisco Voice CODEC Bandwidth Calculator

Although the charts presented in this section aid in determining the required bandwidth for a call, you might prefer to use Cisco's web-based Voice CODEC Bandwidth Calculator located at the following URL:

http://tools.cisco.com/Support/VBC/do/CodecCalc1.do

Note

A Cisco.com account is required in order to use this tool. You can register for a Cisco.com account by pointing your web browser to the Cisco home page at http://www.cisco.com and clicking the Register link. You need a maintenance contract or a partner agreement with Cisco in order to access this tool. A guest account does not have permission to access the Voice CODEC Bandwidth Calculator.

Follow these steps to use Cisco's Voice Bandwidth Calculator:

Allocating Bandwidth for Voice and Data Traffic

Network administrators must be able to calculate existing bandwidth and forecast additional voice bandwidth that is required to implement VoIP. This section describes the importance of proper bandwidth engineering, sometimes called traffic engineering . Simply adding voice to an existing IP network is not acceptable. You must take proper precautions to ensure enough bandwidth for existing data applications and the additional voice traffic.

Traffic Statistics

Traffic engineering, as it applies to traditional voice networks, involves determining the number of trunks necessary to carry a required number of voice calls during a specific time period. For designers of a VoIP network, the goal is to properly calculate the number of trunks and provision the appropriate amount of bandwidth necessary to carry the data equivalent of the number of trunks determined. To determine the number of required voice trunks, you must first have statistics showing the current voice traffic. These statistics can be collected from various sources, as detailed in the following section.

Gathering Voice Statistics

You can gather voice traffic statistics from several sources, including:

• PSTN carriers

• PBX call detail records (CDRs)

• Telephone bills

From the PSTN carrier, you can often gather the following information:

• Peg counts For calls offered , calls abandoned , and all trunks busy. A peg count is a telephony term that dates back to the days of mechanical switches. A mechanical counter was attached to a peg to measure the number of events on that peg. The peg might be energized (that is, sent a signal) for any one of several reasons, including call overflow and trunk seizure. Today, electronic switches record peg counts by way of software programs in their common control components.

• Total traffic Carried voice traffic per trunk group.

In the absence of this detailed information, you could use a telephone bill to approximate the total traffic, but telephone bills do not show you the lost calls or the grade of service (that is, the percentage of calls rejected during the busiest hour of the day).

The internal telecommunications department provides CDRs for PBXs. This information typically records calls that are offered, but might not provide information on calls that were blocked because all trunks were busy.

Ideally, all call statistics are provided on a time-of-day basis. The number of trunks required to carry voice traffic is based on the peak daily traffic, not the average daily traffic.

Gathering Data Statistics

The total data traffic after migrating voice to the data network is the sum of the data traffic and the newly introduced voice traffic. The only exception is when the data network is accommodating voice and data on separate facilities. Therefore, you need to know how much bandwidth is required for data applications. You can gather data traffic statistics from the following:

• Network management systems (NMSs)

• Sniffers

• show interfaces commands

• Router-based accounting

Establishing Network Objectives for Voice and Data

To provide an acceptable level of access to telephone and data services in a combined voice and data network, you should establish guidelines for the acceptable performance of each.

In a data network, users can reasonably expect to achieve a level of throughput in bits per second (bps) or a network transit delay in milliseconds (ms). Unfortunately, few networks have stated objectives for throughput and delay. In planning a combined voice and data network, voice is sharing the same paths as data. Voice is given first access to the network resources because of its real-time requirements. However, service to the data users will be affected. You will be unable to judge the suitability of the combined voice and data network without a target for throughput and delay.

Traffic engineering for voice is based on a target grade of service (GoS). GoS is a unit that measures the chance that a call will be blocked. The GoS is usually defined for the peak or busiest period in the business day when demand for service is at its highest. This approach means that GoS is naturally better during off-peak hours. This GoS value is an important parameter when calculating the number of trunks required to carry a particular quantity of voice traffic.

As an example, a GoS of P(.01) means that one call is blocked in 100 call attempts, and a GoS of P(.001) means that one call is blocked in 1000 attempts.

Meeting the Current Network Objective

The first step to provision an appropriate number of trunks is to measure the level of voice and data traffic in the networks and set the objectives for throughput, delay (data traffic), and GoS (voice traffic). The next step is to determine whether you are meeting these objectives in the current network.

You might discover through your analysis of the voice and data networks that you are providing a poor GoS to your voice users, or that the throughput and delay are below the standards for your data users. Without recognizing these shortcomings, you might be inclined to plan a combined network on the assumption of business as usual. This assumption is a mistake. It creates the very real possibility that you will have an integrated voice and data network that will offer substandard quality as compared to the original network.

Ask two questions to determine if you are meeting current network objectives:

• Are the delay and throughput acceptable on the data network?

• Are you achieving your target GoS on the voice network?

If you conclude that your network performance is below objectives, add a factor to your current traffic analysis for excessive demand.

To understand how voice and data network demands relate to each other, first look at the relationship between the peak demands on each of the networks, as shown in Figure 5-20, if this information is available. It will give you some idea of what to expect later in this process, when you convert the number of voice trunks to bandwidth and add the voice bandwidth requirement to the data bandwidth requirement for the same period. Clearly, the peak bandwidth demand is less if the two network demands are out of phase with each other than if both peaks coincide.

Tip

To best calculate the required bandwidth necessary to support demands, you need to understand peak usage times. Usually, networks exhibit peak demands early in the morning and just after the noon hour.

Traffic Theory

If you know the amount of traffic generated and the GoS required, you can calculate the number of trunks required to meet your needs. Use the following simple equation to calculate traffic flow:

A = C * T

In the equation, A is the offered traffic, C is the number of calls originating during a period of one hour, and T is the average holding time of a call.

It is important to note that C is the number of calls originated , not carried. Typically, the information received from the carrier or from the internal CDRs of the company is in terms of carried traffic. Information provided by PBXs is usually in terms of offered traffic.

The holding time of a call (T) must account for the average time a trunk is occupied and must factor in variables other than the length of a conversation. This includes the time required for dialing and ringing (call establishment), time to terminate the call, and a method of amortizing busy signals and noncompleted calls. Adding 10 to 16 percent to the length of an average call helps account for these miscellaneous time segments.

Hold times based on call billing records might have to be adjusted based on the increment of billing. Billing records based on one-minute increments are usually rounded up to the next minute, not rounded to the nearest minute. Consequently, billing records overstate calls by 30 seconds on average. For example, a bill showing 404 calls (C) totaling 1834 minutes of traffic (A) should be adjusted as follows:

404 calls * 0.5 minutes (overstated call length) = 202 excess call minutes

Adjusted traffic (A): 1834 202 = 1632 actual call minutes

Another way to calculate this would be to use the formula A = C * T to derive the average holding time (T), reduce T by 0.5 minutes (the overstated amount), and recalculate the traffic offered (A).

Average holding time (T):

T = 1834 minutes (A) / 404 calls (C)

T = 4.54 minutes

Corrected holding time (T):

T = 4.54 0.50

T = 4.04 minutes

Adjusted traffic offered (A):

A = 404 calls (C) * 4.04 minutes (T)

A = 1632 call minutes

Busy Hour

It is important to look at call attempts during the busiest hour of the day, as shown in Figure 5-21. The most accurate method of finding the busiest hour is to take the ten busiest days in a year, sum the traffic on an hourly basis, find the busiest hour, and then derive the busy hour traffic .

As a shortcut, you can determine the amount of traffic that occurs in a day based on 22 business days in a month and then multiply that number by 15 to 17 percent. As a rule, the busy hour traffic represents 15 to 17 percent of the total traffic that occurs in one day. Assume that you have a trunk group that carries 66,000 minutes in one month or 3000 minutes per day on average (66,000/22). You might then estimate the busy hour traffic by calculating 15 percent of the average daily traffic, or 3000 * 15% = 450 minutes.

Erlangs

The traffic volume in telephone engineering is measured in units called Erlangs . An Erlang is the amount of traffic one trunk can handle in one hour. It is a nondimensional unit that has many functions. Other equivalent measurements that you might encounter include the following:

1 Erlang = 60 call minutes = 3600 call seconds = 36 centum call seconds (CCS)

Consider an example where, on average, each user in a branch makes 10 calls with an average duration of 5 minutes during the busy hour. If the branch has 25 employees, the total minutes of call time during the busy hour is 10 calls per busy hour multiplied by 5 minutes per call multiplied by 25 employees per branch. The result is 1250 total call minutes. To find the Erlangs, which is based on hours, divide 1250 by 60. This calculation yields 20.83 Erlangs.

Traffic Probability Assumptions

When you have determined the amount of traffic that occurs during the busy hour in Erlangs, you can determine the number of trunks required to meet a particular GoS. The number of trunks required differs , depending on these three traffic probability assumptions:

• Number of potential sources There can be a major difference between planning for an infinite versus a small number of sources. As the number of sources increase, the probability of a wider distribution in the arrival times and holding times of calls increases. As the number of sources decrease, the ability to carry traffic increases.

• Traffic arrival characteristics Usually, this assumption is based on a Poisson traffic distribution. This distribution was named after the mathematician who studied this concept extensively. Call arrivals follow a classic bell-shaped curve. You can commonly use Poisson distribution for infinite traffic sources. The arrival characteristics of traffic (calls) might be classified as random, smooth, or bursty .

• Treatment of lost calls What do you do when the station you are calling does not answer or all trunks are busy? Traffic theory considers three possibilities:

  - Lost calls cleared (LCC) LCC assumes that once a call is placed and the server (network) is busy or not available, the call disappears from the system. In essence, you give up and do something different.
  
  

  - Lost calls held (LCH) LCH assumes that a call is in the system for the duration of the hold time, regardless of whether the call is placed. In essence, you continue to redial for as long as the hold time before giving up. Redialing is an important traffic consideration. Suppose 200 calls are attempted. Forty receive busy signals and attempt to redial. That results in 240 call attempts, a 20 percent increase. The trunk group is now providing an even poorer GoS than initially thought.
  
  

  - Lost calls delayed (LCD) LCD means that when a call is placed, it remains in a queue until a server is ready to handle the call. Then it uses the server for the full holding time. This assumption is most commonly used for automatic call distribution (ACD) systems.
  
  

Note

LCC tends to understate the number of trunks that are required; on the other hand, LCH overstates the number of trunks that are required.

Random arrivals are common with a large or infinite source of users whose calls are independent of each other. Assuming random arrivals, the probability of calls arriving during any particular time interval, such as the busy hour, is modeled by a Poisson distribution. Given the average number of calls per busy hour and the distribution of call-holding times, the Poisson distribution predicts the probability of zero calls, one call, two calls, and so on, up to the probability of a large number of calls arriving during the hour.

The characteristic bell shape of the distribution suggests that the probability of few calls is low, as is the probability of a high number of calls. The peak probability represents the average. For example, if you calculated the average number of calls during the busy hour to be 250, the Poisson distribution estimates the probability that you will receive 0 calls (very low probability), 100 calls (modest probability), 250 calls (the average, which is peak probability), 900 calls (very low probability), or any other number of calls.

Smooth traffic arrivals are common in applications in which the traffic is dependent on other traffic, as in a telemarketing scenario. Due to their nonrandom nature, smooth traffic arrivals are not modeled on the Poisson distribution.

Bursty traffic arrivals are common in trunk overflow scenarios in which excess overflow tends to occur for a short time and then disappears for an extended period of time. Therefore, bursty traffic is not modeled on the Poisson distribution because of its nonrandom nature.

Traffic Calculations

The purpose of traffic calculations is to determine the number of physical trunks that are required. After you have determined the amount of offered traffic during the busy hour, established the target GoS, and recognized the three basic assumptions, you can calculate the number of trunks that are required by using formulas or tables.

Traffic theory consists of many queuing methods and associated formulas. Anyone who has taken a queuing theory class can testify to the complexity of the many queuing models that are derived for various situations. This is the reason why tables dealing with the most commonly encountered model are used.

The most commonly used model and table is Erlang B, as shown in Table 5-11. Erlang B is based on infinite sources, LCC, and a Poisson distribution that is appropriate for either exponential or constant holding times. In general, Erlang B understates the number of trunks because of the LCC assumption. However, Erlang B is the most commonly used algorithm.

Table 5-11. Erlang B Table

A trunk group is a hunt group of parallel trunks. The following example determines the number of trunks in a trunk group carrying the following traffic:

• 352 hours of offered call traffic in a month

• 22 business days per month

• 10 percent call-processing overhead

• 15 percent of the traffic occurring in the busy hour

• GoS = P(.01)

• Busy hour = 352 / 22 * .15 * 1.10 (call-processing overhead) = 2.64 Erlangs

The traffic assumptions are:

• Infinite sources.

• Random or Poisson traffic distribution.

• Lost calls are cleared.

Based on these assumptions, the appropriate algorithm to use is Erlang B. You can use Table 5-11 to determine the appropriate number of trunks for a GoS of P(.01).

Because a GoS of P(.01) is required, you use the column that is designated as P(.01) only. The calculations indicate a busy hour traffic amount of 2.64 Erlangs, which is between 2.501 and 3.128 in the P(.01) column. This corresponds to between seven and eight trunks. Because you cannot use a fractional trunk, you use the next larger value of eight trunks to carry the traffic.

Instead of using an Erlang B table, such as Table 5-11, you could alternatively use a web-based calculator, such as the one found at http://erlang.com/calculator/erlb. This calculator, as shown in Figure 5-22, allows you to enter your Erlang value in the BHT (that is, Busy Hour Traffic) field and your GoS value in the Blocking field.

You can then click on the Calc. button, and the calculator displays the number of trunks needed to support the specified call volume, as shown in Figure 5-23. In this example, eight trunks are required for an Erlang value of 2.64 and a GoS value of 0.010, just as previously determined from the Erlang B table shown in Table 5-11.

Call Density Matrix

Unless your voice network is extremely small (two locations, for example), calculating the trunk requirements between any two points in a network is a tedious task. One way to manage this more effectively is to design a to/from traffic matrix.

As you determine the call minutes between any two points, you enter the amount into the matrix. If you do this on a spreadsheet, you can convert the minutes to busy hour minutes, to Erlangs, and then calculate the number of trunks from the Erlangs. The number of trunks represents the number of concurrent calls you should plan to support during the busy hour.

As an example of a call density matrix, Figure 5-24 shows a progression of spreadsheets for a network with one headquarters and three branches.

Bandwidth Calculations

If you are provisioning a circuit-switched voice network, you should estimate how much traffic each of your trunks is expected to carry. Then investigate the most cost-effective way to provision each of the trunks.

For this discussion, assume that all voice traffic is transported over the IP network. This approach will preclude the need to go through the rigors of choosing the most cost-effective solution for each individual trunk.

At this stage, the goal is to determine the IP bandwidth using the following steps:

You might want to consider some refinements to this simple multiplier . Consider the net benefits of bandwidth-reduction strategies, such as voice activity detection (VAD). VAD commonly reduces the bandwidth to between 60 and 70 percent of the original bandwidth. Just keep in mind that two animated talkers might not allow VAD to have any effect at all.Finally, remember to combine the budget for data applications with the bandwidth budget for voice.

Now that you have the total bandwidth budget, you are ready to ensure that you do not overload the data links. However, on any network, as load approaches middle percentages, drops and delay exponentially increase. When designing networks to carry voice and data, peak bandwidth calculations should not equate to total bandwidth required for a given network link. For most business environments, you can use any of the following load levels as general rules for determining when a network is approaching excessive load:

• 20 percent of full capacity averaged over an 8-hour work day

• 30 percent averaged over the worst hour of the day

• 50 percent averaged over the worst 15 minutes of the day

Capacity planning should take these factors into account, and link speed should be chosen to accommodate the proper load factors. An ideal goal is to have demand equal to about 35 percent of the total link speed.

To put these rules into the context of the example, Figure 5-25 shows a demand for 416 kbps between headquarters and branch 1 during the busiest hour of the day. Using the rules, the average demand during the worst hour should represent only 30 percent of the link speed. If 30 percent of the link speed is 416 kbps, then the link speed must be 1387 kbps or greater.

Based on the traffic in your network, you might justify aiming for a higher utilization of the links, but expecting full utilization is unrealistic . Setting too high a value results in low throughput and high delay for data traffic. Although voice is prioritized so that it is not delayed, you need to determine, through experience, a utilization factor that balances throughput and delay with cost.

Practice Scenario 6: Calculating Bandwidth

Span Engineering LLC is assessing bandwidth requirements for the WAN connection between the Chicago Cicero campus and the Dallas campus, as shown in Figure 5-26. The traffic statistics and requirements for this topology are:

• 50 concurrent calls during busy hour

• G.729 using a 20-byte sample size

• Frame Relay with cRTP

• 10 percent call-processing overhead

• 30 percent bandwidth savings using VAD

• 2 Mbps requirement for data

Based on the Figure 5-26 and the preceding requirements, determine the bandwidth requirements for the Cicero-Dallas connection.

Call statistics obtained from the PBXs and the PSTN carrier show that traffic patterns during the busy hour require support for 50 concurrent calls between Cicero and Dallas.

Design specifications for the Cicero-Dallas connection are as follows:

• All calls traversing the WAN must be compressed to conserve bandwidth and keep connection costs to a minimum.

• Calls traversing the WAN should be configured to use the G.729 CODEC with a 20-byte sample size.

• Calls traversing the WAN should be configured to use VAD. It is estimated that the use of VAD will save 30 percent of calculated voice bandwidth.

• The connection will be Frame Relay between Cicero and Dallas.

• The connection must have RTP header compression enabled.

• It is estimated that there will be 10 percent overhead for call processing.

• The bandwidth requirement for data is 2 Mbps.

Table 5-12 provides per-call bandwidth requirement calculations for a selection of CODECs and connection types.

Table 5-12. Per-Call Bandwidth Calculation Table

Use the information in Table 5-12 to calculate the following total bandwidth requirements:

1. Calculate the total bandwidth required for the expected concurrent call volume.

   ________________________________________

2. Calculate the total bandwidth required, including bandwidth needed for call-processing adjustment.

   ________________________________________

3. Calculate the total bandwidth required, reflecting VAD savings.

   ________________________________________

4. Calculate the total bandwidth required for both voice and data for the Frame Relay connection.

   ________________________________________

5. Calculate the total bandwidth required for both voice and data for the Frame Relay connection.

   ________________________________________

Practice Scenario 6: Solutions

1. Calculate the total bandwidth required for the expected concurrent call volume.

   For 50 concurrent calls, use G.729 for Frame Relay with cRTP: 50 * 11,200 = 560,000 (560 kbps)

2. Calculate the total bandwidth required, including bandwidth needed for call-processing adjustment.

   Add call-processing overhead of 10 percent: 560,000 * 1.1 = 616,000 (616 kbps)

3. Calculate the total bandwidth required, reflecting VAD savings.

   Adjust for VAD bandwidth savings of 30 percent: 616,000 (.30 * 616,000) = 616,000 184,800 = 431,200 (431.2 kbps)

4. Calculate the total bandwidth required for both voice and data for the Frame Relay connection.

   Add data bandwidth requirements: 431,200 + 2,000,000 = 2,431,200 (2.43 Mbps)

Security Implications of VoIP Networks

Security is a top priority in most networks. Security solutions include router access lists, stateful firewalls, and VPNs. These solutions might be stand-alone or layered. Implementing voice in a secure network environment requires an understanding of potential issues and threats. It also requires an in-depth knowledge of existing security measures and how these measures affect the transit of voice through the network. This section describes the implications of implementing security measures in VoIP networks.

Security Policies for VoIP Networks

Numerous problems, from device failures to malicious attacks, affect the uptime of networks. With VoIP's reliance on the IP network, IP-based threats must be mitigated. Varying levels of security are available to suit individual corporate requirements. The requirements for secured IP telephony include the following:

• Provide ubiquitous IP telephony services to the locations and to the users that require them.

• Maintain as many of the characteristics of traditional telephony as possible without compromising security.

• Integrate with existing security architectures without interfering with existing functions.

The starting point for any security implementation is the development of a security policy . In a converged network, the security policy accounts for the impact of security measures on voice traffic. The security policy should address the following points that affect voice:

• Transport security Traffic traversing public access and backbone networks must be properly secured. IP Security (IPSec) and VPNs provide transport security by ensuring data confidentiality (using encryption), data integrity, and data authentication between participating peers. Encryption adds to overhead and delays a voice packet. Therefore, you should factor in encryption when testing the delay budget and bandwidth calculations.

• Network security Cisco firewalls provide stateful perimeter security that is critical to any public- facing network, such as a VPN. When deploying voice and video across VPNs, it is critical to statefully inspect all multiservice traffic traversing the firewall. Firewalls should be configured to allow known signal and payload ports to pass into the network. Designers should also understand where the VPN terminates. If the VPN terminates inside the firewall, then the traffic passing through the firewall is encrypted and is subject to stateful inspection. If the VPN terminates outside the firewall, then the firewall has access to RTP, UDP, TCP, or IP headers and is able to inspect the packet for call setup.

• Intrusion detection The Cisco Security Agent (CSA) provides threat protection for server and desktop computing systems, also known as endpoints. CSA identifies and prevents malicious behavior. This eliminates known and unknown security risks and helps to reduce operational costs. CSA, by itself, aggregates and extends multiple endpoint security functions by providing host intrusion prevention, distributed firewall capabilities, malicious mobile code protection, operating system integrity assurance, and audit log consolidation. In addition, because CSA analyzes behavior rather than relying on signature matching, it reduces operational costs.

Figure 5-27 shows an example of network security, where the network between the branch office and the headquarters has a firewall. The firewall allows the users from the branch office to access only the headquarters network. A user without proper network identification will not be allowed to pass through the firewall. Network identification therefore protects voice networks from hackers.

Unfortunately, the security model chosen for VoIP networks today often mirrors the model chosen for legacy voice systems, which are generally wide open and require little or no authentication to gain access.

Threats to VoIP

Numerous threats to VoIP networks exist, and many of these are similar to threats facing traditional PBX systems. VoIP network threats include:

• Theft and toll fraud Toll fraud is the theft of long-distance telephone service by unauthorized access to a PSTN trunk (that is, an "outside line") on a PBX or voice mail system. Toll fraud is a multibillion-dollar illegal industry, and all organizations are vulnerable. Theft can also be defined as the use of the telephony system, by both authorized and unauthorized users, using voice-network resources to access unauthorized numbers, such as 900 billable numbers.

• Unauthorized access to voice resources Hackers can tamper with voice systems, user identities, and telephone configurations and also intercept voice mail messages. If hackers gain access to the voice mail system, they can change the voice mail greeting, which negatively impacts the image and reputation of the company. A hacker who gains access to the PBX or voice gateway could potentially shut down voice ports or change voice-routing parameters, affecting voice access into and through the network.

• Compromise of network resources The goal of a secure network is to ensure that applications, processes, and users can reliably and securely interoperate using the shared network resources. Because the shared network infrastructure carries both voice and data, security and access to the network infrastructure is critical in securing voice functions. Because VoIP systems are installed on a data network, they are potential targets for hackers who previously targeted only PCs, servers, and data applications. Hackers are aided in their search for vulnerabilities in VoIP systems by the open and well-known standards and protocols used by IP networks.

• Denial-of-service (DoS) attacks DoS attacks are defined as the malicious attacking or overloading of call-processing equipment to deny access to services by legitimate users. Most DoS attacks fall into one of the following categories:

  - Network resource overload Overloading a network resource that is required for proper functioning of a service. The targeted network resource is most often bandwidth. The DoS attack uses up all available bandwidth, preventing authorized users from accessing the required services.
  
  

  - Host resource starvation Using up critical host resources. When use of these resources is maximized by the DoS attack, the server can no longer respond to legitimate service requests .
  
  

  - Out-of-bounds attack Using illegal packet structure and unexpected data, which can cause the operating system of the remote system to crash. One example of this type of attack might be to use illegal combinations of TCP flags. Most TCP/IP stacks are developed to respond to appropriate use. They are not developed for anomalies. When the stack receives illegal data, it might not know how to handle the packet and might cause a system crash.
  
  

  - Eavesdropping Eavesdropping involves the unauthorized interception of voice packets (that is, RTP media streams). Eavesdropping can expose confidential or proprietary information that is obtained by intercepting and reassembling packets in a voice stream. Numerous tools are used by hackers to eavesdrop.
  
  

Secure LAN Design

Many IP security solutions can be implemented only on Layer 3 (IP) devices. Because of protocol architecture, the MAC layer, Layer 2, offers very little or no inherent security. Understanding and establishing broadcast domains is one of the fundamental precepts in designing secure IP networks. Many simple yet dangerous attacks can be launched if the attacking device resides within the same broadcast domain as the target system.

IP phones, VoIP gateways, and network-management workstations should typically be on their own subnet, separate from the rest of the data network and from each other.

To ensure communications privacy and integrity, voice-media streams should be protected from eavesdropping and tampering. Data networking technologies, such as VLANs, can segment voice traffic from data traffic, preventing access to the voice VLAN from the data VLAN. Using separate VLANs for voice and data in a switched Ethernet infrastructure, as shown in Figure 5-28, prevents any attacker or attacking application from snooping or capturing traffic from other VLANs as it traverses the physical wire. By making sure that each device connects to the network using a switched infrastructure, you can render packet-sniffing tools less effective for capturing user traffic. Notice that an IEEE 802.1Q trunk is set up between the IP phone and the Catalyst switch. The 802.1Q trunk allows traffic from both the voice and data VLANs to flow over a single physical link.

Assigning voice traffic to a specific VLAN, thereby logically segmenting voice and data traffic, is an industry-wide accepted best practice. As much as possible, devices identified as voice devices should be restricted to dedicated voice VLANs. This approach ensures that they can communicate only with other voice resources. More importantly, voice traffic is kept away from the general data network where it might more easily be intercepted or tampered with.

Communicating Through a Firewall

Firewalls inspect packets and match them against configured rules. It is difficult to specify ahead of time which ports will be used in a voice call because they are dynamically negotiated during call setup.

H.323 is a complex, dynamic protocol that consists of several interrelated subprotocols . The ports and addresses used with H.323 require detailed inspection as call setup progresses. As the dynamic ports are negotiated, the firewall must maintain a table of current ports associated with the H.323 protocol. As calls are torn down, the firewall must remove those ports from the table. The process of adding and removing ports from the table is called stateful inspection of packets . In addition to checking static ports and recognizing protocols that negotiate dynamic ports as in H.323, the firewall looks into the packets of that protocol to track the flows.

Any application might use a port in the range of 1024 to 65536. In Figure 5-29, the firewall initially blocks all packets destined for UDP port 16384. The firewall becomes H.323-aware when it is configured to look for TCP port 1720 for call setup and UDP port assignments.

Table 5-13 illustrates the dynamic access control process used by firewalls.

Table 5-13. Dynamic Access Control

If the firewall does not support this dynamic access control based on inspection, an H.323 proxy can be used. An H.323 proxy passes all H.323 flows to the firewall with the appearance of a single static source IP address plus a TCP/UDP port number. The firewall can then be configured to allow that static address to pass through.

Firewalls can introduce variable delay into the path of the voice packet. Therefore, it is extremely important that you ensure that the firewall has the proper resources (that is, processor and memory resources) to handle the load.

Table 5-14 lists the ports used for various voice protocols.

Table 5-14. Voice Protocol Ports

Delivering VoIP over a VPN

VPNs, as depicted in Figure 5-30, are widely used to provide secure connections to the corporate network. The connections can originate from a branch office, a small office/home office (SOHO), a telecommuter, or a roaming user.

Frequently asked questions about voice over VPN generally deal with overhead and delay, which impact the quality of service (QoS) for the call.

Note

One important consideration to remember is the absence of QoS when deploying VPNs across the Internet or a public network. Where possible, QoS should be addressed with the provider through a service-level agreement (SLA). An SLA is a document that details the expected QoS parameters for packets transiting the provider's network.

Voice communications do not work well with latency, not even a modest amount of it. Because secure VPNs encrypt data, they might create a throughput bottleneck when they process packets through their encryption algorithm. The problem usually gets worse as security increases. For example, Triple Data Encryption Standard (3DES) uses a long, 168-bit key. 3DES requires that each packet be encrypted three times, effectively tripling the encryption overhead. Approaches to reduce the overhead and delay introduced by VPNs include:

• Optimize the encryption algorithm and data path.

• Handle all processing in a dedicated encryption processor.

• Ensure that the device uses hardware encryption instead of software encryption.

• Use proper QoS techniques.

• Use proper VPN technologies.

VoIP can be secure and free of perceptible latency on a VPN. The solution is to optimize the encryption algorithm and the data path and to handle all processing in a dedicated encryption processor. You should ensure that the device is utilizing hardware encryption instead of software encryption. Software encryption relies on CPU resources and could severely impact voice quality.

Delay can be further minimized through the use of proper QoS techniques. QoS and bandwidth management features allow a VPN to deliver high transmission quality for time-sensitive applications, such as voice or video. Each packet is tagged to identify the priority and time sensitivity of its payload, and traffic is sorted and routed based on its delivery priority. Cisco VPN solutions support a wide range of QoS features.

Designers need to understand that QoS cannot be completely controlled, independent of the underlying network. QoS is only as good as the network through which the voice travels . Users must confirm with a potential service provider that the network can support priority services over a VPN. Specifically, SLAs with carriers can guarantee expectations of network stability and QoS.

You can minimize overhead if you understand the proper use of VPN technologies. You can implement VPNs at Layer 2 through Point-to-Point Tunneling Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP), as well as at Layer 3 with IPSec. Often Layer 2 and Layer 3 technologies are combined to provide additional security. It is crucial that you understand the reasoning and requirements behind combining Layer 2 with Layer 3 security, because the combination adds overhead to the VoIP packet.

International Issues

VoIP and either Data Encryption Standard (DES) or 3DES encryptions are fully compatible with each other as long as the VPN delivers the necessary throughput. Internationally, corporations can run into other factors. The U.S. Department of Commerce places restrictions on the export of certain encryption technology. Usually, DES is exportable while 3DES is not, but that generality takes numerous forms, from total export exclusions applied to certain countries to allowing 3DES export to specific industries and users. Most corporations whose VPNs extend outside the United States should find out if their VPN provider has exportable products and how export regulations impact networks built with those products.

Bandwidth Overhead Associated with VPN

VPN implementations vary, and there are many options to explore. IPSec is the predominant VPN in use today. Figure 5-31 shows the IPSec header. Generally speaking, IPSec encrypts or authenticates the IP packet and adds additional headers to carry the VPN information. The VPN places the original IP packet into another IP packet so that the original information, including headers, is not easily seen or read.

To properly calculate bandwidth overhead, the user must have a thorough understanding of the VPN technology by asking the following questions:

• Should the VPN be a Layer 2 tunnel running PPTP or L2TP?

• Should the VPN be a Layer 3 tunnel running IPSec?

• If the VPN is IPSec, is it using Authentication Header (AH) or Encapsulating Security Payload (ESP)?

• If the VPN is running AH or ESP, is it in transport mode or tunnel mode?

Note

Although the discussion of VPN technology is beyond the scope of this book, Comparing, Designing, and Deploying VPNs (ISBN 1587051796) from Cisco Press can help clarify these concepts.

Calculating VPN Bandwidth

The VPN adds a new IP header that is 20 bytes, plus the VPN header, which can add as much as 20 to 60 additional bytes, depending on which variation of VPN is installed. Table 5-15 shows what a complete VPN packet can look like.

Table 5-15. VPN Packet Overhead

The total size of the packet will be 100 to 160 bytes.

To calculate the total bandwidth for a 160-byte G.729 packet, use the following calculations:

160 bytes * 8= 1280 bits

Total bandwidth = 1280 bits / 20 ms

Total bandwidth = 64,000 bps

Practice Scenario 7: Span Engineering VoIP Network Security Components

Span Engineering LLC is defining its security infrastructure for the VoIP network. Figure 5-32 identifies various components that will provide networkwide security for Span Engineering voice transmissions.

Your task is to identify the benefits associated with each security component:

1. Separate voice and data VLANs:

   _____________________________________________________

   _____________________________________________________

   _____________________________________________________

2. VPN connectivity between sites:

   _____________________________________________________

3. Stateful firewall:

   _____________________________________________________

   _____________________________________________________

   _____________________________________________________

4. Cisco Security Agent:

   _____________________________________________________

   _____________________________________________________

Practice Scenario 7: Solutions

1. Separate voice and data VLANs:

   Separate VLANs create separate broadcast domains.

   Separate VLANs protect against eavesdropping and tampering.

   Separate VLANs render packet-sniffing tools less effective.

2. VPN connectivity between sites:

   Voice packets are encrypted when they traverse the WAN.

3. Stateful firewalls:

   Stateful firewalls inspect packets and match them against a set of rules.

   Stateful firewalls watch call-setup packets and let negotiated ports pass through.

   Stateful firewalls tear down access to negotiated ports when the call is terminated.

4. Cisco Security Agent:

   CSA provides intrusion detection for the network.

   CSA identifies and prevents malicious behavior.