Table 5-6 shows the solution for Practice Scenario 3.
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 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.
Figure 5-14. Number Normalization
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:
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:
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.
Figure 5-15. 911 Call Processing in a Nonmobile Environment
The call illustrated in Figure 5-15 is processed as follows:
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.
Figure 5-16. 911 Call Processing in a Mobile Environment
The call shown in Figure 5-16 is processed as follows:
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: ________________________
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:
The correct answers for the London location scenario follow:
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:
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.
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:
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.
To perform the calculations, you must consider these contributing factors as part of the equation:
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.
Bandwidth savings of 35 percent is an average figure and does not take into account loud background sounds, differences in languages, and other factors.
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.
Practice Scenario 5: Solution
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:
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:
Figure 5-19. Voice Bandwidth Calculator Screen 3
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 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:
From the PSTN carrier, you can often gather the following information:
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:
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:
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.
Figure 5-20. Network Demand
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.
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:
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
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.
Figure 5-21. Busy Hour
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.
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:
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.
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.
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:
The traffic assumptions are:
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.
Figure 5-22. Erlang B Calculator Inputting Busy Hour Traffic
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.
Figure 5-23. Erlang B Calculator Calculating Lines
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.
Figure 5-24. Call Density
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:
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.
Figure 5-25. Bandwidth Example
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:
Figure 5-26. Practice Item: Bandwidth Calculation
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:
Table 5-12 provides per-call bandwidth requirement calculations for a selection of CODECs and connection types.
Use the information in Table 5-12 to calculate the following total bandwidth requirements:
Practice Scenario 6: Solutions
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:
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:
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.
Figure 5-27. Network Security
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:
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.
Figure 5-28. Secure LAN Design
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.
Figure 5-29. Firewall Access
Table 5-13 illustrates the dynamic access control process used by firewalls.
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.
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.
Figure 5-30. Virtual Private Networks
Frequently asked questions about voice over VPN generally deal with overhead and delay, which impact the quality of service (QoS) for the call.
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:
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.
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.
Figure 5-31. VPN Overhead: IPSec Example
To properly calculate bandwidth overhead, the user must have a thorough understanding of the VPN technology by asking the following questions:
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.
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.
Figure 5-32. Span Engineering VoIP Network Security Components
Your task is to identify the benefits associated with each security component:
Practice Scenario 7: Solutions