Network performance and capacity planning helps to ensure that the network will consistently have available bandwidth for data and VoIP traffic and that the VoIP packets will consistently meet delay and jitter requirements. We recommend the following six-step process for network capacity and performance planning:
1. Baseline existing network utilization and peak load requirements.
2. Determine VoIP traffic overhead in required sections of the network based on busy hour estimates, gateway capacities, and/or CallManager capacities.
3. Determine minimum bandwidth requirements.
4. Determine the required design changes and QoS requirements, based on IP Telephony design recommendations and bandwidth requirements (over-provision where possible).
5. Validate baseline performance.
6. Determine trunking capacity.
Each of these steps are described in detail below:
Step 1 Baseline Existing Network Utilization
Baselining network utilization helps to determine the current traffic load and data traffic requirements for a combined VoIP and data architecture. You should perform this step for major distribution, backbone, and required WAN links. If you have a relatively homogenous environment, you may perform a sample baseline from representative links rather than collect large amounts of data for an entire network. You normally use two types of utilization statistics to describe link utilization: peak utilization and average utilization. Both of these measurements have limitations and you should carefully evaluate them.
• Peak Utilization
You normally collect peak utilization data by SNMP polling of the “average” utilization over a short time interval. In most cases, the time interval is five minutes but may be as high as fifteen minutes.
The problem with this information is that it is still an average of utilization over the specified time period. Studies have been done showing that over a five minute period, the actual peak utilization is 40% higher than the reported result. This means that a reported peak utilization of 70% may indicate points in time during the five minute period where utilization is 98%. In VoIP environments, this may already impact delay and jitter of voice packets. Another issue is that the information may not represent duplex links where utilization may be quite different in each direction.
• Average Utilization
Average utilization may not provide complete information for other reasons. For example, data traffic may be much higher during peak periods, such as mornings and afternoons. If the average utilization is reported for a 24-hour period, then the reported result may not show heavily utilized periods during the day.
To be more useful, peak and average utilization should be more closely tied to actual peak periods.
Average utilization would be much more valuable if it depicted “busy hour” utilization for the busiest periods during the day. Peak utilization would be more valuable if it could determine the actual peak periods, perhaps seconds or even milliseconds in duration. Unfortunately, peak utilization is not easily collected over many areas of the network and doesn’t scale well. For this reason, peak utilization values should use the 40% rule to estimate actual peak requirements for five minute SNMP collection intervals.
If you are using QoS in both the LAN and WAN, then peak utilization may not be necessary. However, busy hour utilization is valuable information that you can use to determine if the combined data and voice traffic will have sufficient bandwidth.
To collect busy hour utilization, you should simply poll all distribution, backbone, and WAN links that will carry voice traffic on an hourly basis and report the busy hour utilization over each link after about a week of data collection. Tools such as Concorde NetHealth can provide this information for a large number of links or you can use any SNMP collector to gather data over a representation of LAN links.
In general, you should investigate all WAN links that will be used for VoIP. You will then use this information in conjunction with the expected busy hour voice traffic to determine bandwidth requirements. This process is sufficient for any network that plans of implementing VoIP in a QoS controlled environment. If QoS is not planned for the LAN environment, you may need to inspect peak utilization more closely. In many cases, an organization may also simply choose to over-subscribe the LAN bandwidth to avoid link utilization problems either now or in the future.
Once you collect the data and compare it with voice requirements, you should investigate the desired QoS requirements, expected network growth, and overall requirements to define upgrade requirements.
Closely investigate expected combined busy hour LAN link utilization over 50% and WAN link utilization over 75%. This will ensure you meet data and voice requirements.
Step 2 Determine VoIP Overhead
You should determine VoIP overhead by building or by WAN site. However, network planners will not typically be concerned with the low amount of VoIP overhead in the LAN environment. No specific rules exist to determine the traffic requirements; however, your Telecom department may be able to provide busy hour traffic statistics for different areas of the current voice network. You should take special care to differentiate buildings or sites where more or less voice traffic is required. For example, there may be an organization where one building houses engineers that don’t typically spend much time on the phone and another building with Support Center personnel who are always on the phone.
We recommend you estimate busy hour call volume and use an Erlang calculator to determine busy hour call requirements. This can then be multiplied by the VoIP encoding method to determine busy hour bandwidth requirements. For example, in a building with 100 people, the Telecom department believes that busy hour traffic for this building is 16.66 hours based on a busy hour call volume of 100 calls and average call duration of 10 minutes. You can then perform an Erlang B calculation based on 16.66 hours and a blocking factor of one percent. The blocking factor is then the confidence level that the estimated bandwidth will be sufficient for the voice requirements. The Erlang B calculator (available on their web site—http://www.erlang.com) computes that 26 lines will be needed to support the 99% confidence level. If we multiply 26 times the encapsulation method, we can determine the busy hour traffic volume.
Assuming the G.711 encoding is used with 80 Kilobyte packets and constant bi-directional voice traffic, we estimate that two megabits/second will be needed to provide adequate bandwidth. Since voice traffic is generally not constant, this is considered an acceptable estimate of the voice traffic requirement.
If the Telecom department cannot provide busy hour traffic volume, you should investigate the voice usage within the building, perhaps even with a visual inspection. This may not be too critical in LAN environments since even constant phone use by 500 users only consumes 40 megabits/second of data bandwidth.
Refer to the Cisco IP Telephony Network Design Guide for WAN bandwidth requirements. This document can be found at the following location:
http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/network/dgclustr.htm.
Step 3 Determine Bandwidth Requirements
Over WAN links, you should then combine the busy hour data traffic and busy hour voice traffic to determine link bandwidth requirements. Keep in mind that this value does not offer any room for growth.
It is up to the organization to determine the growth requirements over time and to perform link trending to determine overall bandwidth requirements once data and voice are implemented. We recommend that you baseline and trend link utilization over time to help ensure that the network consistently meets both data and voice requirements.
Step 4 Determine Design Changes and Required QoS
Design changes should first follow IP Telephony deployment guidelines for LAN and WAN topologies.
Note Refer to the Cisco IP Telephony Network Design Guide for detailed information:
http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/network/index.htm.
Once these requirements are met, you should investigate data growth and voice traffic requirements, as well as overall scalability, to define an overall network infrastructure solution for IP Telephony. In addition to overall network design, QoS should be configured for both LAN and WAN environments to validate the network design with a performance baseline.
Step 5 Validate Baseline IP Telephony Performance
You should then validate VoIP performance with a performance baseline prior to implementation to determine voice readiness. Cisco Systems can perform a voice readiness audit that measures delay and jitter across major identified paths. The audit also investigates potential network issues across major
network paths. Issues may include queuing delay, CPU utilization, link utilization, buffer utilization, and error rates. You should also consider this step after full IP Telephony implementation in order to baseline the working solution and help determine potential issues with the additional traffic load and performance requirements.
Step 6 Determine Trunking Capacity
In addition to CallManager capacity issues and network capacity issues, you need to determine trunking requirements for voice mail connectivity, PSTN connectivity, and possibly site-to-site connectivity for off-net trunking or off-net overflow. Capacity planning for trunk for voice trunking is already an established capacity planning process in the voice world and the same process applies to trunking capacity for IP Telephony.
The process is normally performed by determining the busy hour traffic statistics for the required trunking application. Some typical trunking applications are:
• Local PSTN trunking
• Long distance PSTN trunking
• Voice mail trunks connected to voice mail systems
• Site-to-site trunks over leased lines or data/voice TDM systems
• Site-to-site trunks for off-net overflow used with Call admission control
You can normally determine busy hour traffic for each application type from the existing telecom switch vendor. This may be an additional service to the organization. Busy hour traffic can be defined as the number of call hours during the busiest hour period. Busy hours may even be the busiest hour of a month.
For example, if there are 200 calls with an average duration of ten minutes, then busy hour traffic is 2000 minutes or 33.33 hours. If busy hour traffic is not available, you may simply choose to implement a similar (or slightly higher) number of trunks for IP Telephony than the existing Telecom solution.
Once you determine busy hour traffic for the desired application, you can use the Erlang B calculator (http://www.erlang.com) to arrive at a trunking quantity that satisfies the organization based on a desired blocking factor. Most Telecom organizations currently use a blocking factor of one percent, which means that one percent of the time during the busy hour, users are expected to wait or busy out because of trunk non-availability. This calculation shows that you need 45 trunks for the 2000 minutes. This equates very closely to two T-1s with 23 voice channels each.
You must simply define each application, determine or estimate the busy hour traffic, use the Erlang calculator, and then determine the gateway product or combination of products that will best suit your specific requirements.