Allocating Bandwidth
Bandwidth is allocated to the priority class a little differently than to other userdefined
classes. Instead of specifying the guaranteed bandwidth of the class with
the bandwidth command, the priority command is used.This gives a priority
class that will deliver LLQ to all traffic falling under this classification.There is a
particular distinction between how traffic metering is handled with the priority
class as opposed to other user-defined classes. Unlike normal classes, with the priority
class under congestion situations, bandwidth in excess of the limit configured
with the priority command is always dropped on the 7200 Series and lower
Cisco platforms.This is to prevent the priority queue from starving other traffic,
both user-defined classes and other important traffic like network routing
updates. However, in noncongestion situations, the bandwidth allocated to the
priority class may be exceeded.
It is important that you limit the bandwidth allocated to the priority class to
a reasonable value. If you configure too much of your traffic as priority traffic,
then it really is not priority at all. On an airplane, if everyone flies first class, can
you really call it first class? Additionally, it is strongly recommended that packets
classified into the priority class be limited to voice traffic alone, as mentioned
earlier.Voice streams are made of small packets of constant bit rate that are well
behaved by nature. By classifying applications into the priority class that are prone
to bursts or comprised of large packets, you essentially destroy the low latency
provided to the small-packet CBR voice traffic also waiting in the priority queue.
The fact that bandwidth of the priority class under congestion situations creates
a “hard upper limit” to voice traffic should not cause insurmountable problems.
Voice planners are accustomed to providing for an exact number of voice
calls on traditional voice networks.The same can be done on VoIP networks by
multiplying the bandwidth of each voice call (determined by the CODEC) by
the number of simultaneous calls in order to get the bandwidth necessary. It is
www.syngress.com
246 Chapter 8 • Advanced QoS for AVVID Environments
important to note that a call admission control process for the voice calls is
required.This guarantees that the number of calls supported by the bandwidth
provisioned by the priority command is not exceeded. Exceeding this bandwidth
would potentially lead to poor voice performance for all voice callers.
Here is an example.
Consider that a remote site needs up to 24 simultaneous voice calls connected
to the main hub site.The remote site is connected via a T1 serial link.
When the G.729 CODEC is used with cRTP, you can expect each call to use a
maximum of 12 Kbps.This gives a provision of 288 Kbps for all 24 calls.This
bandwidth is configured for the priority class with the priority command. In an
uncongested situation, more than 24 calls could be completed and still have good
quality. However, if congestion occurs in this overloaded call state, even for a
moment, packets will be dropped from the priority queue. Since it can be
assumed that the packets from the individual voice calls are interleaved with each
other, some drops will occur across all connected voice calls, resulting in poor
performance for everyone.To avoid this, some kind of admission control system is
necessary to assure that no more than 24 calls are ever connected.This can be
accomplished in a number of ways, including using gatekeeper technology available
on the Cisco Call Manager, the Cisco AS5300, and Cisco 3640 routers (IOS
12.1(1)), or by limiting the number of active voice ports on communicating gateways.
In either case, it would be preferable for a caller to get a busy signal indicating
that the call could not be completed or to have exceeding calls re-routed
to the PSTN, rather than the quality of all connected callers being affected.