QoS Group–Based dWFQ behaves almost identically to ToS-Based WFQ. The classification feature of each is similar, but with QoS Group–Based dWFQ, the classification is based on the QoS group value assigned to the packet. The QoS group is a value between 0 and 99, inclusive, which is assigned to the packet as it passes through a single router. QoS Group–Based dWFQ classifies a packet into 1 of 100 queues, numbered 0 through 99, matching the QOS group assigned to the packet. (Queue 0 is the default queue.)
The drop policy and scheduler work just like ToS-Based dWFQ as well. The bandwidth percentages can be spread among as many as 100 queues. Table B-15 lists the familiar points for comparison, this time highlighting QoS Group–Based dWFQ, and Figure B-10 depicts the general sequence of events when using QoS Group–Based dWFQ.
Table B-15QoS Group–Based WFQ Functions and Features
Can It Be Used
Max # of
on Shaping
Tool
Classification
Drop Policy
Weighting
Queues
Queues?
QoS
QoS group based
Same as
Configured as
100
No
Group–
dWFQ
percentage of
Based WFQ
link bandwidth
per queue
Figure B-10QoS Group–Based dWFQ: Summary of Main Features
3)Maximum Number of Queues
4)Maximum Queue Length
5) Scheduling Inside Queue
6) Scheduler Logic
1) Classification
Assign SN
2) Drop Decision
100 Queues
Process:
?
Unpublished
SN Calculation
Max Length
TX Queue/Ring
Not Published
Dropped
4096
Result: Gives Each
.
Queue the
.
Weight Based
Configured
on Configured
Modified Tail
.
Percentage
100 Classes, Based on
Percentage
Drop Based on
Bandwidth
Bandwidth
Aggregate and
FIFO
QoS Group
Individual Queue
Limits
QoS Group–Based WFQ Configuration
The configuration for QoS Group–Based dWFQ is simple. Tables B-16 and B-17 lists the generic commands.
Congestion Management (Queuing) 869
Table B-16
Configuration Command Reference for QoS Group–Based dWFQ
Command
Mode and Function
fair-queue qos-group
Interface configuration mode; enables QoS Group–
Based dWFQ. There are no other optional
parameters on this command.
fair-queue aggregate-limit aggregate-packets
Interface configuration mode; sets the aggregate
limit of the number of packets held in all dWFQ
queues.
fair-queue individual-limit individual-packet
Interface configuration subcommand; sets the
maximum number of packets in a single queue.
fair-queue {qos-group number | tos number}
Interface configuration subcommand; sets the
limit class-packet
individual queue limit for a single queue. Takes
precedence over the fair-queue individual-limit
command.
fair-queue {qos-group number | tos number}
Interface subcommand; sets the percentage link
weight weight
bandwidth assigned to the queue. The QoS group
number can be between 1 and 99, with Queue 0
getting the remaining bandwidth.
Table B-17
Exec Command Reference for QoS Group–Based dWFQ
Command
Function
show queue interface-name interface-number
Lists information about the packets that are waiting
[vc [vpi/] vci]]
in a queue on the interface
show queueing [custom | fair | priority |
Lists configuration and statistical information about
random-detect [interface atm-subinterface
the queuing tool on an interface
[vc [[vpi/] vci]]]]
Configuring the fair-queueqos-groupsubcommand on an interface enables QoS Group– Based dWFQ. For this command to work, dCEF must be enabled, and the interface must really be on a VIP2-xx, where xx is 40 or higher. Example B-14 shows a sample configuration, along with changes to the bandwidth percentages given to Queues 1, 2, and 3. In this case, queue 0 gets 39 percent of the link bandwidth, because 61 percent has been assigned using configuration commands.
Example B-14QoS Group–Based dWFQ Configuration
ip cef
!
interface serial 0/0/1 encapsulation ppp
continues
870 Appendix B: Topics on the CCIP QoS Exam
Example B-14QoS Group–Based dWFQ Configuration (Continued)
description Serial interface on VIP2-50 fair-queue qos-group
Example B-14 lists the same basic parameters as Example B-13, but with QoS Group–Based dWFQ in this case. Of course, more queues could be used, with different weights (bandwidth percentages) for each queue.
Summary: dWFQ Options
Of the three dWFQ options, useful on the 7500 series routers only, dWFQ (also called FlowBased dWFQ) is most similar to WFQ. It is flow based, uses a similar (although slightly different) drop policy, and uses the same scheduling logic. However, the other differences are significant: dWFQ does not consider the IP precedence when assigning SNs, and it only allows 512 queues.
The other two dWFQ options, ToS-Based dWFQ and QoS Group–Based dWFQ, stand out in their lack of similarity to WFQ. Neither are flow based, the number of queues is predetermined, and the scheduler assigns weights based on bandwidth percentages, which is more like CQ or CBWFQ. Like dWFQ, these two options are available only on 7500 series routers.
ToS-Based dWFQ classifies based on the 2 low-order bits in the IP Precedence field, which may require you to rethink your QoS classification and marking strategy. For instance, Cisco recommends that you mark video payload with AF41, and the least-important data with DSCP BE. The video needs high bandwidth, low delay, and low jitter. The unimportant data can get the leftover bandwidth, with no significant delay requirements. With DSCP AF41’s binary code being 100010, however, and DSCP BE being 000000, ToS-Based dWFQ would work poorly. (The low-order 2 bits of the IP Precedence field are in bold, and in both cases, the value is binary 00.) Similarly, DSCP EF traffic and DSCP AF11, AF12, and AF13 would all be placed in the same queue with ToS-Based dWFQ. Therefore, you would need to reconsider the QoS policy for marking before using this tool.
From an exam-preparation perspective, try to focus on the details of WFQ and the comparisons between the tools that Table B-18 outlines.
Congestion Management (Queuing) 871
Table B-18Summary of dWFQ Functions and Features
Can It Be Used
Max # of
on Shaping
Tool
Classification
Drop Policy
Weighting
Queues
Queues?
WFQ
Flow based
Modified tail
Based on IP
4096
Yes
drop
precedence
dWFQ
Flow based
Tail drop for
None
512
No
individual
queues, plus a
max aggregate
for all queues
ToS-Based
Class based,
Same as dWFQ
Configured as
4
No
WFQ
predicated on
percentage of
low-order 2 bits
link bandwidth
of precedence
per queue
QoS
QoS group
Same as dWFQ
Configured as
100
No
Group–
based
percentage of
Based WFQ
link bandwidth
per queue
Modified Deficit Round-Robin
Cisco designed Modified Deficit Round-Robin (MDRR) specifically for the Gigabit Switch Router (GSR) models of Internet routers. In fact, MDRR is supported only on the GSR 12000 series routers, and the other queuing tools (WFQ, CBWFQ, PQ, CQ, and so on) are not supported on the GSRs.
Many of the features of MDRR will be familiar. Like all queuing tools, it needs to perform classification and make drop decisions, scheduling decisions, and so on. Figure B-11 depicts the major parts of the queuing puzzle of MDRR, followed by some comments about each step.
MDRR classifies packets only based on the IP Precedence field. Not surprisingly, MDRR supports eight classes, and therefore eight queues, because there are eight precedence values. The queues are numbered 0 through 7, and the precedence values (decimal) are also 0 through 7— but MDRR does map the values one to one. MDRR enables you to configure each precedence value to map to any of the queues, so more than one precedence value could map to the same queue.
Like CBWFQ, MDRR supports either tail drop or Weighted Random Early Detection (WRED) for the drop policy, per queue. Like most other tools, inside each queue, first-in, first-out (FIFO) logic is used. In addition, as expected, the most interesting part relates to the logic used by the scheduler, which is where MDRR gets its name.
872 Appendix B: Topics on the CCIP QoS Exam
Figure B-11MDRR: Summary of Main Features
3) Maximum Number of Queues
4) Maximum Queue Length
6) Scheduler Logic
5) Scheduling Inside Queue
1) Classification
2) Drop Decision
8 Queues
?
Max Length
Dropped
Variable
.
.
Tail Drop or
.
Class Based
WRED
FIFO
Only on IP
Precedence
Process: Round Robin Through
Queues serving a quantum per
pass. Deficit feature evens out the
TX Queue/Ring
process.
PQ feature for a single queue, with strict (always serve the new packets immediately) or alternate (serve the PQ, then take a quantum from another queue, alternating) scheduling
MDRR schedules traffic by making a round-robin pass through the configured queues. (For the time being, assume that the optional PQ [LLQ] feature has not been configured.) MDRR removes packets from a queue, until the quantum value (QV) for that queue has been removed. The QV quantifies a number of bytes, and is used much like the byte count is used by the CQ scheduler. MDRR repeats the process for every queue, in order from 0 through 7, and then repeats this round-robin process. The end result is that each queue gets some percentage bandwidth of the link.
The CQ scheduler has a problem with trying closely to provide a particular percentage bandwidth. MDRR overcomes this same problem, but it is useful to recall an example of the problem first. Repeating an earlier example about CQ, suppose a router uses CQ on an interface, with 3 queues, with the byte counts configured to 1500, 1500, and 1500. Now suppose that all the packets in the queues are 1500 bytes. (This is not going to happen in real life, but it is useful for making the point.) CQ takes a 1500-byte packet, notices that it has met the byte count, and moves to the next queue. In effect, CQ takes one packet from each queue, and each queue gets 1/3 of the link bandwidth. Now suppose that Queue 3 has been configured to send 1501 bytes per queue service, and all the packets in all queues are still 1500 bytes long. CQ takes 1 packet from Queue 1, 1 from Queue 2, and then 2 packets from Queue 3! CQ does not fragment the packet. In effect, Queue 3 sends 2 packets for every 1 packet sent from Queues 1 and 2, effectively giving 25 percent of the bandwidth each to Queues 1 and 2, and 50 percent of the link bandwidth to Queue 3.
MDRR deals with this problem by treating any “extra” bytes sent during a cycle as a “deficit.” Next time around through the queues, the number of “extra” bytes sent by MDRR is subtracted from the QV. In Figure B-12, MDRR is using only two queues, with QVs of 1500 and 3000, respectively, and with all packets at 1000 bytes in length.
Congestion Management (Queuing) 873
Figure B-12MDRR: Making Up Deficits
Note: All Packets are 1000 bytes long!
1st MDRR Pass Through the Queues
Queue1
Beginning Q1 Deficit Count = 1500
P6
P5
P4
P3
P2
P1
Ending Q1 Deficit Count = -500
Queue2
Beginning Q1 Deficit Count = 3000
P12
P11
P10
P9
P8
P7
Ending Q1 Deficit Count = 0
2nd MDRR Pass Through the Queues
Queue1
Beginning Q1 Deficit Count = -500 + 1500 = 1000
P6
P5
P4
P3
Ending Q1 Deficit Count = 0
Queue2
Beginning Q1 Deficit Count = 0 + 3000 = 3000
P12
P11
P10
Ending Q1 Deficit Count = 0
First, some extra information on how to interpret the figure may help. The figure shows the action during the first round-robin pass in the top half of the figure, and the action during the second pass in the lower half of the figure. The example begins with six packets (labeled P1 through P6) in Queue 1, and six packets (labeled P7 through P12) in Queue 2. Each arrowed line, attached to the right sides of the queues, and pointing to the right, represents the choice by MDRR to send a single packet.
When a queue first fills, the queue’s deficit counter is set to the QV for that queue, which is 1500 for Queue 1, and 3000 for Queue 2. In the figure, MDRR begins by taking 1 packet from Queue 1, decrementing the DC to 500, and deciding that the DC has not been decremented to 0 (or less). MDRR takes a second packet from Queue 1, decrementing the DC to –500. MDRR then moves on to Queue 2, taking three packets, after which the DC for Queue 2 has decremented to 0.
That concludes the first pass through the queues. MDRR has taken 2000 bytes from Queue 1, and 3000 from Queue 2, giving the queues 40 percent and 60 percent of link bandwidth, respectively.
In the second round-robin pass, shown in the lower half of the figure, the process begins by MDRR adding the QV for each queue to the DC for each queue. Queue 1’s DC becomes 1500 + –500, or 1000, to begin the second pass. During this pass, MDRR takes P3 from Queue 1, decrements DC to 0, and then moves on to Queue 2. After taking three more packets from
874 Appendix B: Topics on the CCIP QoS Exam
Queue 3, decrementing Queue 2’s DC to 0, MDRR completes the second pass. Over these two round-robin passes, MDRR has taken 3000 bytes from Queue 1, and 6000 from Queue 2— which is the same ratio as the ratio between the QVs.
With the deficit feature of MDRR, over time each queue receives a guaranteed bandwidth based on the following formula:
QV for Queuex
------------------------------------
Sum of all QVs
For additional examples of the operation of the MDRR deficit feature, refer to http:// www.cisco.com/warp/public/63/toc_18841.html. Alternatively, you can go to www.cisco.com and search for “Understanding and Configuring MDRR and WRED on the Cisco 12000 Series Internet Router.”
MDRR also allows one queue to be used as a PQ, but with two variations on how the PQ is scheduled. One scheduling option, called strict scheduling, acts just like PQ’s treatment of the High queue, which is also how Low Latency Queuing (LLQ) and IP RTP Priority scheduling works. Whenever the scheduler decides to remove another packet from any queue, it first checks the strict PQ, and takes a packet if one is in the queue. With strict treatment, MDRR does not need to assign a QV to the low-latency queue, because there is no concept of taking a QV of bytes per pass through the queue—the low-latency queue gets strict service whenever it needs it.
MDRR offers a less strict algorithm for servicing the low-latency queue called alternate service. With alternate service, the low-latency queue is assigned a QV, just like the other queues. MDRR takes QV bytes from the low-latency queue, and then take bytes from a non-low-latency queue. MDRR then goes back to the low-latency queue, taking QV bytes, and then to another queue. If Queues 0 through 2 are Normal queues, and Queue 7 is the low-latency queue, for instance, MDRR serves the queues in this order: 7, 0, 7, 1, 7, 2, and repeats this sequence. Because the low-latency queue gets serviced on every alternate attempt, it can get a disproportionate amount of bandwidth. However, with alternate service, MDRR does prevent the lowlatency queue from taking over the link.
Strict and alternate priority affect delay and jitter differently. With alternate priority, packets experience longer delay and more jitter, as compared with strict scheduling. Alternate priority gives the other queues a little more service, however, which improves their performance.
Table B-19 summarizes some of the key features of MDRR.
Table B-19MDRR Functions and Features
MDRR Feature
Explanation
Classification
Classifies on IP precedence, mapping 1 or more values to a
single queue.
Drop policy
Tail drop or WRED, configurable per queue.
Number of queues
8.
Congestion Management (Queuing) 875
Table B-19
MDRR Functions and Features (Continued)
MDRR Feature
Explanation
Maximum queue length
Variable, based on the type of card.
Scheduling inside a single queue
FIFO.
Scheduling among all queues
Deficit round-robin logic is used for queues that are not priority
queues, with the scheduler taking a number of bytes from each
queue during each pass through the queues. The number of any
extra bytes taken in one pass is deducted from the number taken
in the next pass. LLQ service is either strict (like PQ), or alternate,
where MDRR alternates between the low-latency queue and a
non-low-latency queue, serving the low-latency queue half of
the service slots.
MDRR Configuration
MDRR configuration requires you to understand GSR architecture to a small degree. MDRR configuration also introduces some new terminology. Table B-20 lists the configuration commands related to MDRR, and following the tables is an explanation of the new terminology, the formula used to calculate the QV per queue, and an explanation of the flow of the configuration commands.
Table B-20Command Reference for MDRR
Command
Mode and Function
cos-queue-groupcos-queue-group-name
Global config mode; creates a queue group template,
where other parameters are added as subcommands
precedence <0-7> queue [ <0-6> | low-
cos-queuesubcommand; maps a precedence value
latency]
to a queue.
queue queue-number weight
cos-queuesubcommand; assigns a weight to a
queue.
queue low-latency {alternate-priority weight
cos-queuesubcommand; enables a queue as a low-
| strict-priority}
latency queue, defines scheduling strategy, and
assigns weight
random-detect-label label minimum-
cos-queuesubcommand; creates a set of WRED
threshold maximum-threshold mark-
parameters
probability
precedence queue-numberrandom-detect-
cos-queuesubcommand; enables WRED on the
label label
queue, with the WRED parameters in the random-
detect-label specified.
876 Appendix B: Topics on the CCIP QoS Exam
After you understand the basic concepts, you just need to understand a few facts about how the configuration commands work before being able to configure basic MDRR. First, the lowlatency queue is always Queue 7, and instead of being referred to as Queue 7, the low-latency queue is referred to with the low-latencykeyword. The next thing to note is that the QoS configuration details are configured as subcommands of the cos-queue-groupcommand.
In other words, the classification details, choosing QVs by using the weight keyword, and selecting strict or alternate LLQ scheduling, are configured as subcommands of the cos-queue- group command. MDRR configuration does not enable you to specify the QV for each queue, but rather you configure a value called weight. The QV is then calculated from the weight using the following formula:
QV = MTU + Weight * 512
Here, MTU is the maximum transmission unit configured for the interface. Weight values can be configured between 1 and 2048, but Cisco recommends using low values—in fact, for the lowest-weight queue, use a value of 1.
Finally, like LAN switches, GSR routers benefit from having both input and output queuing. MDRR can be applied to an interface for input packets using the rx-coscommand, and for output packets using the tx-coscommand.
The following criteria is used in the upcoming example configuration:
•Precedence 0 and 1 are placed in Queue 0, with a weight of 1.
•Precedence 5 is placed in the low-latency queue, with strict priority.
•All other precedence values are placed in Queue 1, with a weight of 3.
•WRED is used on Queues 0 and 1, with default WRED parameters.
•The MDRR configuration is used for packets entering interface pos (Packet over SONET) 3/0, and for packets exiting pos 3/1.
Example B-15 shows the configuration and show commands.
Example B-15MDRR: VoIP in High Queue, All Else in Normal Queue
Most of the commands in the sample are configuration subcommands under the cos-queue- group my-samplecommand. For instance, the precedence 0 queue 0 command maps precedence 0 packets to Queue 0; a similar command maps the appropriate precedence values to queues, as stated in the policy before the example. Similarly, WRED parameters apply per precedence, so the precedence 0 random-detect-label 0 command links precedence 0 packets to a set of WRED parameters with a WRED label of 0. At the end of the example, the random- detect-label 0 command creates a WRED label 0, with no specific parameters—even if you want to take default WRED parameters, you still need to create the label, and refer to it with a command such as precedence 0 random-detect-label 0 to enable WRED for those packets.
The weights are configured with the queue command seen toward the end of the configuration. The queue 0 1 command assigns a weight of 1 to Queue 0, and the queue 1 3 command assigns a weight of 3 to Queue 1. The queue low-latency strict command defines that Queue 7, the low-latency queue, should use strict scheduling.
Finally, at the top of the configuration, the rx-cosmy-samplecommand enables cos-queue-listmy-samplefor packets entering interface pos 3/0. Similarly, the tx-cosmy-sampleinterface subcommand enables MDRR for packets exiting pos 3/1.
MDRR provides queuing services on GSR 12000 series routers. It assigns a percentage bandwidth through the use of the weight keyword, with the percentages being much more exact than CQ through the deficit feature of the MDRR scheduler. MDRR allows two options for treatment of the low-latency queue, strict and alternate, which gives the engineer more flexibility in how to deal with delayand jitter-sensitive traffic.
The classification feature of MDRR only supports IP precedence, which can be seen as a negative. Because most networks deploy GSRs in the core of the network, however, a good QoS design, with classification and marking at the edge of the network, can work very well with the precedence-based classification of MDRR.
878 Appendix B: Topics on the CCIP QoS Exam
Q&A for Queuing Tools
1What command enables you to configure Priority Queuing to classify based on ACL 101, placing the traffic in the Medium queue?
Answer: priority-list 5 protocol ip medium list 101
2What command enables you to configure Custom Queuing to classify based on ACL 101, placing the traffic into queue 4?
Answer: queue-list 5 protocol ip 4 list 101
3Which interface subcommands enable Priority Queuing list 5 on interface s 0/0? Custom Queuing?
Answer: priority-group 5 and custom-queue-list 5
4Compare and contrast WFQ and dWFQ. Specifically mention features relating to scheduling, classification, and drop policy.
Answer: WFQ and dWFQ both classify based on the flow. The dWFQ drop policy drops a packet if the individual queue limit or aggregate queue limit is reached. WFQ can also dequeue and discard a previously enqueued packet, if a new packet has a better sequence number. The WFQ scheduler weights packets based on length and IP precedence, whereas dWFQ only weights based on length.
5Compare and contrast WFQ and ToS-Based dWFQ. Specifically mention features relating to scheduling, classification, and drop policy.
Answer: WFQ classifies based on the flow, whereas ToS-Based dWFQ classifies based on the 2 low-order bits of the IP Precedence field. The ToS-Based dWFQ Drop policy drops a packet if the individual queue limit or aggregate queue limit is reached. WFQ can also dequeue and discard a previously enqueued packet, if a new packet has a better sequence number. The WFQ scheduler weights packets based on length and IP precedence, whereas ToS-Based dWFQ guarantees a minimum amount of bandwidth to each queue.
6Compare and contrast WFQ and QoS Group–Based dWFQ. Specifically mention features relating to scheduling, classification, and drop policy.
Answer: WFQ classifies based on the flow, whereas QoS Group–Based dWFQ classifies based on the QoS group. The QoS Group–Based dWFQ drop policy drops a packet if the individual queue limit or aggregate queue limit is reached. WFQ can also dequeue and discard a previously enqueued packet, if a new packet has a better sequence number. The WFQ scheduler weights packets based on length and IP precedence, whereas QoS Group–Based dWFQ guarantees a minimum amount of bandwidth to each queue.
Congestion Management (Queuing) 879
7Compare and contrast WFQ, dWFQ, ToS-Based dWFQ, and QoS Group–Based dWFQ, in relation to the maximum number of queues. Also discuss why the wide range of values is meaningful.
Answer: These four tools allow a maximum of 4096, 512, 4, and 100 queues, respectively. WFQ and dWFQ have a much larger number of queues, because they are flow based. ToS-Based and QoS Group–Based dWFQ are class based, meaning many flows end up in a single queue, therefore requiring fewer queues.
8Compare and contrast WFQ, dWFQ, ToS-Based dWFQ, and QoS Group–Based dWFQ, in relation to which tools can be enabled on 2600 and 7500 series platforms. Also identify the requirements for a 7500 to support these tools.
Answer: These four tools can be enabled on 7500s, but only WFQ can be deployed on 2600 routers. The other three tools are specifically designed for use with 7500 series routers. The router must be running distributed CEF, and have VIP2-40 or better line cards installed on the interfaces on which the queuing tool is deployed.
9You are migrating from WFQ on a 7200 series router to dWFQ on a new 7500 series with VIP2-50s installed. You will be migrating the old 7200 configuration over to the 7500. What changes are needed to support dWFQ, other than changing the numbers of the interfaces?
Answer: The ip cef command is required, in case the 7200 did not run CEF. Because the fair-queue command already exists on the interface, the router automatically uses dWFQ.
10What commands define the percentage bandwidth to be used for Queue 2 for ToS-Based dWFQ? For QoS Group–Based dWFQ?
Answer: The fair-queue tos 2 weight 30 command defines Queue 2 to have 30 percent of guaranteed bandwidth. The fair-queue qos 2 weight 30 command defines the same, but for QoS Group–Based dWFQ.
11Describe the classification options available to Modified Deficit Round-Robin (MDRR), and how these options relate to the number of available queues.
Answer: MDRR classifies based on IP precedence, with eight queues. Conceivably, each precedence value could be placed into a different queue, but MDRR enables you to map each precedence value to a queue, with multiple precedence values into the same queue.
880 Appendix B: Topics on the CCIP QoS Exam
12Describe how the Modified Deficit Round-Robin scheduler works, and specifically why the word “deficit” refers to part of the scheduler logic.
Answer: DRR schedules some number of bytes per pass through the queues. MDRR takes packets from the queue, which means it may take more than the allotted number of bytes; this excess is called the deficit. The deficit is subtracted from the number of bytes taken from that queue in the next round. As a result, MDRR can accurately predict the percentage bandwidth assigned to a queue.
13Describe the names and logic behind the two options for low-latency queues with Modified Deficit Round-Robin (MDRR).
Answer: MDRR allows one queue to be used as a low-latency queue. With strict scheduling, the low-latency queue is serviced like PQ’s High queue—if a packet is waiting in that queue, it always goes next. With alternate scheduling, the low-latency queue is serviced, taking a configured number of bytes. Then another non-low- latency queue is serviced. Then the low-latency queue is served again, and so on, so every other queue service serves the low-latency queue.
14Describe the drop policy options for Modified Deficit Round-Robin (MDRR).
Answer: MDRR can use tail drop or WRED inside each queue.
15List the command syntax of the command that configures the type of queue service to use with the MDRR low-latency queue.
Cisco CallManager resource-based CAC, 591–641 Cisco Service Agent (Assurance Agent), 664–680 class class-default command, 284
Class of Service (CoS), 166–168, 730 class-based policing. See CB policing class-based shaping, 357–369 Class-Based WFQ. See CBWFQ class-default queues, 274
