www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
This section covers network design issues and solutions that a designer needs to be aware of when designing a network for IPT. Topics such as bandwidth requirements, delay, and QoS schemes should be considered.
Bandwidth
VoIP calls need to meet bandwidth and delay parameters. The amount of bandwidth required depends on the codec used, the Layer 2 protocols, and whether VAD is enabled. For the purpose of call control, you can use the following bandwidth requirements for VoIP design:
- G.729 calls use 26 kbps
- G.711 calls use 80 kbps
When you're designing for VoIP networks, the total bandwidth for voice, data, and video should not exceed 75 percent sustained of the provisioned link capacity during peak times. Use the following formula to provision interface speeds:
link capacity = [required bandwidth for voice] + [required bandwidth for video] + [required bandwidth for data]
Note
VAD
As we listen and pause between sentences, typical voice conversations can contain up to 60 percent silence in each direction. In circuit-switched telephone networks, all voice calls use fixed-bandwidth 64-kbps links regardless of how much of the conversation is speech and how much is silence. In multiservice networks, all conversation and silence is packetized. Using Voice Activity Detection (VAD), you can suppress packets of silence. Silence suppression at the source IP telephone or VoIP gateway increases the number of calls or data volumes that can be carried over the links, more effectively utilizing network bandwidth. Bandwidth savings are at least 35 percent in conservative estimates. VAD is enabled by default for all VoIP calls.
Table 15-7 shows how much bandwidth is required based on different parameters. Notice that for G.729, bandwidth is reduced from 26.4 kbps to 17.2 kbps with VAD and to 7.3 kbps with VAD and CRTP enabled.
Cisco has developed a tool, available on its website, that can be used to obtain accurate estimates for IPT design. It also adds an additional 5 percent for signaling overhead. The tool is the Voice Codec Bandwidth Calculator and it is available at http://tools.cisco.com/Support/VBC/do/CodecCalc1.do.
Delay Components
The ITU's G.114 recommendation specifies that the one-way delay between endpoints should not exceed 150 ms to be acceptable commercial voice quality. In private networks, somewhat longer delays might be acceptable for economic reasons. Delay components are one of two major types: fixed delay and variable delay.
- Propagation delay
- Processing delay
- Dejitter delay
Propagation delay is how long it takes a packet to travel between two points. It is based on the distance between the two endpoints. You cannot overcome this delay component. The speed of light is the theoretical limit. A reasonable planning figure is approximately 10 ms per 1000 miles, or 6 ms per 1000 km. This figure allows for media degradation and devices internal to the transport network. Propagation delay is noticeable on satellite links.
Processing delay includes coding, compression, decoding, and decompression delays. G.729 has a delay of 15 ms, and G.711 PCM has a delay of 0.75 ms. The delay created by packetization is also a processing delay. Packetization delay occurs in the process of waiting for a number of digital voice samples before sending out a packet.
Serialization delay is how long it takes to place bits on the circuit. Faster circuits have less serialization delay. Serialization delay is calculated with the following formula:
A 1500-byte packet takes (1500 * 8)/64,000 = 187 ms of serialization delay on a 64 Kbps circuit. If the circuit is increased to 512 kbps, the serialization delay changes to (1500 * 8)/512,000 = 23.4 ms. Data-link fragmentation using Link Fragmentation and Interleaving (LFI) or FRF.12 mechanisms reduces the serialization delay by reducing the size of the larger data packets. This arrangement reduces the delay experienced by voice packets as data packet fragments are serialized and voice packets are interleaved between the fragments. A reasonable design goal is to keep the serialization delay experienced by the largest packets or fragments on the order of 10 ms at any interface.
Packets can take different, redundant paths to reach the destination. Packets might not arrive at a constant rate because they take different paths, and they might experience congestion in the network. This variable delay is called jitter. The receiving end uses dejitter buffers to smooth out the variable delay of received VoIP packets. Dejitter buffers change the variable delay to fixed delay.
The variable-delay component includes queuing delay. As packets cross a network, they pass through several devices. At every output port of these devices, it is possible that other voice and data traffic is sharing the link. Queuing delay is the delay experienced as a result of other traffic sharing the link. It is the sum of the serialization delays of all the packets scheduled ahead of delayed packets. LFI is used as a solution for queuing delay issues. LFI is covered in the next section.
As the traffic load on a network increases, both the probability of delay and the length of the probable delay increase. The actual queuing delay depends on the number of queues, queue lengths, and queue algorithms. Queuing effects in VoIP networks are covered in the next section.
QoS Mechanisms for VoIP Networks
Cisco provides different QoS tools that you should use on edge and backbone routers to support VoIP networks. This section covers several QoS mechanisms and their impact on VoIP networks:
CRTP
CRTP was covered in an earlier section. It compresses the IP/UDP/RTP headers from 40 bytes to 2 or 4 bytes. It is configured on a link-to-link basis. Cisco recommends using CRTP for links lower than 768 kbps. Do not configure CRTP if the router CPU is above 75 percent utilization.
LFI
LFI is a QoS mechanism used to reduce the serialization delay. In a multiservice network, small VoIP packets have to compete with large data traffic packets for outbound interfaces. If the large data packet arrives at the interface first, the VoIP packet has to wait until the large data packet is serialized. When the large packet is fragmented into smaller packets, the VoIP packets can be interleaved between the data packets. Figure 15-17 shows how LFI works. With no LFI, all VoIP packets and other small packets must wait for the FTP data to be transmitted. With LFI, the FTP data packet is fragmented. The queuing mechanism then can interleave the VoIP packets with the other packets and send them out the interface.
FRF.12 is a fragmentation and interleaving mechanism specific to Frame Relay networks. It is configured on Frame Relay PVCs to fragment large data packets into smaller packets and interleave them with VoIP packets. This process reduces the serialization delay caused by larger packets.
PQ-WFQ
PQ-WFQ is also called IP RTP priority. PQ-WFQ adds a single priority queue to WFQ. The priority queue is used for VoIP packets. All other traffic is queued based on the WFQ algorithm. One variation of PQ-WFQ is Frame Relay RTP priority, which allows strict priority for RTP traffic on Frame Relay PVCs.
With IP RTP priority, the router places VoIP RTP packets in a strict priority queue that is always serviced first. All other (data) traffic is serviced by WFQ. If there is no need for differentiated CoS for data traffic, use IP RTP priority instead of LLQ. If you require differentiated CoS for data traffic, use LLQ.
LLQ
LLQ is also known as Priority Queuing–Class-Based Weighted Fair Queuing (PQ-CBWFQ). LLQ provides a single priority queue, as does PQ-WFQ, but it's preferred for VoIP networks because it can also configure guaranteed bandwidth for different classes of traffic. For example, all voice call traffic would be assigned to the priority queue, VoIP signaling and video would be assigned to a traffic class, FTP traffic would be assigned to a low-priority traffic class, and all other traffic would be assigned to a regular class. With LLQ for Frame Relay, queues are set up on a per-PVC basis. Each PVC has a PQ to support voice traffic. This congestion-management method is considered the most optimal for voice.
If multiple classes are configured for LLQ, they share a single queue but are allocated bandwidth and policed individually. It is recommended that you place only voice in the priority queue, because voice traffic typically is well-behaved, requiring fixed maximum amounts of bandwidth per call. The voice traffic is identified by IP precedence bits set to a value of 5 or a DSCP of Expedited Forwarding (EF) with values of 101xxx. Introducing video or other variable-rate real-time or nonreal-time traffic types could cause unacceptable jitter for the voice traffic. Video traffic normally is set to AF41 (100010). And signaling normally is set to an IP precedence of 3 or a DSCP of 011xxx.
Auto QoS
Auto QoS is a recent Cisco IOS feature that uses a simpler command-line interface (CLI) to enable QoS for VoIP in WAN and LAN environments. Auto QoS significantly reduces the amount of configuration lines necessary to support VoIP in the network.
- Automatically classifies RTP and VoIP control packets
- Builds VoIP Modular QoS in the Cisco IOS Software
- Provides LLQ for VoIP bearer traffic
- Provides minimum-bandwidth guarantees by using CBWFQ for VoIP control traffic
- Enables WAN traffic shaping where required
- Enables LFI and RTP where required
For the LAN, Auto QoS provides the following capabilities:
- Enforces a trust boundary at the Cisco IP Phone
- Modifies CoS-to-DSCP and IP Precedence-to-DSCP mappings
AutoQoS is beneficial for small-to-medium-sized businesses that need to deploy IPT quickly but lack the experience and staffing to plan and deploy IP QoS services.
Auto QoS also benefits large customer enterprises that need to deploy Cisco IPT on a large scale while reducing the costs, complexity, and timeframe for deployment and ensuring that the appropriate QoS for voice applications is being set consistently.
IPT Design Recommendations
- Use CAC to avoid oversubscription of priority queues.
IEEE 802.1Q should be configured on the PoE LAN switch ports to allow a voice VLAN for the IP phone and a data VLAN for the PC connected to the IP phone. These VLANs should be on separate IP subnets, and the IP phone should be an RFC 1918 private address subnet. Furthermore, the CallManager servers should be placed on a separate IP subnet in the data center. This lets you restrict access to the IPT environment.
IPT voice packets should be marked with a DSCP of EF (IP precedence 5), and signaling packets should be marked with AF31 (IP precedence 3). This allows QoS schemes to give precedence to the marked packets. LLQ takes the EF marked packets and places them in the strict priority queue, guaranteeing bandwidth for voice. LFI should be configured on WAN links of a size less than 768 kbps to allow smaller IPT packets to get through larger packets. LFI and LLQ also reduce jitter in IPT conversations.
No comments:
Post a Comment