Frame Relay Voice Adaptive Traffic Shaping and Fragmentation

This topic describes Frame Relay voice-adaptive traffic shaping and fragmentation.

This topic describes Frame Relay voice-adaptive traffic shaping and fragmentation.

To address the needs of voice traffic in a Frame Relay network in which shaping is desired only when voice is present, but otherwise bursting to port-speed is desired, you can configure the FR-VATS feature. This feature was introduced in Cisco IOS Release 12.2(15)T.

FR-VATS monitors the Frame Relay permanent virtual circuit (PVC), and when voice activity is present, this feature automatically shapes the CIR to the minCIR. If no voice is present, the voice adaptive feature is turned off, allowing the data traffic to burst to the line rate, which is the CIR. The voice adaptive feature determines the presence of voice based on packets entering a low-latency queue. The feature then automatically turns traffic shaping on or off. Similarly, the FR-VATS feature is triggered on Frame Relay Fragmentation (FRF. 12) on links less than 768 kbps when voice packets are present to prevent unnecessary serialization delays.

Because FR-VATS automatically detects the presence of voice, there could be brief quality degradation in the first couple of seconds of the first voice call made across a PVC. This occurs while the interfaces in the PVC reconfigure themselves to shape to the minimum CIR and empty out their buffers. FR-VATS is not a predictive algorithm, and the change in behavior is triggered by voice packets flowing across the PVC or the presence of H.323 call-setup signaling.

The FR-VATS deactivation period is tunable and, by default, is set to 30 seconds. If you tune it, you should set the timer so that the feature will not turn off frequently during normal business use (for example, between every two calls). The feature works better on PVCs that always have at least one voice call present during daytime use and relinquish shaping only at night.

Benefits in Deploying FR-VATS

This topic describes the benefits of deploying FR-VATS.

This topic describes the benefits of deploying FR-VATS.

Before the introduction of the FR-VATS feature, Frame Relay adaptive shaping was used to reduce the sending rate when a network was congested. Because the adaptive shaping mechanism was triggered by network congestion, voice traffic might already have been delayed by the time the sending rate was reduced. The Frame Relay voice-adaptive traffic shaping and fragmentation feature helps to ensure voice quality by adjusting the rate of traffic based on the presence of voice on the PVC.

Frame Relay voice-adaptive traffic shaping and fragmentation provides these benefits:

■ Prevents delay of voice packets when network congestion occurs by reducing the traffic rate to the minCIR and turning on fragmentation when voice packets are present on a PVC

■ Maximizes utilization of the PVC by increasing the traffic rate to the CIR when voice packets are not present

■ Reduces CPU utilization by turning off fragmentation when there are no voice packets present

Prerequisites for Deploying FR-VATS

This topic describes the prerequisites for deploying FR-VATS.

This topic describes the prerequisites for deploying FR-VATS.

A prerequisite for Frame Relay voice-adaptive traffic shaping is that traffic shaping and LLQ

must be configured using the Modular quality of service (QoS) command-line interface (CLI), or MQC.

Prerequisites for Frame Relay voice-adaptive fragmentation are as follows:

■ End-to-end fragmentation must be configured in a map class or on the interface.

■ Frame Relay traffic shaping or traffic shaping using the MQC must be configured. If end-to-end fragmentation is configured on the interface, traffic shaping must be configured using the MQC.

■ LLQ must be configured.

■ End-to-end fragmentation must be configured on the peer router. Although the peer router may not see the fragmented packets that are expected from the router doing voice-adaptive fragmentation, the peer router will be able to handle large unfragmented packets in addition to fragmented packets.

Note The feature supports FRF.12 fragmentation only. Neither FRF.11 Annex C nor Cisco proprietary fragmentation is supported.

Was this article helpful?

0 0

Post a comment