Cisco Introduction IP QoS (Course)

Introduction
Overview
The module presents a thorough overview of quality of service models and
mechanisms as implemented in complex service provider and enterprise networks.
It includes the following topics:
n Introduction to IP Quality of Service
n Integrated Services Model
n Differentiated Services Model
n Building Blocks of IP QoS Mechanisms
n Enterprise Network Case Study
n Service Provider Case Study
Objectives
Upon completion of this module, you will be able to perform the following tasks:
n Describe the need for IP QoS
n Describe the Integrated Services model
n Describe the Differentiated Services model
n Describe the building blocks of IP QoS mechanisms (classification, marking,
metering, policing, shaping, dropping, forwarding, queuing)
n List the IP QoS mechanisms available in the Cisco IOS
n Describe what QoS features are supported by different IP QoS mechanisms
Introduction to IP Quality of Service
Objectives
Upon completion of this lesson, you will be able to perform the following tasks:
n Describe different types of applications and services that have special resource
requirements
n List the network components that affect the throughput, delay and jitter in IP
networks
n List the benefits of deploying QoS mechanisms in IP networks
n List QoS mechanisms available in Cisco IOS
n Describe typical enterprise and service provider networks and their QoS-related
requirements
2 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Why IP QoS?
• Application X is slow!
• Video broadcast occasionally stalls!
• Phone calls over IP are no better than over satellite!
• Phone calls have really bad voice quality!
• ATM (the money-dispensing-type) are non-

responsive!
• ...
© 2001, Cisco Systems, Inc. IP QoS Introduction-5
The purpose of this module is to determine the following:

n What is, or might be, missing in today’s IP networks?
n What can IP Quality of Service (QoS) do to help solve the problem?
A decade ago when the Internet was still in its early stages there was not much
available. Most users were using Gopher to find information and FTP to retrieve it.
The Internet was something new and exciting and no one was really bothered by
the fact that it was slow.
Today, however, the Internet is serving a large population of all walks of life. The
Internet has also grown in its service offering. Users are using the Internet to view
static or dynamic information, transmit voice and video, shop, play etc.
Along with these new applications of the Internet come some demands on the
service(s) it provides:
n Some applications are slow
n Video broadcast or conferencing may have bad picture quality or appear jerky
n Voice sessions may have bad voice quality or periods of silence
n Critical transactions may take too long (too many seconds)
n Bulk transfers take too long (too many hours)
This module focuses on most common quality-related problems people encounter in
IP networks.
Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 3

Because ...
• Application X is slow! (not enough BANDWIDTH)

• Video broadcast occasionally stalls! (DELAY
temporarily increases – JITTER)
• Phone calls over IP are no better than over satellite!
(too much DELAY)
• Phone calls have really bad voice quality! (too many
phone calls – ADMISSION CONTROL)
• ATM (the money-dispensing-type) are non
responsive! (too many DROPs)
• ...
Quality of Service is usually identified by the following parameters:

n Amount of bandwidth available to a certain application or user
n Average delay experienced by IP packets on end-to-end or link basis
n Jitter that affects applications that transmit packets at a certain fixed rate and
expect to receive them at approximately the same rate (for example, voice and
video)
n Drops of packets when a link is congested can severely impact fragile
applications
n Admission control which prevents too many sessions from congesting links
and causing degradation in quality of service (for example, voice sessions)

What Causes ...
• Lack of bandwidth – multiple flows are

contesting for a limited amount of bandwidth
• Too much delay – packets have to traverse
many network devices and links that add up
to the overall delay
• Variable delay – sometimes there is a lot of
other traffic which results in more delay
• Drops – packets have to be dropped when a
link is congested
If the network is empty any application should get enough bandwidth, acceptable
low and fixed delay and not experience any drops. The reality, however, is that
there are multiple users or applications using the network at the same time.

Available Bandwidth
IP IP IP IP
256 kbps 512 kbps
10 Mbps 100 Mbps
BW max = min(10M, 256k, 512k, 100M)=256kbps

BW avail = BWmax /Flows
• Maximum available bandwidth equals the bandwidth of the weakest link
• Multiple flows are contesting for the same bandwidth resulting in much
less bandwidth being available to one single application.
The example above illustrates an empty network with four hops between a server
and a client. Each hop is using different media with a different bandwidth. The
maximum available bandwidth is equal to the bandwidth of the slowest link.
The calculation of the available bandwidth, however, is much more complex in
cases where there are multiple flows traversing the network. The calculation of the
available bandwidth in the illustration is a rough approximation.

End-to-end Delay
IP IP IP IP
Propagation Propagation Propagation

delay (P1) delay (P2) delay (P3) Propagation
delay (P4)
Processing and Processing and Processing and
queuing delay (Q1) queuing delay (Q2) queuing delay (Q3)
Delay = P1 + Q1 + P2 + Q2 + P3 + Q3 + P4 = X ms
• End-to-end delay equals a sum of all propagation, processing
and queuing delays in the path
• Propagation delay is fixed, processing and queuing delays are
unpredictable in best-effort networks
The figure illustrates the impact a network has on the end-to-end delay of packets
going from one end to the other. Each hop in the network adds to the overall delay
because of the following two factors:
1. Propagation (serialization) delay of the media that, for the most part, depends
solely on the bandwidth.
2. Processing and queuing delays within a router, which can be caused by a wide
variety of conditions.
Ping (ICMP echoes and replies) can be used to measure the round-trip time of IP
packets in a network. There are other tools available to periodically measure
responsiveness of a network.

Processing and Queuing Delay
Forwarding
bandwidth
IP IP IP IP
Processing Delay Queuing Delay

Propagation Delay
• Processing Delay is the time it takes for a router to take the packet from an
input interface and put it into the output queue of the output interface.
• Queuing Delay is the time a packets resides in the output queue of a router.
• Propagation or Serialization Delay is the time it takes to transmit a packet.
n Processing Delay is the time it takes for a router to take the packet from an
input interface and put it into the output queue of the output interface. The
processing delay depends on various factors, such as:
– CPU speed
– CPU utilization
– IP switching mode
– Router architecture
– Configured features on both input and output interface
n Queuing Delay is the time a packet resides in the output queue of a router. It
depends on the number and sizes of packets already in the queue and on the
bandwidth of the interface. It also depends on the queuing mechanism.
n Propagation or Serialization Delay is the time it takes to transmit a packet. It
usually only depends on the bandwidth of the interface. CSMA/CD media may
add slightly more delay due to the increased probability of collisions when an
interface is nearing congestion.

Packet Loss
Forwarding
IP IP IP IP IP
Tail-drop
• Tail-drops occur when the output queue is full. These are the most
common drops which happen when a link is congested.
• There are also many other types of drops that are not as common and
may require a hardware upgrade (input drop, ignore, overrun, no
buffer, ...). These drops are usually a result of router congestion.
The usual packet loss occurs when routers run out of buffer space for a
particular interface (output queue). The figure illustrates a full output queue of an
interface, which causes newly arriving packets to be dropped. The term used for
such drops is simply “output drop” or “tail-drop” (packets are dropped at the tail of
the queue).
Routers might also drop packets for other (less common) reasons, for example:
n Input queue drop - main CPU is congested and cannot process packets (the
input queue is full)
n Ignore - router ran out of buffer space
n Overrun - CPU is congested and cannot assign a free buffer to the new packet
n Frame errors (CRC, runt, giant)—hardware-detected error in a frame

How to Increase Available
Bandwidth?
TCP Header Compression
RTP Header Compression
cTCP data
Compress
the Headers
IP TCP data Fancy

FIFO queuing
queuing
Compress
the Payload
Priority Queuing (PQ)
Custom Queuing (CQ)
Stacker
Compressed packet Modified Deficit Round Robin (MDRR)
Predictor Class-based Weighted Fair Queing (CB-WFQ)
• Upgrade the link. The best solution but also the most expensive.
• Take some bandwidth from less important applications.
• Compress the payload of layer-2 frames.
• Compress the header of IP packets.
There are several approaches to solving a problem of insufficient bandwidth:

n The best approach is to increase the link capacity to accommodate all
applications and users with some extra bandwidth to spare. This solution sounds
simple enough but in the real world it brings a high cost in terms of the money
and time it takes to implement. Very often there are also technological
limitations to upgrading to a higher bandwidth.
n Another option is to classify traffic into QoS classes and prioritize it according
to importance (business-critical traffic should get enough bandwidth, voice
should get enough bandwidth and prioritized forwarding and the least important
traffic should get the remaining bandwidth). There are a wide variety of
mechanisms available in the Cisco IOS that provide bandwidth guarantees, for
example:
– Priority or Custom Queuing
– Modified Deficit Round Robin (on Cisco 12000 series routers)
– Distributed ToS-based and QoS-group-based Weighted Fair Queuing (on
Cisco 7x00 series routers)
– Class-based Weighted Fair Queuing
n Optimizing link usage by compressing the payload of frames (virtually)
increases the link bandwidth. Compression, on the other hand, also increases
delay due to complexity of compression algorithms. Using hardware
compression can accelerate the compression of packet payloads. Stacker and
Predictor are two compression algorithms available in Cisco IOS.
n Another link efficiency mechanism is header compression. This mechanism is
especially effective in networks where most packets carry small amounts of

data (payload-to-header ratio is small). Typical examples of header
compression are TCP Header Compression and RTP Header Compression.

How to Reduce Delay?

cRTP data
Compress
the Headers
IP UDP RTP data Fancy

FIFO queuing
queuing
Compress
the Payload
Priority Queuing (PQ)
Custom Queuing (CQ)
Stacker Strict Priority MDRR
Compressed packet
Predictor IP RTP prioritization
Class-based Low-latency Queuing (CB-LLQ)
• Forward the important packets first.
• Compress the payload of layer-2 frames (it takes time).
• Compress the header of IP packets.
Assuming that a router is powerful enough to make a forwarding decision in a

negligible time it can be said that most of the processing, queuing delay and
propagation delay is influenced by the following factors:
n Average length of the queue
n Average length of packets in the queue
n Link bandwidth
There are several approaches to accelerate packet dispatching of delay-sensitive
flows:
n Increase link capacity. Enough bandwidth causes queues to shrink, making sure
packets do not have to wait long before they can be transmitted. Additionally,
more bandwidth reduces serialization time. On the other hand, this might be an
unrealistic approach due to the costs associated with the upgrade.
n A more cost-effective approach is to enable a queuing mechanism that can give
priority to delay-sensitive packets by forwarding them ahead of other packets.
There are a wide variety of queuing mechanisms available in Cisco IOS that
have pre-emptive queuing capabilities, for example:
– Priority Queuing
– Custom Queuing
– Strict-priority or Alternate Priority queuing within the Modified Deficit
Round Robin (on Cisco 12000 series routers)
– IP RTP prioritization
– Class-based Low-latency Queuing

n Payload compression reduces the size of packets and, therefore, virtually
increases link bandwidth. Additionally, compressed packets are smaller and
need less time to be transmitted. On the other hand, compression uses complex
algorithms that take time and add to the delay. This approach is, therefore, not
used to provide low-delay propagation of packets.
n Header compression on the other hand is not as CPU-intensive and can be used
in combination with other mechanisms to reduce delay. It is especially useful for
voice packets that have a bad payload-to-header ratio, which is improved by
reducing the header of the packet (RTP header compression).
By minimizing delay, jitter is also reduced (delay is more predictable).

How to Prevent Packet Loss?
Weighted Random Early Detection (WRED)
IP data Dropper Fancy

FIFO queuing
queuing
Custom Queuing (CQ)

Modified Deficit Round Robin (MDRR)
Class -based Weighted Fair Queuing (CB-WFQ)
• Guarantee enough bandwidth to sensitive packets.
• Prevent congestion by randomly dropping less important packets
before congestion occurs
Packet loss is usually a result of congestion on an interface. Most applications that

use TCP experience slow down due to TCP adjusting to the network’s resources
(dropped TCP segments cause TCP sessions to reduce their window sizes). There
are some other applications that do not use TCP and cannot handle drops (fragile
flows).
The following approaches can be taken to prevent drops of sensitive applications:
n Increased link capacity to ease or prevent congestion.
n Guarantee enough bandwidth and increase buffer space to accommodate bursts
of fragile applications. There are several mechanisms available in Cisco IOS
that can guarantee bandwidth and/or provide prioritized forwarding to drop-
sensitive applications, for example:
– Priority Queuing
– Custom Queuing
– Modified Deficit Round Robin (on Cisco 12000 series routers)
– IP RTP prioritization
– Class-based Weighted Fair Queuing
– Class-based Low-latency Queuing
n Prevent congestion by dropping other packets before congestion occurs.
Weighted Random Early Detection can be used to start dropping other packets
before congestion occurs.
There are some other mechanisms that can also be used to prevent congestion:
n Traffic Shaping delays packets instead of dropping them (Generic Traffic
Shaping, Frame Relay Traffic Shaping and Class-based Shaping).

n Traffic Policing can limit the rate of less important packets to provide better
service to drop-sensitive packets (Committed Access Rate and Class-based
Policing).

Which Applications Have Which
QoS Requirements?
Throughput Delay Loss

Loss Jitter
Interactive Not
Low Low Low
(e.g. Telnet) Important
Batch (e.g. Not Not
High
High Low
FTP) Important Important
Fragile (e.g. Low Low None Not
SNA) Important
Voice Low Low and Low Low

Predictable
Low and
Video High
High Low Low
Predictable
• Enterprise networks are typically focused on

providing QoS to applications
When QoS is considered in a network implementation, important applications and

their QoS requirements have to be identified. The figure illustrates a table of
different types of applications with the corresponding QoS requirements
(throughput or bandwidth, delay, loss and jitter).
Once the applications are identified and prioritized it must be decided which QoS
mechanisms are to be put in place.
The approach to provide QoS to applications is usually used in Enterprise
Networks where important (business-critical) applications are easy to identify.
Most applications can be classified based on TCP or UDP port numbers. Some
applications use dynamic port numbers that, somewhat, makes classification more
difficult. Cisco IOS supports Network-based Application Recognition (NBAR),
which can be used for such application.

Which Services can be
Implemented in a Network?
Throughput Delay Loss

Loss Jitter
Gold Guaranteed Low Low Low
No No No
Silver
Silver Guaranteed Guarantee Guarantee Guarantee
Bronze Guaranteed No No No
Limitted Guarantee Guarantee Guarantee
Best Effort No No No No
Guarantee Guarantee Guarantee Guarantee
... . . .. . . .. . . .. . . ..
• Service provider networks typically offer services

based on source and destination addresses
Service providers, on the other hand, are there to provide connectivity to

customers. They typically are not concerned with the applications that customers
are using. They are, however, interested in providing different levels of services to
customers. Some customers are willing to pay more for their connectivity to the
Internet, providing they obtain some guarantees. The figure illustrates one of the
many different approaches to defining services. In reality, each service provider
creates its own list of services according to market research and competitive
needs. Cisco IOS is simply the tool used to implement those services.

How can QoS be Applied?
• Best effort – no QoS is applied to packets

(default behavior)
• Integrated Services model – applications
signal to the network that they require
special QoS
• Differentiated Services model – the network
recognizes classes that requires special QoS
By investigating the history of the Internet it can be divided into three QoS-related
periods:
n Best-effort. The Internet was designed for best-effort, no-guarantee delivery
of packets. This behavior is still predominant in today’s Internet.
n Integrated Services model. Introduced to supplement the best-effort delivery
by setting aside some bandwidth for applications that require bandwidth and
delay guarantees. The Integrated Services model expects applications to signal
their requirements to the network. Resource Reservation Protocol (RSVP) is
used to signal QoS requirements to the network.
n Differentiated Services model. Added to provide more scalability in
providing QoS to IP packets. The main difference is that the network
recognizes packets (no signaling is needed) and provides the appropriate
services to them.
Today’s IP networks can use all three models at the same time.

Summary
IP Quality of Service is used to improve performance of IP networks. Quality of
Service can be measured based on available bandwidth, end-to-end delay, packet
loss and jitter. Different QoS mechanisms can be used to provide a predictable
service.
There are many different types of QoS mechanisms available in the Cisco IOS:
n Queuing mechanisms: Priority Queuing (PQ), Custom Queuing (CQ),
Weighted Fair Queuing (WFQ) with its distributed versions, IP RTP
Prioritization, Modified Deficit Round Robin (MDRR), Class-based Weighted
Fair Queuing (CB-WFQ) and Class-based Low-latency Queuing (CB-LLQ)
n Traffic Shaping mechanisms: Generic Traffic Shaping (GTS), Frame Relay
Traffic Shaping (FRTS) and Class-based Shaping
n Traffic Policing mechanisms: Committed Access Rate (CAR) and Class-
based Policing
n Dropping mechanisms: Weighted Random Early Detection (WRED)
n Link Efficiency mechanisms: Stacker, Predictor, TCP Header Compression
and RTP Header Compression
n Signaling mechanism: Resource Reservation Protocol (RSVP)
Review Questions
Answer the following questions:
n What are the relevant parameters that define the quality of service?
n What can be done to give more bandwidth to an application?
n What can be done to reduce delay?
n What can be done to prevent packet loss?
n Name the three QoS models?

Integrated Services Model
Objectives
n Describe the IntServ model
n List the key benefits and drawbacks of the IntServ model
n List some implementations that are based on the IntServ model
n Describe the need for Common Open Policy Service (COPS)

Integrated Services
• The Internet was initially based on a best-

effort packet delivery service
• Today's Internet carries many more different
applications than 20 years ago
• Some applications have special bandwidth
and/or delay requirements
• The Integrated Services model (RFC1633)
was introduced to guarantee a predictable
behavior of the network for these
applications
The Internet Engineering Task Force (IETF) is responsible for standardization of

the Internet and most of the protocols used in the Internet. When faced with a
challenge, vendors introduce their own solutions. However, the IETF is there to
create standards that allow different vendor’s equipment to interoperate. One of
the challenges in the past was to introduce Quality of Service into the best-effort
driven Internet. The Integrated Services (IntServ) model was proposed as standard
with Resource Reservation Protocol (RSVP) as the mechanism used to signal QoS
requirements to the network.
The IntServ model is described in the RFC 1633
(http://www.ietf.org/rfc/rfc1633.txt).
The use of RSVP for Integrated Services is described in RFC 2210
(http://www.ie tf.org/rfc/rfc2210.txt).

IntServ Building Blocks
Local Remote Admission Local

Admission Control Admission
Control Control
Policy Enforcement
Point (PEP)
request request request request
reserve reserve reserve reserve
request
reply
Policy Decision
Point (PDP)
• Resource Reservation is used to identify an application (flow)

and signal if there are enough available resources for it
• Admission Control is used to determine if the application (flow)
can get the requested resources
The IntServ model itself describes the application of QoS in IP networks.

Additional standards were developed to cover the exact protocols used to
implement Quality of Service:
n Resource Reservation is implemented using the Resource Reservation Protocol
(RSVP)
n Admission Control is either implemented locally on the routers or offloaded to
central servers
Common Open Policy Service (COPS) is another IETF standard that defines a
protocol that can be used for policy exchange between network devices (Policy
Enforcement Point or PEP) and policy servers (Policy Decision Point or PDP).
An additional standard was added to integrate RSVP with COPS.
The COPS (Common Open Policy Service) Protocol is defined in RFC 2748
(http://www.rfc-editor.org/rfc/rfc2748.txt).
COPS usage for RSVP is defined in RFC 2749
(http://www.rfc-editor.org/rfc/rfc2749.txt).

Reservation and Admission
Protocols
• The resource ReSerVation Protocol (RSVP)

was developed to communicate resource
needs between hosts and network devices
(RFC 2205-2215)
• Common Open Policy Service (COPS) was
developed to offload admission control to a
central policy server (RFC 2748-2753)
Following is a list of some of the IETF standards (RFCs) that describe RSVP,
COPS, the IntServ model and applications:
n Resource ReSerVation Protocol (RSVP), Version 1, Functional Specification
(http://www.ietf.org/rfc/rfc2205.txt)
n RSVP Management Information Base using SMIv2
n RSVP Extensions for IPSEC Data Flows (http://www.ietf.org/rfc/rfc2207.txt)
n Resource ReSerVation Protocol (RSVP), Version 1, Applicability Statement,
Some Guidelines on Deployment (http://www.ietf.org/rfc/rfc2208.txt)
n Resource ReSerVation Protocol (RSVP), Version 1, Message Processing
Rules (http://www.ietf.org/rfc/rfc2209.txt)
n The Use of RSVP with IETF Integrated Services
n Specification of the Controlled-Load Network Element Service
n Specification of Guaranteed Quality of Service
n Integrated Services Management Information Base using SMIv2
n Integrated Services Management Information Base, Guaranteed Service
Extensions using SMIv2 (http://www.ietf.org/rfc/rfc2214.txt)
n General Characterization Parameters for Integrated Service Network Elements

n The COPS (Common Open Policy Service) Protocol
n COPS usage for RSVP (http://www.ietf.org/rfc/rfc2749.txt)
n RSVP Extensions for Policy Control (http://www.ietf.org/rfc/rfc2750.txt)
n Signaled Preemption Priority Policy Element
n Identity Representation for RSVP (http://www.ietf.org/rfc/rfc2752.txt)
n A Framework for Policy-based Admission Control
(http://www.ie tf.org/rfc/rfc2753.txt)
n SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission
Control over IEEE 802-style networks (http://www.ietf.org/rfc/rfc2814.txt)
n Definitions of Managed Objects for Common Open Policy Service (COPS)
Protocol Clients (http://www.ietf.org/rfc/rfc2940.txt)
n COPS Usage for Policy Provisioning (COPS-PR)

RSVP-enabled Applications
• RSVP is typically used by applications

carrying voice or video over IP networks
(initiated by a host)
• RSVP with extensions is also used by MPLS
Traffic Engineering to establish MPLS/TE
tunnels (initiated by a router)
RSVP, as a resource reservation protocol, was designed for use by end devices in
networks (for example, personal computers and servers). It is a protocol that has
to be supported by an application that requires network resources and needs
guarantees.
n Typical examples of applications that would benefit from RSVP are voice
sessions that require a small amount of bandwidth with low-delay propagation.
n Cisco routers that act as voice gateways can use RSVP to request resources
(controlled-load and guaranteed-delay).
n Cisco routers that use Multiprotocol Label Switching (MPLS) Traffic
Engineering (MPLS/TE) use RSVP with extensions to reserve bandwidth and
set up MPLS/TE tunnels through MPLS and RSVP enabled networks.
n Cisco Soft Phone or Microsoft NetMeeting are Windows applications that use
RSVP to get resources for their VoIP sessions.
There are an increasing number of applications that use RSVP to request QoS
guarantees from a network.

IntServ Implementation Options
RSVP
1) Explicit RSVP on each network node
Class of Service
or
Best Effort
2) RSVP ‘pass -through’ and CoS transport
- map RSVP to CoS at network edge
- pass -through RSVP request to egress
3) RSVP at network edges and ‘pass -through’ with
- best-effort forwarding in the core (if there is
enough bandwidth in the core)
The figure illustrates three options available when implementing QoS mechanisms
via RSVP in a network.
1. The first option is to simply enable RSVP on all interfaces of all the routers in
the network. This approach is mainly used in enterprise networks that have
more predictable RSVP flows (in terms of quantity and direction because they
typically use hub-and-spoke topology). Large service provider networks are
less inclined to use RSVP throughout their networks either because RSVP
would require too many concurrent reservations on a single interface or
because the routers are not capable of providing guarantees to individual flows
on high-bandwidth interfaces.
2. An alternative option is to use RSVP on network edges where there is
typically less bandwidth per interface and congestion is more likely. The edge-
to-core routers (for example, access or distribution layer routers) mark RSVP
flows with IP markers, which can then be used in a DiffServ enabled core—
the Differentiated Services model is covered in the next lesson).
3. Another option is to use RSVP on network edges and rely on best-effort
delivery in a non-congested core.

Explicit RSVP Transport
IntServ End-to-End
RSVP
All Routers
• WFQ applied per flow
based on RSVP requests
In the first scenario, each router in the network processes RSVP messages and
keeps track of the special resource needs for each individual RSVP flow.
Weighted Fair Queuing (WFQ) can be used in the backbone to provide resource
allocation on a flow-by-flow basis.
One concern with this approach is that RSVP is resource intensive on backbone
routers - in terms of the amount of signaling and the amount of special information
that they need to keep on each RSVP flow.
A second issue is that WFQ is a very CPU-intensive algorithm and does not run at
high speed on today’s routers. In the backbone, high speed is a mandatory
requirement.

RSVP Pass-Through
IntServ - DiffServ Integration
RSVP RSVP
Precedence
Classifier
WRED
Premium Egress Router
Standard
• RSVP protocol
sent on to destination
Ingress Router • WFQ applied to
• RSVP protocol manage egress flow
Mapped to classes
Passed through to egress Backbone
• WRED applied based
on class
An alternative to enabling RSVP end-to-end is to use RSVP as a means to signal

special requirements between the customer and the ISP edge, but not to use it in
the backbone. In this model, packets are mapped on RSVP flows into special
service classes which give each class preferential treatment in the core of the
network when congestion occurs. This avoids the scalability problem of end-to-end
RSVP, since these flows are processed between the end station and the network
edge and not in the middle of the backbone.
By using WRED on routers, instead of WFQ, much higher speeds can be
supported. Alternatively, Class-based WFQ can be used on moderate-speed links
to provide better control of bandwidth allocation. The third option is not to use
RSVP in the core and rely on best-effort delivery if the core is not congested.
Lastly, mapping classes of service to ATM is more straightforward than mapping
RSVP directly to ATM.
This concept may accelerate the ability of ISPs to offer an RSVP service and
enable new application areas.

IntServ Support in IOS
• RSVP and Weighted Fair Queuing supported

since ’95
• RSVP signaling for VoIP calls supported on
all VoIP platforms
• IOS supports hop-by-hop and pass-through
RSVP
• RSVP-to-DSCP (DiffServ Code Point)
mapping (RSVP proxy) in 12.1T
Both RSVP and WFQ have been available for some time and can be used on all
low-end platforms and on high-end platforms that are typically used to concentrate
customer networks.
Newer RSVP mechanisms include:
n Mapping of RSVP to DSCP (the Differentiated Services model with the details
of the DiffServ Code point is covered in the next lesson).
n Mapping of RSVP to ATM SVCs (this technology is covered in the “IP QoS -
IP over ATM” module).

Benefits and Drawbacks of the
IntServ Model
+ RSVP benefits:
• Explicit resource admission control (end to end)
• Per-request policy admission control
(authorization object, policy object)
• Signaling of dynamic port numbers (for example,
H.323)
–RSVP drawbacks:
• Continuous signaling due to stateless architecture
• Not scalable
The main benefits of RSVP are:

n It signals QoS requests per individual flow. The network can then provide
guarantees to these individual flows. The problem of this is that it does not scale
to large networks because of the large numbers of concurrent RSVP flows.
n It informs network devices of flow parameters (IP addresses and port
numbers). Some applications use dynamic port numbers, which can be difficult
for network devices to recognize. NBAR is a mechanism that has been
introduced to supplement RSVP for applications that use dynamic port numbers
but do not use RSVP.
It supports admission control that allows a network to reject (or down-grade) new
RSVP sessions if one of the interfaces in the path has reached the limit (all
reservable bandwidth is booked).
The main drawbacks of RSVP are:
n Continuous signaling due to stateless operation of RSVP.
n RSVP is not scalable to large networks where per-flow guarantees would have
to be made to thousands of flows.

Common Open Policy Service
• Common Open Policy Service (COPS)

provides the following benefits when used
with RSVP:
– Centralized management of services
– Centralized admission control and authorization of
RSVP flows
• RSVP-based QoS solutions become more
scalable
The Common Open Policy Service (COPS) is an add-on to RSVP. It can be used
to offload certain tasks from network devices to a central server. The result is that
the configuration of individual devices is more standardized (template-based) and
all individual parameters are managed from a centralized location. In addition,
COPS supports admission control of individual flows (the network device
determines the available resources and the central server authorizes the flow).

Summary
The Integrated Services (IntServ) model was introduced to allow vendors of
routers to add interoperable QoS mechanisms to their best-effort packet
forwarding. Resource Reservation Protocol (RSVP) is used by end-devices to
signal QoS requirements to the network. Common Open Policy Service (COPS) is
used to offload policy management to central servers.
Review Questions
n What are the two building blocks of the Integrated Services model?
n Which protocol is used to signal QoS requirements to the network?

Differentiated Services Model
Objectives
n Describe the DiffServ model
n List the key benefits of the DiffServ model compared to the IntServ model
n Describe the purpose of the DS field in IP headers
n Describe the interoperability between DSCP-based and IP-precedence-based
devices in a network
n Describe the Expedited Forwarding service
n Describe the Assured Forwarding service

• Differentiated Services model describes

services associated with traffic classes
• Complex traffic classification and
conditioning is performed at network edge
resulting in a per-packet Differentiated
Services Code Point (DSCP).
• No per-flow/per-application state in the core
• Core only performs simple ‘per-hop
behavior's’ on traffic aggregates
• Goal is Scalability
The Differentiated Services (DiffServ) model describes services associated

with traffic classes. Traffic classes are identified by the value of the DiffServ
Code Point (DSCP replaces IP precedence in the ToS field of the IP header).
The main goals of the DiffServ model are to provide scalability and a similar level
of QoS to the IntServ model, without having to do it on a per-flow basis. The
network simply identifies a class (not application) and applies the appropriate per-
hop behavior (QoS mechanism).
The DiffServ model and associated standards are described in the following IETF
standardization documents (RFCs):
n An Architecture for Differentiated Services
n Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers (http://www.ietf.org/rfc/rfc2474.txt)
n Assured Forwarding per-hop behavior (PHB) Group
n An Expedited Forwarding per-hop behavior (PHB)

Additional Requirements
• Wide variety of services and provisioning

policies
• Decouple service and application in use
• No application modification
• No hop-by-hop signaling
• Interoperability with non-DS-compliant nodes
• Incremental deployment
The DiffServ model describes services and allows for more user-defined services
to be used in a DiffServ-enabled network.
Services are provided to classes. A class can be identified as a single application
or, as in most cases, it can be identified based on source or destination IP address.
The idea is for the network to recognize a class without having to receive any
request from applications. This allows the QoS mechanisms to be applied to other
applications that do not have the RSVP functionality, which is the case for 99% of
applications that use IP.
The introduction of the DiffServ Code Point (DSCP) replaces the IP precedence
but maintains interoperability with non-DS compliant devices (those that still use IP
precedence). Because of this backward-compatibility DiffServ can be gradually
deployed in large networks.

DiffServ Elements
• The service defines QoS requirements and

guarantees provided to a traffic aggregate;
• The conditioning functions and per-hop behaviors
are used to realize services;
• The DS field value (DS code point) is used to mark
packets to select a per-hop behavior
• Per-hop Behavior (PHB) is realized using a particular
QoS mechanism
• Provisioning is used to allocate resources to traffic
classes
A traffic aggregate is a collection of all flows that require the same service. A
service is implemented using different QoS mechanisms (a QoS mechanism
implements a per-hop behavior).
The DiffServ field (DS fie ld) is the former 8-bit Type of Service field. The main
difference is that the DSCP supports more classes (64) than IP precedence (8).
The most important part of designing QoS is to provision services as explained on
the next page.

Why is Provisioning Important?
• QoS does not create bandwidth!

• QoS manages bandwidth usage among
multiple classes
• QoS gives better service to a well-
provisioned class with respect to another
class
Provisioning requires a thorough network analysis to determine parameters for

services that are being deployed in the network. The result of provisioning is the
allocation of bandwidth among all classes in times of congestion.
Services are implemented by defining per-hop behavior (PHB) properties. PHBs
are implemented by using the available QoS mechanisms in networks devices.

Topological Terminology
DS interior node
DS Egress
DS Ingress Boundary node
Boundary node
Boundary link
Upstream
DS domain Downstream
DS domain
DS region
Traffic Stream = set of flows
Behaviour Aggregate (flows with the same DSCP)
A DS domain consists of DS boundary nodes and DS interior nodes. DS

boundary nodes interconnect the DS domain to other DS or non-DS-capable
domains. While DS interior nodes only connect to other DS interior or boundary
nodes within the same DS domain. Both DS boundary nodes and interior nodes
must be able to apply the appropriate PHB to packets based on the DS code
point; otherwise unpredictable behaviour may result.
DS boundary nodes act both as a DS ingress node and as a DS egress node for
traffic traversing the network in different directions. Traffic enters a DS domain at
a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress
node is responsible for ensuring that the traffic entering the DS domain conforms
to any Traffic Conditioning Agreement (TCA) between it and the other domain
to which the ingress node is connected. A DS egress node may perform traffic
conditioning functions on traffic forwarded to a directly connected peering domain,
depending on the details of the TCA between the two domains.
A differentiated services region (DS Region) is a set of one or more contiguous
DS domains. DS regions are capable of supporting differentiated services along
paths that span the domains within the region.
The DS domains in a DS region may support different PHB groups internally and
different code point-PHB mappings. However, to permit services that span across
the domains, the peering DS domains must each establish a peering Service
Level Agreement (SLA) that defines (either explicitly or implicitly) a TCA. The
TCA specifies how transit traffic from one DS domain to another is conditioned at
the boundary between the two DS domains.
It is possible that several DS domains within a DS region may adopt a common
service provisioning policy and may support a common set of PHB groups and

code point mappings. This eliminates the need for traffic conditioning between
those DS domains.

Traffic Terminology
• Flow: a single instance of an application-to-

application flow of packets which is identified by
source address, source port, destination address,
destination port and protocol id.
• Traffic stream: an administratively significant set of
one or more flows which traverse a path segment. A
traffic stream may consist of a set of active flows
which are selected by a particular classifier.
• Traffic profile: a description of the temporal
properties of a traffic stream such as average and
peak rate and burst size.
The terminology used throughout the course includes the following:

n Flow (or microflow) is a sequence of packets identified by source and
destination IP addresses, protocol identifier (for example, TCP and UDP) and
source and destination port numbers.
n Traffic stream is a collection of flows with a common set of parameters (for
example, the same port number and the same source and destination network).
n Traffic profile specifies typical properties of a traffic stream (average rate and
burstiness). Provisioning should be performed based on traffic profiles and the
importance of traffic streams.

Traffic Terminology
• Behavior Aggregate (BA) is a collection of

packets with the same DS code point
crossing a link in a particular direction.
• Per-Hop Behavior (queuing in a node)
externally observable forwarding behavior
applied at a DS-compliant node to a DS
behavior aggregate.
• PHB Mechanism: a specific algorithm or
operation (e.g., queuing discipline) that is
implemented in a node to realize a set of one
or more per-hop behaviors.
Other important terms used throughout the course are:

n Behavior Aggregate (BA) identifies packets marked with the same DSCP
n Per-hop Behavior (PHB) is applied to each BA according to the QoS policy
n PHB mechanism is the actual QoS mechanism that satisfies PHB specification
Other terms can be found in RFC 2475, which defines the Differentiated Services
model (http://www.ie tf.org/rfc/rfc2475.txt).

Packet Header Terminology
DSCP field: 6bits Unused: 2bits
Former ToS byte = new DS field
• DS code point: a specific value of the DSCP portion

of the DS field, used to select a PHB (Per-Hop
Behavior; forwarding and queuing method)
• DS field: the IPv4 header ToS octet or the IPv6 Traffic
Class octet when interpreted in conformance with
the definition given in RFC2474. The bits of the
DSCP field encode the DS code point, while the
remaining bits are currently unused.
The DiffServ model uses the DS field in the IP header to mark packets according
to their classification into Behavior Aggregates (BAs). The DS field occupies the
same eight bits of the IP header that were previously used for the Type of Service
(ToS) field.
There are three IETF standards describing the purpose of those eight bits:
n RFC 791 includes specification of the ToS field where the high-order three bits
are used for IP precedence. The other bits are used for delay, throughput,
reliability and cost.
n RFC 1812 modifies the meaning of the ToS field by removing any meaning
from the five low-order bits (those bits should all be zero).
n RFC 2474 replaces the ToS field with the DS field where the six high-order bits
are used for the DiffServ Code Point (DSCP). The remaining two bits are
currently not used.
Each DSCP value identifies a Behavior Aggregate (BA). Each BA is assigned a
per-hop behavior (PHB). Each PHB is implemented using the appropriate QoS
mechanism or a set of QoS mechanisms.

DSCP Encoding
• Three pools:
– “xxxxx0” Standard Action
– “xxxx11” Experimental/Local Use
– “xxxx01” EXP/LU (possible std action)
• Default DSCP: “000000”
• Default PHB: FIFO, tail-drop
Unlike IP precedence, which lacked any standard definitions of values and

corresponding PHBs, the DSCP has half of its value range reserved for standard
defined PHBs.
The low-order bit of the DSCP identifies whether the DSCP value identifies a
standard action (PHB) or a user-defined action.
The second bit could, potentially, (in the future) also be used to identify additional
standard actions.
The default value of DSCP is 0. The associated PHB is FIFO service with a
tail-drop. FIFO queuing is discussed in the “IP QoS – Queuing mechanisms
module”.
The default DSCP value seamlessly maps to the default IP precedence value,
which is also 0 according to RFC 1812.

DSCP Usage
DS Code point selects per-hop behavior

(PHB) throughout the network
• Default PHB
• Class Selector (IP precedence) PHB
• Expedited Forwarding (EF) PHB
• Assured Forwarding (AF) PHB
The following per-hop behaviors are defined by IETF standards:

n Default PHB – used for best-effort service
n Class Selector PHB – used for backward compatibility with non-DS
compliant devices (RFC 1812 compliant devices and, optionally, RFC 791
compliant devices)
n Expedited Forwarding PHB – used for low-delay service
n Assured Forwarding PHB – used for guaranteed bandwidth service
The Default PHB and the Class Selector PHB are described in RFC 2474
(http://www.ietf.org/rfc/rfc2474.txt), Expedited Forwarding PHB is described in
RFC 2598 (http://www.ietf.org/rfc/rfc2598.txt) and Assured Forwarding in
RFC 2597 (http://www.ietf.org/rfc/rfc2597.txt).

Backward Compatibility Using the
Class Selector
• Non-DS compliant node: node that does not

interpret the DSCP correctly or that does not
support all the standardized PHB’s
• Legacy node: a non-DS compliant node that
interprets IPv4 ToS such as defined by
RFC791 and RFC1812.
• DSCP is backward compatible with IP
Precedence (Class Selector Code point, RFC
1812) but not with the ToS byte definition
from RFC 791 (“DTR” bits)
The history of the eight bits in question (ToS field alias DS field) can be divided
into three periods according to the RFCs describing the purpose of those bits:
RFC 791
RFC 791 defines the Type of Service field with the following components:
n Bits seven, six and five are used for IP precedence
n Bit four is used for delay (0 = Normal Delay, 1 = Low Delay)
n Bit three is used for throughput (0 = Normal Throughput, 1 = High
Throughput)
n Bit two is used for reliability (0 = Normal Reliability, 1 = High Reliability)
n Bits one and zero are not used and should be zero (bit one was later applied a
meaning of monetary-cost by RFC 1349; this RFC also replaces individual bits
with a four-bit ToS value to allow more types of services)
RFC 1812
RFC 1812 loosens the strict representation of the ToS field (obsole tes RFC 795).
RFC 2474
RFC 2474 replaces the ToS field with the DS field where a range of eight values
(Class Selector) is used for backward compatibility with IP precedence. There is
no compatibility with the delay, throughput, reliability and monetary-cost bits.

Class Selector Code Point
• Compatibility with current IP precedence

usage (RFC 1812)
• “xxx000” DS code points
• Differentiates probability of timely forwarding
(PTF)
– PTF (xyz000) >= PTF(abc000) if xyz > abc
RFC 1812 simply prioritizes packets according to the precedence value. The PHB
is defined as the probability of timely forwarding. Packets with higher IP
precedence should (on the average) be forwarded in less time than packets with
lower IP precedence.
RFC 2474 adopts this set of PHBs and values by creating the Class Selector PHB
group. Class Selector can be identified by the low-order three bits of the DSCP or
low-order five bits of the DS field: all bits are zero.

Expedited Forwarding
• Expedited Forwarding (EF) PHB:

– Ensures a minimum departure rate
– Guarantees bandwidth – the class is guaranteed
an amount of bandwidth with prioritized
forwarding
– Polices bandwidth – the class is not allowed to
exceed the guaranteed amount (excess traffic is
dropped)
• DSCP value: “101110”; looks like IP precedence 5 to
non-DS compliant devices
The Expedited Forwarding PHB is identified based on the following parameters:

n Ensures a minimum departure rate to provide the lowest possible delay to
delay-sensitive applications
n Guarantees bandwidth to prevent starvation of the application if there are
multiple applications using Expedited Forwarding PHB
n Polices bandwidth to prevent starvation of other applications or classes that
are not using this PHB
n Packets requiring Expedited Forwarding should be marked with DSCP binary
value “101110” (46 or 0x2E)
Non-DS compliant devices will regard EF DSCP value as IP precedence 5 (101),
which is the highest user-definable IP precedence and is typically used for
delay-sensitive traffic such as Voice over IP.

IOS EF PHB Implementations
• Priority Queuing
• IP RTP Prioritization
• Class-based Low-latency Queuing (CB-LLQ)
• Strict Priority queuing within Modified Deficit
Round Robin (MDRR) on GSR
Expedited Forwarding PHB can be implemented on Cisco routers using several

different QoS mechanisms:
n Routers running older Cisco IOS versions can use Priority Queuing (PQ) and
put delay-sensitive traffic into a “high” priority queue. Priority Queuing,
however, does not fully comply with the specification of the EF PHB – it does
not have the capability to police the bandwidth used by the EF class.
n IP RTP Prioritization can be used in combination with Weighted Fair Queuing
(WFQ) or Class-based Weighted Fair Queuing (CB-WFQ). IP RTP
Prioritization provides expedited forwarding with bandwidth guarantee and
bandwidth policing.
n Class-based Low-latency Queuing (CB-LLQ) is a mechanism similar to IP
RTP Prioritization. It is the preferred mechanism for implementing EF PHB.
n Strict Priority within Modified Deficit Round Robin (MDRR) on the Cisco
12000 series routers provides low-latency queuing but does not police
bandwidth. Alternate Priority MDRR prevents starvation of other classes but
it does not police bandwidth of the EF class.

Assured Forwarding
• Assured Forwarding (AF) PHB:

–Guarantees bandwidth
–Allows access to extra bandwidth if
available
• Four standard classes (af1, af2, af3 and af4)
• DSCP value range: “aaadd0” where “aaa” is
a binary value of the class and “dd” is drop
probability
The Assured Forwarding PHB is identified based on the following parameters:

n Guarantees a certain amount of bandwidth to an AF class
n Allows access to extra bandwidth, if available
n Packets requiring AF PHB should be marked with DSCP value “aaadd0”
where “aaa” is the number of the class and “dd” is the drop probability
There are four standard-defined AF classes. Each class should be treated
independently and have bandwidth allocated based on the QoS policy.

AF Encoding
Class Value Drop Value

Probability
AF1 001dd0 (dd)
Low 01
AF2 010dd0 Medium 10
AF3 011dd0 High 11
AF4 100dd0
• Each AF class uses three DSCP values
• Each AF class is independently forwarded with its
guaranteed bandwidth
• Differentiated RED is used within each class to
prevent congestion within the class
As the figure illustrates there are three DSCP values assigned to each of the four
AF classes.
Assured Forwarding class Drop Probability DSCP value
AF class 1 Low 001 01 0
Medium 001 10 0
High 001 11 0
Medium 010 10 0
High 010 11 0
Medium 011 10 0
High 011 11 0
Medium 100 10 0
High 100 11 0

AF PHB Definition
• A DS node MUST allocate a configurable,

minimum amount of forwarding resources
(buffer space and bandwidth) per AF class
• Excess resources may be allocated between
non-idle classes. The manner must be
specified.
• Reordering of IP packets of the same flow is
not allowed if they belong to the same AF
class
An AF implementation must attempt to minimize long-term congestion within each

class, while allowing short-term congestion resulting from bursts. This requires an
active queue management algorithm. An example of such an algorithm is Weighted
Random Early Detection (WRED).
The AF specification does not define the use of a particular algorithm, but does
require that several properties hold.
An AF implementation must detect and respond to long-term congestion within
each cla ss by dropping packets, while handling short-term congestion (packet
bursts) by queuing packets. This implies the presence of a smoothing or
filtering function that monitors the instantaneous congestion level and
computes a smoothed congestion level. The dropping algorithm uses this
smoothed congestion level to determine when packets should be discarded.
The dropping algorithm must treat all packets within a single class and precedence
level identically. This implies that, for any given smoothed congestion level, the
discard rate of a particular microflow's packets within a single precedence level
will be proportional to that flow's percentage of the total amount of traffic passing
through that precedence level.
The congestion indication feedback to the end nodes, and thus the level of packet
discard at each drop precedence in relation to congestion, must be gradual rather
than abrupt. This allows the overall system to reach a stable operating point.
WRED uses two (configurable) smoothed congestion level thresholds. When the
smoothed congestion level is below the first threshold, no packets of the relevant
drop precedence are discarded. When the smoothed congestion level is between
the first and the second threshold, packets are discarded with linearly increasing
probability, ranging from zero to a configurable value reached just prior to the
second threshold. When the smoothed congestion level is above the second

threshold, packets of the relevant drop precedence are discarded with 100%
probability.
To allow the AF PHB to be used in many different operating environments, the
dropping algorithm control parameters must be independently configurable for each
packet drop precedence and for each AF class. Within the limits above, this
specification allows for a range of packet discard behaviours.

AF PHB Implementation
• CBWFQ (4 classes) with WRED within each

class
• (M)DRR with WRED within each class
• Optionally Custom Queuing (does not
support differentiated dropping)
As with Expedited Forwarding there are multiple QoS mechanisms in the Cisco
IOS that can accommodate some or all of the requirements of Assured Forwarding
PHB:
n The preferred implementation is to use the Class-based Weighted Fair Queuing
(CB-WFQ) with four classes (four independent queues) and Weighted Random
Early Detection (WRED) within each queue.
n A similar solution can be provided on the Cisco 12000 series routers by using
the Modified Deficit Round Robin (MDRR) queuing with WRED in each
queue. The AF PHB can also be implemented using the old-fashioned IP
precedence. The only restriction is the number of available IP precedence
values.
n Example 1:
n Four classes but no differentiated dropping:
n AF1—IP precedence 1
n Example 2:
n Two classes with differentiated dropping (two drop precedence values):
n AF1—IP precedence 1 for high-drop, IP precedence 2 for low-drop
n AF1—IP precedence 3 for high-drop, IP precedence 4 for low-drop

n In both examples IP precedence 0 can be used for a best-effort class and IP
precedence 5 for an EF class.
n A similar solution as shown in Example 1 is also possible with Custom
Queuing, except it has no support for differentiated dropping and DSCP. A
workaround is possible if access-lists are used to match the DSCP value
(direct matching of DSCP available only in IOS 12.1 and above) with a
combination of IP precedence and ToS value.

Summary
After completing this lesson, you should be able to perform the following tasks:
n Describe the DiffServ model
n List the key benefits of the DiffServ model compared to the IntServ model
n Describe the purpose of the DS field in IP headers
n Describe the interoperability between DSCP-based and IP-precedence-based
devices in a network
n Describe the Expedited Forwarding service
n Describe the Assured Forwarding service
Review Questions
n What are the benefits of the DiffServ model compared to the IntServ model?
n What is a DiffServ Code Point?
n Name the standard PHBs?
n How was backward compatibility with IP precedence achieved?
n Describe the PHB of Assured Forwarding.
n Describe the PHB of Expedited Forwarding.

Building Blocks of IP QoS Mechanisms
Objectives
n Describe different classification options in IP networks
n Describe different marking options in IP networks
n List the mechanisms that are capable of measuring the rate of traffic
n List the mechanisms that are used for traffic conditioning, shaping and avoiding
congestion
n List the forwarding mechanisms available in Cisco IOS
n List the queuing mechanisms available in Cisco IOS

Router Functions
Defragmentation
Decompression (payload, header) Rate -limiting
Source -based qos-label/precedence setting Random dropping
Destination-based qos-label/precedence Shaping
setting Compression (payload, header)
Rate -limiting Fragmentation
Class -based marking Queuing and scheduling
Policy-based-routing ...
...
Input Output
Input I/O Forwarding Output I/O
Processing Processing
Process switching
Fast/optimum switching
Netflow switching
CEF switching
• Depending on the configuration, a router may perform a number of

actions prior to forwarding a packet (input processing)
• Depending on the configuration, a router may perform a number of
actions prior to enqueuing a packet in the hardware queue (output
processing)
Basic router function takes packets received on the input interface, makes a
forwarding decision and transmits the packet out through the output interface.
Today’s routers, however, can do much more than that. The figure lists a small
subset of features that affect packet processing on input or output interfaces.
Following is a list of some of the features available with Cisco routers:
n Payload compression (Stacker, Predictor)
n Header compression (TCP and RTP header compression)
n BGP-policy marking (CEF-based marking or QoS Policy propagation through
BGP)
n Traffic Policing (CAR, CB Policing)
n Traffic Shaping (GTS, FRTS, CB-Shaping)
n Class-based marking
n Encryption (CET or IPsec)
n WRED
n Policy-based Routing
n Accounting (IP accounting, NetFlow accounting)
n Filtering (access lists)
n Reverse-path checking
n Address and port translation (NAT, PAT)
n Stateful filtering (firewalling)
n Web-cache redirection

IP QoS Actions
• Classification – Each class-oriented QoS mechanism

has to support some type of classification (access
lists, route maps, class maps, etc.)
• Metering – Some mechanisms measure the rate of
traffic to enforce a certain policy (e.g. rate limiting,
shaping, scheduling, etc.)
• Dropping – Some mechanisms are used to drop
packets (e.g. random early detection)
• Policing – Some mechanisms are used to enforce a
rate limit based on the metering (excess traffic is
dropped)
• Shaping – Some mechanisms are used to enforce a
rate limit based on the metering (excess traffic is
delayed)
IP QoS mechanisms can perform different types of actions. All QoS mechanisms
can be divided into the following QoS actions:
n Classification – most QoS mechanisms support multiple classes. There are
different classification tools available with different QoS mechanisms (for
example, access lists, route maps, class maps and rate-limit access lists). Some
QoS mechanisms have the capability to match directly on certain parameters.
For example:
– CAR (QoS group and DSCP)
– WRED (IP precedence)
– ToS-based dWFQ (IP precedence)
– QoS-group-based dWFQ (QoS group)
– WFQ (flow parameters)
– PQ and CQ (interface, packet size and protocol)
n Some mechanisms require the information about traffic rate of classes (for
example, CAR, GTS, FRTS, CB-Shaping, CB-Policing, CB-WFQ, CB-LLQ,
MDRR and IP RTP Prioritization).
n Some mechanisms are used for dropping purposes. They utilize a dropping
scheme different from the usual tail-drop. WRED is an example of such
mechanism.
n Some mechanisms are used to limit traffic rate by dropping excess traffic
(CAR and CB-Policing).
n Some mechanisms are used to limit traffic rate by delaying excess traffic (GTS,
FRTS and CB-Shaping).

IP QoS Actions
• Marking – Some mechanisms have the capability to

mark packets based on classification and/or
metering (e.g. CAR, class-based marking, etc.)
• Queuing – Each interface has to have a queuing
mechanism
• Forwarding – There are several supported
forwarding mechanisms (process switching, fast
switching, CEF switching, etc.)
n Some mechanisms have the capability to mark packets with different types of
markers (IP precedence, DSCP, QoS group, MPLS experimental bits, ATM
CLP bit, Frame Relay DE bit and 802.1q or ISL priority/cos bits)
n Some mechanisms are used for queuing on output interfaces (for example,
FIFO, PQ, CQ, WFQ, dWFQ, ToS-based dWFQ, QoS-group-based dWFQ,
CB-WFQ, IP RTP Prioritization and MDRR)
n Cisco IOS also has different types of forwarding mechanisms (Process
Switching, Fast Switching, Optimum Switching, Silicon Switching, Autonomous
Switching, NetFlow Switching, Cisco Express Forwarding and Policy-based
routing)

DiffServ Mechanisms in IOS
Meter
Classifier Marker Conditioner Queuing

Inbound
traffic Shaping Scheduling
stream Dropping Dropping
• Most traditional QoS mechanisms include extensive built-in classifiers

– Committed Access Rate (CAR)
– QoS Policy Propagation via BGP (QPPB)
– Route-maps
– Queuing mechanisms
– ...
• Modular QoS CLI (first implemented in 12.0(5)T) separates classifier
from other actions
– Includes all traditional classifiers + Network Based Application Recognition
(NBAR)
Most QoS mechanisms include several different classification options. The

following table lists some QoS mechanisms with the corresponding classification
options.
QoS Mechanism Classification options
Committed Access Rate (CAR) Access list
Rate limit access list
QoS-group
DSCP
QoS Policy Propagation through BGP Route map
(QPPB)
Policy-based routing Route map
Generic Traffic Shaping Access list
Priority Queuing and Custom Queuing Access list
Packet size
Input interface
Protocol
All mechanisms available using the Class map which can use: another class
modular QoS CLI (CB-WFQ, CB-LLQ, map, access list, protocol (including
CB-Shaping, CB-Policing, CB-Marking) NBAR), input interface, source or
destination MAC address, IP
precedence, DSCP, QoS group, MPLS
experimental bits, etc.)

Meter

Inbound
• Token Bucket model is used for metering

– Generic Traffic Shaping (GTS)
– Frame Relay Traffic Shaping (FRTS)
– Class-based Weighted Fair Queuing (CB-WFQ)
– Class-based Low Latency Queuing (CB-LLQ)
– Class-based Policing
– Class-based Shaping
– IP RTP Prioritization
The figure lists QoS mechanisms in the Cisco IOS that have the capability to
measure the rate of traffic by using the Token Bucket model.

Meter

Inbound
• Marker is used to set: • Marking mechanisms:

– IP precedence – Comitted Access Rate (CAR)
– DSCP – QoS Policy Propagation
– QoS group through BGP (QPPB)
– MPLS experimental bits – Policy-based Routing (PBR)
– Frame Relay DE bit – Class-based Marking
– ATM CLP bit
– IEEE 802.1Q or ISL CoS
The figure lists markers that can be set using Cisco routers and the queuing
mechanisms that have marking capabilities.
The following table lists all the mechanisms that have marking capabilities and the
markers that are supported by those mechanisms.
QoS Mechanism Available markers
Committed Access Rate (CAR) IP precedence
DSCP
QoS group
MPLS experimental bits
QoS Policy Propagation through BGP IP precedence
(QPPB) QoS group
Policy-based Routing (PBR) IP precedence
QoS group
Class-based Marking IP precedence
DSCP
QoS group
ATM CLP bit
Frame Relay DE bit
802.1Q/ISL cos/priority

Comparison of Markers
Marker
Marker Preservation Value range
IP precedence Throught a network 8 values, 2 reserved

(0 to 7)
DSCP Throught a network 64 values, 32 are standard

(0 to 63)
QoS group
group Local to a router 100 values
(0 to 99)
Throughout an MPLS network
MPLS experimental
experimental bits
bits 8 values
(optionally throughout
throughout an
entire IP network)
Frame Relay DE bit Throughout a Frame Relay 2 values
network (0 or 1)
ATM CLP bit Throughout an ATM 2 values
network (0 or 1)
IEEE 802.1Q or
or ISL
ISL CoS
CoS Throughout a LAN 8 values
switched network (0 to 7)
The figure describes the differences between markers in terms of preservation of

the marker and a value range. Markers can:
n Be local to the router (the QoS group is not part of a packet or frame; it is a
piece of information attached to a packet while it is stored in the router’s
memory)
n Have a limited range due to layer-2 technology that they use (ATM CLP, FR
DE, 802.1q/ISL cos/priority, MPLS exp bits)
n Have an unlimited range (IP precedence, DSCP)

Meter

Inbound
• Shaping mechanisms:
– Hardware shaping on ATM VC
The figure lists four mechanisms that are used for traffic shaping purposes. All of
these mechanisms are implemented in software (Cisco IOS) except for ATM
shaping which is implemented in hardware.
Traffic shaping is used to limit the departure rate of packets, frames or cells by
delaying them if they exceed the contractual rate. A token bucket model is used to
measure the arrival rate and determine when packets can be forwarded.

Meter

Inbound
• Dropping mechanisms
– Committed Access Rate (CAR) and Class-based
Policing can drop packets that exceed the
contractual rate
– Weighted Random Early Detection (WRED) can
randomly drop packets when an interface is
nearing congestion
Another way of enforcing rate limits is to drop excess traffic. Committed Access
Rate (CAR) and Class-based Policing can be used for this purpose.
Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism
that randomly drops packets when interfaces are nearing congestion.

Meter
Classifier Marker Conditioner Forwarding Queuing

Inbound
• Cisco Express Forwarding (CEF) is

recommended from IOS 12.0
• Some QoS features work only in combination
with CEF
The Cisco IOS supports a large number of different forwarding mechanisms

(depending on the platform and the IOS version). From the QoS perspective it can
be said that:
n Most newer mechanisms require Cisco Express Forwarding (CEF)
n Some older mechanisms do not work with CEF (Process or Fast switching is
required)
Some other forwarding mechanisms available in the Cisco IOS include:
n Process switching, which is the oldest forwarding mechanisms available since
the first releases of Cisco IOS.
n Fast switching, which is the first optimization of forwarding. It uses a cache to
store most used destinations and it is performed in the interrupt code to improve
performance.
n Optimum switching, which is a further optimized version of fast switching on
high-end routers.
n NetFlow switching, which forwards packets by recognizing and caching flow
information.

Meter

Inbound
• Traditional queuing mechanisms

– FIFO, Priority Queuing (PQ), Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ) family
– WFQ, dWFQ, CoS-based dWFQ, QoS-group dWFQ
• Advanced queuing mechanisms
– Class-based WFQ, Class-based LLQ
The last mechanism that handles packets in the IOS is the queuing mechanism.
The figure lists most of the queuing mechanisms.

Meter

Inbound
• Tail drop on queue congestion

• WFQ has an improved tail-drop scheme
• WRED randomly drops packets when nearing
congestion
All queuing mechanisms include a drop policy. Most mechanisms use a simple tail-
drop scheme (the last packet to arrive is dropped if there is no room in the queue).
Weighted Fair Queuing (WFQ) uses a more intelligent dropping scheme, which
is discussed in the “IP QoS – Queuing mechanisms” module. Some queuing
mechanisms also include the Weighted Random Early Detection (WRED) to
prevent congestion in their queues.

Summary
n Describe different classification options in IP networks
n Describe different marking options in IP networks
n List the mechanisms that are capable of measuring the rate of traffic
n List the mechanisms that are used for traffic conditioning, shaping and avoiding
congestion
n List the forwarding mechanisms available in the Cisco IOS
n List the queuing mechanisms available in the Cisco IOS
Review Questions
n Name the QoS building blocks.
n What is the purpose of classification?
n What is the purpose of marking?
n Which markers do you know?
n Which mechanisms can classify and mark packets?
n Which mechanisms have the ability to measure the rate of traffic?
n Which forwarding mechanisms do you know?
n Which queuing mechanisms do you know?
n How, when and where do routers drop packets?

Enterprise Network Case Study
Objectives
n Describe a typical structure of an enterprise network
n Describe the need for QoS in enterprise networks
n List typical QoS requirements in enterprise networks
n List the QoS mechanisms that are typically used in enterprise networks

Traditional
Enterprise Networks
Core
(central sites
and
data centres)
X.25 (ancient), Frame Relay (old),

ATM (newer)
Distribution
(regional centres)
X.25 (ancient), Frame Relay (old),

ATM (newer)
Access
(branch offices)
• Traditional enterprise network use a hub-and-spoke topology

• Redundant connections are used to improve resilience
• Partial mesh can be used between the core sites and the distribution
sites
This lesson describes typical Enterprise Networks to show the topology and
technologies involved in such networks. Designing IP QoS networks largely
depends on the topology and QoS requirements.
The figure illustrates a three-layered network:
1. The core interconnects the data center(s) with the distribution-layer routers.
2. The distribution layer routers concentrate links towards a number of access-
layer routers.
3. The access-layer routers connect branch offices to the network.
Most traffic in enterprise networks goes between branches and the data center.

Modern
Enterprise Networks
Core
(central sites
and
data centres)
MPLS/VPN (new)
Access
(branch offices)
• Modern enterprise network use a full mesh topology provided by an MPLS/VPN

backbone
• Redundant connections to the backbone can be used to improve resilience
• The MPLS/VPN backbone uses redundant connections and a partial mesh to
improve resilience
Modern enterprise networks can use MPLS/VPN backbones to get a virtual full
mesh even though most traffic still goes between the data center and the branches.
Implementing QoS in such environments requires QoS guarantees from the service
provider and provisioning in the enterprise part of the network.

QoS in Enterprise Networks
• Typical enterprise networks have a large

number of different applications
• Some applications are business-critical and
require some guarantees (bandwidth, delay)
• The network should provide enough
resources to these business-critical
applications
• Applications are usually identified based on
TCP or UDP port numbers
Enterprise networks are typically concerned with providing differentiated QoS to

applications. Applications can be classified based on TCP or UDP port numbers
and marked with IP precedence or DSCP at network edges. The network should
guarantee resources to all business-critical applications (classes).

Case Study
• Typical line speeds

– Core - Distribution < 2 Mbps
– Distribution - Branch 64 kbps - 256 kbps
• Typical protocols
– SNA, NetBIOS, Desktop protocols (IPX), Some
TCP/IP, Voice, Multimedia
• Typical QoS requirements
– SNA and voice are high priority
– Guaranteed bandwidth for some application
– Rest of the traffic is best-effort
The figure shows a case study where relatively low bandwidths are used which
calls for QoS to manage bandwidth according to the needs of the enterprise.

Case Study
Implementation #1
• Core - Distribution
– Custom queuing
• Distribution - Branch
– Priority queuing or
– Custom Queuing with a priority queue
• Options
– Traffic shaping
– Adaptation to Frame Relay congestion notification
The figure lists mechanisms that could be used to accommodate the need of the
enterprise. This solution would normally be used in networks where an old IOS
version is being used and an upgrade is not an option (due to the cost of getting
newer IOS versions, memory upgrade, flash upgrade, etc.). The listed mechanisms
(Priority Queuing and Custom Queuing) have been available since Cisco IOS
version 10.0.

Case Study
Implementation #2
• Core - Distribution
• Distribution - Branch
• Options
– Weighted Random Early Detection (WRED)
This figure shows a solution using advanced mechanisms to provide better control
of bandwidth usage. This solution requires newer Cisco IOS software versions
(12.1 or 12.2, depending on the details of the implementation).

Summary
n Describe a typical structure of an enterprise network
n Describe the need for QoS in enterprise networks
n List typical QoS requirements in enterprise networks
n List the QoS mechanisms that are typically used in enterprise networks
Review Questions
n What is the typical enterprise network topology?
n How is resilience achieved?
n Based on which information do typical enterprise networks apply QoS?

Service Provider Case Study
Objectives
n Describe a typical structure of a service provider network
n Describe the need for QoS in service provider networks
n List typical QoS requirements in service provider networks
n List the QoS mechanisms that can be used in service provider networks

Typical
Service Provider Networks
Partial mesh Core

ATM, SONET/SDH, DPT, GE, ... Rings
Redundant connections
ATM, SONET/SDH, DPT, GE, ... Rings
Distribution
(regional POPs)
Single connections
Frame Relay, ATM, Leased line (analog, TDM), Optional redundant connections
dial-up (PSTN, ISDN, GSM), xDSL, (fast)ethernet, ... Dial backup
Access
(customers)
• Typical service provider networks use a high -speed partially-meshed core (backbone)
• Regional POPs use two or more connections to the core
• There may be another layer of smaller POPs connected to distribution-layer POPs
• Customers are usually connected to the service provide via a single point-to-point link (a
secondary link or a dial line can be used to improve resilience)
As the figure illustrates, Service Provider networks significantly differ from typical
enterprise networks. Enterprise Networks are used as a tool to support the
enterprise whereas with Service Providers the network is the business itself.
Enterprise networks are concerned with providing quality to business-critical
applications and Service Providers tend to broaden their service offering by
introducing QoS.

QoS in Service Provider Networks
Networks
• Service providers extend their service offerings by

introducing quality
• Customers can get bandwidth guarantees (like CIR
in Frame Relay)
• Customers can get delay guarantees (like CBR in
ATM)
• Customers can get preferential treatment in case of
congestion (Olympic service)
• QoS mechanisms have to be deployed where
congestion is likely (usually at network edge)
• Customer’s traffic is identified based on source or
destination IP addresses
Service Providers want to offer customers more than plain connectivity. Service
Providers want to establish differentiated levels of service for customers with
incremental pricing and SLA agreements. The customer should not only shop
around among a number of service providers that offer connectivity to the Internet
or provide MPLS/VPNs, but also have a menu of services they can choose from.
Some customers are satisfied with the best-effort service; some want certain
service guarantees.

Case Study
A service provider wants to offer gold,

silver, bronze and premium services
• Premium gets 40% of available bandwidth
with a low-delay guarantee
• Gold gets 30% of available bandwidth
• Silver gets 20% of available bandwidth
• Bronze gets 10% of available bandwidth
The case study shows an example of a Service Provider which offers

differentiated service levels where customers can choose the type of service they
want and are willing to pay for.
The service provider offers four services. Each of the services is basically a virtual
service-provider network using a common infrastructure. The Premium service is
guaranteed the most bandwidth and low-delay propagation of packets. Each of the
following services is guaranteed less bandwidth. Premium customers will benefit
most in times of congestion, whereas Bronze customers will only receive 10
percent of any link’s bandwidth.

Case Study
Implementation
• Class-based Weighted Fair Queuing (CB-

WFQ) on slow to moderate-speed links
• Class-based Low Latency Queuing (CB-LLQ)
on slow to moderate-speed links
• Weighted Random Early Detection (WRED)
on fast links
Service Provider networks would generally use newer Cisco IOS software and
can therefore deploy the latest available mechanisms. The case study is
implemented using CB-WFQ in combination with WRED and CB-LLQ at
networks edges (between access and distribution layer). WRED can be used on
high-speed links (on core links).

Summary
n Describe a typical structure of a service provider network
n Describe the need for QoS in service provider networks
n List typical QoS requirements in service provider networks
n List the QoS mechanisms that can be used in service provider networks
Review Questions
n What is the typical topology of service provider networks?
n Based on which information do typical service provider networks apply QoS?

Summary
After completing this module, you should be able to perform the following tasks:
n Describe the need for IP QoS
n Describe the Integrated Services model
n Describe the Differentiated Services model
n Describe the building blocks of IP QoS mechanisms (classification, marking,
metering, policing, shaping, dropping, forwarding and queuing)
n List the IP QoS mechanisms available in the Cisco IOS
n Describe what QoS features are supported by different IP QoS mechanisms

Review Questions and Answers
Introduction to IP Quality of Service
Question: What are the relevant parameters that define the quality of service?
Answer: Throughput (bandwidth), delay and jitter.
Question: What can be done to give more bandwidth to an application?
Answer: An application can get more throughput by increasing the bandwidth of
the links in the path and/or using a QoS mechanism to guarantee bandwidth when
the application has to contend with other flows. Payload and header compression
also virtually increase the available bandwidth by reducing the overhead.
Question: What can be done to reduce delay?
Answer: Delay can be reduced by increasing the bandwidth of the links in the path
and/or using a queuing mechanism that ensures minimum queuing delay for delay-
sensitive applications. Header compression will also help by reducing the
serialization delay of small packets on low-speed links. Payload compression would
have a similar result but it increases the delay because of the complexity of the
compression algorithm.
Question: What can be done to prevent packet loss?
Answer: Packet loss can also be prevented by providing enough bandwidth.
Alternatively a differentiated dropping mechanism can be used to drop packets of
less important flows to prevent drops of high-priority flows. Another option is to
use a queuing mechanism to guarantee enough bandwidth to high-priority flows.
Question: Name the three QoS models?
Answer: Best effort, Integrated services and Differentiated services.
Integrated Services Model

Question: What are the two building blocks of the Integrated Services model?
Answer: Resource reservation and admission control.
Question: Which protocol is used to signal QoS requirements to the network?
Answer: Resource reservation protocol (RSVP) is used to reserve network
resources for applications.

Question: What are the benefits of the DiffServ model compared to the IntServ
model?
Answer: DiffServ provides more scalable QoS solutions by applying QoS
mechanisms (per-hop behavior) to traffic classes instead of individual applications.
The DiffServ model does not require any signaling mechanism thus allowing QoS
provisioning to non-RSVP applications.

Questions: What is a DiffServ Code Point?
Answer: The DSCP is used to mark IP packets. It occupies the high-order 6 bits
of the DiffServ field (former ToS field).
Questions: Name the standard PHBs?
Answer: Expedited Forwarding (EF), Assured Forwarding (AF) and Class Selector
(CS).
Questions: How was backward compatibility with IP precedence achieved?
Answer: Backward compatibility is provided by using the DSCP values that map
into IP precedence values that are typically used to achieve a similar goal: EF
maps into IP precedence 5, AF1 maps into IP precedence 1, AF2 maps into IP
precedence 2, AF3 maps into IP precedence 3, AF4 maps into IP precedence 4,
the default DSCP maps into the default IP precedence 0.
Questions: Describe the PHB of Assured Forwarding.
Answer: AF PHB provides a bandwidth guarantee to a traffic class with the
possibility to use more bandwidth if it is available.
Questions: Describe the PHB of Expedited Forwarding.
Answer: EF PHB provides a bandwidth guarantee to a traffic class and it ensures
a minimum queuing delay. The traffic class is also limited to the provisioned
bandwidth.

Building Blocks of IP QoS Mechanisms
Review Questions
n Name the QoS building blocks.
Classification, marking, metering, dropping, policing, shaping and queuing.
n What is the purpose of classification?
Classification is used to assign packets to traffic classes with different
QoS requirements (behavior aggregates).
n What is the purpose of marking?
Marking is used to allow simplified classification on other devices in the
network.
n Which markers do you know?
IP precedence, DSCP, MPLS experimental bits, QoS group, Frame
Relay DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits.
n Which mechanisms can classify and mark
packets?
Policy-based Routing (PBR)
Committed Access Rate (CAR)
QoS Policy Propagation through BGP (QPPB)
Class-based Policing
Class-based Marking
n Which mechanisms have the ability to measure
the rate of traffic?
Generic Traffic Shaping (GTS)
Frame Relay Traffic Shaping (FRTS)
Class-based Weighted Fair Queuing (CB-WFQ)
Class-based Low Latency Queuing (CB-LLQ)
Class-based Shaping
IP RTP Prioritization
n Which forwarding mechanisms do you know?
Process Switching, Fast Switching, Optimum Switching, NetFlow
Switching, CEF switching …

n Which queuing mechanisms do you know?
FIFO, Priority Queuing (PQ), Custom Queuing (CQ), WFQ, dWFQ,
CoS-based dWFQ, QoS-group dWFQ, Class-based WFQ, Class-based
LLQ
n How, when and where do routers drop packets?
Routers typically drop packets when an output interface is congested.
The output queue fills up and the newly arriving packets have to be
dropped (tail drop).

Enterprise Network Case Study
Review Questions
n What is the typical enterprise network topology?
Enterprise networks typically use the hub-and-spoke topology.
Resilience is achieved by using redundant links.
n Based on which information do typical enterprise
networks apply QoS?
Enterprise networks typically provide QoS to applications. Applications
are typically identified based on the TCP or UDP port numbers.

Service Provider Case Study
Review Questions
n What is the typical topology of service provider
networks?
Typical service provider networks use a partially meshed core with a
redundant hub-and-spoke topology for the POPs.
Resilience is achieved by using partial mesh (core) and redundant links
(distribution, access).
n Based on which information do typical service
provider networks apply QoS?
Service providers typically apply QoS to customer traffic. Customer
traffic is identified based on source or destination IP addresses.

Classification and
Marking
Overview
This module describes the mechanisms that are used to classify and mark IP
packets. This module builds on the knowledge acquired from the introductory
module where classification and marking is discussed. Theoretical knowledge is
supplemented by detailing Policy-based routing (PBR) and QoS Policy Propagation
through BGP (QPPB) mechanisms.
Objectives
Upon completion of this module, you will be able to:
n Describe Policy-based routing and how it is used to classify and mark IP
packets
n Describe QoS Policy Propagation through BGP and how it is used to classify
and mark IP packets
n List other mechanisms that also support classification and marking capabilities
(Committed Access Rate, Class-based Policing and Class-based Marking)
Traffic Classification and Marking
Classification
• Most QoS mechanisms in the Cisco IOS
include some type of classification
• Some mechanisms classify packets
automatically, some require manual
configuration
Marking
• Only a small number of mechanisms also
include a marking capability
© 2001, Cisco Systems, Inc. Classification and Marking-3
This module focuses on the QoS mechanisms that are used for classification and
marking purposes only. Most QoS mechanisms include some type of classification
but only a small number of mechanisms also include marking capability.
Classification is the term used for identifying a Behavior Aggregate to which a
packet belongs. A Behavior Aggregate is a collection of flows requiring the same
quality of service.
Marking is the term used for coloring packets by applying a class-identifying
value to one of the following markers: IP precedence, DSCP, QoS group (value is
local to a router), MPLS experimental bits (can be used only in MPLS-enabled
networks), ATM CLP bit (value can be used only within ATM networks), Frame
Relay DE bit (value can be used only within Frame Relay networks), IEEE 802.1q
or ISL cos/priority bits (value can be used on within LAN-switched networks).
2-2 IP QoS Classification and Marking Copyright  2001, Cisco Systems, Inc.
Traffic Classification and Marking
• This module describes the two mechanisms

that are used for classification and marking
only:
– Policy-based Routing (PBR)
– QoS Policy Propagation through BGP (QPPB)
• Other classification and/or marking
mechanisms are described in other QoS
modules
This module describes the two QoS mechanisms that are used purely for
classification and marking purposes:
n Policy-based Routing (PBR)
n QoS Policy Propagation through BGP (QPPB)
There are other QoS mechanisms that also support classification and marking:
n Committed Access Rate (CAR) – this mechanism is described in the “IP
QoS – Traffic Shaping and Policing” module
n Class-based Policing (CB-Policing) – this mechanism is described in the
“IP QoS – Modular QoS CLI (Chapter 2)” module
n Class-based Marking (CB-Marking) – this mechanism is described in the
“IP QoS – Modular QoS CLI (Chapter 2)” module
Copyright  2001, Cisco Systems, Inc. IP QoS Classification and Marking 2-3
Policy-based Routing
Objectives
Upon completion of this lesson, you will be able to:
n Describe Policy Based Routing (PBR)
n Configure PBR on Cisco routers
n Monitor and troubleshoot PBR
• Policy-based Routing (PBR) is a mechanism

that can be used to bypass the default
destination-based forwarding functionality of
routers
• PBR is implemented using a route map
where match commands are used to classify
packets and set commands are used to
process packets
• Route maps are applied to interfaces for
processing of inbound packets (forwarding
and/or marking)
The primary function of Policy-based Routing (PBR) is to bypass the

destination-based forwarding functionality of routers by using a route map to make
a forwarding decision based on other information.
One additional feature of Policy Based Routing is the ability to modify IP packets
by marking them with IP precedence or QoS group.
PBR “match” and “set” Options
Set:
• Output interface (bypass the
Match on: routing table)
• Standard and extended access • Next-hop address (bypass the
lists routing table)
• Length of packets (min,max) • ToS field (QoS marking)
• IP precedence (QoS marking)
• QoS group (QoS marking)
IP
Input Output
interface interface
PBR has two primary applications:

• Implementation of more complex routing paradigms than a
simple destination-based forwarding
• Classification and marking of packets for QoS purposes
PBR classifies packets based on standard or extended access lists, the length of
packets and the incoming router interface (a route map is applied to an input
interface).
The route map sets the following parameters:
n Output interface: force the router to forward packets to an interface even if it
would not provide for optimal routing
n Next-hop address: to make a forwarding decision by using a different next-hop
address than the one determined by the routing table
n ToS value: the ToS value in this case applies to bits 4,3,2 and 1 of the ToS field
n IP precedence: three-bit field used to identify a class of service
n QoS group: the local parameter with an expanded value range
The first two parameters (output interface and next-hop address) are used to
bypass the default destination-based routing. The other three parameters are used
for QoS purposes (ToS value is less commonly used).
PBR Capabilities
PBR can only

classify and mark
Meter inbound or locally-
originated packets
Inbound Dropper
or
Classifier Marker
Locally-originated
Forwarding
Outbound
Meter
Shaper Queuing
Classifier Marker
Dropper
The figure illustrates the “full” QoS building-block scheme showing that PBR
works only on input and that it supports only classification and marking. The
“Forwarding” box could be colored as well since PBR can be used to make a
forwarding decision. PBR contains no mechanism for metering or dropping of data
packets.
Configuring Classification and
Marking Using PBR
• Create a route map

• Apply the route map to an incoming interface
and/or
• Apply the route map to locally originated
traffic
• Monitor and debug policy routing
© 2001, Cisco Systems, Inc. Classification and Marking -10
Configuring PBR involves the following steps:

n Creating a route map where the match statement is used to match with the
source or destination IP address or with any other parameter that can be
matched by an access list (standard or extended). It can also match packets
based on their size.
n Applying the route-map to:
n An input interface to process inbound packets on that interface or
n To locally originated packets
Route Map Rules
Router(config)#
route-map <name> [permit | deny] [<sequence-number>]
match <condition>
set <parameter>
• Route maps are identified by a case sensitive name
• Route maps can have multiple statements (same name,
different sequence number)
• Packets are processed in the specified sequence
• Packets not matched by the route map are forwarded using the
default destination-based forwarding
• If packets are matched by the “match” condition but the route
map statement is using the “deny” option, the default
destination-based forwarding is applied to the packet
A brief refresher about route maps:

n Route maps can have one or more statements. A route map, or a set of
route-map statements with the same name is identified by a case-sensitive
name .
n Individual route-map statements are identified by their name and sequence
number. When packets are processed by a route map they are evaluated in
the order specified by sequence numbers.
n A route map is basically made to be a filtering mechanism. When used for
PBR:
n permit means “do whatever the set commands says”
n deny means “do not do anything”
n When a packet is matched by one of the route-map statements it is processed
by that statement and the processing of the packet ends. Ordering route-map
statements correctly is therefore necessary.
PBR Classification
Router(config-route-map)#
match ip address <#acl>
• Classify using a standard access list against the source

address
• Classify using an extended access list against the source
and/or destination address, source and/or destination TCP/UDP
port, IP precedence, DSCP, ToS
match length <min> <max>
• Classify using a range of packet lengths that will be matched by

the route map statement
Route maps have a number of match options but only two can be used for policy-
based routing purposes:
n match ip address is used to examine the packet’s headers with a standard or
an extended access list
n match length is used to mach packets based on their length
PBR Marking
set ip precedence <precedence>
• Set the specified IP precedence to packets matched by the route map

• IP precedence supports 8 classes, two are reserved (6 and 7)
set ip qos-group <qos-group>
• Classify using a range of packet lengths that will be matched by the

route map statement
• QoS group supports 100 classes (0-99)
set ip tos <tos>
• Set the low-order 4 bits of the Type-of-service (ToS) field

• These bits are used to specify the delay, throughput and reliability
parameters (specified in RFC 791, no longer used after RFC 1812)
The following marking options are available with route maps:

n IP precedence
n QoS group
n ToS value (the four bits below IP precedence in the ToS field) used for
Delay, Throughput, Reliability and Monetary Cost
IP precedence is encoded into the three high-order bits of the ToS field in the IP
header. It supports eight classes of which two are reserved and should not be used
for user-defined classes (IP precedence 6 and 7). Ip precedence 0 is the default
value and is usually used for the best-effort class.
QoS group has one major advantage over IP precedence and one major
drawback:
n QoS group supports up to 100 classes. Values 0 to 99 can be used to mark
packets.
n QoS group is a parameter that is local to the router where it is set. It is not part
of any header. It is usually set on input interface and later examined (matched)
on output interfaces. Once the packet is transmitted, the QoS-group
information is lost, and the next router must reclassify and mark the packet.
ToS value is encoded into bits 4,3,2 and 1 of the ToS field (according to older
RFCs 791 and 1349). This value was made obsolete by the introduction of the
DiffServ Code Point, which does not take into account compatibility with these
bits.
Applying a Route Map
Router(config-if)#
ip policy-map <route-map-name>
• Specifies the route map used to set QoS and other

policy-routing parameters for packets received
through the specified interface
Router(config)#
ip local policy-map <route-map-name>
• Specifies the route map used to set QoS and other

policy-routing parameters for packets generated by
the router
Once a route map is configured it must be applied to either packets coming into the
router through an interface or to packets being generated by the router.
The first command (ip policy-map) is used for forwarded packets.
The second command (ip local policy-map) is used for packets generated by a
router and is typically used for tunneling packets (e.g. DLSw)
Note Policy-based routing is a mechanism that puts interfaces into Process Switching
mode. This will significantly degrade performance. PBR has been available in
the fast-switching path since Cisco IOS version 11.3. The ip route-cache policy
command can be used on an interface to enable caching for PBR. This
command has been available since Cisco IOS software version 12.0.
Monitoring and Troubleshooting
PBR
Router#
show route-map <name>
• Displays the route map and number of packets and

bytes matched by each statement
Router#
debug ip policy
• Displays all packets matched by policy routing route-

maps
The show route-map command is used to display the route map with its match
and set options.
The debug ip policy command is used to display all packets being processed by
PBR.
The show ip policy command is used to see a list of all interfaces that are enabled
for PBR. The output also displays the corresponding route maps.
The show ip local policy command is used to display the configured parameters
for local PBR with a number of packets and bytes that have been policy-routed by
the local PBR.
Monitoring and Debugging
Policy Routing
Router#show
Router#show route-map
route-map CPE
CPE
route-map
route-map CPE,
CPE, permit,
permit, sequence
sequence 10
Match
Match clauses:
ip address
address (access-lists):
(access-lists): 199
Set clauses:
clauses:
ip precedence
precedence flash-override
flash-override
Policy routing matches: 3418 packets, 412108 bytes
route-map
route-map CPE,
CPE, permit,
permit, sequence
sequence 20
Match
Match clauses:
ip address
address (access-lists):
(access-lists): MatchPing
MatchPing
Set clauses:
clauses:
ip precedence
precedence priority
priority
Policy
Policy routing
routing matches:
matches: 8282 packets,
packets, 31045
31045 bytes
bytes
Router#show
Router#show access-list
access-list MatchPing
MatchPing
Extended
Extended IP
IP access
access list MatchPing
MatchPing
permit icmp any any echo (25 matches)
Router#
Router#
The figure shows a sample output of the show route-map and show access-list
commands.
Monitoring and Debugging
Router#debug
Router#debug ip
ip policy
policy
Policy
Policy routing
routing debugging
debugging is
is on
on
Router#ping
Router#ping 192.168.1.1
192.168.1.1
Type
Type escape
escape sequence
sequence to
to abort.
abort.
Sending
Sending 5,
5, 100-byte
100 -byte ICMP
ICMP Echos
Echos to
to 192.168.1.1,
192.168.1.1, timeout
timeout is
is 22 seconds:
seconds:
!!!!!
!!!!!
Success
Success rate
rate is
is 100
100 percent
percent (5/5),
(5/5), round-trip
round -trip min/avg/max
min/avg/max == 28/31/32
28/31/32 ms
ms
Router#
Router#
2d02h:
2d02h: IP:
IP: s=192.168.1.2
s=192.168.1.2 (local),
(local), d=192.168.1.1,
d=192.168.1.1, len
len 100,
100, policy
policy match
match
2d02h:
2d02h: IP:
IP: route
route map
map CPE,
CPE, item
item 20,
20, permit
permit
...
...
The debug ip policy command is similar to the debug ip packet except that the
debug ip policy only displays policy-routed packets. This command should be
used with caution as it may produce too much output.
IP Precedence Marking
Case Study #1
• Branch office of a bank has two LANs connected to

an access router
• Ethernet0 is the front office with the real time transactions
• Ethernet1 is the back office with non-real time transactions
(like e-mail)
• The network provides different services to two
classes:
• Business traffic (marked with IP precedence 2)
• Other traffic (marked with IP precedence 0)
• Packets coming from Ethernet 0 should be classified
and marked as Business traffic
• Packets coming from Ethernet 1 should be classified
and marked as Other traffic
The case study involves a bank branch office where a single router connects two
LANs to the corporate network via one serial interface. This case study focuses
on the classification and marking part of a larger QoS solution, which includes
other QoS mechanisms.
Case #1- Solution
Mark all traffic with

precedence 2
Mark all traffic with

E0
precedence 0
WAN core
interface
interface ethernet
ethernet 0
ip policy-map
policy-map set-prec-2
set-prec-2
E1 !! Core
Branch interface
interface ethernet
ethernet 1
office ip policy-map
policy-map set-prec-0
set-prec-0
!!
route-map
route-map set-prec-2
set-prec-2 permit
permit 10
10
set ip
ip precedence 2
!!
route-map
route-map set-prec-0
set-prec-0 permit
permit 10
10
set ip
ip precedence 0
Policy-based routing can be used to mark packets with IP precedence values. All
packets from Ethernet 0 are marked with IP precedence 2. Since matching is
applied to all packets no “match” command is needed in the route map. The other
route map is applied to the other Ethernet interface and it marks packets with IP
precedence 0.
IP Precedence Marking
Case Study #2
• Branch office of a bank has one LAN connected to an

access router
• The network provides different services to three
classes:
• Transaction traffic (marked with IP precedence 2)
• Business traffic (marked with IP precedence 1)
• Other traffic (marked with IP precedence 0)
• TN3270 should be marked as Transaction traffic

• Internal HTTP should be marked as Business traffic
• All other traffic should be marked as Other traffic
The second case study is more complicated because classification is not done
based on the input interface. Instead, classification if performed based on
application (TCP or UDP port numbers).
Case #2 - Solution
WAN core
E0
interface
interface eth
eth 0
0 Core
ip
ip policy-map
policy-map set-prec
set-prec
Branch
Mark
Mark IP
IP precedence:
precedence: !!
office
route-map
route-map set-prec permit
set-prec permit 10
10
Telnet
Telnet = 22 match
match ip
ip address
address CorporateWebTraffic
CorporateWebTraffic
Corporate
Corporate Web
Web == 1 set
set ip precedence 11
everything
everything else
else == 0 route-map
route-map set-prec
set-prec permit
permit 20
20
match
match ip
ip address
address TN3270
TN3270
set
route-map
route-map set-prec
set-prec permit
permit 30
30
set
!!
ip
ip access-list
access-list extended
extended CorporateWebTraffic
CorporateWebTraffic
permit
permit tcp
tcp any
any 10.1.1.0
10.1.1.0 0.0.0.255
0.0.0.255 eq
eq www
www
ip
ip access-list
access-list extended
extended TN3270
TN3270
permit
permit tcp
tcp any
any any
any eq
eq telnet
telnet
A route map is created with three statements, one for each application:
n The first statement uses an access list to identify corporate web traffic
(destination port 80). IP precedence 1 is applied to these packets.
n The second statement uses another access list to identify outbound telnet
sessions. IP precedence 2 is applied to these packets.
n The last statement sets IP precedence 0 to all other packets.
Route Map - Review
• Policy routing with route maps can classify

and mark IP packets based on a wide variety
of conditions
• No metering, shaping or dropping is possible
• Performance depends on the IOS version
– Policy routing is fast -switched in 11.3 and 12.0
– (d)CEF or Net Flow-switched in 12.0(3)T
Policy-based Routing features:

n Static classification and marking (no metering, shaping, policing or dropping is
possible).
n PBR has performance limitations due to implementation (complex access lists
can degrade performance, sub-optimal order of statements can also degrade
performance due to sequential processing) and the IOS version (newer IOS
versions support fast-switched operation of PBR).
Summary
Policy based routing is used for two purposes:
n Bypassing the traditional destination-based forwarding
n Marking of IP packets with Ip precedence or QoS group
Lesson Review
n What are the applications of Policy-based Routing?
n What configuration tool is used to implement PBR?
n How can PBR be applied to IP traffic?
n Describe the classification options with PBR.
n Describe the marking options with PBR.
Objectives
n Describe the QPPB mechanism
n Configure the QPPB mechanism on Cisco routers
n Monitor and troubleshoot QPPB
IP QoS Policy Propagation
Through BGP (QPPB)
• QPPB uses BGP attributes to advertise class of

service to other routers in the network
• BGP Communities are usually used to propagate
class of service information bound to IP networks
• Packet classification policy can be propagated via
BGP without having to use complex access lists at
each of a large number of border (edge) routers
• A route map is used to translate BGP information
(e.g. BGP Community value) into IP precedence or
QoS group
QoS Policy Propagation through BGP is a mechanism that can be split into two
parts:
n Policy propagation via BGP, where a QoS policy is encoded into a BGP
attribute. BGP Communities are typically used to encode a QoS policy.
n Marking of packets with IP precedence or QoS group based on the QoS policy
learned via BGP.
BGP Policy is usually set on ingress routers (ingress for route propagation, egress
for packet forwarding) in an Autonomous System. BGP then carries the
information to other routers in the AS and translates (using a route map) this
information into IP precedence or QoS group. Marking is then enabled on per-
interface basis.
QPPB Capabilities
QPPB can only

Meter classify and mark
inbound packets
Inbound Dropper
or
Classifier Marker
Locally-originated
Forwarding
Outbound
Meter
Shaper Queuing
Classifier Marker
Dropper
Similar to PBR, QPPB also supports classification and marking only on the input
interface.
BGP Marking
Meter
Inbound
traffic
stream
Classifier Marker Dropper
1. Propagate the class of service by encoding it into BGP attributes:

• BGP communities,
• AS paths,
• IP prefixes or
• any other BGP attribute
2. Translate the selected BGP attribute into either:
• IP precedence or
• QoS group
3. Enable Cisco Express Forwarding (CEF) and packet marking on
interfaces
QoS policy can be applied to source or destination IP addresses or networks.

When BGP entries are inserted into the routing table a route map is used to
translate a certain BGP parameter or attribute into IP precedence or QoS group.
Packet marking is then enabled on input interfaces.
Cisco Express Forwarding
Review
• The two main components of CEF operation

– Forwarding Information Base
– Adjacency Tables
• CEF was first introduced on the following
platforms:
– Cisco 7x00 series in 11.1CC
– All RISC-based platforms in IOS 12.0
• QPPB is only supported on high-end routers
(Cisco 7x00 and above)
QPPB has the following requirements:

n Cisco Express Forwarding (CEF)
n A high end platform (Cisco 7x000 routers)
Review: Standard IP Switching
Address Prefix AS-Path Next hop Communities Other attr.

BGP table 10.0.0.0 /8 42 13 1.2.3.4 37:12
... ... ... ... ... ...
Protocol Address Prefix Next-hop Outgoing interface

IP routing
BGP 10.0.0.0 /8 1.2.3.4 ---
table
conn. 1.2.3.0 /24 --- Ethernet 0
Address Prefix L2 header

Switching
10.0.0.0 /8 MAC header
cache
... ... ...
IP address MAC address

ARP cache 1.2.3.4 0c.00.11.22.33.44
... ...
The figure illustrates how BGP routing information is used on routers that are
configured with the default switching operation:
n A BGP entry is inserted into the main routing table (the network points to the
BGP next-hop address.
n A recursive routing lookup is needed when the first packet arrives. After the
output interface is identified, a cache entry is generated. Multi-access media
requires additional information from the ARP cache.
n The subsequent packets are forwarded using the fast-switching cache.
Review: CEF Switching

BGP table 10.0.0.0 /8 42 13 1.2.3.4 37:12
... ... ... ... ... ...
Protocol Address Prefix Next-hop Outgoing interface

IP routing
BGP 10.0.0.0 /8 1.2.3.4 ---
table
OSPF 1.2.3.0 /24 1.5.4.1 Ethernet 0
conn. 1.5.4.0 /24 --- Ethernet 0
Address Prefix Adjacency pointer

FIB table 10.0.0.0 /8 1.5.4.1
(CEF cache) ... ... ...
ARP cache
IP address Layer 2 header IP address MAC address
Adjacency
1.5.4.1 MAC header 1.5.4.1 0c.00.11.22.33.44
table
... ... ... ...
CEF switching is different from the default operation in the following ways:
n CEF switching cache (the FIB table and the adjacency table) reflects the
information from the main routing table. Changes in the FIB table are not
triggered by packets but by changes in the main routing table itself.
n The CEF switching cache is split into two tables:
n Forwarding Information Base (FIB) which contains all networks that
are taken from the routing table. Those entries point to directly accessible
next-hops. Adjacency pointers are used to get information about these
next-hops from the Adjacency table
n Adjacency table contains a list of directly connected neighboring IP
devices. A layer-2 header is created in advance to accelerate the
encapsulation process.
CEF Switching with QoS
Packet Marking
BGP table 10.0.0.0 /8 42 13 1.2.3.4 37:12
... ... ... ... ... BGP table...
map
Protocol Address Prefix Next-hop Outgoing interface Precedence QoS group

IP routing
BGP 10.0.0.0 /8 1.2.3.4 --- 3 7
table
OSPF 1.2.3.0 /24 1.5.4.1 Ethernet 0 --- ---
conn. 1.5.4.0 /24 --- Ethernet 0 --- ---
Address Prefix Adjacency pointer Precedence QoS group

FIB table 10.0.0.0 /8 1.5.4.1 3 7
(CEF cache) ... ... ... ... ...
ARP cache
IP address Layer 2 header IP address MAC address
Adjacency
1.5.4.1 MAC header 1.5.4.1 0c.00.11.22.33.44
table
... ... ... ...
When using CEF for packet marking a table map is used in the BGP configuration
mode to process routes inserted into the routing table. A route map (used as a table
map in BGP) can translate any BGP parameter or attribute into IP precedence or
QoS group. This information is then passed on to the FIB table.
Once packet marking is enabled the router will perform two CEF lookups:
n The first lookup is used to mark packets
n The second lookup is used to make a forwarding decision
QPPB Configuration Tasks
• Create a route map to set IP precedence or

QoS group
• Apply the route map to BGP routes
transferred to main IP routing table
• Enable per-interface packet marking
Before configuring routers to support QPPB, a QoS design, which must include the
following, is needed:
n BGP attribute used to encode class of service (BGP Communities are usually
used)
n Marker (when using QPPB only IP precedence or QoS group can be used)
The following configuration steps are necessary on routers that perform packet
marking:
n Enable CEF
n Create a route map that translates a BGP attribute into IP precedence or QoS
group
n Apply the route map to process BGP routes before they are entered into the
main routing table.
n Enable per interface marking.
Setting IP Precedence or QoS
Group in the IP Routing Table
Router(config-router)#
table-map <route-map-name>
• Specifies the route map used to set additional

routing table attributes
Router(config)#
route-map <name> permit <seq>
set ip precedence <precedence>
set ip qos-group <group>
• Specifies IP precedence and QoS group values in the

routing table/FIB table entry
Use the table -map command in the BGP configuration mode to populate the main
routing table with the class of service information.
A route map can “tag” networks with IP precedence, QoS group or both.
Enable Per-interface Packet
Marking
Router(config-if)#
bgp-policy source ip-prec-map
• Applied to packets received through this interface

• Uses FIB to map packet source IP address to IP
precedence
• Rewrites IP precedence in the packet
Router(config-if)#
bgp-policy source ip-qos-map

• Uses FIB to map packet source IP address to QoS
group
• QoS group attached to the incoming packet
Once the FIB table contains the class of service information (IP precedence or
QoS group), marking can be configured on input interfaces.
CEF-based marking is performed based on the following:
n Find the source address (taken from the packet being marked) in the FIB
table and mark it with the IP precedence value attached to the
address/network. Use the bgp-policy source ip-prec-map interface
command to mark the packet.
n Find the source address (taken from the packet being marked) in the FIB
table and mark it with the QoS group value attached to the address/network.
Use the bgp-policy source ip-qos-map interface command to mark the
packet.
Enable Per-interface Packet
Marking
Router(config-if)#
bgp-policy destination ip-prec-map

• Uses FIB to map packet destination IP address to IP
precedence
• Rewrites IP precedence in the packet
Router(config-if)#
bgp-policy destination ip-qos-map

• Uses FIB to map packet destination IP address to
QoS group
• QoS group attached to the incoming packet
n Find the destination address (taken from the packet being marked) in the
FIB table and mark it with the IP precedence value attached to the
address/network. Use the bgp-policy destination ip-qos-map interface
n Find the destination address (taken from the packet being marked) in the
FIB table and mark it with the QoS group value attached to the
address/network. Use the bgp-policy destination ip-qos-map interface
All four commands can be attached to the same interface (although not
recommended) and they are processed in the following order:
n Source-based IP precedence marking
n Source-based QoS group marking
n Destination-based IP precedence marking (overrides source-based marking)
n Destination-based QoS group marking (overrides source-based marking)
Case Study
WAN core
NAP router NAP router POP router
Customer
AS 24 AS 12 (AS 73)
Create an end-to-end IP QoS solution in a

Service Provider network:
• Customer in AS 73 is a Premium customer
• All packets to and from AS 73 shall be sent with
precedence flash
This case study shows how customer networks can be marked with a BGP
community identifying a class of service, which is then propagated throughout the
Autonomous System 12 and used on edge routers to classify and mark packets
towards the customer networks with IP precedence flash (IP precedence 3).
Each IP precedence value is also identified by a name:
IP precedence IP precedence
value name
0 Routine
1 Priority
2 Immediate
3 Flash
4 Flash-override
5 Critical
6 Internet
7 Network
Step #1
Distribute QoS functions
WAN core
Customer
AS 24 AS 12 (AS 73)
packets for AS73

marked with
precedence flash
packets from serial

interface marked with
precedence flash
To achieve the same level of quality in both directions the packets going to and
coming from the customer network must first be classified and marked.
Classification and marking of packets coming from the customer network is trivial:
n PBR without a match statement is used on the interface connection from the
customer network to the ISP’s network.
n Another option is to use other mechanisms such as Committed Access Rate
(CAR), Class-based Policing or Class-based Marking.
Classifying and marking packets going to the customer network is a more difficult
task because:
n Classifying and marking must be performed on all edge routers.
n Classifying and marking requires the identification of the customer network.
Using PBR, CAR, CB-Policing or CB-Marking does not scale because it
involves the use of access lists (this is especially difficult if customer networks
are dynamically learned via BGP).
QPPB is the only scalable mechanism that can classify and mark packets based on
their source or destination IP address.
Step #2
Select QoS mechanisms
WAN core
Customer
AS 24 AS 12 (AS 73)
CEF-based marking
packets for AS73

marked with
precedence flash PBR on interface
packets from serial

interface marked with
precedence flash
The case study will employ PBR to do the marking of outbound packets (from the
customer perspective). QPPB will be used to mark inbound packets on remote
edge (border) routers.
Step #3 - Design Individual QoS
Mechanisms
Mark BGP routes from AS 73

with special community (12:17)
Configure community propagation
WAN core
Customer
AS 24 ASSet
12 FIB table (AS 73) on
based
BGP community
Configure CEF packet marking

for packets coming from adjacent AS
Customers networks are tagged with BGP Community 12:17 and sent to all internal
BGP neighbors.
Edge routers use a table map to translate BGP Community 12:17 into IP
precedence 3.
Destination-based precedence marking is enabled on interfaces connecting the AS
to other ASs.
Mark Routes Coming From AS 73
WAN core
Customer
AS 24 AS 12 (AS 73)
router bgp 12
neighbor 1.2.3.4 remote-as 73
neighbor 1.2.3.4 route-map Premium in
!
route-map Premium permit 10
set community 12:17 additive
The figure illustrates how a route map is used to process inbound BGP routing
updates coming from the customer’s AS 73. The BGP community attribute 12:17 is
added to the routing updates.
Configure Community
Propagation
WAN core
Customer
AS 24 AS 12 (AS 73)
router bgp 12
neighbor 2.3.4.5 remote-as 12
neighbor 2.3.4.5 send-community
BGP Community propagation is not enabled by default. It is, therefore, necessary

to use the send-community option on all internal BGP sessions to allow BGP
Communities to be propagated throughout the autonomous system.
Set FIB Table Based on BGP
Community
WAN core
router bgp 12 Customer
AS 24 AS 12
table-map PremiumCheck (AS 73)
!
route-map PremiumCheck permit 10
match community 17
set ip precedence flash
!
route-map PremiumCheck permit 20
set ip precedence 0
!
ip community-list 17 permit 12:17
The edge routers use route maps to translate BGP Community values into
appropriate IP precedence values. The figure illustrates how all routes carrying
BGP community 12:17 are tagged with IP precedence 3 in the routing table and the
FIB table. All other networks are tagged with IP precedence 0.
Note Setting IP precedence 0 on all packets not specifically matched by a table map is
also a security feature because it prevents IP precedence spoofing. Anyone
trying to use a high IP precedence value (e.g. 6 or 7) will be remarked with IP
precedence 0 and get the best-effort service.
Configure CEF Packet Marking
WAN core
Customer
AS 24 AS 12 (AS 73)
ip cef
!
interface hssi 0/0
bgp-policy destination ip-prec-map
!
The last configuration step is to enable CEF-based marking on border interfaces.

The case study requires that all packets going to (destination-based marking) the
customer’s network be marked with IP precedence 3.
QPPB marking is only available in combination with CEF switching. The global ip
cef command enables CEF switching on all interfaces that support CEF.
IP QoS and BGP Interaction
Review
• IP QoS features work independently of BGP

routing
• BGP is used only to propagate policies for
source or destination IP prefixes through the
network
• QPPB works only on high-end platforms
Although QPPB support is only available on high-end routers there is no limitation

when it comes to tagging BGP routes. Only marking routers have to support
QPPB: all other routers simply have to support BGP.
Summary
QPPB is a mechanism that is used to implement more scalable QoS solutions. It
uses BGP to propagate QoS policy information and CEF to mark packets with IP
precedence or QoS group.
Lesson Review
n Why is QPPB needed?
n How is QoS policy propagated through a network?
n How are QoS traffic classes defined by QPPB?
n Which IP forwarding mechanisms support QPPB?
Other QoS Mechanisms with Classification and
Marking Capability
Objectives
n Explain how most QoS mechanisms support some type of classification
n Name CAR, CB-Policing and CB-Marking as mechanisms that support
classification and marking
Classification
• Most QoS mechanisms include some type of

classification
• Some mechanisms have automatic
classification (e.g. WFQ, WRED, ...)
• Some mechanisms require manual
configuration of classification (e.g. CQ, PQ,
CB-WFQ, ...)
Most QoS mechanisms include some type of classification:

n Some mechanisms classify packets automatically. Weighted Fair Queuing
(WFQ), for instance, classifies packets into flows. Weighted Random Early
Detection (WRED) classifies packets based on their IP precedence values,
etc.
n Other mechanisms require manual configuration of classification.
Marking
The following mechanism (in addition to

PBR and QPPB) contain classification
and marking capability :
• Committed Access Rate (CAR)
• Class-based Policing
• Class-based Marking
Only a few remaining mechanisms have marking capabilities:

n Committed Access Rate (CAR), which is used for traffic policing
n Class-based Policing, which is also used for traffic policing
n Class-based Marking, which is used for classification and marking purposes
only. It may however be combined with other mechanisms available with the
Modular QoS CLI
CAR and Class-based Policing are discussed in detail in the “IP QoS – Traffic
Shaping and Policing” module.
Class-based Marking is discussed in detail in the “IP QoS – Modular QoS CLI
(Service Policy)” module.
This module includes a high-level overview of these QoS mechanisms.
• CAR is a mechanism used for traffic policing

• CAR uses a token bucket model to measure the rate
of traffic and (optionally) drop excess traffic
• CAR can also be used to mark packets with:
– IP precedence
– DiffServ Code Point (DSCP)
– MPLS experimental bits
– QoS group
• CAR can mark packets with different values
depending on whether they conform or exceed the
specified policy
CAR is a mechanism used to limit the traffic rate of a class and optionally mark
packets with one of the following markers:
n IP precedence
n DSCP
n MPLS experimental bits
n QoS group
CAR can also mark packets with two different values depending on whether they:
n Conform to the policy (packet is within the contractual bit-rate)
n Exceed the policy (packet is over the contractual bit-rate)
Conforming and exceeding packets can be marked with different values.
• Class-based Policing is similar to CAR except it is implemented

using the modular QoS CLI
• CB-Policing uses two token buckets to determine if packets
conform, exceed or violate the QoS policy
• CB-Policing can also be used to mark packets with:
– IP precedence
– DiffServ Code Point (DSCP)
– QoS group
– ATM CLP bit
– Frame Relay DE bit
• CB-Policing can mark packets with different values
depending on whether they conform, exceed or violate the
policy
Class-based Policing (CB-Policing) is a mechanism similar to CAR with the

following main differences:
n Modular QoS CLI is used to implement CB-Policing on Cisco routers
n CB-Policing supports more marking options than Committed Access Rate
n CB-Policing uses two token buckets to identify not just conforming and
exceeding packets but also violating packets.
Class-based policing can mark packets with three different values depending on
whether they conform, exceed or violate the policy.
Class-based Marking can mark packets with the following markers:
n IP precedence
n DSCP
n QoS group
n ATM CLP bit
n Frame Relay DE bit
Class-based Marking
• Class-based Marking is used to classify and mark

packets
• This mechanism uses the modular QoS CLI where
classes are manually configured
• Class-based Marking can mark packets with the
following markers:
– IP precedence
– DSCP
– QoS group
– ATM CLP bit
– IEEE 802.1Q or ISL’s CoS
Class-based Marking is also implemented using the Modular QoS CLI.

It supports the following markers:
n IP precedence
n DSCP
n QoS group
n ATM CLP bit
n IEEE 802.1Q or ISL cos/priority bits
Class-based marking can be combined with other mechanisms available in the
Modular QoS CLI.
Summary
The following mechanisms are used for classification and marking purposes:
n QoS Policy Propagation through BGP (QPPB)
n Committed Access Rate (CAR)
n Class-based Policing
n Class-based Marking
PBR is a mechanism that was primarily intended for bypassing the destination-
based forwarding and marking packets with IP precedence or QoS group.
QPPB is a mechanism that can also be used to mark packets with IP precedence
or QoS group. Its main advantage is scalability.
Lesson Review
n Which mechanisms in IOS support classification and marking of packets?
n Which fields or parameters can be used to mark packets in Cisco IOS?
Summary
n Describe Policy-based routing and how it is used to classify and mark IP
packets
n Describe QoS Policy Propagation through BGP and how it is used to classify
and mark IP packets
n List other mechanisms that also support classification and marking capabilities
(Committed Access Rate, Class-based Marking)
Question: What are the applications of Policy-based Routing?
Answer: PBR is used to bypass the destination-based forwarding or to classify
and mark packets.
Question: What configuration tool is used to implement PBR?
Answer: Route maps are used to implement PBR.
Question: How can PBR be applied to IP traffic?
Answer: PBR can be applied to input packets or packets originated by the
router.
Question: Describe the classification options with PBR.
Answer: PBR’s classification options include standard and extended access lists
as well as packet size based classification. PBR can also classify based on the
input interface because it is used on per-interface basis.
Question: Describe the marking options with PBR.
Answer: PBR can set the next-hop address or output interface to bypass the
default destination based forwarding. PBR can also mark packets with the
following options: ToS bits, IP precedence or QoS group.

Question: Why is QPPB needed?
Answer: QPPB can propagate a QoS class of service information throughout an
autonomous system. This allows more scalable QoS designs where classification is
performed on one router and automatically propagated to all other routers in the
AS.
Question: How is QoS policy propagated through a network?
Answer: BGP is used to propagate the CoS by encoding it into any available BGP
attribute.
Question: How are QoS traffic classes defined by QPPB?
Answer: QPPB is limited to assigning IP networks to traffic classes.
Question: Which IP forwarding mechanisms support QPPB?
Answer: QPPB requires CEF switching to mark packets with IP precedence or
QoS group.
Other QoS Mechanisms with Classification and Marking Capability
Question: Which mechanisms in IOS support classification and marking of
packets?
Answer:
Policy-based Routing (PBR)
Class based Marking
Question: Which fields or parameters can be used to mark packets in Cisco IOS?
Answer: IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay
DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits.
Queuing Mechanisms
Overview
This module describes the queuing mechanisms that can be used on output
interfaces.
n Queuing Overview
n FIFO Queuing
n Priority Queuing
n Custom Queuing
n Weighted Fair Queuing
n Distributed Weighted Fair Queuing
n Modified Deficit Round-robin
n IP RTP Prioritization
Objectives
n Describe and configure FIFO Queuing (FQ)
n Describe and configure Priority Queuing (PQ)
n Describe and configure Custom Queuing (CQ)
n Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ,
ToS-based distributed WFQ and QoS-group-based distributed WFQ
n Describe and configure Modified Weighted Round-robin (MDRR) queuing
n Describe and configure IP RTP Prioritization
Queuing Overview
Objectives
n Understand how queuing works on Cisco routers
n List the most used queuing mechanisms
3-2 Queuing Mechanisms Copyright  2001, Cisco Systems, Inc.

Queuing in Cisco IOS
• Cisco routers running Cisco IOS have a number of

different queuing mechanisms
• This module focuses on the following:
– First In First Out (FIFO)
– Priority Queuing (PQ)
– Custom Queuing (CQ)
– Weighted Fair Queuing (WFQ) with the different
distributed versions
– Modified Deficit Round Robin (MDRR)
– IP RTP Prioritization
• These mechnisms are implemented as software
queues
© 2001, Cisco Systems, Inc. Queuing Mechanisms -5
The lesson discusses how output queuing mechanisms are implemented on Cisco
routers running Cisco IOS. It discusses most of the queuing mechanisms in detail,
except Class-based Weighted Fair Queuing and Class-based Low-latency
Queuing, which are discussed in the “IP QoS – Modular QoS CLI (Chapter 2)”
module.
Copyright  2001, Cisco Systems, Inc. Queuing Mechanisms 3-3

Output Interface Queue Structure
Software Hardware
Output
Forwarder Queuing Queue Interface
System (TxQ)
Any supported Always FIFO

queuing mechanism
• Each Interface has its hardware and software queuing

system
• The hardware queuing system always uses FIFO queuing
(Transmission queue or TxQ)
• The software queuing system can be selected and
configured depending on the platform and Cisco IOS
version
Queuing on routers is necessary to accommodate bursts when the arrival rate of

packets is greater than the departure rate due to one of the following two reasons:
n Input interface is faster than the output interface
n Output interface is receiving packets coming in from multiple other interfaces
Initial implementations of queuing used a single FIFO (first-in first-out or first-come
first-serve queuing) strategy. More complex queuing mechanisms were introduced
when special requirements need routers to differentiate between packets of
different importance.
Queuing was split into two parts:
n The hardware queue that still uses FIFO strategy, which is necessary for the
interface drivers to transmit packets one by one. The hardware queue is
sometimes referred to as the transmit queue or TxQ.
n The software queue that schedules packets into the hardware queue based on
the QoS requirements
Listed on the previous graphic are some of the available software queuing
strategies with their goals:
n FIFO: no differentiation of packets (true fairness but no guarantees)
n Priority Queuing (PQ): strict prioritizing of packets
n Custom Queuing (CQ): service (bandwidth) guaranteed to up to 16 classes
n Weighted Fair Queuing (WFQ) and Distributed WFQ: service (bandwidth)
guarantee to individual flows
n Distributed ToS-based WFQ: service (bandwidth) guaranteed to up to 4 classes

n Distributed QoS-group-based WFQ: service (bandwidth) guaranteed to up to
100 classes
n Modified Deficit Round-robin (MDRR): service (bandwidth) guaranteed to up
to 8 classes; low-delay guarantee if Strict or Alternate Priority is used
n IP RTP Prioritization: low-delay guarantee
Most queuing mechanisms depend on the availability on different platforms and
Cisco IOS versions. For example:
n MDRR is only available on Cisco 12000 series routers (GSR)
n Distributed ToS-based and QoS-group-based WFQ are only available on Cisco
7x00 series routers with Versatile Interface Processors (VIP)

Bypassing the Software Queue
Hardware
Software Queue Yes Hardware Queue No
Empty? Full? Queue
(TxQ)
No Yes
Software
Queuing
System
• When a packet is being forwarded the router will bypass the

software queue if:
– the software queue is empty and
– the hardware queue is not full
The implementation of software queuing was optimized for periods when the
interface is not congested. The software queuing system is bypassed whenever
there is no packet in the software queue and there is room in the hardware queue.
The software queue is, therefore, only used when data must wait to be placed into
the hardware queue.

Hardware Queue (TxQ) Size
• Routers determine the length of the hardware

queue based on the configured bandwidth of
the interface
• Long TxQ may result in poor performance of
the software queue
• Short TxQ may result in a large number of
interrupts which causes high CPU utilization
and low link utilization
The double queuing strategy (software and hardware queue) has its impacts on the
result of overall queuing:
n Software queue is used for a certain reason. If the hardware queue is too long
it will contain a large number of packets scheduled in the FIFO fashion. This is
probably against the QoS design that required a certain complex software
queuing system (for example, Custom Queuing).
So why use the hardware queue at all? Or why not just set its length to one? That
would force all packets to go through the software queue and be scheduled one by
one to the interface for transmission. This approach has the following drawbacks:
n Each time a packet is transmitted, the interface driver interrupts the CPU and
requests more packets to be delivered into its hardware queue. Some queuing
mechanisms have complex scheduling that takes time to deliver more packets.
The interface does not send anything during that time (link utilization is
decreased) if the hardware queue is empty because its maximum size is one.
n The CPU schedules packets one by one instead of many at the same time (in
the same interrupt interval). This increases the CPU utilization.
Choosing the appropriate length of the hardware queue is very important. The
default TxQ size is determined by the IOS based on the bandwidth of the media
and should be fine for most queuing implementations. Faster interfaces have longer
hardware queues because they produce less delay. Slower interfaces have shorter
hardware queues to prevent too much delay in the worst-case scenario where the
entire hardware queue is full of MTU-sized packets.

Queuing Components
Forwarded Packets
Software Queuing System
Class 1? Add/Drop Queue 1
Hardware
Queuing System
Class 2? Add/Drop Queue 2
Hardware Q Interface
Scheduler
Class n? Add/Drop Queue n
• Each queuing mechanism has three main components that define it:
– Classification (selecting the class)
– Insertion policy (determining whether a packet can be enqueued)
– Service policy (scheduling packets to be put into the hardware queue)
The figure illustrates the actions that have to be taken before a packet can be
transmitted:
n Most queuing mechanisms include classification of packets.
n Once a packet is classifie d, a router has to determine whether it can put the
packet into the queue or it has to drop the packet. Most queuing mechanisms
will drop a packet only if the corresponding queue is full (tail-drop). Some
mechanisms use a more intelligent dropping scheme (Weighted Fair Queuing)
or a random dropping scheme (Weighted Random Early Detection).
n If the packet is allowed to be enqueued it will be put into the FIFO queue for
that particular class.
n Packets are then taken from the individual per-class queues and put into the
hardware queue.
Queuing systems differ in the following ways:
n Classification options: some mechanisms classify packets automatically (for
example, WFQ), while other mechanisms require manual configuration of
classification (for example, PQ or CQ).
n Insertion policy: most queuing mechanisms use the tail-dropping scheme.
n Scheduling policy: this is the most important part of every queuing mechanism
because it determines the order in which the packets will leave the router.

Summary
n Understand how queuing works on Cisco routers
n List the most used queuing mechanisms
Review Questions
n Which queuing mechanisms do Cisco routers support?
n When is a software queuing mechanisms not used?
n How does TxQ length affect the software queuing system?

FIFO Queuing
Objectives
n Describe FIFO queuing
n Describe the drawbacks of FIFO queuing
n Configure FIFO queuing on Cisco routers
n Monitor and troubleshoot FIFO queuing

FIFO Queuing
Forwarded Packets
FIFO Queuing System Hardware

Queuing System
All in one FIFO

Tail-drop Queue 1 Hardware Q Interface
queue Scheduler
Routers serve packets in the

first-come first-serve fashion
FIFO uses one single queue
Newly arriving packets are

dropped if the queue is full
All packets are
classified into one class
• Software FIFO queue is basically an extension to the

hardware FIFO queue
© 2001, Cisco Systems, Inc. Queuing Mechanisms-14
FIFO queuing has no classification because all packets belong to the same class.
Packets are dropped when the output queue is full (tail-drop). The scheduler
services packets in the order they arrived.
Software FIFO queue is basically an extension of the hardware FIFO queue.

Benefits and Drawbacks of FIFO
Queuing
+ Benefits
• Simple and fast (one single queue with a simple
scheduling mechanism)
• Supported on all platforms
• Supported in all switching paths
• Supported in all IOS versions
– Drawbacks
• Unfair allocation of bandwidth among multiple flows
• Causes starvation (aggressive flows can monopolize
links)
• Causes jitter (bursts or packet trains temporarily fill
the queue)
FIFO queuing might be regarded as the fairest queuing mechanism but it has a long
list of drawbacks:
n FIFO does not fairly allocate bandwidth among multiple flows. Some flows
receive more bandwidth because they use larger packets or send more packets.
n FIFO is extremely unfair when an aggressive flow is contesting with a fragile
flow. Aggressive flows send a large number of packets, many of which are
dropped. Fragile flows send a modest amount of packets and most of them are
dropped because the queue is always full due to the aggressive flow. This type
of behavior is called starvation.
n Short or long bursts cause a FIFO queue to fill. Packets entering an almost full
queue have to wait a long time before they can be transmitted. Another time,
the queue might be empty causing packets of the same flow to experience
almost no delay. Variation in delay is called jitter.
In spite of all the drawbacks FIFO is still the most used queuing mechanism
because of the following benefits:
n It is simple and fast. Most high-end routers with fast interfaces are not really
challenged by the drawbacks mentioned earlier. Furthermore, routers are not
capable of complex classification and scheduling when they have to process a
large number of packets per second. FIFO is, therefore, the most suitable
queuing mechanisms on these platforms.
n It is supported on all platforms.
n It is supported in all IOS versions.

Configuring FIFO Queuing
Router(config-if)#
no fair-queue
fair-queue
• FIFO queuing is enabled by default on all interfaces

that have a default bandwidth of more than 2Mbsp
• Weighted Fair Queuing is enabled if the bandwidth is
less than 2Mbps
• Disable WFQ to enable FIFO on interfaces that have
less than 2Mbps of bandwidth
Cisco routers have two default queuing mechanisms:

n All interfaces with the default bandwidth above 2Mbps use FIFO queuing. No
configuration is necessary on such interfaces.
n All interfaces with the default bandwidth below 2Mbps use Weighted Fair
Queuing (WFQ). The no fair-queue command must be used to disable WFQ
and enable FIFO.
There is no special command that specifically enables FIFO.

Configuring FIFO Queuing
Router(config-if)#
hold-queue <buffers>
<buffers> out
• FIFO queuing allows a maximum of 40 packets to be

stored in the output queue
• This command can be used to increase or decrease
the maximum number of buffered packets
• A large value can be set to support longer bursts
(less drops, more buffer usage)
• A small value can be set to prevent bursts (more
drops)
One of the considerations when using FIFO queuing is the maximum burst size.
Routers allow (by default) up to 40 packets to be in the output queue. Shortening
the queue causes more drops, especially for bursty sessions. Lengthening the
queue allows more packets to be enqueued. A long queue should be used to allow
bursts without drops.
The hold-queue command is used to set the maximum number of packets in the
output queue.

FIFO Example
The Ethernet interface has a default

bandwidth of 10Mbps.
FIFO is the default queuing and it does
not need to be configured.
interface
interface Ethernet0/0
ip
ip address
address 1.1.1.1
1.1.1.1 255.0.0.0
255.0.0.0 The serial interface (A/S) has a default
!! bandwidth of 128 kbps.
interface WFQ is the default queuing and it has
interface Serial0/0
Serial0/0 to be disabled to enable FIFO queuing.
ip
ip address
address 2.2.2.2
2.2.2.2 255.0.0.0
255.0.0.0
no
no fair-queue
fair-queue Up to 50 frames are allowed to be
hold-queue enqueued before the router will start
hold-queue 50
50 out
out tail-dropping newely arriving packets.
!!
The example shows how FIFO can be enabled on an interface that uses WFQ by
default. The serial interface in question has the default bandwidth of 128 kbps
(below 2 Mbps). The ethernet interface has the default bandwidth of 10 Mbps
(above 2 Mbps) and requires no configuration.
The maximum output queue size was also slightly increased from the default 40 to
50.

FIFO
Router#
show interface
interface [<interface>]
[<interface>]
• The command displays information about the selected
interface(s)
Router#show
Router#show interface
interface Serial0/0
Serial0/0 The queue is currently empty ( 0/50).
Serial0/0
Serial0/0 isis up,
up, line
line protocol
protocol is
is up
up There can be a maximum of 50 frames in the
Hardware
Hardware is PowerQUICC Serial queue (0/50).
Internet
Internet address is 1.1.1.1/8
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 128
128 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec,
reliability
reliability 255/255,
255/255, txload
txload 1/255,
1/255, rxload
rxload 1/255
1/255
Encapsulation
Encapsulation HDLC,
HDLC, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec) FIFO queuing is enabled
Last
Last input 00:00:02, output 00:00:04, output hang neveron an interface with the
input 00:00:02,
Last
Last clearing
clearing of "show
"show interface"
interface" counters never default bandwidth of
128kbps.
Queueing
Queueing strategy:
strategy: fifo
fifo
Output
Output queue
queue 0/50,
0/50, 00 drops;
drops; input
input queue
queue 0/75, 0 drops
55 minute
minute input
input rate
rate 00 bits/sec,
bits/sec, 00 packets/sec
packets/sec
55 minute
minute output
output rate
rate 00 bits/sec,
packets/sec
……
FIFO queuing is not supported by a large arsenal of show and debug commands.
The show interface command can be used to determine the queuing strategy of
an interface and to display the following statistics:
n The current queue size (buffer usage)
n The maximum queue size (default 40 or whatever is configured with the
hold-queue out command)

Summary
FIFO queuing is the oldest queuing mechanism in the Cisco IOS. It is used on fast
interfaces because of its simplicity and speed. FIFO produces undesirable behavior
on congested (low-speed) interfaces that manifest itself as:
n Unfair allocation of bandwidth
n Starvation of less-aggressive flows
n Delay
n Jitter
FIFO is the default queuing mechanism on all interfaces that have the default
bandwidth of more than 2 Mbps. FIFO queuing can be enabled on interfaces with
the default bandwidth of 2 Mbps or less by disabling WFQ.
Review Questions
n Why is FIFO the fastest queuing mechanism?
n Describe the classification and scheduling of FIFO queuing.
n List the drawbacks of FIFO queuing.

Priority Queuing
Objectives
n Describe Priority Queuing
n Describe the benefits and drawbacks of Priority Queuing
n Configure Priority Queuing on Cisco routers
n Monitor and troubleshoot Priority Queuing

Priority Queuing
Forwarded Packets
Priority Queuing System
High? Tail-drop Queue 1
Hardware
Medium? Tail-drop Queue 2 Queuing System
Pre-emptive
Scheduler Hardware Q Interface
Normal? Tail-drop Queue 3
Low? Tail-drop Queue 4
• Priority Queuing (PQ) uses four FIFO queues

Priority Queuing (PQ) is one of the first mechanisms that allowed classification of
packets into multiple classes. Scheduling is done in strict priority.
PQ can classify packets into one of the four queues:
n High queue
n Medium queue
n Normal queue (the default queue)
n Low queue
Scheduling prefers packets in the same order. Each class uses one FIFO queue,
where packets are dropped if a queue is full.

Priority Queuing
Classification
• Priority Queuing classification for IP supports the

following options:
– Source interface
– IP access list (standard and extended)
– Packet size (greater or smaller than specified)
– Fragments
– TCP source or destination port numbers
– UDP source or destination port numbers
Priority Queuing can classify IP packets with the following tools:

n Direct matching on the source interface.
n Standard or extended IP Access list. Extended IP access lists support matching
on the following parameters:
– Source IP address
– Destination IP address
– Source TCP or UDP port number or port range
– Destination TCP or UDP port number or port range
– IP precedence (high-order three bits of the ToS field)
– DSCP (high-order six bits of the ToS field)
– ToS value (bits one through four of the ToS field)
– Fragments
– TCP flags (ACK, SYN, RST, URG, PSH)
n Direct matching of TCP or UDP source and destination port numbers.
n Direct matching of fragments.
n Direct matching of packets based on their size.

Priority Queuing
Classification
• Priority Queuing also supports classification of other protocols
with the following options:
– Protocol-specific access list (if available for the specified
protocol)
• Some of the supported protocols are:
– IPX
– CLNS
– DECNET
– AppleTalk
– VINES
– DLSw
Priority Queuing is a multi-protocol QoS mechanism because it supports

classification tools for other (non-IP) protocols. The figure lists the match options
for some of the supported Layer-3 protocols as well as other higher-layer
protocols.
Although other protocols are supported, the classification options are not as
powerful as with IP. Most protocols can use their corresponding access lists to
classify packets. Matching on packet size is also available with all supported
protocols.

Priority Queuing
Insertion Policy
• Each queue has a maximum number of

packets that it can hold (queue size).
• After a packet is classified to one of the
following queues the router will enqueue the
packet if the queue limit has not been
reached (tail-drop within each class).
Priority Queuing is basically a collection of four parallel FIFO queues. Each queue
suffers from all FIFO problems isolated to the class (unfair, starvation, delay,
jitter). Each queue uses the tail-drop scheme when the queue is full.
Each of the four queues can be configured with the maximum number of packets
that it can hold.

Priority Queuing
Scheduling
Packet in No
HIGH
queue?
Packet in No
Yes
MEDIUM
queue?
Packet in No
Yes
NORMAL
queue?
Packet in No
Yes
LOW
queue?
Yes
Dispatch Packet
And start checking the Hardware Q
HIGH queue again
Priority Queuing uses strict priority scheduling. As long as there are packets in the
high queue no other queue will be served. If the high queue is empty the router
starts serving the medium queue.
Congestion in any of the queues, except the low queue, causes a different type of
starvation. A congested higher-priority queue causes all lower-priority queues to
starve (class starvation).

Benefits and Drawbacks of
Priority Queuing
+ Benefits
• Provides low-delay propagation to high-priority
packets
• Supported on most platforms
• Supported in all IOS versions (above 10.0)
– Drawbacks
• All drawbacks of FIFO queuing within a single class
• Starvation of lower -priority classes when higher-
priority classes are congested
• Manual configuration of classification on every hop
As mentioned previously, Priority Queuing suffers from the same drawbacks as

FIFO queuing, except it is localized to four classes. Each class can experience
starvation, delay and jitter if one or more flows in the class cause congestion.
Furthermore, one higher-priority queue can cause all other queues to starve if it is
congested.
Priority Queuing requires manual configuration of classification.
The main benefit of PQ is that it enables the user to create a class that is used for
applications that require low delay (high queue).

Configuring Priority Queuing
• Configure priority lists

–Configure classification
–Select a queue
–Set maximum queue size
• Apply the priority list to outbound traffic on
an interface
The configuration of Priority Queuing can be split into the following four steps:
1. Classify data into four classes
2. Assign a queue to each class
3. Set the maximum queue size (if the default is not appropriate)
4. Apply the priority queuing system to one or more interfaces

Priority Queuing Classification
Router(config)#
priority-list list-number
list-number protocol protocol-name
{high|medium|normal|low} queue-keyword keyword-value
• Selects the queue based on layer-3 protocol

• Additional classification (queue-keyword):
– fragment (IP packets with non-zero fragment
offset)
– gt/lt <size>: based on packet size (including L2
frame)
– list <acl>: ACL classification
– tcp/udp <port>: TCP or UDP port number
• System and link-level messages are classified in
high by default
The first three configuration steps are achieved using the priority-list command.
A Priority Queuing system is identified with a common number (list-number).
Priority Queuing supports the following direct classification options of IP packets:
1. Match fragments
2. Match packets based on their size
3. Match packets based on their source or destination TCP/UDP port number
A far more powerful classification tool is an access list (standard or extended).

Priority Queuing Classification
Router(config)#
priority-list list-number interface intf {high|medium|normal|low}
{high|medium|normal|low}
• Classifies the packet based on incoming interface

Router(config)#
priority-list list-number default
default {high|medium|normal|low}
• Classifies all unclassified packets in a default queue
Additionally, PQ supports classification based on source interface.

By default, all traffic not specifically classified goes into the normal queue. This
behavior can be changed by using the priority-list default command.
Note The priority-list commands are evaluated in the order they were entered. This is
especially important when overlapping classification is configured for separate
queues.
For example:
Line 1: all IP traffic goes into the high priority queue
Line 2: all TCP traffic goes into the medium queue
The medium queue in this example would never g et any packets because it
appears second in the configuration and it is a subset of the first line.

Priority Queuing Scheduling and
Dropping Parameters
Router(config)#
priority-list list-number queue-limit high medium normal low
low
• Specifies the maximum queue sizes of individual

priority queues
Router(config-if)#
priority-group list
• Assigns Priority Queuing definition to an interface
Priority Queuing uses the following default maximum queue sizes for the four
queues:
n High queue has a default queue limit of 20
n Medium queue has a default queue limit of 40
n Normal queue has a default queue limit of 60
n Low queue has a default queue limit of 80
The last configuration step is to apply a priority-list to an interface. Use the
priority-group command with a corresponding priority-list number to enable
Priority Queuing on an interface.

Sample PQ Configuration
E0
WAN core
E1
Core
interface
interface serial0
serial0
Branch priority-group
priority-group 1
office
priority-list
priority-list 1 protocol
protocol ip high list 101
priority-list
priority-list 1 interface
interface ethernet
ethernet 00 medium
medium
priority-list
priority-list 1 default normal
priority-list
priority-list 1 queue-limit 20 40 60 80
access-list
access-list 101
101 permit
permit tcp
tcp any
any any
any eq 23
The figure illustrates a simple example where outbound traffic is classified into the
following three classes:
1. All outbound telnet sessions (access list 101) are using the high priority queue
2. All traffic coming into the router via interface Ethernet 0 is forwarded through
the medium queue
3. All other traffic is using the default normal queue

Monitoring Priority Queuing
Router#
show interface
interface interface
• Displays information and statistics about queuing

on interface
Router#
show queueing [priority|custom|fair|random-detect] interface
• Displays queuing parameters on interfaces
Router#
show queue
queue interface
interface
• Displays queue contents
The show interface command can be used to determine the queuing strategy of
an interface. If the queuing strategy is PQ some statistics are also displayed.
The show queueing priority command can be used to display all non-default
parameters of priority lists.
Note To use the show queueing command, you must enter at least the first six
characters to differentiate the command (show queuei vs. show queue).

Show Interface
Router#show
interface serial
serial 1/0
1/0
Serial1/0
Serial1/0 isis up,
up, line
line protocol
protocol is
is up
up
Hardware
Hardware is
is M4T
M4T
Internet
Internet address
address is
is 20.0.0.1/8
20.0.0.1/8
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 19
19 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec, rely
rely 255/255,
255/255, load
load 93/255
93/255
Encapsulation
Encapsulation HDLC,
HDLC, crc
crc 16,
16, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:00,
00:00:00, output
output hang
hang never
never
Last
Last clearing
clearing ofof "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0
0/75/0 (size/max/drops);
(size/max/drops); Total
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: priority-list
priority-list 11
Output
Output queue
queue (queue
(queue priority:
priority: size/max/drops):
size/max/drops):
high:
high: 0/20/0,
0/20/0, medium:
medium: 0/40/0,
0/40/0, normal:
normal: 0/60/0,
0/60/0, low:
low: 0/80/0
0/80/0
55 minute
minute input
input rate
rate 18000
18000 bits/sec,
packets/sec
55 minute
minute output
output rate
rate 7000
7000 bits/sec,
packets/sec
…… rest
rest ignored
ignored ...
...
The show interface command displays the parameters and the statistics of all four
priority queues. The first parameter is the current size of the queue, the second is
the maximum allowed size of the queue and the third parameter is the number of
drops since the last clearing of counters.

Show Queuing Priority
Router#show
Router#show queueing
queueing priority
Current
Current priority
priority queue
queue configuration:
configuration:
List
List Queue Args
Args
11 high
high protocol ip list 101
11 medium
medium interface
• The “show queueing priority” command

displays only the non-default parameters
The show queueing priority command lists all non-default parameters.

The figure shows the two parameters:
n All packets permitted by access list 101 go into the high queue
n All packets coming from interface Ethernet6/0 go into the medium queue
The commands that set default parameters are not displayed, either in the running
configuration or by using this command.

Summary
Priority Queuing uses four FIFO queues. Strict priority queuing is used. Starvation
within a single class or starvation of lower-priority classes is possible when one
flow congests a higher-priority queue.
Priority queuing can be used to guarantee all the bandwidth and low-delay
propagation.
Review Questions
n When would you use priority queuing?
n What are the benefits and drawbacks of priority queuing?
n How many classes does priority queuing support?
n How does priority queuing schedule packets?

Custom Queuing
Objectives
n Describe Custom Queuing
n Describe the benefits and drawbacks of Custom Queuing
n Configure Custom Queuing on Cisco routers
n Monitor and troubleshoot Custom Queuing

Custom Queuing
Forwarded Packets
Custom Queuing System
Class 1? Tail-drop Queue 1
Hardware
Class 2? Tail-drop Queue 2 Queuing System
Round
Robin Hardware Q Interface
Scheduler
• Custom Queuing (CQ) uses 16 FIFO queues for

user defined traffic classes
Custom Queuing (CQ) is similar to Priority Queuing in the way it is configured and
in the supported classification options. The scheduling, however, is completely
different.
CQ uses up to 16 queues that can be used for user-defined classes. The
classification options are identical to those of Priority Queuing.
The scheduling mechanism uses the round-robin service where each queue is
allowed to forward a certain number of bytes (not packets).
Tail-drop is still used within each individual queue.

Custom Queuing
Classification
• Custom Queuing classification for IP supports the

following options:
– Source interface
– IP access list (standard and extended)
– Fragments
– TCP source or destination port numbers
– UDP source or destination port numbers
• Custom Queuing classification is identical to that of
Priority Queuing
Custom Queuing (similar to Priority Queuing) can classify IP packets with the
following tools:
n Direct matching on the source interface.
n Standard or extended IP Access list. Extended IP access lists support matching
on the following parameters:
– Source IP address
– Destination IP address
– Source TCP or UDP port number or port range
– Destination TCP or UDP port number or port range
– IP precedence (high-order three bits of the ToS field)
– DSCP (high-order six bits of the ToS field)
– ToS value (bits one through four of the ToS field)
– Fragments
– TCP flags (ACK, SYN, RST, URG, PSH)
n Direct matching of TCP or UDP source and destination port numbers.
n Direct matching of fragments.
n Direct matching of packets based on their size.

Custom Queuing
Insertion Policy

packets that it can hold (queue size).
following queues the router will enqueue the
packet if the queue limit has not been
reached (tail-drop within each class).
Once the packet is classified a router has to determine if the packet can be
enqueued. The packet is dropped if the queue is full.
Each queue, unless configured otherwise, can buffer up to 20 packets before the
first packet is dropped.

Custom Queuing
Scheduling
No
Is Queue N
Packet in No Next Queue Yes
over the
Queue N? (increase N)
threshold?
Yes
Dispatch
Packet Hardware Q
• Custom Queuing uses round-robin service policy

• Each queue is allowed to forward a configurable
amount of bytes (threshold) in one round
Custom Queuing uses round-robin scheduling, where each queue gets some
service (bandwidth). Each queue is configured with the number of bytes
(byte-count) it can send in one round. The last packet is always sent, even if the
total amount of bytes sent in one round is above the limit (byte-count). The router
then starts processing the next queue.

Custom Queuing
Scheduling Parameters
1500 1499 1500
Threshold (byte-count) = 3000
Up to 4499 bytes can be forwarded

in one round in the worst case
• The threshold (byte count) parameter specifies the lower

boundary on how many bytes the system allows to be delivered
from a given queue during a particular cycle
• The router is allowed to send the entire packet even if the sum
of all bytes is more than the threshold
The figure illustrates the worst case scenario where the following parameters were
used to implement Custom Queuing on an interface:
n MTU of the interface is 1500 bytes
n Byte-count is 3000 (twice the MTU)
The example shows how the router first sent two packets with a total size of 2999
bytes. Since this is still within the limit (3000) the router can send the next packet
(MTU-sized). The result was that the queue received almost 50% more bandwidth
in this round than it should.
This is one of the drawbacks of Custom Queuing – it does not allocate bandwidth
accurately.

CQ Design Guideline
• Configure the amount to remove from a

queue in each round to configure the
proportional “weight” of the queue
• Amounts to remove should approximate a
small multiple of the interface’s MTU
• Ratio between largest and smallest queue
should be a small positive integer, not more
than 10:1
The limit or weight of the queue is configured in bytes. The accuracy of Custom
Queuing depends on the weight (byte-count) and the MTU.
If the ratio between the byte-count and the MTU is too small CQ will not allocate
bandwidth accurately.
If the ratio between the byte-count and the MTU is too large CQ will cause long
delays. This problem is discussed in detail on the next two pages.

Delay vs. Bandwidth Allocation
Queue 1
5999 4500
Round
Queue 2 Robin 64 kbps
Scheduler
4499 3000 MTU=1500
Queue 3
2999 1500
BW
BW (Queue 1) == bc1/(bc1+bc2+bc3)
bc1/(bc1+bc2+bc3) == 4500/9000 == 50%
Delay
Delay (Queue
(Queue 1)
1) = (bc2+bc3)/Bandwidth = 562ms
Worst-case
Worst-case Delay
Delay (Queue
(Queue 1) = ((bc2+1499) +(bc3+1499))/Bandwidth
+(bc3+1499))/Bandwidth == 937ms
The figure illustrates sample calculations of bandwidth guarantees and the

maximum delay.
The time it takes to complete a round depends on the bandwidth of the interface,
the MTU size and the sum of all queue byte-counts.
The case study parameters are:
n The first queue uses a byte-count of 4500 (three times the MTU)—5999 bytes
can be sent in the worst case
n The second queue uses a byte-count of 3000 (two times the MTU)—4499
bytes can be sent in the worst case
n The third queue uses byte-count 1500 (MTU)—2999 bytes can be sent in the
worst case
The first calculation shows that the first queue should receive approximately 50%
of the bandwidth.
The second calculation shows the round-robin delay of 562ms for Queue 1 when
all classes are congested.
The third calculation shows the round-robin delay of 937ms for Queue 1 when all
classes are congested and manage to send the maximum number of bytes
(byte-count + MTU - 1) in one round. Although this worst case is very unlikely it is
also unlikely that classes will use the exact configured maximum.

Worst-case Delay
• MTU=1500, byte-count (4500, 3000, 1500)

Max(delay)=(5999+4499)*8/64000=1312 ms
• MTU=1000, byte-count (4500, 3000, 1500)
Max(delay)=(5499+3999)*8/64000=1187 ms
• MTU=250, byte-count (450, 300, 150)
Max(delay)=(699+549)*8/64000=156 ms
Expected delay=(500+500)*8/64000=125 ms
Custom queuing is not appropriate for low-
delay environment. Changing MTU and byte-
counts might be a workaround.
The figure shows several calculations where the worst-case maximum delay was
reduced by reducing both the MTU and the byte-counts.
Note The calculation merely shows the impact the MTU and the byte-count have on
the delay. Lowering the MTU is not a recommended solution because it
potentially increases the CPU utilization of the router due to fragmentation of
packets.

Custom Queuing
+ Benefits
• Guarantees throughput to traffic classes (prevents
starvation between traffic classes)
– Drawbacks
• Manual configuration of classification on every hop
• Not accurate bandwidth allocation
• High jitter due to implementation of scheduling
In addition to all the benefits and drawbacks of Priority Queuing, Custom Queuing
can also guarantee bandwidth to up to 16 classes.
Custom Queuing can cause all queues to experience delay due to the
implementation of scheduling (one round can take a long time).

Custom Queuing Classification
Router(config)#
queue-list list-number protocol protocol-name
protocol-name
queue-number
queue-number queue-keyword keyword-value
• Classifies the packet into a custom queue based on

protocol and other protocol-specific criteria
• Selection criteria identical to priority queuing
Router(config)#
queue-list list-number interface incoming-intf queue-number
queue-number
• Classifies the packet into a custom queue based on

incoming interface
Custom queuing uses the same classification options as Priority Queuing. Instead
of using names queues are numbered (1 to 16).

Custom Queuing Classification
Router(config)#
queue-list list-number default
default queue-number
• Classifies all unclassified packets into a default

queue
Router(config-if)#
custom-queue list-number
• Starts custom queuing on an interface and assigns

specified CQ definition to the interface
All traffic that is not specifically classified is put into Queue 1.

n Use the queue -list default command to change the default queue.
n Use the custom-queue interface command to apply a queue-list to an
interface.

Custom Queuing
Router(config)#
queue-list list queue
queue queue-number byte-count bc
• Specifies the lower boundary on how many bytes

the system allows to be delivered from a given
queue during one round-robin cycle
Default: 1500 bytes
Router(config)#
queue-list list queue
queue queue-number limit limit
• Specifies the maximum number of packets in a

queue
• Incoming packets are tail-dropped if the limit is
exceeded
n Use the byte-count option to change the default weight of a queue (default
equals MTU size)
n Use the limit option to change the number of packets that a queue can hold
(default is 20)

Custom Queuing with Pre-
emptive Queues
Forwarded Packets
Custom Queuing has
Custom Queuing System queue 0 for system and
link-level messages which
use pre-emptive scheduling
Class 1? Tail-drop Queue 1 Hardware

Queuing System
Pre -emptive
Scheduler Hardware Q Intf
Round
Robin
Scheduler
Queue 1 is the lowest

custom queue that is
Class 16? Tail-drop Queue 16 serviced by the round
robin scheduler
Custom queuing has another queue—Queue 0. This queue is used for system
packets (routing protocols, link-level messages).
This queue is not served by the round-robin scheduler. Instead, a strict priority
scheduler is used to prioritize packets from this queue.

Custom Queuing with Pre-
emptive Queues
Forwarded Packets
Custom Queuing System

Custom queues can be
configured to use the
Class 0? Tail-drop Queue 0 pre -emptive scheduler
Class 1? Tail-drop Queue 1 Hardware

Queuing System
Pre -emptive
Scheduler Hardware Q Intf
Queue 2 is now the

Round lowest custom queue
Robin that is serviced by the
Scheduler round robin scheduler
The strict priority scheduler can be extended to other queues that are normally
served by the round-robin scheduler.
The figure illustrates how Queue 1 was moved into the priority-scheduled part of
the Custom Queuing system. The delimiter can be set to any queue by specifying
the lowest custom queue (Queue 2 in this example). In fact, Custom Queuing can
be turned into Priority Queuing with 17 queues if Queue 16 is selected as the
lowest custom queue.

Custom Queuing
Router(config)#
queue-list list-number lowest-custom queue-number
queue-number
• Set the lowest queue to be treated as custom queue

• Queues below the specified queue are pre-emptive
priority queues (Q1 having highest priority)
• Queue 0 is always treated as pre-emptive
– System and link-level messages are classified in
Q0 by default
Use the lowest-custom option to achieve the following:

n All queues from Queue 0 to the queue before the one specified in the command
use priority queuing (Queue 0 has the highest priority)
n All queues from the one specified in the command to Queue 16 use the
round-robin scheduler

Custom Queuing
Example
E0
WAN core
interface
interface serial 1/0
1/0
E1 custom-queue-list 5 Core
Branch !!
queue-list
queue-list 55 protocol
protocol ip
ip 11 list
list 101
101
office
queue-list
queue-list 5 queue 1 limit 40
queue-list
queue-list 5 lowest-custom
lowest-custom 22
queue-list
queue-list 5 interface
interface ethernet
ethernet 0/0
0/0 22
queue-list
queue-list 55 queue
queue 22 byte-count
byte-count 3000
queue-list
queue-list 5 protocol ip 3
queue-list
queue-list 55 queue
queue 33 byte-count
byte-count 5000
queue-list
queue-list 5 default
default 4
!!
access-list
access-list 101 permit
permit ip any any precedence
precedence 5
The figure shows a sample configuration where four queues are used:
n Queue 1 is used for delay-sensitive applications (marked with IP precedence
5). It uses the strict priority scheduler.
n Queue 2 is used for all packets coming from interface Ethernet0/0.
n Queue 3 is used for all IP packets that do not end in one of the first two
queues.
n Queue 4 is used for all other traffic.

Custom Queuing - Show Interface
Router#show
interface serial
serial 1/0
1/0
Serial1/0
Serial1/0 isis up,
up, line
line protocol
protocol is
is up
up
Hardware
Hardware isis M4T
M4T
Internet
Internet address
address is
is 20.0.0.1/8
20.0.0.1/8
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 19
19 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec, rely
rely 255/255,
255/255, load
load 107/255
107/255
Encapsulation
Encapsulation HDLC,
HDLC, crc
crc 16,
16, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:00,
00:00:00, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: custom-list
custom-list 55
Output
Output queues:
queues: (queue
(queue #:
#: size/max/drops)
size/max/drops)
0:
0: 0/20/0
0/20/0 1:
1: 0/40/0
0/40/0 2:
2: 0/20/0
0/20/0 3:
3: 0/20/0
0/20/0 4:
4: 0/20/0
0/20/0
5:
5: 0/20/0
0/20/0 6:
6: 0/20/0
0/20/0 7:
7: 0/20/0
0/20/0 8:
8: 0/20/0
0/20/0 9:
9: 0/20/0
0/20/0
10:
10: 0/20/0
0/20/0 11:
11: 0/20/0
0/20/0 12:
12: 0/20/0
0/20/0 13:
13: 0/20/0
0/20/0 14:
14: 0/20/0
0/20/0
15:
15: 0/20/0
0/20/0 16:
16: 0/20/0
0/20/0
…… rest
rest ignored
ignored ...
...
The show interface command is used to determine the queuing strategy of an

interface. If custom queuing is used on an interface the following information is
also displayed:
n The number of the queue-list
n Statistics for each of the 17 queues:
– Current size
– Maximum size
– Total number of drops since the last clearing of counters

Show Queueing Custom
Router#show
queueing custom
Current
Current custom
custom queue
List
List Queue Args
Args
55 33 default
default
55 11 protocol
protocol ip
ip list 101
55 22 interface
55 11 byte-count
byte-count 3000 limit 40
55 22 byte-count
byte-count 5000
• The “show queueing custom” command

displays only the non-default parameters
The show queueing custom command can be used to display all non-default
parameters of Custom Queuing.

Summary
Custom Queuing introduces a scheduler that can guarantee bandwidth to 16
classes.
In addition to the round-robin scheduling between 16 classes, a number of classes
can be switched to priority scheduling.
Review Questions
n When would you use custom queuing?
n What are the benefits and drawbacks of custom queuing?
n How many classes does custom queuing support?
n How does custom queuing schedule packets?

Weighted Fair Queuing
Objectives
n Describe WFQ
n Describe the benefits and drawbacks of WFQ
n Configure WFQ on Cisco routers
n Monitor and troubleshoot WFQ

• Queuing algorithm should fairly share the bandwidth

among flows by:
– reducing response time for interactive flows by
scheduling them to the front of the queue
– preventing high volume conversations from
monopolizing an interface
• Implementation: Messages are sorted into
conversations (flows) and transmitted by the order
of the last bit crossing its channel
• Unfairness is reinstated by introducing “weight” (IP
precedence) to give proportionately more bandwidth
to flows with higher weight
Weighted Fair Queuing (WFQ) was introduced as a solution to the problems of the
following queuing mechanisms:
n FIFO queuing causes starvation, delay and jitter
n PQ causes starvation of other lower-priority classes and suffers from all FIFO
problems within each of the four queues
n CQ causes long delays and also suffers from all FIFO problems within each of
the 16 queues
The idea of WFQ is to:
n Have a dedicated queue for each flow (no starvation, delay or jitter within the
queue)
n Fairly and accurately allocate bandwidth among all flows (minimum scheduling
delay, guaranteed service)
n Use IP precedence as weight when allocating bandwidth

Forwarded Packets
Weighted Fair Queuing System
Flow 1? WFQ-drop Queue 1
Hardware
Flow 2? WFQ-drop Queue 2 Queuing System
WFQ
Flow N? WFQ-drop Queue N
• WFQ uses per-flow FIFO queues
n WFQ uses automatic classification. Manually defined classes are not supported.
n WFQ dropping is not a simple tail-drop. WFQ drops packets of the most
aggressive flows.
n WFQ scheduler is a simulation of a TDM system (time-division multiplexer).
The bandwidth is equally distributed to all active flows.

Implementations
• Implementation parameters
–Queuing platform: central CPU or VIP
–Classification mechanism
–Weighted fairness
• Modified Tail-Drop within each queue
WFQ is supported on most Cisco routers as well as Versatile Interface Processors

(VIP). The implementation on the VIP slightly differs from the one discussed in
this lesson.
n Classification identifies a flow and assigns a queue to the flow
n Weight is used for scheduling to give proportionately more bandwidth to flows
with a higher IP precedence
n Tail-dropping scheme is improved to drop packets of the most aggressive flows

WFQ Classification
IP TCP Payload WFQ Classification uses the

following parameters:
• source IP address
• destination IP address
• source TCP or UDP port
Src. Dst. Proto. ToS Src. Dst. • destination TCP or UDP
Addr. Addr. Port Port port
• transport protocol
• type of service (ToS) field
A hash algorithm is used to

Hash Algorithm produce the index of the
queue where the packet is
enqueued
#queue (Index of the queue)

• Packets of the same flow end up in the same queue
• ToS field is the only parameter that might change causing
packets of the same flow to end up in different queues
WFQ classification has to identify individual flows (the term conversation is also
used to signify flows). A flow is identified based on the following information taken
from the IP header and the TCP or UDP headers:
n Source IP address
n Destination IP address
n Protocol number (identifying TCP or UDP)
n Type of Service Field
n Source TCP/UDP port number
n Destination TCP/UDP port number
All these parameters are usually fixed for a single flow, although there are some
exceptions:
n A QoS design could mark packets with different IP precedence values even if
they belong to the same flow. This kind of behavior should be avoided when
using WFQ.
n Some applications change port numbers (for example, TFTP).
If packets of the same flow do not have the same parameters (for example, a
different ToS field) the packets can end up in different queues and reordering can
occur.
The parameters are used as input for a hash algorithm that produces a fixed-length
number that is used as the index of the queue.

WFQ Classification
Details
• Fixed number of per-flow queues is configured

• A hash function is used to translate flow parameters
into queue number
• System packets (8 queues) and RSVP flows (if
configured) are mapped into separate queues
• Two or more flows could map into the same queue,
resulting in lower per-flow bandwidth
• Important: the number of queues configured has to
be larger than the expected number of flows
WFQ uses a fixed number of queues. The hash function is used to assign a queue
to a flow. There are eight additional queues for system packets and optionally up to
1000 queues for RSVP flows.
WFQ uses 256 queues by default. The number of queues can be configured in the
range between 16 and 4096 (the number must be a power of 2).
If there are a large number of concurrent flows it is very likely that two flows
could end up in the same queue. It is recommended to have several times as many
queues as there are flows (on the average). This may not be possible in larger
environments where the number of concurrent flows is in thousands.
The probability of two flows ending up in the same flow could be calculated using
the following formula:
Queues!
P =1−
Queues Flows
⋅ ( Queues − Flows)!
The following table lists the probability values for 3 sizes of the WFQ system (64,
128 and 256 queues), with the number of concurrent flows from 5 to 40.
Flows 64 queues 128 queues 256 queues
5 15% 8% 4%
10 52% 30% 16%
15 83% 57% 34%
20 96% 79% 53%
25 100% 92% 70%
30 100% 98% 83%
35 100% 99% 91%
40 100% 100% 96%

WFQ Insertion and Drop Policy
• WFQ has two modes of dropping:

–Early dropping when the congestion
discard threshold (CDT) is reached
–Aggressive dropping when the hold-queue
limit (HQO) is reached
• WFQ always drops packets of the most
aggressive flow
WFQ uses two parameters that affect the dropping of packets.

n The congestive discard threshold (CDT) is used to start dropping packets of
the most aggressive flow, even before the hold-queue limit is reached.
n The hold-queue limit defines the total maximum number of packets that can be
in the WFQ system at any time.

WFQ Insertion and Drop Policy
No No Enqueue
N-th packet N>HQO? N>CDT?
packet
Yes Yes
Worst Worst
Yes No
Finish Finish
Time? Time?
No Yes
Old
Drop the packet with
the worst finish time
(old) and enqueue the
N-th packet (new)
New
• HQO (hold-queue out limit) is the max . number of packets that the WFQ system can hold
• CDT (congestive discard threshold) is the threshold when WFQ starts dropping packets of
the most aggressive flow
• N is the number of packets in the WFQ system when the N -th packet arrives
The figure illustrates the dropping scheme of WFQ. The process can be split into
the following steps:
Step 1 Drop the new packet if the WFQ system is full (hold-queue limit reached) and the
new packet has the worst finish time (the last in the entire system).
Step 2 Drop the packet with the worst finish time in the WFQ system if the system is full.
Enqueue the new packet.
Step 3 Drop the new packet if the queue, where the packet should be enqueued, is the
longest (not in packets but in the finish time of the new packet) and there are more
packets in the WFQ system than the CDT.
Step 4 Otherwise enqueue the new packet.

Case Study
• WFQ system can hold a maximum of ten

packets (hold-queue limit)
• Early dropping (of aggressive flows) should
start when there are eight packets
(congestive discard threshold) in the WFQ
system
The following case study is used to describe how packets are dropped in different
situations.
The WFQ system was reduced to a modest hold-queue limit of ten and a
congestive discard threshold of eight.

Case Study
Interface Congestion
• Absolute maximum (HQO=10) exceeded, new

packet is the last in the TDM system and is
dropped
There are already ten packets in the WFQ system. The new packet would be the
eleventh and also the last in the entire WFQ system. The packet is dropped.

Case Study
Interface Congestion
• Absolute maximum exceeded (HQO=10), new

packet is not the last in the TDM system, last
packet is dropped
In this example there are also ten packets in the system when the eleventh packet
arrives. The new packet, if enqueued, would not be the last in the system. The
packet is therefore allowed to be enqueued and the last packet in the system is
deleted.

Case Study
Flow Congestion
• CDT exceeded (CDT=8), new packet would be

the last in the TDM system and is dropped
This example illustrates how WFQ can drop packets even if the WFQ system is
still within the hold-queue limit. The system, however, is above the CDT limit. In
this case a packet can be dropped if it is the last in the system.

Case Study
Flow Congestion
• CDT exceeded (CDT=8), new packet would

not be the last. Packet is enqueued
This example is different from the previous one in that the new packet would not
be the last in the WFQ system. The packet can be enqueued and no other packet
is dropped.

Drop Mechanism within WFQ
Exceptions
• Packet classified into an empty sub-queue is

never dropped
• The packet precedence has no effect on the
dropping scheme
There is an exception to the CDT rule —if the WFQ system is above the CDT
limit, and the new packet would be the last in the system, the packet is still
enqueued if the flow queue is empty.
The dropping strategy is not directly influenced by IP precedence.

WFQ Scheduling
• Each packet is tagged with its Finish time in

a virtual TDM system
• The scheduler selects the packets with the
earliest finish time tag (thus the packet that
leaves the virtual TDM the earliest)
• Reference: “On the Efficient Implementation
of Fair Queuing", Keshav, Berkeley, 1994
The length of queues (for scheduling purposes) is not in packets but in the time it
would take to transmit all the packets in the queue. The following pages discuss the
WFQ scheduling issue in detail.
The end result is that WFQ adapts to the number of active flows (queues) and
allocates equal amounts of bandwidth to each flow (queue).
The side effect is that flows with small packets (usually interactive flows) get a
much better servic e because they do not need a lot of bandwidth. They, however,
need low-delay, which they get because small packets have a low finish time.

Fair Queuing
Finish Time Calculation
If Flow
Flow FF Active,
Active,
Then FT(Pk+1
k+1) = FT(Pkk) + Size(Pk+1
k+1)
Otherwise FT(P0) = Now + Size(P0)
FT(A1)=0+100
FT(B1)=50+300 A1[100]
B1[300]
FT(A2)=100+20 A2[20]
FT(B2)=350+300 FT(A3)=120+10 A3[10]
B2[300]
t
100 70 60 50 0
Hence the resulting scheduling is:
B2 B1 A3 A2 A1
The figure illustrates how two queues (Queue A and Queue B) are contesting for
link bandwidth. For this example, assume the time units are in milliseconds and time
T (value 0 is used in the figure) is the starting point.
Queue A is receiving packets in the following order and the following times:
n Packet A1 arrives at time T + 0ms and would require 100ms to be transmitted
n Packet A2 arrives at time T + 60ms (the input interface is obviously faster than
the output interface because the arrival time of packet A2 is before the finish
time of packet A1) and would require 20 ms to be transmitted
n Packet A3 arrives at time T + 60ms (the input interface is obviously much
faster than the output interface) and would require 10 ms to be transmitted
Queue B is receiving packets in the following order and the following times:
n Packet B1 arrives at time T + 50ms and would require 300ms to be transmitted
n Packet B2 arrives at time T + 100ms and would also require 300ms to be
transmitted
The finish time of packets in Queue A are:
n Packet A1 has a finish time which is the sum of the current time (because the
queue was empty at the time of arrival) and the time it takes to transmit this
packet (100ms): FTA1 = 0ms + 100ms = 100ms
n Packet A2 has a finish time which is the sum of the finish time of the last
packet in Queue A (Packet A1) and the time it would take to transmit this

n Packet A3 has a finish time which is the sum of the finish time of the last
packet in Queue A (Packet A2) and the time it would take to transmit this
The finish time of packets in queue B are:
n Packet B1 has a finish time which is the sum of the current time (because the
queue was empty at the time of arrival) and the time it takes to transmit this
packet (300ms): FTB1 = 50ms + 300ms = 350ms
n Packet B2 has a finish time which is the sum of the finish time of the last
packet in Queue B (Packet B1) and the time it would take to transmit this
packet (300ms): FTB2 = 350ms + 300ms = 650ms
The packets are scheduled into the hardware queue (TxQ) in the ascending order
of finish times:
1. A1 (100ms)
2. A2 (120ms)
3. A3 (130ms)
4. B1 (350ms)
5. B2 (650ms)
The following remarks should be noted in conclusion of the case study:
n WFQ prevents reordering of packets within a single flow (conversation)
n Small packets are automatically preferred over large packets

Weight in WFQ Scheduling
WFQ system (real size packets)

Flow with P=001 2 1
Flow with P=000 3 2 1
Precedence-1
Virtual Packet Size = Real Packet Size / (IP precedence + 1)
packets appear
half the real size
WFQ system (virtual size packets)

Flow with P=001 4 3 2 1
Precedence -1 flow
gets twice as much
Flow with P=000 3 2 1 bandwidth as
precedence -0 flow
Hardware FIFO Queue

3 3 2 2 1 1
This figure introduces the weight into the finish time calculation. The time it takes
to transmit the packet is divided by IP precedence increased by one (to prevent
division by zero).
The WFQ implementation in Cisco routers was optimized in the following way:
n The real time it takes to transmit the packet is not relevant. The packet size can
be used instead because it is proportional to the transmit time.
n The packet size is not divided by IP precedence (division is a CPU-intensive
operation). Instead, the size is multiplied by a fixed value (one multiplication
value for each IP precedence value).
Packets with IP precedence one appear half the size they really are. The result is
that these packets receive twice as much bandwidth as packets with IP
precedence zero.

Finish Time Calculation
Finish Time is adjusted based on IP precedence of the packet

If Flow F Active,
Then FT(Pk+1) = FT(Pk) + Size(P
Size(P k+1
k+1)/(IPPrec+1)
Otherwise FT(P00) = Now + Size(P0)/(IPPrec+1)
IOS implementation scales the finish time to allow integer

arithmetic
If Flow F Active,
Then FT(Pk+1) = FT(Pk) + Size(P
Size(P k+1
k+1)*4096/(IPPrec+1)
Otherwise FT(P00) = Now + Size(P0)*4096/(IPPrec+1)
RSVP packets and high-priority internal packets (PAK-Priority)

have special weights (4 and 128)
The first formula in the figure is the first optimisation where the finish time is really
the sum of packet sizes divided by an increased IP precedence value.
The second formula shows further optimisation where, instead of dividing, the
packet size is multiplied by 4096/(IP precedence + 1). A value for each IP
precedence is stored in a table and it does not have to be calculated for each
packet.
Packets belonging to RSVP flows and system packets have special low weights
that guarantee them more bandwidth.
Note Cisco IOS versions after 12.0(5)T use a new formula where the weight is
calculated on the following formula: Weight = 32384 / (IP precedence +1)

IP Precedence to Weight
Mapping
IP Precednece Weight
0 4096
1 2048
2 1365
3 1024
4 819
5 682
6 585
7 512
32 (virtual IP precedence) 128 (PAC-Priority)
1024 (virtual IP precedence) 4 (RSVP)
• RSVP packets and high-priority internal packets (PAK-Priority) have

special weights (4 and 128)
• Lower weight makes packets appear smaller (preffered)
The table above shows the mapping between IP precedence values and WFQ
weights.
Note According to the new formula for weight in Cisco IOS versions after 12.0(5)T the
following values are used:
IP precedence 0 weight 32384


Voice and Data integration
• WAN link speed 128 kbps

• Voice requirements 30 kbps
• VoIP is precedence 5 (counts as 6 data
sessions)
• 1 VoIP session, 5 data sessions
– voice gets up to 6/(6+5)*128 = 69 kbps (enough)
• 1 VoIP session, 20 data sessions
– voice gets up to 6/(6+20)*128 = 29 kbps (problem)
The case study above is concerned with the propagation of voice packets across a
128 kbps link without using RSVP.
Assume that VoIP is using G.729 codec that uses approximately 30 kbps of
bandwidth (including RTP, UDP, IP and frame headers).
All voice packets are marked with IP precedence 5.
n The first calculation is where a voice session is contesting for available
bandwidth with 5 precedence-0 data sessions. WFQ would guarantee 69 kbps
to the voice session.
n The second calculation is where the same voice session is contesting for
available bandwidth with 20 precedence-0 data sessions. WFQ would now
guarantee only 29 kbps to the voice session.
The conclusion is that, although WFQ can give a much better service to flows with
small packets or high IP precedence value, it is not an exact tool that can
guarantee a fixed amount of bandwidth.

+ Benefits
• Simple configuration (classification does not have to be
configured)
• Guarantees throughput to all flows
• Drops packets of most aggressive flows
– Drawbacks
• All drawbacks of FIFO queuing within a single queue
• Multiple flows can end up in one queue
• Does not support the configuration of classification
• Can not provide fixed bandwidth guarantees
• Performance limitations due to complex classification and
scheduling mechanisms
The main benefits of WFQ are:

n Simple configuration (no manual classification is necessary)
n Drops packets of the most aggressive flows
The main drawbacks are:
n It is not always possible to have one flow per queue
n Does not allow manual classification
n It cannot provide fixed guarantees

Configuration
Router(config-intf)#
fair-queue [cdt [dynamic-queues [reservable-queues]]]
• congestive-discard-threshold (CDT)
–Number of messages allowed in the WFQ
system before the router starts dropping
new packets for the longest queue.
–The value can be in the range from 1 to
4096 (default is 64)
WFQ is automatically enabled on all interfaces that have a default bandwidth of

less than 2 Mbps.
Use the fair-queue command to enable WFQ on interfaces where it is not enabled
by default or was previously disabled.
The CDT value can be changed from the default 64.

Configuration
fair-queue [cdt [dynamic-queues [reservable-queues]]]
• dynamic-queues
– Number of dynamic queues used for best-effort
conversations (values are: 16, 32, 64, 128, 256,
512, 1024, 2048, and 4096 - the default is 256)
• reservable-queues
– Number of reservable queues used for reserved
conversations in the range 0 to 1000 (used for
interfaces configured for features such as RSVP -
the default is 0)
The number of dynamic queues can also be changed from the default number of
256 queues.
The maximum number of reservable queues should be set when RSVP requires
guarantees for the reserved bandwidth.

Additional Parameters
Router(config-if)#
hold-queue max-limit out
• Specifies the maximum number of packets that can

be in all output queues on the interface at any time
• The default value for WFQ is 1000
• Under special circumstances WFQ can consume a
lot of buffers which may require lowering this limit
The same hold-queue command that can be used with FIFO queuing can also be
used with WFQ. The default hold-queue limit with WFQ is 1,000 packets.
The WFQ system will generally never reach the hold-queue limit because the CDT
limit starts dropping packets of aggressive flows. Under special circumstances it
would be possible to fill the WFQ system. For example, a denial-of-service attack
that floods the interface with a large number of packets (each different) could fill
all queues at the same rate.

Fair Queuing Defaults
• Fair Queuing is enabled by default on

– physical interfaces whose bandwidth is less than
or equal to 2.048 Mbps
– interfaces configured for Multilink PPP
• Fair Queuing is disabled
– if you enable the autonomous or silicon switching
engine mechanisms
– for any sequenced encapsulation: X.25, SDLC,
LAPB, reliable PPP
The figure explains the default behavior of WFQ. As mentioned previously, WFQ
is automatically enable d on all interfaces slower than 2Mbps. WFQ is also required
on interfaces using Multilink PPP.
WFQ cannot be used if reordering of frames is not allowed due to sequence
numbering of Layer-2 frames or if the switching path does not support WFQ.

WFQ
Router#
show interface
interface interface
interface
• Displays interface delays including the activated

queuing mechanism with the summary information
Router#
show queue interface
• Displays detailed information about the WFQ system

of the selected interface
The same show commands can be used as with other queuing mechanisms:
n show interface
n show queue
n show queueing

Show Interface
Router#show
interface serial
serial 1/0
1/0
Hardware
Hardware is
is M4T
M4T
Internet
Internet address
address isis 20.0.0.1/8
20.0.0.1/8
MTU
MTU 1500
1500 bytes,
bytes, BWBW 19
19 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec, rely
rely 255/255,
255/255, load
load 147/255
147/255
Encapsulation
Encapsulation HDLC,
HDLC, crc
crc 16,
16, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:00,
00:00:00, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 0/1000/64/0
0/1000/64/0 (size/max
(size/max total/threshold/drops)
total/threshold/drops)
Conversations
Conversations 0/4/256
0/4/256 (active/max
(active/max active/max
active/max total)
total)
Reserved
Reserved Conversations
Conversations 0/0
0/0 (allocated/max
(allocated/max allocated)
allocated)
55 minute
minute input
input rate
rate 18000
18000 bits/sec,
packets/sec
55 minute
minute output
output rate
rate 11000
11000 bits/sec,
packets/sec
…… rest
rest deleted
deleted ...
...
The show interface command can be used to determine the queuing strategy. The
summary statistics are also displayed.
The sample output in the figure shows that there are currently no packets in the
WFQ system that allows up to 1,000 packets (hold-queue limit) with CDT 64.
WFQ is using 256 queues. The maximum number of concurrent conversations
(active queues) was 4.

Show Queue
Router#show
Router#show queue
queue serial
serial 1/0
1/0
Input
Input queue:
queue: 0/75/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 2/1000/64/0
2/1000/64/0 (size/max
Conversations
2/4/256 (active/max
active/max total)
total)
Reserved
Conversations 0/0
0/0 (allocated/max
allocated)
(depth/weight/discards/tail
(depth/weight/discards/tail drops/interleaves)
drops/interleaves) 1/4096/0/0/0
1/4096/0/0/0
Conversation
Conversation 124,
124, linktype:
linktype: ip,
ip, length:
length: 580
580
source:
source: 193.77.3.244,
193.77.3.244, destination:
destination: 20.0.0.2,
20.0.0.2, id:
id: 0x0166,
0x0166, ttl:
ttl: 254,
254,
TOS:
TOS: 00 prot:
prot: 6,
6, source
source port
port 23,
23, destination
destination port
port 11033
11033
1/4096/0/0/0
Conversation
Conversation 127,
127, linktype:
linktype: ip,
ip, length:
length: 585
585
source:
source: 193.77.4.111
193.77.4.111 destination:
40.0.0.2, id:
id: 0x020D,
0x020D, ttl:
ttl: 252,
252,
TOS:
TOS: 00 prot:
prot: 6,
6, source
source port
port 23,
23, destination
destination port
port 11013
11013
The show queue command also displays the flow (conversation) statistics:
n Queue depth is the number of packets in the queue
n Weight is 4096/(IP precedence + 1) or 32384/(IP precedence + 1),
depending on the Cisco IOS version
n Discards is the number of drops due to the CDT limit
n Tail drops is the number of drops due to the hold-queue limit

Queuing comparison
Weighted Fair Queuing Priority Queuing Custom Queuing
No queue lists 4 queues 16 queues
Low volume traffic High priority queue Round-robin service

given priority serviced first
Conversation Packet-by-packet
Threshold dispatching
dispatching dispatching
Interactive traffic Critical traffic gets Proportional allocation
gets priority through of bandwidth
Works well on speeds Designed for Designed for
up to 2 Mbps low-bandwidth links medium-speed links
Enabled by default Must configure Must configure
The table shows the main differences between WFQ, PQ and CQ.

Summary
The goal of WFQ is to:
n Perform queuing on a per-flow basis
n Guarantee service to all flows
n Share bandwidth fairly
n Prioritize traffic by giving higher-priority flows proportionately more bandwidth
n Prioritize low-volume (interactive) traffic
Review Questions
n How does WFQ classify packets?
n When does WFQ drop packets?
n How does WFQ schedule packets?

Distributed Weighted Fair Queuing
Objectives
n Describe and configure dWFQ
n Describe and configure ToS-based dWFQ
n Describe and configure QoS-group-based dWFQ
n Monitor and troubleshoot WFQ

Distributed WFQ
• The term “distributed” is primarily used for features

available on Versatile Interface Processors (VIP) on
Cisco 7x00 routers
• Cisco IOS supports the following four versions of
dWFQ:
– Flow-based dWFQ
– ToS-based dWFQ
– QoS-group-based dWFQ
– Distributed Class-based WFQ
• This lesson focuses on the first three versions of
dWFQ
The distributed versions of Weighted Fair Queuing are implemented on Cisco 7x00
series routers with Versatile Interface Processors (VIPs). There are four different
versions of distributed WFQ, three of which are discussed in this module:
n Flow-based dWFQ or simply dWFQ
n ToS-based dWFQ
n QoS-group-based dWFQ or QoS-based dWFQ
VIP is basically a router within a router. It has its own processor and its own
(different) version of the IOS. Most features implemented on VIPs have different
functionality than those available on the Route Switch Processor (RSP).

Flow-based dWFQ
Forwarded Packets
Flow-based dWFQ System
Hardware
Flow 2? WFQ-drop Queue 2 Queuing System
WFQ
• Flow-based dWFQ looks the same as RSP/LE

WFQ, but ...
The structure of Distributed Flow-based WFQ (dWFQ) is similar to that discussed

in the previous lesson.
There are, however, some differences.

Flow-based dWFQ Classification
IP TCP Payload
WFQ Classification uses the
• source IP address
• destination IP address
• source TCP or UDP port
Src. Dst. Proto. Src. Dst. • destination TCP or UDP
Addr. Addr. Port Port port
• transport protocol
A hash algorithm is used to

Hash Algorithm produce the index of the
queue where the packet is
enqueued
#queue (9-bit index of the queue)
• The number of queues is 512 (not tunable)

• ToS is not used for classification (except in IOS version 11.1CC)
Classification identifies flows but it does not use the ToS field. It uses all the other
parameters that identify a flow (conversation):
n Source IP address
n Protocol number (identifying TCP or UDP)
n Source TCP/UDP port number
n Destination TCP/UDP port number
The number of queues is 512 and cannot be changed.

dWFQ Insertion and Drop Policy
• dWFQ drops packets when both the

individual queue limit (IQL) and aggregate
queue limit (AQL) are reached
• dWFQ is not as strict with aggressive flows
as non-distributed WFQ
• This insertion and drop policy is the same for
all three versions of dWFQ (flow-based, ToS-
based and QoS-group-based)
The dropping scheme of dWFQ is similar to that of non-distributed WFQ, except

that it is not as strict with aggressive flows.
The same dropping policy is used for all three versions of dWFQ (Flow-based
dWFQ, ToS-based dWFQ and QoS-group-based dWFQ).

dWFQ Insertion and Drop Policy
No No Enqueue
N-th packet M>QL? N>AQL?
packet
Yes Yes
No
M>IQL?
Yes
• QL (queue limit) is the maximum number of packets the selected que ue can hold
• AQL (aggregate queue limit) is the max. number of packets that the dWFQ system can hold
• IQL (individual queue limit) is the max. number of packets that an individual queue a
congested dWFQ system can hold
• N is the number of packets in the dWFQ system when the N -th packet arrives
• M is the number of packets in the queue to which the packet is cl assified
When a new packet is to be inserted into one of the queues the router follows
these rules:
1. Enqueue the packet if the WFQ system is within the aggregate queue limit
2. Enqueue the packet if the queue is within the individual queue limit
3. Otherwise, drop the packet

Flow-based dWFQ Scheduling
Flow-based dWFQ System Packets are scheduled

(ordered) in advance for
faster transfer to the
Queue 1 hardware queue
Hardware
Queue 2 Queuing System
dWFQ
Scheduler
(Calendar Calendar Queue Hardware Q Interface
Queuing)
Queue N
• Uses Calendar Queuing (optimized version of scheduling based

on finish time, more jitter)
• Weight (IP precedence) is NOT used for scheduling purposes
(pure Fair Queuing)
The scheduler uses the same finish time calculation except it does not include the
weight. It is a pure Fair Queuing mechanism.
The scheduler was also optimized for performance (Calendar Queuing).

Configuring Flow-based dWFQ
Router(config-if)#
fair-queue
fair-queue
• The command enables dWFQ on an interface

connected to a VIP2-40 or newer interface processor
• For all other interfaces, this command enables RSP-
based WFQ
• Can be configured on interfaces but not on
subinterfaces
• dWFQ is not supported on Fast EtherChannel, tunnel,
or other logical or virtual interfaces (MPPP)
Using the fair-queue interface command enables dWFQ if the following

requirements are met:
n Interface is on a VIP2-40 or newer
n Distributed CEF is enabled

Configuring Flow-based dWFQ
Router(config)#
fair-queue aggregate-limit
aggregate-limit aggregate-packets
• The total number of packets in all output queues

before some packets may be dropped
Router(config)#
fair-queue individual-limit individual-packets
• The maximum individual per-flow queue size during

periods of congestion
• Defaults: aggregate-limit depends on the
transmission rate and the available buffer space on
the VIP; individual-limit is half of the aggregate-limit
• Don’t change the defaults unless necessary
Use these two commands to change the default limits that govern the dropping of
packets when individual queues and the WFQ system are congested.

Flow-based dWFQ
Example
interface
interface FastEthernet
FastEthernet 1/1/0
ip
ip address
address 80.0.2.70
80.0.2.70 255.255.255.0
255.255.255.0
fair-queue
fair-queue
fair-queue
aggregate-limit 200
200
fair-queue
fair-queue individual-limit
individual-limit 30
30
!!
• dWFQ on a FastEthernet interface

• dWFQ system should not contain more than
200 packets
• No queue should accept new packets when
the dWFQ system is congested and the
queue is longer than 30 packets
The example illustrates how dWFQ was implemented on a FastEthernet interface.

Show Interface
Router#show
Router#show interfaces
interfaces FastEthernet1/1/0
FastEthernet1/1/0
FastEthernet1/1/0
FastEthernet1/1/0 isis up,
up, line
line protocol
protocol is
is up
up
Hardware
Hardware is
is cyBus
cyBus FastEthernet
FastEthernet Interface,
Interface, address
address is
is 0007.f618.4448
0007.f618.4448
Description:
Description: pkt
pkt input
input i/f
i/f for
for WRL
WRL tests
tests (to
(to pagent)
pagent)
Internet
Internet address
address is
is 80.0.2.70/24
80.0.2.70/24
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 100000
100000 Kbit,
Kbit, DLY
DLY 100
100 usec,
usec, rely
rely 255/255,
255/255, load
load 1/255
1/255
Encapsulation
Encapsulation ARPA,
ARPA, loopback
loopback not
not set,
set, keepalive
keepalive not
not set,
set, 100BaseTX/FX
100BaseTX/FX
ARP
ARP type:
type: ARPA,
ARPA, ARP
ARP Timeout
Timeout 04:00:00
04:00:00
Last
Last input
input never,
never, output
output 01:11:01,
01:11:01, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters 01:12:31
01:12:31
Queueing
Queueing strategy:
strategy: VIP-based
VIP-based fair
fair queuing
queuing
Output
Output queue
queue 0/40,
0/40, 00 drops;
drops; input
input queue
queue 0/75,
0/75, 00 drops
drops
30
30 second
second input
input rate
rate 00 bits/sec,
packets/sec
30
30 second
second output
output rate
rate 00 bits/sec,
packets/sec
…… rest
rest deleted
deleted ...
...
The usual show interface command reveals that VIP-based fair queuing is
enabled (dWFQ). Some other show commands used with other queuing
mechanisms do not display any valuable information (RSP regards this interface as
FIFO).

Show Interface Fair-queue
Router#show
interface fastethernet
fastethernet 1/1/0 fair
fair
FastEthernet
FastEthernet 1/1/0
1/1/0 queue size 0
pkts
pkts output
output 0,
0, wfq drops 0, nobuffer
nobuffer drops
drops 0
WFQ:
WFQ: aggregate
aggregate queue
queue limit
limit 200 individual
individual queue
queue limit
limit 30
max available buffers 0
• Displays dWFQ statistics
This command can be used to display some statistics about dWFQ.

Benefits and Drawbacks of Flow-
based dWFQ
+ Benefits
• Automatic classification
• High performance
– Drawbacks
• Does not use IP precedence as weight
• Only supported on Cisco 7x00 series routers with
VIP 2-40 or newer
The distributed version of WFQ has one advantage over normal WFQ: better
performance.
The main drawbacks include:
n Lack of tuning capability
n Not weighted
n Only supported on VIPs

ToS-based dWFQ
Forwarded Packets
ToS -based dWFQ System
Class 1? WFQ-drop Queue 1
Hardware
Class 2? WFQ-drop Queue 2 Queuing System
dWFQ
• ToS-based dWFQ has four classes

The ToS-based dWFQ differs from Flow-based dWFQ in the following ways:
n Classification is done based on the two low-order IP precedence bits
n Scheduling is configurable by setting weights manually
n Four queues are used

ToS-based dWFQ Classification
IP Payload
ToS -based dWFQ
IP Classification uses the two
Prec. low -order IP precedence bits
to classify packets
XXX 00000
IP precedence
Queue 1 0 and 4
#queue
(2-bit index of Queue 2 1 and 5
the queue)
Queue 3 2 and 6
Queue 4 3 and 7
• The number of queues is 4 (fixed)

• Classification is based on the two low-order IP
precedence bits
The classification uses the two low-order IP precedence bits. The result of
classification is that:
n Packets with IP precedence values 0 and 4 are classified into Queue 0

ToS-based dWFQ Scheduling
• One weight per class configured as a %

–Sum of all weights must be =< 99
–Some bandwidth needed for Class 0
• Tail-Drop within each queue
• First release: 11.1cc, 12.0
Weights that determine how much bandwidth is guaranteed to each class are
configured in percentage points.
Weights can be assigned to Queues 1¸ 2 and 3. Queue 0 gets the rest of the
bandwidth.

Configuring ToS-based dWFQ
fair-queue tos
• Enables ToS-based distributed WFQ
fair-queue tos num
num weight weight
weight
tos number - 2 low order precedence bits (only classes 1, 2 and 3 can be configured
with weight; class 0 takes the remaining bandwidth)
weight - percentage of the output link bandwidth allocated to this class (the sum for all
classes cannot exceed 99)
Defaults:
unclassified traffic is assigned to class 0;
class 1 - 20, class 2 - 30, class 3 - 40
class 0 has the remaining weight (100%-W1-W2-W3); default 10
ToS-based dWFQ is enabled using the fair-queue tos interface command.
Note Distributed CEF has to be enabled prior to using this command.

Configuring ToS-based dWFQ
Router(config-if)#
fair-queue tos
tos num limit class-packets
• Configures maximum number of packets allowed in the selected queue
• If not configured, the default is individual-limit
• If queue limit is not configured it is set to the number of available buffers
multiplited by weight
Router(config-if)#
fair-queue
fair-queue individual-limit
individual-limit individual-packet
individual-packet
• If individual limit is not configured it is set to one quarter of the

number of available buffers
Router(config-if)#
fair-queue aggregate-limit aggregate-packets
• If aggregate limit is not configured is set to the number of availble

buffers
These three optional commands can be used to control individual queue sizes.
The default behavior is:
n Aggregate queue limit equals maximum available buffers
n Individual queue limit equals one quarter of maximum available buffers
n Per-queue limit equals maximum available buffers multiplied by weight

ToS-based WFQ
Configuration Example
interface
interface Hssi0/0/0
Hssi0/0/0
ip address 188.1.3.70 255.255.255.0
fair-queue tos
tos
fair-queue tos
tos 1 weight
weight 20
fair-queue tos
tos 1 limit 27
fair-queue tos
tos 2 weight
weight 30
fair-queue tos
tos 2 limit 27
fair-queue tos
tos 3 weight
weight 40
fair-queue tos
tos 3 limit 27
!!
The example shows how ToS-based dWFQ is configured on VIP-based

interfaces.

Show Interface Fair-queue
Router#show interfaces fair-queue

fair-queue
Hssi0/0/0
Hssi0/0/0 queue
queue size
size 00
pkts
pkts output
output 947,
947, wfq
wfq drops
drops 0, nobuffer drops 0
WFQ:
WFQ: aggregate
aggregate queue
queue limit
limit 386
386 individual
individual queue
queue limit
limit 96
96
max available
available buffers
buffers 386
386
Class
Class 0:
0: weight
weight 10
10 limit
limit 20 qsize
qsize 00 pkts
pkts output
output 947
947 drops
drops 00
Class
Class 1:
1: weight
weight 20
20 limit
limit 27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 2:
2: weight
weight 30
30 limit
limit 27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 3:
3: weight
weight 40
40 limit
limit 27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
The show interface fair-queue command can be issued to display parameters

and statistics for VIP-based interfaces.

Benefits and Drawbacks of ToS-
based dWFQ
+ Benefits
• Automatic classification
• Guarantees throughput to all classes
– Drawbacks
• Only four classes are supported
• Unusual interpretation of IP precedence (high-priority packets
with IP precedence 6 and 7 share queues with lower-priority
packets with IP precedence 2 and 3)
• Only supported on Cisco 7x00 series routers with VIP 2-40 or
newer
The ToS-based dWFQ represents the first class-oriented queuing mechanism

available on VIPs. The main drawbacks of this queuing mechanism are that it:
n Supports only four classes
n Mixes packets of different IP precedence values

QoS-group-based dWFQ
Forwarded Packets
QoS-group-based dWFQ System
Hardware
Class 2? WFQ-drop Queue 2 Queuing System
dWFQ
• QoS-group-based dWFQ supports 100

classes
QoS-group-based dWFQ was introduced to provide a solution to ToS-based dWFQ

drawbacks:
n 4 classes are upgraded to 100 classes
n Classification is more flexible (any other parameter can be translated into the
QoS group number)

Classification
Packet Buffer Frame IP

Payload
Buffer Header Header Header
QoS
group
• The number of queues is 100

• Classification is based on the QoS group parameter
• The parameter is local to the router and it has to be set by some
other QoS mechanism:
– Policy-based Routing (PBR)
– QoS Policy Propagation through BGP (QPPB)
– Class-based Marking
Classification is performed using the QoS group parameter to select one of the 100
queues. The QoS group parameter is local to the router so it has to be set on every
hop using one of the QoS mechanisms that supports marking:
n QoS Policy Propagation through BGP(QPPB)
n Committed Access Rate (CAR)

Scheduling
• Scheduling is identical to that of ToS-based

dWFQ
• One weight per class configured as a %
–Sum of all weights must be =< 99
–Some bandwidth needed for Class 0
• Tail-Drop within each queue
Scheduling and configuration of scheduling and dropping is identical to that of ToS-

based dWFQ. The only difference is that there are up to 100 queues to configure.

Configuring QoS-group-based
dWFQ
fair-queue qos-group
qos-group
• Enables ToS-based distributed WFQ
qos-group num weight weight
qos-group number - classes 1 through 99 can be configured with weight; class 0 takes
the remaining bandwidth
weight - percentage of the output link bandwidth allocated to this class (the sum for all
classes cannot exceed 99)
Defaults:
unclassified traffic is assigned to class 0;
class 1 - 20, class 2 - 30, class 3 - 40
class 0 has the remaining weight (100%-W1-W2-W3); default 10
Replacing ToS-based dWFQ involves using only the fair-queue qos-group

interface command. All existing fair-queue tos commands are replaced with
fair-queue qos-group commands.
Note Replacing ToS-based dWFQ with QoS-group-based dWFQ causes all packets
to go into Queue 0 because classification is no longer perform ed based on IP
precedence value. Some additional configuration steps are necessary.

Configuring QoS-group-based
dWFQ
qos-group num limit class-packets
• Configures individual queue depth

– class-packets - maximum number of packets allowed in the
queue for the class during periods of congestion
• If not configured, the default is individual-limit, which
is half of the aggregate queue limit
fair-queue
fair-queue aggregate-limit aggregate-packets
aggregate-packets
fair-queue
fair-queue individual-limit individual-packet
These commands have the same meaning as with ToS-based dWFQ.

QoS-group-based dWFQ Example
• QoS-group-based dWFQ can be used to

implement mapping of different parameters
into QoS group:
– Assume another mechanism has been configured
to translate QoS class information into QoS group
(e.g. QPPB)
– Use QoS-group-based dWFQ output queuing
• Example:
– allocate 10% to class 1 traffic
allocate 30% to class 2 traffic
allocate 60% to other traffic
The case study involves using three queues.

Classification and marking is performed using QPPB where the QoS group is set
based on some BGP information (for example, BGP community attribute).

QoS-group based WFQ
interface
interface FastEthernet1/0/0
FastEthernet1/0/0
bgp-policy
bgp-policy destination
destination ip-qos-map
ip-qos-map
!!
...
...
!!
interface
interface Hssi0/0/0
Hssi0/0/0
ip
ip address
address 188.1.3.70
188.1.3.70 255.255.255.0
255.255.255.0
bgp-policy
bgp-policy destination
destination ip-prec-map
ip-prec-map
fair-queue
qos-group
fair-queue
aggregate-limit 60
fair-queue
qos-group 1 weight
weight 10
fair-queue
qos-group 2 weight
weight 30
fair-queue
qos-group 2 limit
limit 27
27
!!

Monitoring QoS-group-based
dWFQ
Router#show
interfaces fair-queue
fair-queue
Hssi0/0/0
Hssi0/0/0 queue
queue size
size 00
pkts
pkts output
output 4,
4, wfq
wfq drops
drops 0,
0, nobuffer
nobuffer drops
drops 00
WFQ:
WFQ: aggregate
aggregate queue
queue limit
limit 60
60 individual
individual queue
queue limit
limit 96
96
max
max available
available buffers
buffers 386
386
Class
Class 0:
0: weight
weight 60
60 limit
limit 231
231 qsize
qsize 00 pkts
pkts output
output 44 drops
drops 00
Class
Class 1:
1: weight
weight 10
10 limit
limit 38
38 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 2:
2: weight
weight 30
30 limit
limit 27
27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
The show interface fair-queue command only displays information for queues
with a weight higher than zero.

Benefits and Drawbacks of QoS-
group-based dWFQ
+ Benefits
• Guarantees throughput to all classes
• A large number of classes (100)
– Drawbacks
• Requires other QoS mechanisms to set QoS group
• Only supported on Cisco 7x00 series routers with
VIP 2-40 or newer
QoS-group-based dWFQ is the first high-performance class-oriented queuing

mechanism. Its main drawback is that it is only available on Cisco 7x00 series
routers with VIPs.

dWFQ Summary
Classification Classes Weighted Implementation

Fairnes
WFQ Per-flow 16 to 4096 Yes (IP RSP/LE

precedence)
dWFQ Per-flow 512 No VIP
IP
ToS dWFQ precedence 4 Manual VIP
QoS dWFQ QoS group 100 Manual VIP
CB-WFQ* Manual 64 Manual RSP/LE/VIP
* Class-based WFQ is covered in the “Modular QoS CLI” module
The figure illustrates the comparison of all versions of Weighted Fair Queuing.
n Traditional WFQ is only available on low-end (LE) routers and the Route
Switch Processor (RSP) of Cisco 7x00 series routers
n All three distributed versions are only available on VIP-based interfaces of
Cisco 7x00 series routers
Class-based WFQ is now available on low-end routers, the RSP and on the VIP
(distributed)

Summary
There are five versions of WFQ:
n Flow-based WFQ (non-distributed, per-flow queuing)
n Flow-based dWFQ (not weighted, per-flow queuing, fixed number of queues)
n ToS-based dWFQ (four queues, limited classification options)
n QoS-group-based dWFQ (up to 100 queues, requires marking on every hop)
n CB-WFQ
Review Questions
n Which distributed Weighted Fair Queuing mechanisms do you know?
n What are the main differences between dWFQ versions?
n What platforms support dWFQ?

Modified Deficit Round-robin
Objectives
n Describe MDRR queuing
n Describe the benefits and drawbacks of MDRR queuing
n Configure MDRR queuing on Cisco GSR routers
n Monitor and troubleshoot MDRR

Modified Deficit Round Robin
• Deficit Round Robin (DRR) is a class-based

queuing mechanism available on Cisco GSR
routers
• MDRR supports 8 classes
• Low-latency queuing is introduced in the
Modified Deficit Round Robin (MDRR)
Modified Deficit Round-robin (MDRR) is a class-oriented queuing mechanism

available on Cisco 12000 series routers (GSR).
It supports eight classes, one of which can be used for low-delay propagation.

MDRR Architecture
Forwarded Packets
Modified Deficit Round Robin
Tail -drop
Class 1? VOQ 1
WRED
Hardware
Tail -drop
Class 2? VOQ 2 Queuing System
WRED
or
MDRR
Crossbar Interface
Scheduler
Switching Fabric
Tail -drop
Class 8? VOQ 8
WRED
• MDRR supports 8 classes (8 RR queues, one can be high-priority)

• MDRR is implemented on the receive side (in front of the Crossbar
Switching Matrix) and on the transmit side (in front of an interface)
MDRR classifies packets based on IP precedence value. Each queue can be

configured to support WRED.
MDRR can be implemented on output to interfaces (as in all other queuing
mechanisms) or in front of the GSR’s Crossbar Switching Matrix.

MDRR Features
• Deficit Round Robin (DRR) is using eight Virtual

Output Queues (VOQ) to prevent head-of-line
blocking
• DRR can use Weighted Random Early Detection
(WRED) within each class to prevent congestion
within the class
• Modified DRR (MDRR) can have one high priority
queue for delay-sensitive traffic being serviced in
either of the two supported modes:
– Strict priority
– Alternate priority
DRR was the first implementation that was later improved by allowing one queue
to be high priority.

MDRR Classification
IP
precedence
0
VOQ 0
IP
precedence VOQ 1
1
VOQ 2
IP VOQ 7
precedence
7
• MDRR supports classification of any IP precedence into any of the

8 virtual output queues
• One of the 8 queues can be used as low-latency queue
Classification is done using IP precedence to put packets into one of the eight
Virtual Output Queues (VOQ). One of these queues can be configured as high
priority.

MDRR Insertion and Drop Policy
Tail-drop
or Virtual Output Queue
WRED
• MDRR uses a traditional tail-drop scheme if a

queue is congested
• MDRR can also use Weighted Random Early
Detection (WRED) to prevent congestion
Each queue uses the tail-drop scheme unless it is configured with WRED.

DRR Scheduling
Each queue can transmit a configured

amount of bytes in one round:
MTU + (weight-1)*512
VOQ 0
Round
VOQ 1
Robin
Scheduler
VOQ 7
• Service policy for one queue in one round:

1. Add MTU+(Weight-1)*512 tokens to the token bucket.
2. Transmit packets until tokens are used up or the queue is empty.
3. Reset the token bucket to 0 if the queue is empty. Otherwise
remember the deficit (how much more tokens were used than
available).
4. Start serving the next queue.
The scheduling of DRR is similar to that of Custom Queuing, except it is more

accurate. DRR remembers the number of bytes it sent above the threshold in the
previous round (deficit).

MDRR Scheduling with
Strict Priority Queue
Str The Strict Priority Low-latency Queue
LL Queue ict is not limitted by the Token Bucket
Qu Priori
eui t mechanism
ng y
VOQ 0
Round
VOQ 1
Robin
Scheduler
VOQ 7
• Service policy for MDRR with Strict Priority:

1. Transmit packets from the Strict Priority Low-latency Queue until the
queue is empty.
2. Serve the next-in-line round robin queue.
3. Start serving the Low-latency queue again.
MDRR can schedule one queue ahead of all the others if it is configured as a Strict
Priority queue. This queue can be used for delay-sensitive applications (for
example, voice).
The problem of this solution is that it can cause other queues to starve if the high
priority queue is congested.

MDRR Scheduling with
Alternate Priority Queue
Alt The Alternate Priority Queue is using
LL Queue er the Token Bucket to limit the amount
Pr nate
Qu iority of bytes it can transmit in one round
eui
VOQ 0 ng
Round
VOQ 1
Robin
Scheduler
VOQ 7
• Service policy for MDRR with Alternate Priority:

1. Transmit packets from the Alternate Priority Low-latency Queue until
the tokens are used up or the queue is empty.
2. Serve the next-in-line round robin queue
3. Start serving the Low-latency queue again.
The high priority queue can be set to Alternate Priority mode where all other
queues still get service, even if the high-priority queue is congested.
The high priority queue, however, experiences slightly more delay because it has to
wait for the currently served queue to reach its threshold or be emptied.

Benefits and Drawbacks of MDRR
+ Benefits
• Accurate bandwidth allocation (takes into account the deficit
from the previous round as opposed to Custom Queuing)
• Prevents head-of-line blocking in front of the crossbar
switching fabric
• Supports low-latency queuing (strict priority and alternate
priority)
– Drawbacks
• Limited classification tools (only IP precedence)
• Limited number of classes (only 8)
• Only supported on Cisco 12000 series routers (GSR)
MDRR is a high performance queuing mechanism that supports eight classes and
allocates bandwidth according to configured weights. It also supports one queue
for low-delay propagation of packets.

Configuring Interface MDRR
Router(config)#
cos-queue-group cos-queue-group-name
cos-queue-group-name
• Create a queue group template and enter COS queue group

configuration mode
Router(config-cos-que)#
precedence precedence queue {queue-number|low-latency}
{queue-number|low-latency}
• Map IP precedence to a queue
queue queue-number weight
• Set weight of a queue
Configuration of MDRR requires a cos-queue -group to be configured first. All

MDRR configuration is performed in the cos-queue -group configuration mode.
The first step is to map an IP precedence value to one of the eight queues. Each
queue can be configured with a weight that determines the number of bytes that
can be transmitted in one round.

Configuring Interface MDRR
queue low-latency {alternate-priority weight|strict-priority}
• Specify the type of low-latency queue
Router(config-if)#
tx-cos cos-queue-group-name
• Associate a COS queue group name with the transmit queues

on an interface
One of the queues can be turned into a high priority queue. The type of queue is
determined by the alternate-priority or strict-priority keywords.
The last step is to apply the cos-queue-group to an output interface.

Configuring Receive MDRR
Router(config)#
slot-table-cos slot-table-name
• Define a slot table name and enter slot table configuration mode
Router(config-slot-cos)#
destination slot
slot {slot-number|all}
{slot-number|all} cos-queue-group-name
• Define destination slot parameters for this slot table name
Router(config)#
rx-cos-slot line-card-number cos-queue-group-name
• Link a slot-table-cos template to a line card
MDRR can also be applied to traffic leaving the line card through the Crossbar
Switching Matrix.
A slot-table -cos has to be configured where the destination line cards are
specified using the destination slot command.
The slot table is then applied to one or more line cards using the rx-cos-slot
command.

MDRR Example
interface
interface POS3/0
POS3/0
ip address 1.0.0.1 255.0.0.0
tx-cos
tx-cos C4template
C4template
!!
cos-queue-group
cos-queue-group C4template
precedence 0 queue 0
precedence 5 queue low-latency
queue 0 10
10
queue 1 20
20
queue 2 40
40
queue
queue low-latency
low-latency alternate-priority
alternate-priority 80
80
exit
exit
!!
The example illustrates a sample configuration of MDRR applied to traffic leaving

the POS interface.

MDRR
Router#
show cos statistics
• Display MDRR statistics
Router#show
Router#show cos statistics
Slot
Slot 33
---------------
---------------
Dest
Dest slot
slot 55
cos-queue-group:
cos-queue-group: C7template
C7template
...
...
Queue
Queue Lengths
Lengths
To
To Fabric
Fabric Queues
Queues (DRR
(DRR configured)
configured) C7template
Queue
Queue Average
Average High
High Water
Water Mark
Mark Weight
Weight
00 712.000
712.000 5562.000
5562.000 10
10
11 702.000
702.000 7716.000
7716.000 10
10
22 702.000
702.000 11540.000
11540.000 10
10
33 753.000
753.000 14368.000
14368.000 10
10
44 0.000
0.000 0.000
0.000 10
10
55 0.000
0.000 0.000
0.000 10
10
66 0.000
0.000 0.000
0.000 10
10
Low latency
Low latency 0.000
0.000 0.000
0.000 10
10
...
...
The show cos statistics can be used to display results of MDRR.

Summary
MDRR is a class-oriented queuing mechanism available on the Cisco 1200 series
routers. It allows bandwidth guarantees to eight classes and low-delay propagation
to one class.
MDRR can be applied to outbound traffic or traffic leaving a line card through the
Crossbar Switching Matrix.
Review Questions
n Describe the scheduling mechanism of MDRR.
n Which two types of low-latency queuing does MDRR support?
n What are the benefits and drawbacks of MDRR?
n Where can MDRR be applied?

Objectives
n Describe IP RTP prioritization
n Describe the benefits and drawbacks of IP RTP prioritization
n Configure IP RTP prioritization on Cisco routers
n Monitor and troubleshoot IP RTP Prioritization

• IP RTP Prioritization provides low-latency

queuing when used in combination with WFQ
or CB-WFQ
• It can only be used with UDP traffic with
predictable port numbers
• It is usually used for VoIP traffic
• IP RTP Prioritization is limited to prevent
starvation of other traffic
IP RTP Prioritization is an add-on to WFQ to support low-delay propagation of

packets. It can be used for UDP traffic only.
IP RTP Prioritization also polices the high priority traffic to prevent starvation of
other queues.

Forwarded Packets
High
Priority?
Weighted Fair Queuing System

Hardware
Queuing System
RTP
Flow 2? WFQ-drop Queue 2 Hardware Q Interface
WFQ
Scheduler
Scheduler
• IP RTP prioritization adds one high-priority

queue to WFQ
IP RTP Prioritization supports one high priority queue. Packets from this queue are
scheduled ahead of other packets as long as they are within the configured rate.
Excess packets are dropped.

IP RTP Priority Classification
Forwarded Packets
IP UDP Payload
UDP
Destination port
UDP port Yes

RTP Queue
In range?
No WFQ
Queuing
System
• IP RTP Prioritization classifies packets based

on the UDP port number
• Classification is specified by a range of UDP
port numbers
IP RTP Prioritization classifies packets based on UDP port numbers.

If the destination UDP port is within the configured range it is enqueued into the
high priority queue.

IP RTP Priority Insertion and Drop
Policy
Classified Packets
Packet
Token Yes
within RTP Queue
Bucket Contract?
No
• IP RTP Prioritization limits the amount of

high-priority traffic
• Excess traffic is dropped
Packets that exceed the policy are dropped. A token Bucket model is used to
measure the arrival rate of packets into this queue.

Benefits and Drawbacks of IP RTP
Prioritization
+ Benefits
• Adds low-latency queuing to WFQ and CB-
WFQ
• Prevents starvation of other traffic
– Drawbacks
• Poor classification options
• Obsoleted by Class-based Low-latency
Queuing
The main benefit of IP RTP Prioritization is that it allows low-latency propagation

when using WFQ.
The main drawback is that it has limited classification capabilities (UDP port range
only).
IP RTP Prioritization was made obsolete by the introduction of Class-based Low
Latency Queuing (discussed in the “IP QoS - Modular QoS CLI” module).

Configuring IP RTP Prioritization
Router(config-if)#
ip rtp priority
priority starting-port port-range
port-range bandwidth
bandwidth
• Creates a separate priority queue for VoIP packets and specifies

maximum bandwidth available to voice traffic
• Maximum bandwidth shall always be slightly larger than actually
required bandwidth due to jitter in the network and the Layer-2
overhead
• Only UDP packets with a destination port number in the configured
range are classified into this queue
Router(config-if)#
max-reserved-bandwidth percent
• Specifies the maximum bandwidth percentage that can be allocated

to class-based WFQ and priority RTP traffic
• The remaining bandwidth is available to flow-classified best-effort
traffic and control packets
• Default: 75% of the interface bandwidth can be reserved
Configuration of IP RTP Prioritization requires using the ip rtp priority command

where the following parameters have to be specified:
n Starting UDP port number
n UDP port range (added to the starting port number)
n Maximum and guaranteed bandwidth
If the requested bandwidth is less than 75% of the bandwidth configured on the
interface, the command will fail. Reservable bandwidth can be increased by using
the max-reserved-bandwidth interface command.

Example
interface
interface Serial0/0
Serial0/0
bandwidth
bandwidth 128
ip
ip address
address 10.0.0.1
10.0.0.1 255.255.255.252
encapsulation ppp
ppp
fair-queue
fair-queue Up to 75% of configured bandwidth is
ip
ip rtp priority 16384 16383 50
50 reservable.
!!
BWavail = BW * 0.75 - BWRTP
Router#show
Router#show queue
queue serial0/0
serial0/0
Input
Input queue:
queue: 0/75/0/0
0/75/0/0 (size/max/drops/flushes);
(size/max/drops/flushes); Total
Total output
output dr
drops:
ops: 00
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations
0/1/256 (active/max
active/max total)
total)
Reserved
Conversations 0/0
0/0 (allocated/max
allocated)
Available
Available Bandwidth
Bandwidth 46
46 kilobits/sec
kilobits/sec
Router#
Router#
The sample configuration shows how 50 kbps of bandwidth is guaranteed for RTP
traffic. The show queue command shows there is only 46 kbps of bandwidth (128
kbps • 75% -50 kbps = 46 kbps) remaining for WFQ.

Summary
IP RTP Prioritization adds low-latency queuing capability to WFQ. It can only
classify packets into one queue based on the UDP port range.
Review Questions
n When would you use IP RTP prioritization?
n What are the drawbacks of IP RTP prioritization?
n How many high-priority queues does IP RTP prioritization support?

Summary
n Describe and configure FIFO Queuing (FQ)
n Describe and configure Priority Queuing (PQ)
n Describe and configure Custom Queuing (CQ)
n Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ,
ToS-based distributed WFQ and QoS-group-based distributed WFQ
n Describe and configure Modified Weighted Round-robin (MDRR) queuing
n Describe and configure IP RTP Prioritization

Queuing Overview
Question: Which queuing mechanisms do Cisco routers support?
Answer: First In First Out (FIFO), Priority Queuing (PQ), Custom Queuing
(CQ), Weighted Fair Queuing (WFQ) with the different distributed versions,
Modified Deficit Round Robin (MDRR), IP RTP Prioritization, Class-based
WFQ and Class-based Low-latency Queuing.
Question: When is a software queuing mechanisms not used?
Answer: Routers bypass the software queue (hold queue) if it is empty and there
is room in the hardware queue (TxQ).
Question: How does TxQ length affect the software queuing system?
Answer: A long TxQ can cause FIFO drawbacks; a short TxQ can cause high
CPU utilization and low link utilization.
FIFO Queuing
Question: Why is FIFO the fastest queuing mechanism?
Answer: It has no classification and the simplest scheduling mechanism.
Question: Describe the classification and scheduling of FIFO queuing.
Answer: FIFO has only one queue and all packets are enqueued into this queue.
Scheduling takes packets out of the queue in the order they arrived (first come
first serve).
Question: List the drawbacks of FIFO queuing.
Answer: FIFO queuing can cause starvation and jitter.
Priority Queuing
Question: When would you use priority queuing?
Answer: To provide minimum-delay forwarding for delay-sensitive packets.
Question: What are the benefits and drawbacks of priority queuing?
Answer: PQ has all the drawbacks of FIFO queuing within each class and in
addition it can cause starvation of lower-priority classes.
Question: How many classes does priority queuing support?
Answer: PQ supports four classes.
Question: How does priority queuing schedule packets?

Answer: PQ schedules packets in the priority order. Lower-priority packets are
scheduled only when all higher-priority queues are empty.
Custom Queuing
Question: When would you use custom queuing?
Answer: CQ is used to guarantee bandwidth to traffic classes.
Question: What are the benefits and drawbacks of custom queuing?
Answer: CQ has all the drawbacks of FIFO queuing within each class. In
addition CQ can cause jitter due to the implementation of scheduling.
Question: How many classes does custom queuing support?
Answer: CQ supports up to 16 classes.
Question: How does custom queuing schedule packets?
Answer: CQ uses weighted round robin scheduling to ensure that each class is
serviced.

Question: How does WFQ classify packets?
Answer: WFQ classifies packets based on the flow information (source and
destination IP addresses and TCP/UDP port numbers, protocol identifier and
ToS field).
Question: When does WFQ drop packets?
Answer: WFQ drops packets of the longest queue when the number of packets
in the queuing system reaches the CDT (congestive discard threshold).
Question: How does WFQ schedule packets?
Answer: WFQ schedules packets with the shortest finish time.
Distributed Weighted Fair Queuing

Question: Which distributed Weighted Fair Queuing mechanisms do you know?
Answer: Distributed WFQ versions: flow-based, ToS-based and QoS-group-
based.
Question: What are the main differences between dWFQ versions?
Answer: Distributed versions of WFQ differ primarily in the classification.
Question: What platforms support dWFQ?
Answer: Cisco 7x00 series routers with VIP-based interfaces support dWFQ.

Modified Deficit Round-robin
Question: Describe the scheduling mechanism of MDRR.
Answer: MDRR uses an improved implementation of round robin scheduling to
provide more accurate allocation of bandwidth.
Question: Which two types of low-latency queuing does MDRR support?
Answer: MDRR can use one queue for strict priority or alternate priority queuing.
Question: What are the benefits and drawbacks of MDRR?
Answer: MDRR is fast accurate and prevents head-of-line blocking in front of the
crossbar switching matrix. MDRR only supports 8 queues and can only classify
based on IP precedence.
Question: Where can MDRR be applied?
Answer: MDRR can be used on output interfaces or in front of the crossbar
switching matrix.
Question: When would you use IP RTP prioritization?
Answer: To provide low-latency queuing with IOS versions that do not support
CB-LLQ.
Question: What are the drawbacks of IP RTP prioritization?
Answer: Limited classification options (only one UDP port range is supported).
Question: How many high-priority queues does IP RTP prioritization support?
Answer: One per interface.

4
Traffic Shaping and

Policing
Overview
This module describes for the QoS mechanisms that are used to limit the available
bandwidth to traffic classes. It discusses two options—traffic policing and traffic
shaping. Committed Access Rate (CAR) is discussed as a mechanism to provide
traffic policing. Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping
(FRTS) are discussed as traffic shaping mechanisms.
n Traffic Shaping and Policing
n Generic Traffic Shaping
n Frame Relay Traffic Shaping
n Committed Access Rate
Objectives
n Describe and configure Generic Traffic Shaping (GTS)
n Describe and configure Frame Relay Traffic Shaping (FRTS)
n Describe and configure Committed Access Rate (CAR)
n Identify other mechanisms that support traffic shaping and policing (Class-
based Policing and Class-based Shaping)
Traffic Shaping and Policing
Overview
The lesson introduces mechanisms for traffic policing and traffic shaping.
Committed Access Rate (CAR), Generic Traffic Shaping (GTS) and Frame Relay
Traffic Shaping (FRTS) are introduced in this section.
Objectives
n Describe the need for implementing traffic policing and shaping mechanisms
n List traffic policing and shaping mechanisms available in Cisco IOS
n Describe the benefits and drawbacks of traffic shaping and policing
mechanisms
4-2 IP QoS Traffic Shaping and Policing Copyright  2001, Cisco Systems, Inc.
Meter

Traffic
stream
• Traffic Shaping and Policing mechanisms are used to rate-limit

traffic classes
• They have to be able to classify packets and meter their rate of
arrival
• Traffic Shaping delays excess packets to stay within the rate
limit
• Traffic Policing typically drops excess traffic to stay within the
limit; alternatively it can remark excess traffic
© 2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing-5
Both shaping and policing mechanisms are used in a network to control the rate at
which traffic is admitted into the network. Both mechanisms use classification, so
they can differentiate traffic. They also use metering to measure the rate of traffic
and compare it to the configured shaping or policing polic y.
The difference between shaping and policing can be described in terms of their
rate-limiting implementation:
n Shaping meters the traffic rate and delays excessive traffic so that it stays
within the desired rate limit. With shaping, traffic bursts are smoothed out
producing a steadier flow of data. Reducing traffic bursts helps reduce
congestion in the core of the network.
n Policing drops excess traffic in order to control traffic flow within specified
limits. Policing does not introduce any delay to traffic that conforms to traffic
policies. It can however, cause more TCP retransmissions, because traffic in
excess of specified limits is dropped.
Copyright  2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing 4-3
Why Use Rate Limiting
• To handle congestion at ingress to ATM/FR

network with asymmetric link bandwidths
• To limit access to resources when high-
speed access is used but not desired
• To limit certain applications or classes
• To implement a virtual TDM system
Rate limiting is typically used to satisfy one of the following requirements:

n Prevent and manage congestion in ATM and Frame Relay networks, where
asymmetric bandwidths are used along the traffic path. This prevents the
layer-2 network from dropping large amounts of traffic by differentiately
dropping excess traffic at ingress to the ATM or Frame Relay networks based
on Layer-3 information (for example: IP precedence, DSCP, access list,
protocol type, etc.)
n Limit the access rate on an interface when high-speed physical infrastructure
is used in transport, but sub-rate access is desired.
n Engineer bandwidth so that traffic rates to certain applications or classes of
traffic follow a specified traffic -rate policy.
n Implement a virtual TDM system, where an IP network is used, but has the
bandwidth characteristics of a TDM system (that is, fixed maximum available
bandwidth). Inbound and outbound policing can, for example, be used on one
router to split a single point-to-point link into two or more virtual point-to-point
links by assigning a portion of the bandwidth to each class, thus preventing any
class from monopolizing the link in either direction.
Typical Traffic Shaping or
Policing Applications
High-speed Low-speed
link link
WAN
Output interface is Congestion in WAN

not congested network results in
queuing and WRED non-intelligent layer-
do not work 2 drops
256 kbps Implementing a

Limiting access to virtual TDM or
resources Leased line over a
FastEthernet
64 kbps single physical link
on one side
128 kbps
Server
Farm Internet
The figure shows three possible applications of rate-limiting (shaping or policing)

mechanisms. The first picture shows a Layer-2 WAN with unequal link
bandwidths along a Layer-3 path. The ingress (left side) of the network has a high-
speed link available into the Layer-2 backbone, which enables it to send traffic at a
high rate. At the egress side, the sent traffic hits a low-speed link, and the Layer-2
network is forced to drop a large amount of traffic. If traffic were rate-limited at
the ingress, optimal traffic flow occurs, resulting in minimal dropping by the Layer-
2 network.
The second picture shows a hosting farm, which is accessible from the Internet via
a shared link. Depending on the service contract, the hosting provider may offer
different bandwidth guarantees to customers, and may want to limit the resources
a particular server uses. Rate limiting can be used to divide the shared resource
(upstream link) between many servers.
The third example shows the option of implementing virtual leased lines over a
Layer-3 infrastructure, where rate-limited reserved bandwidth is available over a
shared link.
Shaping vs. Policing
• Benefits of Shaping
– Shaping does not drop packets
– Shaping supports interaction with Frame Relay
congestion indication
• Benefits of Policing
– Policing supports marking
– Less buffer usage (shaping requires an additional
queuing system)
A shaper typically delays excess traffic using a buffer, or mechanism, to hold

packets and shape the flow when the data rate of the source is higher than
expected. Traffic shaping smoothes traffic by storing traffic above the configured
rate in a queue. Therefore, shaping increases buffer utilization on a router, but
causes non-deterministic packet delays. Shaping can also interact with a Frame
Relay network, adapting to indications of Layer-2 congestion in the WAN.
A policer typically:
n Drops non-conforming traffic
n Supports marking of traffic
n Is more efficient in terms of memory utilization (no additional buffering of
packets in needed)
n Does not increase buffer usage
Both policing and shaping ensure that traffic does not exceed a bandwidth limit, but
they have different impacts on the traffic:
n Policing drops packets more often, generally causing more retransmissions of
connection-oriented protocols
n Shaping adds variable delay to traffic, possibly causing jitter
How do Routers Measure Traffic
Rate
Bandwidth
Link bandwidth
Exceeding traffic
Rate limit
Conforming Traffic
Time
• Routers use the Token Bucket mathematical model to keep
track of packet arrival rate
• The Token Bucket model is used whenever a new packet is
processed
• The return value is conform or exceed
In order to perform rate limiting, routers must meter (or measure) traffic rates
through their interfaces. To enforce a rate limit, metered traffic is said to:
n Conform to the rate limit, if the rate of traffic is below or equal to the
configured rate limit
n Exceed the rate limit, if the rate of traffic is above the configured rate limit
The metering is usually performed with an abstract model called a token bucket,
which is used when processing each packet. The token bucket can calculate
whether the current packet conforms or exceeds the configured rate limit on an
interface.
Token Bucket
200
700
500 bytes Conform Action 500 bytes
© 2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing -10
The token bucket is a mathematical model used in a device that regulates the data
flow. The mode has two basic components:
n Tokens: where each token represents the permission to send a fixed number of
bits into the network
n The bucket: which has the capacity to hold a specified amount of tokens
Tokens are put into the bucket at a certain rate by the operating system. Each
incoming packet, if forwarded, takes tokens from the bucket, representing the
packet’s size.
If the bucket fills to capacity, newly arriving tokens are discarded. Discarded
tokens are not available to future packets.
If there are not enough tokens in the bucket to send the packet, the regulator may:
n Wait for enough tokens to accumulate in the bucket (traffic shaping)
n Discard the packet (policing)
The figure shows a token bucket, with the current capacity of 700 bytes. When a
500-byte packet arrives at the interface, its size is compared to the bucket capacity
(in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), and the
packet is forwarded. 500 tokens are taken out of the token bucket leaving 200
tokens for the next packet.
Token Bucket
200
300 bytes Exceed Action
300
byte
s
When the next packet arrives immediately after the first packet, and no new
tokens have been added to the bucket (which is done periodically), the packet
exceeds the rate limit. The packet size is greater than the current capacity of the
bucket, and the exceed action is performed (drop in the case of pure policing, delay
in the case of shaping).
Token Bucket
Be
Link BW
Bc of tokens is added Link
Utilization
every Tc [ms]
Bc Bc Bc Bc Bc Bc Average BW
Tc = Bc / CIR (CIR)
Tc 2*Tc 3*Tc 4*Tc 5*Tc Time
Bc + B e
• Bc is normal burst size (specifies sustained rate)

• Be is excess burst size (specifies length of burst)
Token bucket implementations usually rely on three parameters: CIR, Bc and Be.
CIR is the Committed Information Rate (also called the committed rate, or the
shaped rate). Bc is known as the burst capacity. Be is known as the excess burst
capacity. Tc is an interval constant that represents time. A Bc of tokens are
forwarded without constraint in every Tc interval.
In the token bucket metaphor, tokens are put into the bucket at a certain rate,
which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If
the bucket fills to capacity (Bc + Be), it will overflow and therefore newly arriving
tokens are discarded. Each token grants permission for a source to send a certain
number of bits into the network. To send a packet, the regulator must remove,
from the bucket, the number of tokens equal in representation to the packet size.
For example, if 8000 bytes worth of tokens are placed in the bucket every 125
milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if
traffic constantly arrives at the router.
If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the
bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore
collects 64000 bytes worth of tokens, which can be transmitted immediately in the
case of a burst. The upper limit, Bc+Be, defines the maximum amount of data,
which can be transmitted in a single burst, at the line rate.
Note Again, note that the token bucket mechanism used for traffic shaping has both a
token bucket and a queue used to delay packets. If the token bucket did not have
a data buffer, it would be a policer. For traffic shaping, packets that arrive that
cannot be sent immediately (because there are not enough tokens in the bucket)
are delayed in the data buffer.
Although token bucket permits burstiness, traffic bursts are bound. This guarantee
is made so that traffic flow will never send faster than the token bucket's capacity.
In the long-term, this means that the transmission rate will not exceed the
established rate at which tokens are placed in the bucket (the committed rate).
Mechanisms
• Shaping Mechanisms:
• Policing Mechanisms:
There are five token-bucket based rate-limiting methods available in Cisco IOS.
Three methods are shaping mechanisms:
n Generic traffic shaping
n Frame Relay traffic shaping
n Class-based shaping
Two methods are policing mechanisms:
n Committed access rate
n Class-based policing
All these methods are discussed next in specific sections.
Summary
n Describe the need for implementing traffic policing and shaping mechanisms
n List traffic policing and shaping mechanisms available in Cisco IOS
n Describe the benefits and drawbacks of traffic shaping and policing
mechanisms
Lesson Review
1. How do shaping and policing mechanisms keep track of the traffic rate?
2. Which shaping mechanisms are available with the Cisco IOS software?
3. Which policing mechanisms are available with the Cisco IOS software?
4. What are the main differences between shaping and policing?
Generic Traffic Shaping
Overview
This lesson describes the Generic Traffic Shaping (GTS) mechanism.
Objectives
n Describe the GTS mechanism
n Describe the benefits and drawbacks of GTS
n Configure GTS on Cisco routers
n Monitor and troubleshoot GTS
Meter
Shaper
Classifier Marker
Dropper
Traffic
stream
• Can shape multiple classes (classification)

• Can measure traffic rate of individual classes
(metering)
• Delays packets of exceeding classes
(shaping)
Generic Traffic Shaping (GTS) shapes traffic by reducing the outbound traffic flow
to avoid congestion. This is achieved by constraining traffic to a particular bit rate
using the token bucket mechanism. GTS is applied on a per-interface basis and can
use access lists to select the traffic to shape. It works with a variety of Layer-2
technologies, including Frame Relay, ATM, Switched Multi-megabit Data Service
(SMDS) and Ethernet.
As shown in the block diagram, GTS performs three basic functions:
n Classification of traffic, so that different traffic classes can have different
policies applied to them
n Metering, using a token-bucket mechanism, to distinguish between conforming
and exceeding traffic
n Shaping, using buffering, to delay exceeding traffic and shape it to the
configured rate limit
GTS Building Blocks
Shaping
Forwarder Classifier Yes No
WFQ
No
No Shaping
Classifier Yes Yes WFQ
No
Yes
Shaping
Classifier Yes No
WFQ
Yes
No
Physical Interface
queue(s)
GTS is implemented as a queuing mechanism, where there are separate WFQ

delay queues implemented for each traffic class. Each WFQ-queue delays packets
until they conform to the rate-limit, and also schedules them according to the WFQ
algorithm. Conforming traffic is then sent to the physical interface.
Arriving packets are first classified into one of the shaping classes. Traffic not
classified into any class is not shaped. Classification can be performed using
access lists.
Once a packet is classified into a shaping class, its size is compared to the amount
of available token in the token bucket of that class. The packet is forwarded to the
main interface queue if there are enough tokens. A number of tokens taken out of
the token bucket is equal to the size of the packet (in bytes).
If, on the other hand, there are not enough tokens to forward the packet, the
packet is buffered in the WFQ system assigned to this shaping class. The router
will then periodically replenish the token bucket and check if there are enough
tokens to forward one or more packets out of the shaping queue. Packets are
scheduled out of the shaping queue according to the WFQ scheduling algorithm.
GTS Overview
• GTS is multiprotocol
• GTS uses WFQ as the shaping queue
• GTS can be implemented in combination with
any queuing mechanisms:
– FIFO Queuing
– Weighted Fair Queuing (WFQ)
• GTS works on output only
The GTS implementation in Cisco IOS supports multiple protocols and works on a
variety of interface types. WFQ is used as the shaping delay queue, providing fair
scheduling within a traffic class. Other queuing strategies (FIFO, PQ, CQ and
WFQ) may be employed after GTS to provide traffic scheduling on the shaped
traffic. Also, GTS only works at the output of an interface.
GTS can be used to shape all outbound traffic on an interface or it can separately
shape multiple classes. Classification is performed using any type of access list
including all non-ip access lists.
GTS Implementation
Dispatches Dispatches Dispatches

packets at packets at line packets at line
configured rate rate rate
Shaping Software Hardware

Queue Queue Queue
(FIFO, PQ,
(WFQ) (FIFO)
CQ, WFQ, ...)
Bypass the software queue

if it is empty and there is
room in the hardware queue
• The software queue may have no function if

the sum of all shaping rates is less than link
bandwidth
Packet flow through GTS is implemented using three queues. The first, the shaping
queue, is WFQ-based and shapes traffic according to the specified rate using a
token bucket model. This queue dispatches packets to the software queue, which
may be configured with other queuing mechanisms (PQ, CQ, WFQ or FIFO). If
the software queue is empty, traffic is forwarded directly to the output hardware
queue.
GTS supports distributed implementation on VIP adapters. This offloads traffic
shaping from the route switch processor (RSP) to the Versatile Interface
Processor (VIP), and constructs all of the queues in VIP packet memory. Only IP
traffic can be shaped with dWFQ. Another requirement is that dCEF switching
must be enabled.
Configuring GTS
Router(config-if)#
traffic-shape rate bit-rate [burst-size [excess-
burst-size]]
• Enables traffic shaping of all outbound

(sub)interface traffic
• In IOS versions prior to 11.2(19) and 12.0(4),
optimum switching is disabled on all interfaces if
traffic shaping is enabled on any interface
To enable traffic shaping for outbound traffic on an interface, use the traffic-
shape rate interface configuration command. Of the parameters to be specified,
bit-rate is the only mandatory one. The burst-size and excess-burst-size are
optional.
Generic traffic shaping can be used in all switching paths. Older Cisco IOS
versions may use slower switching paths when GTS is in effect.
Configuring GTS
Router(config-if)#
burst-size]]
• Bit rate – average traffic rate in bps (equivalent to

Frame Relay CIR)
• Burst size – amount of traffic sent in a measurement
interval in bits (equivalent to Frame Relay Bc)
Default value: 1/8 of bit rate
Bit rate (in bits per second) is configured as the average traffic rate to which the
traffic should be shaped on the output of the interface.
Burst size (in bits) can be configured to allow for varying levels of allowed
burstiness. That is, traffic, which bursts over the average traffic rate, also
conforms if it falls within the burst rate in an interval. By default, this is set to one
eighth of the average traffic rate, which sets the Tc at one eighth of a second. This
parameter is equivalent to the Frame Relay Bc parameter.
Configuring GTS
Router(config-if)#
burst-size]]
• Excess-burst-size - amount of excess traffic that

can be sent during the first burst in bps (equivalent
to Frame Relay Be)
Default value: no excess burst
• Measurement interval (Tc) is computed from bit-rate
and burst -size
Tc smaller than 25 ms is rejected, Tc greater than
125 ms is reduced
The excess-burst-size parameter (in bits), equivalent to the Frame Relay Be

parameter, defines the excess burst of traffic, which can still be sent through the
first noticed burst. By default, there is no excess burst allowed.
The Tc parameter defines the measurement interval, which is used in the operation
of the token bucket. By default, it is directly computed from the bit rate and the
burst size as Bc divided by the average bit rate. To ensure proper operation of
shaping, those parameters are bounded to values between 25 and 125 ms.
Configuring GTS
Router(config-if)#
traffic-shape group access-list bit-rate [burst
[excess-burst]]
• Shapes outbound traffic matched by the specified access list

• Several traffic-shape group commands can be configured on
the same interface
• The “traffic-shape rate“ and “traffic-shape group“ commands
cannot be mixed on the same interface
• Separate token bucket and shaping queue is maintained for
each traffic-shape group command
• Traffic not matching any access list is not shaped
Classification of traffic to be shaped is performed using access lists. To enable

traffic shaping based on a specific access list for outbound traffic on an interface,
use the traffic-shape group interface configuration command. The traffic-shape
group command allows specification of one or more previously defined access
lists to shape traffic on the interface. One traffic-shape group command must be
specified for each access list on the interface.
Cisco IOS uses separate token buckets and shaping queues for each class, as
differentiated by the access list specification. Traffic not matching any access list
bypasses traffic shaping and is immediately sent to the software or hardware
interface queue.
Use the traffic-shape rate command if no classification is needed and shaping
should be applied to all traffic. Remember that the traffic-shape group command
using an IP access list permitting all IP traffic is not equivalent to the traffic-shape
rate command if non-IP traffic is present in the network.
GTS
Example #1
• ISP wants to sell a service in which a

customer may use all of a E1 line for 30
seconds in a burst, but on a long term
average is limited to 256 kbps
• GTS parameters
– bit-rate: 256000 - output rate is 256000 bps
– burst-size: 32000 the number of bits sent in 125
msec
– excess-burst-size: 61440000 = 2048000 * 30
In the first GTS example, an ISP wants to control the amount of traffic injected
into the Frame Relay WAN by the customer. The SP service uses an E1 line as
the access line, limits the customer to 256 Kbps on the average, but also permits
bursts of up to thirty seconds at the E1 line rate.
The parameters are calculated based on the service requirements. CIR (the
average bit rate) is set at the specified average rate, the burst size is set to one
eighth of the CIR (32000 bits), and the excess burst size reflects the allowed thirty-
second burst at full E1 line rate.
The excess burst size was calculated using the following formula:
1. Each second of transmission at line-speed requires 2 Mbits
2. Thirty second burst therefore requires 30 x 2 Mbits
3. The excess burst size is 30 x 2048000 = 61440000
It takes thirty seconds to empty the token bucket. How long does it take to fill it up
again?
The token bucket is emptied at 2Mbps but it is replenished at 256kbps. It takes
eight times as long to fill it as it does to empty it. Every thirty second burst would,
therefore, require a four-minute silence on the line to accumulate tokens.
GTS
Example #1
WAN
Core
Customer
interface
interface ethernet
ethernet0/0
0/0
traffic-shape
traffic-shape rate
rate 256000
256000 32000
32000 61440000
61440000
!!
interface
interface serial1/0
serial 1/0
traffic-shape
traffic-shape rate
rate 256000
256000 32000
32000 61440000
61440000
• Since ISP wants to control the total amount of load

the configuration would be done on both the
inbound and outbound interfaces
The figure shows the router configuration required to implement this service. All
the output traffic is shaped, and the shaping needs to be configured on all customer
edge sites, which will perform admission control using GTS.
GTS
Example #2
WAN
Core
Customer
interface
interface ethernet
ethernet 0/0
0/0
traffic-shape
traffic-shape group
group 101
101 64000
64000
interface
interface serial
serial 1/0
1/0
traffic-shape
traffic-shape group
group 101
101 64000
64000
!!
access-list
access -list 101
101 permit
permit tcp
tcp any
any any
any eq
eq www
www
• The customer wants to be sure that Web

traffic will never use more than 64 kbps
In the second example, a customer wants to limit web usage, so that web traffic
never uses more than 64 Kbps on the access link. The router configuration is
shown in the figure, using default parameters for traffic bursts. An access list
defines web traffic as the only shaped traffic. All other traffic bypasses GTS and
can use the full access line bandwidth.
Monitoring GTS
Router(config)#
show traffic-shape
• Displays current traffic shaping configuration
MAX = (Bc + Be)/8 Be Bc = Tc * CIR
Router#show traffic-shape
access Target Byte Sustain Excess Interval Increment Adapt
I/F list Rate Limit bits/int bits/int (ms) (bytes) Active
Se3/3 100000 2000 8000 8000 80 1000 -
CIR Bc Tc=Bc/CIR do we listen to

FECN/BECN?
The figure shows the results of the show traffic-shape command issued on a
router that shapes traffic to 100kbps with Bc and Be set to 8000.
To display the current traffic-shaping configuration, use the show traffic-shape
command. To display the current traffic -shaping statistics, use the show traffic-
shape statistics command. Output of both the commands is detailed in the
ensuing figures.
Information displayed includes:
n The rate that traffic is shaped to
n The maximum number of bytes transmitted per internal interval
n Configured sustained bits per interval
n Configured excess bits in the first interval
n Interval being used internally (may be smaller than the committed burst divided
by the CIR)
n Number of bytes that will be sustained per internal interval
n If Frame Relay has FECN/BECN adaptation configured
Monitoring GTS
Router(config)#
show traffic-shape statistic
• Displays traffic shaping statistics

Number of packets/bytes sent
on the interface
traffic-shape statistic
statistic
Access
Access Queue
Queue Packets
Packets Bytes
Bytes Packets
Packets Bytes
Bytes Shaping
Shaping
I/F List
List Depth
Depth Delayed Delayed Active
Active
Se3/3 77 16091
16091 3733112
3733112 414
414 96048
96048 yes
yes
Subset of the previous

Depth of the associated WFQ
queue for delayed packets number of packets/bytes
delayed via the WFQ queue
The show traffic-shape statistics command displays the statistics of traffic

shaping for all the configured interfaces. Displayed in the output is:
n The interface where the traffic-shape rate or traffic-shape group command
is used (traffic-shape rate command is used on interface serial3/3 in the
example)
n The associated access list if the traffic-shape group command is used
n The number of packets currently in the shaping queue (queue depth)
n The total number of packets that have been processed by the traffic-shape
command since the last clearing of interface counters (16091 packets in the
example)
n The total number of bytes that have been processed by the traffic-shape
command since the last clearing of interface counters (3733112 bytes in the
example)
n The total number of packets that have been delayed by the traffic-shape
command since the last clearing of interface counters (414 packets in the
example)
n The total number of bytes that have been delayed by the traffic-shape
command since the last clearing of interface counters (96048 bytes in the
example)
n If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets
and delayed packets.
If the number of delayed packets is very high (compared to the total number of
packets) then there are probably non-responsive aggressive flows being shaped
and the queue depth could show high buffer utilization.
If the number of delayed packets is zero then it is very likely that the access list
does not match any traffic.
Monitoring GTS
Router(config)#
show traffic-shape queue
• Displays the shaping queue contents

router#show
router#show traffic-shape
traffic-shape queue
queue
Traffic queued in shaping queue on Serial0
(depth/weight) 1/4096
Conversation 254, linktype:
linktype: ip,
ip, length: 232
source:
source: 1.1.1.1,
destination: 1.1.2.47, id: 0x0001, ttl:
ttl: 208,
208,
TOS:
TOS: 00 prot:
prot: 17, source
source port
port 11111,
11111, destination
destination port
port 22222
22222
The show traffic-shape queue command displays the contents of the shaping
queue associated with an interface.
This command can be used to determine the types of flows that are congesting the
shaping queue. The command displays the parameters that are used for
classification within WFQ:
n Source IP address
n Time to live (TTL)
n Type of Service (ToS) field
n Protocol ID
n Source port number
n Destination port number
The example shows that there is a non-responsive UDP flow (protocol 17)
congesting the shaping queue.
GTS on Frame Relay Interfaces
• GTS can be implemented on any type of

(sub)interface
• GTS supports additional features when
implemented on Frame Relay interfaces:
– BECT-to-FECN reflection
– FECN creation on congestion
GTS applies on a per-interface basis, can use access lists to select the traffic to
shape, and works with a variety of Layer-2 technologies, including:
n Frame Relay
n ATM
n Switched Multi-megabit Data Service (SMDS)
n Ethernet
On a Frame Relay subinterface, GTS can be set up to shape to a specified rate
and to adapt dynamically to available bandwidth by integrating Frame Relay
congestion signaling with GTS.
Frame Relay Refresher
• Frame Relay Explicit Congestion Notification

– FECN (Forward Explicit Congestion Notification)
– BECN (Backward Explicit Congestion Notification)
– CLLM (Consolidated Link Layer Management)
• Implicit Congestion Notification
– Network discards detected by end user at
higher layers
– DE (Discard Eligibility) bit
Frame Relay performs congestion notification to its Layer-2 endpoints by including

congestion signaling inside the Layer-2 frame headers.
n The FECN, BECN and DE bits in the Q.922 header of the frame provide in-
band congestion signaling.
n The Forward Explicit Congestion Notification (FECN) is bit set by a Frame
Relay network to notify a device (FR DTE, which may be a router) that it
should initiate congestion avoidance procedures.
n The Backward Explicit Congestion Notification (BECN) is bit set by a Frame
Relay network to notify a device (DTE) that it should initiate proper congestion
avoidance procedures.
n CLLM is an enhanced signaling method, used by Frame Relay switches, which
expands on the FECN/BECN mechanism to improve congestion management.
n The Discard Eligibility (DE) bit indicates that a frame may be discarded in
preference to other frames, if congestion occurs, to maintain the committed
quality of service within the network. Frames with the DE bit set are
considered Be excess data.
Congestion notification may be explicit (honored by Layer-2 devices) or implicit
(detected and honored by higher-layer protocols, not by the Layer-2 network).
FECN/BECN and CLLM are explicit methods, while BE-setting is an implicit
notification method.
Frame Relay FECN/BECN
Congestion Control
Switch
Switch monitors
monitors all
all
transmit
transmit queues
queues for
for
congestion
congestion
R
S
e
e
Frame 1 FECN c
n Frame 11
Frame
Frame e
d No Congestion this Side Congestion this Side
Relay i
e Relay
v
r Switch
Frame
Frame 22 BECN Frame 2 e
r
Same Virtual Circuit (VC)
• FR Switch detects congestion on output queue and informs:
– The receiver by setting the FECN bit on forwarded frames
– The source by setting the BECN bit on frames going in the opposite
direction
A Frame Relay switch can explicitly report congestion in two directions: Forward
and Backward. When a frame queue inside a switch is congested, the switch will
generate congestion signals based on the FECN and BECN bits. If congestion
occurs in a queue towards the main receiver of traffic, FECN signals are sent to
the receiving Layer-2 endpoint and BECN signals are sent to the sending Layer-2
endpoint. FECN and BECN bits are not sent as separate frames, but are
piggybacked inside data frames.
GTS Frame Relay Congestion
Adaptability
• On a Frame Relay (sub)interface, GTS can

adapt dynamically to available Frame Relay
bandwidth by integrating BECN signals
– The GTS bit rate is reduced when BECN packets
are received to reduce the data flow through
congested Frame Relay network
– Adaptation is done on per (sub)interface basis
– GTS bit rate is gradually increased when the
congestion is no longer present (no BECN packets
are received any more)
BECN is the flag that the sending DTE (router as a Frame Relay endpoint) is able
to integrate to determine the congestion status of the Layer-2 WAN.
GTS Frame Relay Congestion
Adaptability Mechanisms
• Bit-rate adaptation
– Traffic shaping bit-rate is reduced when a packet
with BECN bit is received in the Tc
– Traffic shaping bit-rate is increased if no BECN
bits were received in the Tc
• FECN to BECN propagation
– A test packet with BECN bit set is sent to the
sender if a packet with FECN bit set is received
The first adaptation mechanism is bit-rate adaptation. GTS is able to respond to

Layer-2 congestion by reducing its shaping rate to three-quarters of the current
rate, until the Layer-2 network recovers from congestion. When BECN flags are
no longer received, the rate is slowly ramped up again to the original shaping rate.
This is also a lower limit of rate reduction, which bounds the reduction process so
that at least some throughput is maintained. The BECN-integrating functionality is
performed on a per sub-interface (DLCI) basis.
However, if the congestion was caused by simplex traffic (such as a multicast
video stream) or by an aggressive TCP connection, it is expected that the reverse
traffic (frames flowing from the receiver to the sender, marked with the BECN
bit) might come by less frequently than required to feed the integration. So the
receiving DTE (the receiving router) can help matters when it receives a message
with FECN set by first checking to see if it has any data, and if it does not,
originating a message with BECN set. This message might be a Q.922 TEST
RESPONSE message, which would by virtue of its message type be understood to
be a message to discard and not reply to. This feature is called FECN-to-BECN
propagation.
An Example of BECN Integration
becn
9000
BECN Integration
INC added every Tc in the token Bucket

8000
becn
7000
6000
5000
Inc
4000
traffic-shape rate 64000 8000 8000

3000 traffic-shape adaptive 32000
2000 BECN received at Tc#1 and Tc#3
1000 Hypothesis: no idle traffic
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
time represented in units of Tc
The figure shows the shaped rate of a token bucket-based GTS responding to
BECN packets it received. As mentioned, the rate is reduced to three-quarters of
the previous rate for every Tc interval, which saw at least one BECN message
received at the router. When no BECN messages are received in a Tc period, the
shaped rate is brought up slowly, up one-sixteenth of the current rate.
FECN to BECN Propagation
R
S e
FECN
e c
n Frame e
Congestion
d Relay i
e v
Switch
Switch
r BECN in e
Q.922Test r
If there is no reverse traffic,

the switch is not able to set
BECN in frames going back
to sender
The other adaptation method, FECN-to-BECN propagation, configures a Frame

Relay sub-interface to reflect received FECN bits as BECN in Q.922 TEST
RESPONSE messages. This enables the sender to notice congestion in the Layer-
2 network, even if there is no data traffic flowing from the receiver back to the
sender.
Configuring Bit-rate Adaptation
Router(config-if)#
traffic-shape adaptive [bit-rate]
• Configures Traffic Shaping Frame Relay bit-rate

adaptation
bit-rate - lowest bit-rate the traffic is shaped to in
response to continuous BECN signals
Default: 1/2 the specified traffic shaping rate
• Traffic shaping has to be enabled
Frame Relay bit rate adaptation is configured using the traffic-shape adaptive
command, which specifies the lower limit to which the shaped rate should be
reduced in presence of incoming BECN signals. By default, this is half the
configured sustained (committed) rate in GTS. The bit rate is configured in bits per
second.
Configuring FECN to BECN
propagation
Router(config-if)#
traffic-shape
traffic-shape fecn-adapt
• Configures the router to send Frame Relay TEST

message with BECN bit set in response to receiving
a frame with FECN bit set
• Can be used without adaptive traffic shaping
Router(config-if)#
traffic-shape
traffic-shape fecn-create
fecn-create
• Sets FECN bit in all outgoing packets that have

been delayed due to traffic shaping
• Use for debugging/simulation only
The traffic-shape fecn-adapt command enables the FECN-to-BECN

propagation. It can be used without adaptive GTS, as configured with the previous
command.
This feature should be used for testing purposes only. If the feature is combined
with the adaptation feature it is very likely that the first delayed packet will cause
the shaping to slow down to the minimum shaping rate. For example:
1. Router A (sender) sends a frame with a FECN bit because it had to delay
a packet.
2. Router B (receiver) replies with the TEST frame with the BECN bit set
3. Router A (sender) reduces the shaping rate due to the received BECN
causing even more delay and more packets with the FECN bit set.
GTS Frame Relay
Adaptation Design
Conservative scenario
• Set shaping rate to CIR
• Set minimum rate to MIR (or 1/2 CIR)
Optimistic scenario
• Set shaping rate to EIR
• Set minimum rate to CIR
Realistic scenario
• Set shaping rate to EIR
• Set minimum rate to MIR (or 1/2 CIR)
To illustrate different possibilities of adaptation, consider the following three

scenarios for using GTS over a Frame Relay circuit
n In a conservative scenario, where there should be minimal congestion and
dropping, the shaping rate is set to the contracted Frame Relay CIR
(Committed Information Rate) and the minimum rate of adaptation is set either
to MIR (Minimum Information Rate) or half the CIR value. MIR depends on
the provider’s over provisioning of the network and can be as low as one-tenth
of the CIR. This configuration minimizes dropping, but does not allow excess
bandwidth to be fully utilized.
n In an optimistic scenario, the normal shaping rate may be set to the EIR
(Excess Information Rate) and the minimum rate to the CIR. This
configuration would probably cause too much dropping in a loaded Frame
Relay network.
n In a realistic scenario, utilizing most excess bandwidth can be achieved by
setting the shaping rate to the EIR and the minimum adaptation rate to the
MIR (or half the CIR). This would allow full advantage to be made of the
Frame Relay network, if possible, and to adapt to a realistic level if congestion
is indicated.
GTS Frame Relay Adaptation
Example
WAN
Core
Customer interface
0/0
traffic-shape
traffic-shape rate
rate 64000 8000 8000
traffic-shape
traffic-shape adaptive
adaptive 48000
48000
• EIR = 64 kbps
• CIR = 48 kbps
• Assumption: Frame Relay network is usually not
congested
This GTS shape rate adaptation example shows a configuration of GTS, where
traffic is shaped to the EIR of 64 Kbps, with the adaptive floor being equal to CIR,
which is contracted at 48 Kbps. No FECN-to-BECN propagation is configured.
This example would work optimally only if the Frame Relay network is unlikely to
get congested because setting the adaptive floor to the CIR cannot lower the
shaping rate below the CIR. Lowering the rate below the contracted CIR may be
necessary in most commercial Frame Relay networks.
Summary
n GTS can be applied only on output interfaces
n GTS performs traffic shaping or smoothing
n GTS cannot mark or drop packets
n GTS supports BECN and FECN in Frame Relay environments
n GTS does not support cascaded policies
n GTS does not provide managed discard
n GTS cannot run in distributed mode
n GTS supports only extended IP access lists
n GTS supports RSVP as it uses WFQ
Lesson Review
1. What software queuing mechanisms are supported in combination with GTS?
2. Which queuing structure does GTS use?
3. What features does GTS include when used on Frame Relay interfaces?
Frame Relay Traffic Shaping
Overview
The section describes the Frame Relay Traffic Shaping (FRTS) mechanism.
Objectives
Upon completion of this section, you will be able to perform the following tasks:
n Describe the FRTS mechanism
n Describe the benefits and drawbacks of FRTS
n Compare the GTS and FRTS mechanisms
n Configure FRTS on Cisco routers
n Monitor and troubleshoot FRTS
Frame Relay
Traffic Shaping
Meter
Shaper
Classifier Marker
Dropper
Traffic
stream
• Can NOT shape multiple classes

• Can be implemented on per-vc basis (classification)
• Can measure traffic rate of individual virtual circuits (metering)
• Delays packets of exceeding VC-s (shaping)
• Dynamic Traffic Throttling on a Per-VC Basis (BECN or
ForeSight)
• Enhanced Queuing Support on a Per-VC Basis (PQ, CQ or WFQ)
Cisco has long provided support for FECN for DECnet and OSI, and BECN for
SNA traffic using LLC2 encapsulation and DE bit support. FRTS builds upon this
existing Frame Relay support with additional capabilities that improve the scalability
and performance of a Frame Relay network, thereby increasing the density of VCs
and improving response time.
Frame Relay Traffic Shaping (FRTS) can eliminate bottlenecks in Frame Relay
networks that have high-speed connections at the central site and low-speed
connections at branch sites. Rate enforcement can be configured to limit the rate
at which data is sent on the VC at the central site.
Using FRTS, rate enforcement can be configured to either the CIR or some other
defined value such as the excess information rate on a per-VC basis. The ability
to allow the transmission speed used by the router to be controlled by criteria other
than line speed (that is, by the CIR or the excess information rate) provides a
mechanism for sharing media by multiple VCs. Bandwidth can be allocated per
VC, creating a virtual time-division multiplexing (TDM) network.
PQ, CQ and WFQ can also be defined at the VC or subinterface level. Using
these queuing methods allows for finer granularity in prioritising and queuing of
traffic, thus providing more control over the traffic flow on an individual VC. If CQ
is combined with the per-VC queuing and rate enforcement capabilities, Frame
Relay VCs are enabled to carry multiple traffic types, such as IP, SNA and IPX,
with guaranteed bandwidth for each traffic type.
Using information contained in the BECN-tagged packets received from the
network, FRTS can also dynamically throttle traffic. With BECN-based throttling,
packets are held in the buffers of the router to reduce the data flow from the
router into the Frame Relay network. The throttling is done on a per-VC basis and
the transmission rate is adjusted based on the number of BECN-tagged packets
received.
With the Cisco FRTS feature, ATM ForeSight closed loop congestion control can
be integrated to actively adapt to downstream congestion conditions.
FRTS Building Blocks
Enough
No classifier, shaping Shaping
Tokens? No
performed on individual VC Queue
Enough No Shaping
Forwarder Tokens? Yes
+ Queue
Frame Relay maps
Yes
Enough Shaping
Tokens? No
Queue
Yes
Traffic for VCs that are not shaped Physical Interface

queue(s)
In this block diagram, FRTS operation on a physical Frame Relay interface is

shown. There is no global pre-classification of traffic, but packets are sent to their
individual VCs instead. Shaping is then performed on a per-VC basis, with a
separate shaping queue/token bucket for each VC. Packets coming out of their
individual per-VC shapers are then sent to the physical interface queue (Tx
queue/Tx ring).
FRTS Overview
• FRTS is multiprotocol
• FRTS can use one of the following queuing
mechanisms as the shaping queue:
– Weighted Fair Queuing (WFQ)
• FRTS can only be implemented in
combination with WFQ on the interface
• FRTS works on output only
FRTS is a shaping implementation that supports multiple protocols. Unlike GTS,

which performs a WFQ-based scheduling on the entry of the shaper with an
arbitrary scheduling mechanism on the physical interface, FRTS performs its
operations the other way around.
FRTS can use priority queuing, custom queuing, or weighed fair queuing as the
scheduling method on the entry of the shaper. This allows for finer granularity in
the prioritization and queuing of traffic and provides more control over the traffic
flow on an individual VC. If CQ is combined with the per-VC queuing and rate
enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic
types, with bandwidth guaranteed for each traffic type.
For example, if CQ is combined with the per-VC queuing and rate enforcement
capabilities, FR VC’s can be enabled to carry IP, SNA and IPX traffic, with
bandwidth guaranteed for each.
At the physical interface itself (after the packet has been fancy queued and
shaped) WFQ needs to be enabled in conjunction with FRTS. WFQ is currently the
only supported interface scheduling method.
FRTS can only be configured on the output of an interface.
GTS vs. FRTS
Generic Traffic Shaping Frame Relay Traffic Shaping
• Works on any (sub)interface • Works only on Frame Relay

• Shapes traffic on • Shapes traffic of individual
(sub)interface basis virtual circuits
• Any physical interface • Only WFQ can be used on
queuing can be used physical interface
• Only WFQ can be used for • CQ, PQ or WFQ can be used in
shaping queue shaping queue
Generic Traffic Shaping is equivalent to Frame Relay Traffic Shaping

when it’s configured on point-to-point Frame Relay subinterfaces
The figure compares GTS to FRTS, based on their main differences. Generic
Traffic Shaping:
n Works on any (sub) interface type
n Shapes traffic on that (sub)interface basis
n Can use any physical interface queuing (FIFO, PQ, CQ or WFQ)
n Only uses WFQ as the shaping queue (that is, on the input of the shaper)
In contrast, Frame Relay Traffic Shaping:
n Works only on Frame Relay (sub) interfaces
n Shapes traffic inside individual FR Virtual Circuits
n Only permits WFQ as the physical interface queuing method
n Can use any queuing method as the shaping queue (that is, on the input of the
shaper)
Configuring FRTS
• Define the shaping parameters (map-class)

– Token-bucket parameters
– Frame Relay congestion adaptation
– Shaping queue type
• Enable Frame Relay traffic shaping on
physical interface
• Apply the shaping definition
– For all VCs on (sub)interface
– For individual PVC/SVC
Enabling FRTS on an interface enables both traffic shaping and per-VC queuing on
all the interface's PVCs and SVCs. Traffic shaping enables the router to control
the circuit's output rate and, if configured, to react to congestion notification
information. Queuing enables per-VC scheduling of traffic to be shaped.
Configuring FRTS involves:
Step 1 Defining the shaping parameters with the map-class command
Step 2 Enabling FRTS on the physical interface
Step 3 Applying the shaping parameters to all, or selected, VCs on that interface
Creating a Map Class
Router(config)#
map-class frame-relay name
• Creates a new Frame Relay map class or starts

editing existing map-class
• Map class names are case sensitive
The map-class frame -relay command defines the per-VC shaping and queuing
parameters. A case-sensitive name must be assigned to each map class.
Define Map-class Shaping Queue
Router(config-map-class)#
frame-relay priority-group number
• Selects priority queuing as the shaping queue

structure
frame-relay custom-queue-list number
• Selects custom queuing as the shaping queue

structure
frame-relay
frame-relay fair
fair cdt max-queue rsvp-queues
rsvp-queues max-buf
max-buf
• Selects WFQ as the shaping queue structure

• FRF.12 requires weighted fair queuing
Inside the map class, the frame-relay priority-group, frame-relay custom-

queue -list, and frame-relay fair keywords enable a queuing discipline of either
priority, custom or weighed fair queuing, respectively. This queuing discipline is
used for traffic departing on a VC, before shaping is applied to it. If FRF.12
payload compression is used, WFQ needs to be configured as the queuing
discipline.
Define Traffic Shaping
Parameters
frame-relay [in|out]
[in|out] cir
cir bit-rate
frame-relay [in|out]
[in|out] bc bits
frame-relay [in|out] be bits
• Specifies the shaping parameters in CIR/Bc/Be values

• Tc is computed from CIR and Bc
• Only outgoing values can be specified for FRTS
frame-relay traffic-rate
traffic-rate average-rate peak-rate
• Specifies only the CIR and peak rate

• Tc is specified by the router
• Bc and Be are computed from Tc, average and peak rate
Per-VC traffic shaping parameters specify shaping behavior for the configured
map class. Two configuration mechanisms are available:
n Specification of CIR, Bc and Be parameters of the per-VC token bucket
n Specification of per-VC average rate and peak rate, where Bc and Be are
computed from the default Tc, average rate and peak rate
Define Congestion Adaptation
Mechanism
frame-relay adaptive-shaping
adaptive-shaping becn|foresight
becn|foresight
• Enables adaptive shaping for the Frame Relay map

class
• Congestion indication mechanism could be BECN
or Foresight (CLLM)
frame-relay mincir rate
• Specifies the minimum bit rate for congestion

adaptation algorithm
As part of the map class definition, either BECN or ForeSight are used as the
congestion backward notification mechanism to which traffic shaping will adapt.
The BECN adaptation feature is the same as with GTS, thus the router reacts to
received BECN signals by reducing its shaping rate.
The ForeSight adaptation feature uses the network traffic control software used in
Cisco Frame Relay switches. When the ForeSight feature is enabled on the switch,
the switch will periodically send out a ForeSight message based on the time value
configured. The time interval can range from 40 to 5000 milliseconds. The
ForeSight feature allows Cisco Frame Relay routers to process and react to
ForeSight messages and adjust VC-level traffic shaping in a timely manner.
Note The ForeSight feature is only available in combination with Cisco WAN switches.
The difference between the BECN and ForeSight congestion notification methods
is that BECN requires a user packet to be sent in the direction of the congested
DLCI to convey the signal. The sending of user packets is not predictable and,
therefore, is not reliable as a notification mechanism. Rather than wait for user
packets to provide the congestion notification, timed periodic ForeSight messages
guarantee that the router receives notification before congestion becomes a
problem. Traffic can be slowed down in the direction of the congested DLCI.
Define Dedicated Queue for VoFR
Packets
frame-relay voice bandwidth bps queue depth
• Creates dedicated queue for VoFR packets

• VoFR queue has priority over regular queues
configured on the same VC
• Specified bandwidth has to include L2 and VoFR
overhead
• Voice calls over Frame Relay will not be placed
unless the voice queue is configured
• Voice over FR call will be rejected if there is not
enough bandwidth available in the voice queue
The frame-relay voice-bandwidth map-class command is used to configure how

much bandwidth is reserved for voice over Frame Relay (VoFR) traffic, if used in
the network. The router then creates a dedicated priority queue, used only for
VoFR traffic. If not enough reserved voice bandwidth remains on the PVC, any
new calls that are attempted will be rejected.
When the amount of bandwidth to allocate to voice is calculated, the overall
bandwidth calculation must include the voice packetization overhead and not just
the raw compressed speech codec bandwidth.
Enable FRTS on an Interface
Router(config-if)#
frame-relay traffic-shaping
• Enables Frame Relay traffic shaping on a physical

interface
• No special queuing can be configured on the
interface
• Weighted Fair Queuing is used as the physical
interface queuing mechanism regardless of
interface bandwidth
After the map class is configured, traffic shaping must be applied to the physical
interface. As mentioned, WFQ is the only supported mechanism on the physical
interface running FRTS.
Apply FRTS to a VC
Router(config-if)#
frame-relay class map-class-name
• Applies the specified Frame Relay map class to all

VCs configured on the specified (sub)interface
Router(config-if)#
frame-relay interface-dlci
interface-dlci DLCI
DLCI
class map-class-name
• Applies the specified Frame Relay map class only to

the specified DLCI
• Traffic for DLCIs that have no map class defined (on
DLCI or on (sub)interface) is not shaped
Map class settings are then applied to all or specific VCs on an interface or
subinterface. All VCs without shaping information are not shaped and only use the
physical interface queuing discipline (WFQ).
Example
interface Serial1/1
frame-relay
frame -relay traffic-shaping
!
interface Serial1/1.1 point-to-point
point-to-point
frame-relay
WAN interface-dlci 101
frame -relay 101
class
class slow_vcs
slow_vcs
!
interface Serial1/1.2 Core
point-to-point
point-to-point
frame-relay
frame -relay interface-dlci 102
102
class
class fast_vcs
fast_vcs
Customer !
map-class
map-class frame-relay
frame-relay fast_vcs
fast_vcs
frame-relay
frame -relay custom-queue-list
custom-queue-list 11
frame-relay
frame -relay traffic-rate 32000 64000
!
map-class
frame-relay slow_vcs
slow_vcs
frame-relay
frame -relay priority-group 1
frame-relay
frame -relay traffic-rate 9600
9600 16000
16000
• Customer uses different policies and queuing mechanisms for

each DLCI
The figure shows an FRTS configuration example, where two VCs are individually
shaped with two map class parameter sets. In this example, two generic map
classes are defined, one for generic fast VCs and the other for slow VCs. The fast
VC map class uses custom queuing to allocate bandwidth within the shaped rate.
The slow VC map class uses priority queuing to always forward mission-critical
traffic, and then shape it to the required rate.
Frame Relay QoS Autosense
• Frame Relay QoS parameters are usually

defined manually on the router
• The same parameters are also carried in
ELMI (CLLM) messages
• QoS Autosense allows the router to learn the
DLCI QoS parameters from the switch
– ELMI must be configured on the router and the
switch
– Only Cisco Frame Relay switches are supported
When used in conjunction with traffic shaping, the router can respond to changes in
the network dynamically. This optional feature allows the router to learn QoS
parameters from the Cisco switch and use them for traffic shaping, configuration,
or management purposes.
Enhanced Local Management Interface (ELMI) also simplifies traffic shaping
configuration on the router. Previously, users needed to configure traffic shaping
rate enforcement values, possibly for every VC. Enabling ELMI reduces the
chance of specifying inconsistent or incorrect values when configuring the router.
It is not necessary to configure traffic shaping on the interface to enable ELMI.
One option is to enable it to learn what values being used by the switch. If the
router is required to respond to the QoS information received from the switch by
adjusting the output rate, traffic shaping must be configured on the interface using
the frame-relay traffic-shaping command in interface configuration mode.
Configuring QoS Autosense
Router(config-if)#
frame-relay qos-autosense
• Enable the Enhanced Local Management Interface

feature
• Allows QoS parameters (CIR, Bc, Be) to be passed
by the switch to the router automatically in ELMI
messages
The frame-relay qos-autosense command enables:

n ELMI on the router
n The router to learn QoS parameters from the switch over the ELMI protocol
Monitoring Frame Relay Traffic
Shaping
• Show frame-relay PVC

– Displays VC QoS and shaping parameters
• Show traffic-shape statistics
– Displays GTS and FRTS statistics
• Show traffic-shape queue
– Displays GTS and FRTS shaping queue contents
The listed show commands enable monitoring of per-VC QoS and general GTS
parameters.
Display PVC Information
Router#
show frame-relay pvc
• Displays VC QoS and shaping parameters
Router#show
Router#show frame-relay
frame-relay pvc
pvc 2020
PVC
PVC Statistics
Statistics for
for interface
interface Serial4/0
Serial4/0 (Frame
(Frame Relay
Relay DCE)
DCE)
DLCI
DLCI == 20,
20, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.1Serial4/0.1
input
input pkts
pkts 16963
16963 output
output pkts
pkts 33632
33632 in
in bytes
bytes 4669839
4669839
out
out bytes
bytes 12442428
12442428 dropped pkts
pkts 00 in
in FECN
FECN pkts
pkts 00
in
in BECN
BECN pkts
pkts 00 out
out FECN
FECN pkts
pkts 00 out
out BECN
BECN pkts
pkts 00
in DE pkts
in DE pkts 0 0 out DE pkts
out DE pkts 0 0
out
out bcast
bcast pkts
pkts 31361
31361 out
out bcast
bcast bytes
bytes 9095644
9095644
Shaping
Shaping adapts
adapts toto BECN
BECN
pvc
pvc create
create time
time 1w3d,
1w3d, last
last time
time pvc
pvc status
status changed
changed 1w3d
1w3d
cir
cir 64000
64000 bc
bc 64000
64000 be
be 00 limit
limit 1000
1000 interval
interval 125
125
mincir 32000
mincir 32000 byte increment 1000 BECN response
byte increment 1000 BECN response yes yes
pkts
pkts 1103
1103 bytes
bytes 1632516
1632516 pkts
pkts delayed
delayed 1091
1091 bytes
bytes delayed
delayed 16287
16287
shaping
shaping active
active
traffic
traffic shaping
shaping drops 1136
Current
Current fair
fair queue
configuration:
Discard
Discard Dynamic
Dynamic Reserved
Reserved
threshold
threshold queue
queue count
count queue
queue count
count
64
64 16
16 00
Output
Output queue
queue size
size 46/max
46/max total 50/drops 1136
The show frame -relay pvc command displays information about individual FR
PVC status and provides information about:
n Configured CIR
n Shaping
n Queuing
n Congestion adaptation
Display Shaping Statistics
Router#
show traffic-shape statistics
• Displays GTS and FRTS statistics

Router#show
traffic-shape statistics
statistics
Access
Access Queue
Queue Packets
Packets Bytes
Bytes Packets
Packets Bytes
Bytes Shaping
Shaping
I/F
I/F List
List Depth
Depth Delayed
Delayed Delayed
Delayed Active
Active
Se4/0.1
Se4/0.1 50
50 1283
1283 1903236
1903236 1271
1271 1899472
1899472 yes
yes
Se4/0.2
Se4/0.2 00 14
14 4060 0 0 no
The show traffic-shape statistics command displays the statistics of traffic

shaping for all configured interfaces. In the output, the amount of delayed traffic,
the shaping queue sizes and the amount of transmitted traffic is displayed.
Displayed in the output is:
n The interface where the frame-relay taffic-shaping command is used
n The number of packets currently in the shaping queue (queue depth)
n The total number of packets that have been processed by the frame-relay
taffic-shaping command since the last clearing of interface counters (16091
packets in the example)
n The total number of bytes that have been processed by the frame-relay taffic-
shaping command since the last clearing of interface counters (3733112 bytes
in the example)
n The total number of packets that have been delayed by the frame-relay taffic-
shaping command since the last clearing of interface counters (414 packets in
the example)
n The total number of bytes that have been delayed by the frame-relay taffic-
shaping command since the last clearing of interface counters (96048 bytes in
the example)
n If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets
and delayed packets.
If the number of delayed packets is very high (compared to the total number of
packets) then there are probably non-responsive aggressive flows being shaped
and the queue depth could show high buffer utilization.
If the number of delayed packets is zero then it is very likely that the access list
does not match any traffic.
Display Shaping Queue
Information
Router#
show traffic-shape queue
• Displays GTS and FRTS shaping queue contents

Router#show
traffic-shape queue
queue
Traffic
Traffic queued
queued in
in shaping
shaping queue
queue on
on Serial4/0.1
Serial4/0.1 dlci
dlci 20
20
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Queueing
Queueing Stats:
Stats: 46/50/64/1377
46/50/64/1377 (size/max
Conversations
1/2/16 (active/max
active/max total)
total)
Reserved
Conversations 0/0
0/0 (allocated/max
allocated)
46/32384/1377/0 /0
Conversation
Conversation 5,
5, linktype:
linktype: ip,
ip, length:
length: 1504
1504
source:
source: 193.77.3.1,
193.77.3.1, id:
id: 0x00F4,
0x00F4, ttl:
ttl: 255,
255, prot:
prot: 1
The show traffic-shape queue command displays the queuing configuration of

individual interfaces.
Display Shaping Queue
Information
PE_2#show
PE_2#show traffic-shape
traffic-shape queue
queue
Traffic
Traffic queued
queued in
in shaping
shaping queue
queue on
on Serial4/0.1
Serial4/0.1 dlci
dlci 20
20
Queueing
Queueing strategy:
strategy: priority-group
priority-group 11
Queueing
Queueing Stats:
Stats: high 16/20/19 (queue/size/max total/drops)
Packet
Packet 1,
1, linktype:
linktype: ip,
ip, length:
length: 1504,
1504, flags:
flags: 0x10000048
source:
source: 193.77.3.1,
193.77.3.1, id:
id: 0x0141,
0x0141, ttl:
ttl: 255,
255, prot:
prot: 11
data:
data: 0x0800
0x0800 0x9105
0x9105 0x2659
0x2659 0x1F89
0x1F89 0x0000
0x0000 0x0000
0x0000 0x3819
0x3819
0x223C
0x223C 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
Packet
Packet 2,
2, linktype:
linktype: ip,
ip, length:
length: 1504,
1504, flags:
flags: 0x10000048
source:
source: 193.77.3.1,
193.77.3.1, id:
id: 0x0141,
0x0141, ttl:
ttl: 255, prot:
prot: 11
data:
data: 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
The show traffic-shape queue command also displays the contents of the shaping
queue associated with an interface.
The example shows the contents of the high queue in the Priority Queuing system
used as the shaping queue.
Summary
n FRTS enables granular, per-VC queuing and shaping definition
n FRTS can be applied only on output interfaces
n FRTS enables per-VC queuing, which is performed before shaping
n FRTS performs traffic shaping or smoothing within a VC
n FRTS supports the same congestion adaptation mechanisms as GTS
Lesson Review
1. What are the main differences between GTS and FRTS?
2. Where can FRTS be used?
3. What classification options does FRTS have?
Committed Access Rate
Overview
The lesson describes the Committed Access Rate (CAR) mechanism.
Objectives
n Describe the CAR mechanism
n Describe the benefits and drawbacks of CAR
n Describe the differences between CAR, GTS and FRTS
n Configure CAR on Cisco routers
n Monitor and troubleshoot CAR
Meter
Inbound
or
Outbound
• Primarily intended for rate limiting

• Can be used on inbound and outbound traffic
• Does not queue (delay) packets
• Can also mark packets
• Can be implemented for differentiated
marking
Committed Access Rate (CAR) provides the capability to allow the service
provider to rate-limit traffic in and out of router interfaces, thereby enabling various
forms of ingress and egress rate-limiting in a network. CAR is a policing
mechanism, not a queuing mechanism. Therefore it does not buffer or delay
packets, which do or do not conform to the policy, but simply rate-limits them
according to a simple “forward or drop” policy, according to the configuration.
CAR also uses a token-bucket metering mechanism, similar to GTS, but without a
delay queue.
The CAR rate-limiting feature manages a network's access bandwidth policy by
ensuring that traffic falling within specified rate parameters is sent, while dropping
packets that exceed the acceptable amount of traffic or sending them with a
different priority. CAR is often configured on interfaces at the edge of a network
to limit traffic into or out of the network.
CAR can also be used for packet marking. The operator can specify a policy that
determines which packets should be assigned to which traffic class, and use CAR
to implement the marking. The IP header already provides a mechanism to do this,
namely the three precedence bits in the ‘type of service’ field in the IP header.
CAR allows the setting of policies, based on information in the IP or TCP header
such as IP address, application port, physical port or sub-interface, IP protocol,
etc., to decide how the precedence bits should be marked or “colored.” Once
marked, appropriate treatment can be given in the backbone to ensure that
premium packets receive premium service in terms of bandwidth allocation, delay
control, etc.
Note CAR can also be used to police (or “recolor”) precedence bits set externally to
the network either by the customer or by a downstream service provider. Thus
the network can decide to either accept or override external decisions.
CAR is implemented using the following abstract mechanisms:

n The classifier, which differentiates traffic into multiple classes, which may be
treated in a discriminate manner
n The meter, which uses a token-bucket scheme to measure the rate of
classified traffic
n The marker, which can be used to mark or re-mark classified traffic (for
example, with precedence or DSCP values)
n The dropper, which may drop packets (in the rate-limiting scenario) according
to the configured policy
CAR on Input and Output
Meter
Inbound Classifier Marker Dropper
Forwarding
Outbound
Meter
Classifier Marker Dropper Queuing
• CAR on input is processed just before forwarding (most other

QoS mechanisms are processed before CAR)
• CAR on output is processed immediately after forwarding (most
other QoS mechanisms are processed after CAR)
CAR can be configured on router input or output interfaces. When configured on

the input side, CAR is usually processed last in a series of QoS mechanisms.
Therefore, CAR rate-limiting and marking occurs just before the forwarding
decision.
On the output side, CAR is processed just after the forwarding decision. Therefore
all output QoS mechanisms (queuing, WRED, etc.) are generally processed after
CAR.
VIP-based distributed CAR (dCAR) is a version of CAR that runs on the
Versatile Interface Processor (VIP). It is supported on the Cisco 7500 routers with
a VIP2-40 or later versatile interface processor. Distributed Cisco Express
Forwarding (dCEF) switching must be enabled on any interface that uses dCAR,
even when only output-based CAR is configured.
CAR Implementation
Dispatches Dispatches Dispatches

packets at packets at line packets at line
configured rate rate rate
Software Hardware
CAR Queue Queue
(FIFO, PQ,
(FIFO)
CQ, WFQ, ...)
Bypass the software queue

if it is empty and there is
room in the hardware queue
• The software queue may have no function if

the sum of all CAR rates is less than link
bandwidth
Whether configured on input or output, CAR has the option of managing

throughput on a certain interface’s output. With the Cisco IOS queuing design,
there are two output queues:
n A software queue, which may be configured for different queuing types (for
example: FIFO, Priority Queuing, Custom Queuing, Weighted Fair Queuing)
n A hardware interface queue, which is always FIFO and immediately used, if
the software queue is empty
One possible implementation caveat arises when CAR is configured so that the
aggregate policed bandwidth of output flows does not exceed the link bandwidth.
In that case, the software queue is always empty and there is no queuing impact on
traffic.
Interface-wide CAR Diagram
drop
transmit
Class
Class 1?
1? CAR
CAR
continue
drop
transmit Output Queue
Class
Class 2?
2? CAR
CAR or
Forward
continue
drop
transmit
Class n? CAR
CAR
• CAR has three different actions:

– Transmit
– Continue
– Drop
The basic rate-limiting function of CAR does the following:

n Allows control of the maximum rate of traffic transmitted or received on an
interface.
n Provides the ability to define Layer-3 aggregate or granular rate limits and to
specify traffic -handling policies when the traffic either conforms to or exceeds
the specified rate limits.
n Uses granular bandwidth rate limits to match a particular type of traffic based
on precedence, MAC address, or other parameters.
When CAR is in effect, traffic is first classified and then undergoes CAR
processing. CAR then meters the traffic and, based on the result of CAR metering,
traffic either conforms or exceeds the configured policy.
There are three possible basic actions on each packet, depending on it conforming
or exceeding the policy:
n Transmit—the packet is sent.
n Drop—the packet is discarded.
n Continue—the packet is evaluated using the next rate policy in a chain of rate
limits. If there is not another rate policy, the packet is sent.
CAR Diagram
Meter
Meter
Yes Forward
Yes / No
Conforms?
Conforms? Transmit?
Transmit? or
Enqueue
No
Go to
Mark?
Mark? Yes
Continue?
Continue? Next
CAR command
Yes No
Set
Set IP
IP prec?
prec? Set
SetIP
IPPrecedence
Precedence
Yes
Yes Drop?
Drop?
Set
Set DSCP?
DSCP? Set
Set DSCP
DSCP
Yes
Set
Set MPLS
MPLS exp?
exp? Set
Set MPLS
MPLS Experimental
Yes
Set
Set QoS
QoS grp?
grp? Set
Set QoS
QoS Group
Group
• Marking depends on whether the packet conforms to

or exceeds the policy
As mentioned previously, CAR can also be used to mark or remark traffic as well
as performing rate limiting. Depending on traffic conformance, the following
marking/remarking actions can be performed within CAR processing:
n Set precedence (or DSCP value) and transmit—the IP Precedence (ToS) or
DSCP bits in the packet header are rewritten. The packet is then sent. This
action can be used to either color (set precedence) or recolor (modify existing
packet precedence) the packet.
n Set MPLS experimental bits and transmit – the MPLS experimental bits can
be set. These are usually used to signal QoS parameters in a MPLS cloud.
n Set QoS group and transmit—the QoS group can be set. It is only used locally
within the router. The QoS group can be used in later QoS mechanisms and
performed in the same router, such as CB-WFQ.
Configuring CAR
Router(config-if)#
rate-limit {input | output}
[access-group [rate-limit] #acl | qos-group number | dscpdscp dscp]
mean-rate B cc Bee
conform-action { drop || transmit
transmit || continue
continue ||
set-prec-transmit value | set-prec-continue
set-prec-continue value
value |
set-qos-transmit value | set-qos-continue value
set-dscp-transmit value | set-dscp-continue
set-dscp-continue value
value |
set-mpls-transmit value | set-mpls-continue value
value }
exceed-action {{ drop | transmit | continue |
set-prec-transmit value | set-prec-continue
set-prec-continue value
value |
set-qos-transmit value | set-qos-continue value
set-dscp-transmit value | set-dscp-continue
set-dscp-continue value
value |
set-mpls-transmit value | set-mpls-continue value
value }
• Specifies all four conditioner elements for a particular traffic class

• Repeat this command for different classes of traffic
• If a match is not found, the default action is to transmit
To configure CAR and Distributed CAR (dCAR) policies, use the rate-limit
interface configuration command. The figure illustrates all the command options
which are discussed in detail on the following pages.
A single CAR rate policy includes information about the rate limit, conform actions
and exceed actions. Each interface can have multiple CAR rate policies
corresponding to different types of traffic. For example, low priority traffic may be
limited to a lower rate than high priority traffic. When there are multiple rate
policies, the router examines each policy in the order entered until the packet
matches. If no match is found, the default action is to transmit.
Rate policies can be independent: each rate policy deals with a different type of
traffic. Alternatively, rate policies can be cascading: a packet may be compared to
multiple different rate policies in succession. Cascading of rate policies allows a
series of rate limits to be applied to packets to specify more granular policies. For
example, the total traffic on an access link can be rate limited to a specified
subrate bandwidth, and then the World Wide Web traffic on the same link can be
limited to a given proportion of the subrate limit. CAR can be configured to match
packets against an ordered sequence of policies until an applicable rate limit is
encountered—that is, rate limiting several MAC addresses with different
bandwidth allocations at an exchange point. Up to a 100 rate polic ies can be
configured on a subinterface.
The CAR action may be one of the following:
n Continue: evaluate the next rate-limit command
n Drop: drop the packet
n Set-prec-continue new-prec: set the IP Precedence and evaluate the next
rate-limit command
n Set-prec-transmit new-prec: set the IP Precedence and send the packet
n Set-dscp-continue new-prec: set the DSCP value and evaluate the next rate-
limit command
n Set-dscp-transmit new-prec: set the DSCP value and send the packet
n Set-mpls-continue new-prec: set the MPLS experimental bits and evaluate the
next rate-limit command
n Set-mpls-transmit new-prec: set the MPLS experimental bits and send the
packet
n Transmit: send the packet
CAR Classification
Router(config-if)#
[access-group [rate-limit]
[access-group [rate-limit] #acl | qos-group number
number |
dscp dscp]
...
• IP packets are classified:

– based on their direction (input or output)
• Optional classification based on:
– numbered IP access list (standard or extended)
– IP precedence rate-limit access list
– MAC address rate-limit access list
– QoS-group set by a previous conditioner in the same node
– DSCP
CAR classifies traffic using many IOS-based classification mechanisms. The most
basic classification is to first specify whether inbound or outbound traffic on the
interface is being policed. Then, additional more granular specification can further
classify traffic that needs to be policed separately.
Null CAR Classifier
Router(config-if)#
rate-limit {input | output} ...
• Selects packets in ingress or egress direction that

have not been classified with any previous rate-limit
commands on this interface
• Usually used as the last rate-limit command on an
interface
The null CAR classifier is in effect when no additional classifiers are present, apart
from the input or output application of the rate-limiting rule. This can be used either
as a default rate-limiting class (used as the last rate-limit command on the
interface to classify packets, not classified by any previous rules), or, if only global
policy is applied to an interface, classifying all traffic into one group (that is,
policing to a specified aggregate input rate).
CAR Classifier
Based on IP Access List
Router(config-if)#
rate-limit {input | output} access-group number ...
• Classifies packets received over an interface with

the IP access list
• Classification based on IP precedence can be done
with IP access list
Router(config)#
access-list
access-list acl-index
acl-index {deny
{deny | permit}
permit} source [source-wildcard]
access-list
access-list acl-index
acl-index {deny
{deny | permit}
permit} protocol source source-
wildcard destination destination-wildcard [precedence precedence]
[tos tos] [dscp dscp] [log]
• Configures an IP access list to be used as packet

classifier
The basic classification of traffic is based on extended IP access lists, which

describe traffic based on Layer-3 and Layer-4 parameters, such as source and
destination IP addresses, protocols and port numbers. Normal IOS access control
lists are used and then applied to the interface rate-limit command.
As IOS access lists can filter on IP precedence, access-list based classification
can also classify traffic solely on IP precedence. Such an approach is not
recommended if only precedence-based classification is desired, as there is a more
efficient mechanism present.
CAR Classifier Based on
IP Precedence
Router(config-if)#
rate-limit {input | output} access-group rate-limit
number ...
• The IP precedence classifier uses rate-limit access

lists from 1 to 99 to match on IP precedence values
To classify incoming or outgoing traffic based solely on IP precedence, rate-limit

access lists can be used. Rate-limit access lists match only on the precedence bits
in the IP header, and can perform precedence matching with a wildcard
specification.
IP Precedence-based
Rate-limit Access List
Router(config)#
access-list rate-limit
rate-limit acl-index precedence
precedence
• ACL index is between 1 and 99

• Matches packets with specified IP precedence
• Only one line is allowed in the access list
Router(config)#
rate-limit acl-index mask precedence-mask

• Matches packets that match any precedence value
specified in the mask
• Precedence mask has one bit for each precedence
value (bit 0 = precedence 0)
To configure classification rules on the IP precedence value, use the access-list

rate-limit global configuration command. The CAR process then treats packets
with different IP precedence differently. Use the mask keyword to assign multiple
IP precedence values to the same rate-limit list. The ACL indices for precedence-
based classification range from 1 to 99.
CAR Classifier Based on
Upstream MAC Address
Router(config-if)#
rate-limit {input | output} access-group rate-limit
number ...
• The upstream MAC address classifier uses rate-limit

access lists from 100 to 199 to match on the MAC
address of upstream router or host
Rate-limit access lists are also used to classify traffic based on the upstream MAC
address. That is, for output-based CAR, traffic is classified on the destination
MAC address, and for input-based CAR, traffic is classified using the source
MAC address.
MAC-based classification is particularly useful at ISP peering points, where a
multi-access LAN network connects ISP border routers. MAC-based
classification can classify traffic based on their upstream neighbor (another ISP
border router) and on their QoS peering policy with other providers.
MAC Address Rate-limit Access
List
Router(config)#
access-list rate-limit acl-index mac-address

• Matches packets received from upstream neighbor
with specified MAC address
• Only MAC address is allowed in the access list
(each upstream neighbor requires a different rate-
limit statement)
To configure classification rules on the upstream MAC value, use the access-list
rate-limit global configuration command. The CAR process then treats packets
with different upstream (source or destination) MAC addresses differently. The
ACL indices for precedence-based classification range from 100 to 199.
QoS-group CAR classifier
Router(config-if)#
rate-limit {input | output} qos-group number ...
• Selects IP packets already marked in this node with

specified QoS group
• QoS group marking could be done through:
– Policy-based routing
– CEF marking based on QPPB
– Inbound rate-limit on another interface
– Inbound Class-based Marking on another interface
• Available only on high-end platforms
The operator may also classify traffic based on their QoS group value. The QoS
group is a tag, which may be assigned to each packet during the forwarding
process, and is local to the router. The QoS group may be set:
n By some marking mechanism in the same router, such as policy routing,
inbound rate-limiting on another interface, or inbound class-based marking on
another interface.
n By QPPB (QoS Policy Propagation through BGP), which distributes centrally
administered QoS group values to routers over BGP sessions. The routers
automatically mark traffic based on the QPPB-learned policy during the CEF
forwarding process.
The QoS-group-based classification and marking is generally available only on
high-end router platforms.
DSCP-based CAR Classifier
Router(config-if)#
rate-limit {input | output} dscp dscp ...
• Selects IP packets marked with the specified DiffServ

Code Point
• DSCP marking could be done through:
– Rate-limit on another interface or router
– Class-based Marking on another interface or router
In a DiffServ-based model, the whole DSCP value can be used as the packet
classifier. The marking of the DSCP value is accomplished through class-based
marking or rate limiting on another interface or router.
CAR Meter
Router(config-if)#
[access-group
[access-group [rate-limit]
[rate-limit] number | qos-group number |
dscp dscp]
mean-rate Bc Bee
...
• The rate-limit meter measure the contract compliance

of traffic class selected with classifier
• Modified token-bucket algorithm is used
– mean-rate specifies average traffic rate
– B c specifies the normal burst size
– B e specifies the excess burst size
• Token-bucket size is defined by Be alone
The CAR metering mechanism uses a modified token bucket scheme, which
decides whether a packet conforms or exceeds the contracted rate. CAR is
configured with three parameters:
n Mean rate specifies the average traffic rate which traffic should be policed to
(analogous to committed rate with GTS). This is the long-term sustained
throughput through the CAR policing mechanism.
n Bc specifies the normal burst size, which is the amount of tokens added
periodically to the token bucket.
n Be specifies the excess burst size, which equals the size of the bucket in the
CAR implementation. This is the maximum burst size that can be sent by the
token bucket at one time, at the access line rate.
If CAR is used as a pure policer, packets exceeding the contracted rate are
dropped.
CAR Actions
• CAR actions can be split into two sub-actions:

– Marking action
– Processing action
• Marking actions support the setting of:
– IP precedence
– DSCP
– QoS group
• Processing actions:
– Transmit – packet is transmitted
– Continue – packet is also processed by the next “rate-limit”
command
– Drop – packet is dropped
CAR actions can be divided into marking and processing actions. The marking
actions support the setting of QoS signaling values inside the packet header
(precedence, DSCP, MPLS experimental) or locally to the router (QoS group).
The processing actions define the basic action of a single CAR rule. Those actions
may be to transmit (forward) the packet immediately, drop the packet, or continue
with the evaluation of the next CAR rule.
Each CAR rate limit statement is checked sequentially for a match. When a match
is found, the CAR meter (the token bucket), if there is one, is evaluated.
If the action is a “continue” action, the policer will go to the next rate-limit on the
list to find a subsequent match. If a match is found the traffic is subjected to the
next applicable rate-limit. If an end of rate-limit list is encountered without finding a
match or “continue” action, the default behavior is to transmit.
CAR Actions
• Processing actions “transmit”, “continue” and

“drop” can be used as stand-alone actions
• Processing actions “transmit” and “continue” can
be combined with marking actions (set-mark_action-
proc_action):
– set-prec-transmit
– set-qos-transmit
– set-mpls-transmit
– set-dscp-transmit
– set-prec-continue
– set-qos-continue
– set-mpls-continue
– set-dscp-continue
The three processing actions can be used stand-alone to enforce a pure rate-
limiting functionality. Alternatively, the “transmit” and “continue” actions can be,
and often are, combined with marking actions, whic h enable further differentiation
of the traffic.
CAR Actions
• Conforming and exceeding packets can be

configured with different actions
• There are three typicall usages of CAR:
– Pure rate limiting
• Transmit conforming packets
• Drop exceecing packets
– Differentiated marking
• Transmit conforming packets with marker value x (e.g IP
precedence 3)
• Transmit exceeding packets with marker value y (e.g IP
precedence 2)
– Pure marking
• Transmit confirming and exceeding packets with the same
marker value
Based on the “conform” or “exceed” results of the CAR meter, three CAR
configuration philosophies are usually used:
n Use only the “transmit” and “drop” actions—effectively enabling only local
rate limiting on an interface.
n Use all processing actions, and additionally mark traffic based on its
conformance of exceeding the configured rate limit. For example, conforming
traffic may be colored with one marker value (precedence, DSCP, QoS, etc.),
and exceeding traffic with another value. This differentiation may be used
locally or elsewhere in the network to differentiate between in-contract
(conforming) traffic and out-of-contract (exceeding) traffic.
n Transmit all traffic and use only the marking actions to color traffic with a
marker value.
Displaying CAR Parameters and
Statistics
Router#
show interfaces intf rate-limit
• Displays CAR parameters and statistics

Router#show
interfaces serial
serial 0/0
0/0 rate-limit
rate-limit
Serial0
Serial0
Input
Input
matches:
matches: qos-group
qos-group 4
params:
params: 128000
128000 bps,
bps, 64000
64000 limit,
limit, 128000
128000 extended
extended limit
limit
conformed
conformed 00 packets,
packets, 00 bytes;
bytes; action:
action: transmit
transmit
exceeded
exceeded 00 packets,
packets, 00 bytes;
bytes; action:
action: set-prec-transmit
set-prec-transmit 0 0
last
last packet:
packet: 421250660ms
421250660ms ago, current
current burst:
burst: 00 bytes
bytes
last
last cleared
cleared 00:00:59
00:00:59 ago,
ago, conformed
conformed 00 bps,
bps, exceeded
exceeded 00 bps
bps
Output
Output
matches:
matches: access-group
access -group 181
181
params:
params: 8000
8000 bps,
bps, 8000
8000 limit,
limit, 16000
16000 extended limit
extended limit
conformed
conformed 19
19 packets,
packets, 21576
21576 bytes;
bytes; action:
action: set -prec-transmit 33
set-prec-transmit
exceeded
exceeded 5 packets,
packets, 7520 bytes; action: drop
last
last packet:
packet: 145344ms
145344ms ago,
ago, current
current burst:
burst: 11552
11552 bytes
bytes
last
last cleared
cleared 00:03:01
00:03:01 ago,
ago, conformed
conformed 00 bps,
bps, exceeded
exceeded 00 bps
bps
To display information about the Committed Access Rate (CAR) for an interface,
use the show interfaces rate-limit EXEC command.
Information retrieved by the show interface rate limit command includes:
n Packets that match this rate limit
n Parameters for this rate limit (as configured by the rate-limit command)
n Average rate
n Normal burst size
n Excess burst size
n Number of packets that have conformed to the rate limit
n Conform action
n Number of packets that have exceeded the rate limit
n Exceed action
n Time since the last packet
n Instantaneous burst size at the current time
n Time since the burst counter was reset
n Rate of conforming traffic
n Rate of exceeding traffic
n Rate limits applicable to packets sent out by the interface
Display Rate-limit
Access Lists
Router(config)#
show access-lists rate-limit
• List rate-limit access lists

Router#show
Router#show access-lists
access-lists rate-limit
rate-limit
Rate-limit
Rate-limit access
access list
list 10
10
1
Rate-limit
Rate-limit access
access list
list 11
11
mask 81
Rate-limit
Rate-limit access
access list
list 120
120
4000.1234.ABCD
To display information about rate-limit access lists, use the show access-lists
rate-limit EXEC command. Information displayed includes:
n Whether the access list is precedence-based or MAC address-based
n What the IP precedence and IP precedence mask for packets in this rate-limit
access list are or what the MAC address for packets in this rate-limit access
list are
CAR – Limiting
Example #1
• A service provider connects all its customers

via 2 Mbps physical leased lines (or ADSL
links) and uses CAR to limit the actual
amount of traffic the user can send or
receive
• In addition several differentiated services
could be provided based on customers
needs
The first CAR case study shows a service provider, which uses a unified
infrastructure to connect all customers to an IP backbone. 2 Mbps leased lines or
ADSL links are used to connect customers to a POP. CAR is used to limit the
actual traffic rate to a lower value, as specified by the customer contract.
CAR can be used to offer differentiated, easy to upgrade services in this scenario,
as throughput is not limited by physical infrastructure, but rather by the traffic
policing by the ISP.
CAR – Limiting
Example #1

rate-limit input 256000 4000 96000
conform-action transmit exceed-action drop
rate-limit output 256000 4000 96000
2M
bps
Customer
2 Mbps
Internet
NAP
Customer ISP
bps
2M
Customer
In the configuration example, CAR is applied on the input and output of a customer
interface on the provider edge router. Traffic is policed to 256 Kbps on input and
output, with some bursting allowed. All exceeding traffic is dropped at the provider
edge.
The result of the configuration is that traffic to and from the customer is limited to
the average rate of approximately 256kbps (256000 in the configuration) with
sustained bursts of approximately 32kbps (4kBps or 4000 in the configuration).
Initial bursts at line speed can last up to 3 seconds because the token bucket can
hold up to 96000 tokens (bytes) which equals 768000 bits (3 x 256000 bits).
CAR – Limiting and Marking
Example #2
• Web traffic is limited to 512 Kbps and

transmitted with higher precedence
– Excess Web traffic is classified as regular traffic
• All other traffic is limited to 256 Kbps and
transmitted with precedence 0
– Excess traffic is dropped
– Burst size is 16000 bytes
– Excess burst size is 24000 bytes
The second case study provides a differentiated service for a customer, where
web traffic needs to be given more bandwidth compared to other traffic types.
Web traffic is limited to 512 Kbps, and a higher precedence is set. Web traffic
exceeding the configured rate limit is reclassified as regular traffic.
Regular traffic is limited to 256 Kbps, and colored with a precedence value of 0.
The same burst values are configured for web and all other traffic.
CAR – Limiting and Marking
Example #2
2 Mbps
Internet
Customer NAP
ISP

rate-limit input access-group 101 512000 64000 128000
conform-action set-prec-transmit 1 exceed -action continue
conform-action set-prec-transmit 0 exceed-action drop
rate-limit output access -group 101 512000 64000 128000
conform-action set-prec-transmit 1 exceed -action continue
!
access-list 101 permit tcp any any eq www
access-list 101 permit tcp any eq www any
The configuration implements the policy outlined in the previous case study. Traffic
is classified with extended access lists (to differentiate web traffic from other
traffic), and CAR uses the access list to apply the correct policing to the traffic.
Precedence values of 0 and 1 are set to signal preferential treatment of the web-
traffic to other QoS mechanisms, such as queuing and WRED.
The access list 101 identifies HTTP traffic using the default well-known port
number 80 (“www” in the configuration) either as the source or destination port
number in TCP segments. The conforming part of the class (up to 512 kbps) is
marked with IP precedence 1. The exceeding part of the class is further evaluated
by the next rate-limit command where it is limited together with the rest of the
traffic (non-HTTP) to 256 kbps. The total throughput, therefore, will never exceed
768 kbps (512 kbps of conforming HTTP traffic + 256 kbps of exceeding HTTP
traffic and all other traffic). WRED can be used in combination with CAR to
provide differentiated congestion avoidance anywhere in the network.
CAR – Limiting
Example #3
• The customer can send or receive up to 128

Kbps of premium traffic
– Premium traffic is marked with precedence 1
Excess premium traffic is dropped
• Non-premium (best-effort) traffic is not rate
limited
In the third case study, an ISP’s customer can exchange up to 128 Kbps of
premium traffic with the world. Premium traffic is marked with precedence 1 by
the customer, and the ISP polices the traffic to 128 Kbps using CAR. Other traffic
is not rate-limited.
CAR – Limiting
Example #3

rate-limit input access -group rate-limit 13 128000 16000 48000
conform-action transmit exceed -action drop
rate-limit output access-group rate -limit 13 128000 16000 48000
conform-action transmit exceed -action drop
!
access-list rate-limit 13 1
2M
bps
Customer
2 Mbps Internet
NAP
Customer ISP
bps
2M
Customer
The configuration shows traffic classification based on the packet precedence,

classified by the rate-limit access list. CAR only polices premium traffic, and all
other traffic has policing applied to it.
The premium traffic, previously marked with IP precedence 1, is classified using
the rate-limit access list 13. The premium traffic is strictly policed to 128kbps
where all excess traffic is dropped. All other traffic is not policed.
CAR – Precedence Spoofing
Example #4
rate-limit input
access-group rate-limit 1 64000 8000 8000
2M
bps conform-action drop
Customer exceed-action drop
!
2 Mbps access-list rate-limit 1 mask FE
Internet
NAP
Customer ISP
bps
2M
Customer
• If a customer is trying to spoof a service provider

with high-precedence traffic, the traffic is dropped
– Drop all non-precedence-0 traffic received from a customer
This case study shows a possible solution for preventing precedence spoofing for
best-effort customers. The customer may only send traffic with the precedence
value of 0. The CAR policing rule matches all non-zero-precedence traffic and
drops it unconditionally. The CAR metering parameters can be arbitrarily set to
any value.
The rate-limit access list in this example is using the mask option to match multiple
IP precedence values. Each bit in the mask corresponds to one IP precedence
value. The mask FE (11111110 binary) in the example matches all packets with IP
precedence values between 1 and 7. The rate-limit command drops all packets that
do not have IP precedence 0.
CAR – Limiting
Example #5
• Application: Web server collocation

– The customer can locate his server at service
provider premises (switched LAN)
– CAR is used to limit the amount of traffic the web
server can generate
– Unknown traffic is rate-limited to 64 kbps to allow
remote configuration of new servers
• Alternate application: central site in an
enterprise network
The fifth case study application uses web hosting as the example of QoS
application. The SP hosts a web-farm and wants to police traffic going to and from
specific servers. CAR is used, with MAC-based classification, to differentiate
traffic to or from different servers. A default policing statement allows some
traffic through to allow management protocols to run to yet unprovisioned servers.
This application can also be used to manage traffic flows to centralized servers in
enterprise networks.
CAR – Limiting
Example #5
Server
Core network
LAN switch Distribution
Server Router
interface FastEthernet 0/0

rate-limit input access-group rate -limit 100 10000000 100000 100000
rate-limit output access-group rate-limit 100 10000000 100000 100000
Server
!
access-list rate-limit 100 00ae.0123.abcd ! Server MAC address
The figure shows the configuration used to police traffic going to a specific server.
MAC-based rate-limit ACLs are used, which filter based on the upstream server
MAC address.
The special rate-limit access list is used to identify traffic from a web server which
may have multiple IP addresses. The traffic is limited to Ethernet speed even if the
underlying interface is using another type of media (for example: FastEthernet).
In the event that a customer changes the interface card (MAC address changes)
on the server, he can still get limited access to the server (64kbps) for
administrative purposes. The MAC-based rate-limit access list has to be modified
to reflect the new MAC address being used by the server.
CAR – Marking
Example #6
WAN
Core
Customer
interface ethernet 0/0
!
!
• CAR can be used purely for marking purposes

In this example, CAR is used purely for marking purposes. All traffic from one
customer (attached to the ethernet0/0 interface) is rate-limited to the line rate and
CAR marks all incoming packets with a configured precedence. Another customer
is connected to the same router, also rate-limited to the line rate, and marked with
a lower precedence.
The bit rate in the rate-limit command should be higher or equal to the physical
bandwidth of the interface to implement marking without any rate limiting. Another
option is to use the same action for both conforming and exceeding traffic.
CAR – Marking
Example #7
Customer
WAN
Core

conform-action set -prec-transmit 2
exceed-action drop
exceed-action drop
exceed-action drop
!
access-list 101 permit tcp any any eq telnet
access-list 102 permit tcp any any eq www
This configuration extends the possibilities of the previous example, using

application-specific marking. CAR is used to mark telnet traffic with a higher
precedence and web-traffic with a lower precedence. All other traffic is marked
with precedence zero.
Note There is no true policed rate limiting in this example, as traffic is rate -limited to
the line rate.
The first rate-limit command identifies inbound telnet sessions (access list 101) and
marks them with IP precedence 2 without limiting it.
The second rate-limit command identifies inbound HTTP sessions (access list 102)
and marks them with IP precedence 1 without limiting it.
The third rate-limit command marks all other packets (no access list is used) with
IP precedence 0 without limiting it.
Summary
n CAR can be applied on input and output interfaces
n CAR performs no buffering or shaping
n CAR can mark packets
n In Frame Relay, CAR has no support for BECN or FECN
n Cascaded policies can be applied
n CAR provides managed discard between the normal burst and extended burst
parameters
n CAR can run in distributed mode (on 7500 VIP)
n CAR can apply access lists based on ToS bits/MAC address and IP extended
access lists
n CAR is not RSVP aware
Lesson Review
1. What classification options does CAR support?
2. What are the main differences between CAR and traffic shaping?
3. Where can CAR be implemented?
Summary
n GTS/FRTS perform traffic shaping or smoothing
n GTS/FRTS cannot mark or drop packets
n GTS/FRTS can intelligently adapt to Layer-2 congestion
n GTS/FRTS do not support cascaded policies
n GTS/FRTS do not provide managed discard
n CAR performs no buffering or shaping
n CAR can mark packets
n In Frame Relay, CAR has no support for BECN or FECN
n Cascaded policies can be applied in CAR
n Both GTS and CAR can run in distributed mode
n CAR is not RSVP aware, while GTS is
Question: How do shaping and policing mechanisms keep track of the traffic
rate?
Answer: Both mechanisms use a token bucket as a rate measurement method.
Question: Which shaping mechanisms are available with the Cisco IOS software?
Answer: Cisco IOS supports Generic Traffic Shaping, Frame Relay Traffic
Shaping, and Class-based Shaping.
Question: Which policing mechanisms are available with the Cisco IOS
software?
Answer: Cisco IOS supports Committed Access Rate (CAR) and Class-based
Policing.
Question: What are the main differences between shaping and policing?
Answer: To stay within the configured rate, shaping delays excessive traffic while
policing drops excessive traffic.

Question: What software queuing mechanisms are supported in combination with
GTS?
Answer: Any software queuing method (FIFO, priority queuing, custom queuing,
WFQ, CB-WFQ) is supported on an interface in combination with GTS.
Question: Which queuing structure does GTS use?
Answer: GTS uses WFQ as the shaping queue.
Question: What features does GTS include when used on Frame Relay
interfaces?
Answer: GTS can adapt its rate to Frame Relay congestion signaling, and
propagate FECN signals to BECN signals, sent towards the sender on the
Frame Relay network.

Question: What are the main differences between GTS and FRTS?
Answer: FRTS shapes traffic of individual Frame Relay VCs. Also, the shaping
queue of FRTS is configurable and can be any of the software queuing
mechanisms.
Question: Where can FRTS be used?
Answer: FRTS can only be used on Frame Relay interfaces.
Question: What classification options does FRTS have?
Answer: None, FRTS shapes all traffic on a Frame Relay VC.

Question: What classification options does CAR support?
Answer: CAR supports Access Control Lists (ACLs), rate-limit ACLs, DSCP
value, and QoS-group as its classifiers.
Question: What are the main differences between CAR and traffic shaping?
Answer: CAR never delays excess traffic, but can drop or transmit it. CAR also
supports marking of conforming and exceeding traffic, and supports nested
classification and policing. CAR can also be used both on input and output of
interfaces, while traffic shaping can only be used on output.
Question: Where can CAR be implemented?
Answer: CAR can be implemented on input or output of interfaces.
5
Congestion Avoidance
Overview
This module describes the problems of congested networks. It introduces Random
Early Detection (RED), WRED, and Flow-based WRED as mechanisms to
prevent congestion on router interfaces.
Objectives
n Describe Random Early Detection (RED)
n Describe and configure Weighted Random Early Detection (WRED)
n Describe and configure Flow-based WRED
Random Early Detection
Overview
The section describes the need for congestion avoidance in nearly-congested
networks and explains the benefits of using RED on congested links.
Objectives
n Explain the need for congestion avoidance mechanisms.
n Explain how RED works and how it can prevent congestion.
n Describe the benefits and drawbacks of RED.
5-2 Congestion Avoidance Copyright  2001, Cisco Systems, Inc.

Router Interface Congestion
• Router interfaces congest when the output

queue is full
–Additional incoming packets are dropped
–Dropped packets may cause significant
application performance degradation
–By default, routers perform tail-drop
–Tail-drop has significant drawbacks
–WFQ, if configured, has a more intelligent
dropping scheme
© 2001, Cisco Systems, Inc. Congestion Avoidance-5
When an interface on a router cannot transmit a packet immediately, the packet is

queued, either in an interface Tx ring, or the interface output hold queue, depending
on the switching path used. Packets are then taken out of the queue and eventually
transmitted on the interface.
If the arrival rate of packets to the output interface exceeds the router’s capability
to buffer and forward traffic, the queues increase to their maximum length and the
interface becomes congested. Tail drop is the router’s default queuing response to
congestion. When the output queue is full and tail drop is in effect, all packets
trying to enter (at the tail of) the queue are dropped until the congestion is
eliminated and the queue is no longer full.
Congestion avoidance techniques monitor network traffic loads in an effort to
anticipate and avoid congestion at common network bottleneck points. Congestion
avoidance is achieved through packet dropping using more complex techniques
than simple tail-drop.
As mentioned, tail drop is the default queuing response to congestion. Tail drop
treats all traffic equally and does not differentiate between classes of service.
Weighted fair queuing, if configured on an interface, has a more elaborate scheme
for dropping traffic, as it is able to punish the most aggressive flows via its
Congestion Discard Threshold (CDT)-based dropping algorithm. Unfortunately,
WFQ does not scale to backbone speeds. WFQ dropping is discussed in detail in its
associated module.
This module introduces Random Early Detection (RED) and its scalable dropping
method, which is suitable for low and high-speed networks.
Copyright  2001, Cisco Systems, Inc. Congestion Avoidance 5-3

Tail-drop Flaws
• Simple tail-drop has significant flaws

–TCP synchronization
–TCP starvation
–High delay and jitter
–No differentiated drop
–Poor feedback to TCP
The simple tail-dropping scheme unfortunately does not work very well in
environments with a large number of TCP flows or in environments in which
selective dropping is deserved. Understanding of the interaction between TCP
stack intelligence and dropping in the network is required to implement a more
efficient and fair dropping scheme, especially in SP environments.
Tail drop has the following shortcomings:
n When congestion occurs, dropping affects most of the TCP sessions, which
simultaneously back-off and then restart again. This causes inefficient link
utilization at the congestion point (TCP global synchronization)
n TCP starvation, where all buffers are temporarily seized by aggressive flows,
and normal TCP flows experience buffer starvation.
n Buffering at the point of congestion can introduce delay and jitter, as packets
are stuck waiting in queues.
n There is no differentiated drop mechanism, and therefore premium traffic is
dropped in the same way as best-effort traffic.
n Even in the event of a single TCP stream across an interface, the presence of
other non-TCP traffic can congest the interface and TCP traffic will also be
dropped. In this scenario, the feedback to the TCP protocol is very poor and
therefore it cannot adapt properly to a congested network.

TCP Synchronization
Average link Flow A

utilization
Flow B
Flow C
• Multiple TCP sessions start at different times

• TCP window sizes are increased
• Tail-drops cause many packets of many sessions to be
dropped at the same time
• TCP sessions restart at the same time (synchronized)
A router can handle multiple concurrent TCP sessions. There is a high probability
that when traffic exceeds the queue limit at all, it vastly exceeds the limit due to the
bursty nature of packet networks. However, there is also a high probability that
excessive traffic depth caused by packet bursts is temporary and that traffic does
not stay excessively deep except at points where traffic flows merge, or at edge
routers.
If the receiving router drops all traffic that exceeds the queue limit, as is done by
default (with tail drop), many TCP sessions then simultaneously go into slow start.
Consequently, traffic temporarily slows down to the extreme and then all flows
slow-start again. This activity creates a condition called global synchronization.
Global synchronization occurs as waves of congestion crest only to be followed by
troughs during which the transmission link is not fully utilized. Global
synchronization of Transmission Control Protocol (TCP) hosts, for example, can
occur because packets are dropped all at once. Global synchronization manifests
when multiple TCP hosts reduce their transmission rates in response to packet
dropping, then increase their transmission rates once again when the congestion is
reduced. The most important point is that the waves of transmission known as
global synchronization result in significant link under-utilization.

TCP Starvation, Delay and Jitter
Packets of
Packets of aggressive
starving flows flows
Prec. Prec. Prec. Prec. Prec. Prec. Prec. Prec.

3 3 3 0 3 0 0 0 Queue
Delay
TCP does not
react well if Tail-drop does
multiple Packets experience long delay if
not look at IP
packets are interface is constantly congested
precedence
dropped
• Constant high buffer usage (long queue) causes delay

• More aggressive flows can cause other flows to starve
• Variable buffer usage causes jitter
• No differentiated dropping
Another TCP-related phenomenon, which reduces optimal throughput of network

applications is TCP starvation. When multiple flows are established over a router,
some of these flows may be much more aggressive as compared to others. For
instance, when a file transfer application’s TCP transmit window increases, it can
send a number of large packets to its destination. The packets immediately fill the
queue on the router, and other, less aggressive flows can be starved, because they
are tail-dropped at the output interface.
During periods of congestion, packets are queued up to the full queue length, which
also causes increased delay for packets already in the queue. In addition, queuing,
being a probabilistic mechanism, introduces unequal delays for packets of the same
flow, producing jitter.

Conclusion
• Tail-drop should be avoided

• Tail-drop can be avoided if congestion is
prevented
• Congestion can be prevented if TCP
sessions (that still make up more than 80
percent of average Internet traffic) can be
slowed down
• TCP sessions can be slowed down if some
packets are occasionally dropped
• Therefore: packets should be dropped when
interface is nearing congestion
Based on the knowledge of TCP behavior during periods of congestion, it can be

concluded that tail-drop is not the optimal mechanism for congestion avoidance and
therefore should not be used. Instead, more intelligent congestion avoidance
mechanisms should be used, which would slow down traffic before actual
congestion occurs.
IP traffic can be “slowed down” only for traffic using an adaptive transmission
protocol, such as TCP. Dropping packets of a TCP session indicates to the sender
that it should lower its transmission rate to adapt to changing network conditions.
UDP, on the other hand, has no built-in adaptive mechanisms – it sends packets
out at a rate specified by the application. About 80% of Internet traffic today is
carried over the TCP protocol. If TCP packets of aggressive flows are intelligently
dropped, those sessions will slow down and congestion will be avoided.
Therefore, to prevent congestion, the output queues should not be allowed to get
full, and TCP can be controlled via packet dropping. The new dropping
mechanisms should drop packets before congestion occurs, and drop them in such
a way that primarily influences aggressive traffic flows.

• Random Early Detection (RED) is a mechanism that

randomly drops packets even before a queue is full
• RED drops packets with an increasing probability
• RED result:
– TCP sessions slow down to the approximate rate of output-
link bandwidth
– Average queue size is small (much less than the maximum
queue size)
• IP precedence can be used to drop lower -
precedence packets more aggressively than higher-
precedence packets
© 2001, Cisco Systems, Inc. Congestion Avoidance -10
Random Early Detection is a dropping mechanism that randomly drops packets

before a queue is full. The dropping strategy is based primarily on the average
queue length - that is, when the average queue gets longer (fuller), RED will be
more likely to drop an incoming packet than when the queue is shorter.
Because RED drops packets randomly, it has no per-flow intelligence. The
rationale behind this is that an aggressive flow will represent most of the arriving
traffic, therefore it is more probable that RED will drop a packet of an aggressive
session. RED therefore punishes more aggressive sessions with higher statistical
probability, and is therefore able to somewhat selectively slow down the most
significant cause of congestion. Directing one TCP session at a time to slow down
allows for full utilization of the bandwidth, rather than utilization that manifests itself
as crests and troughs of traffic.
As a result, the TCP global synchronization is much less likely to occur, and TCP
can utilize the bandwidth more efficiently. The average queue size also decreases
significantly, as the possibility of the queue filling up is very small. This is due to
very aggressive dropping in the event of traffic bursts, when the queue is already
quite full.
RED distributes losses over time and maintains normally low queue depth while
absorbing spikes. RED can also utilize precedence/DSCP bits in packets to
establish different drop profiles for different classes of traffic.

RED Profile
Drop No drop Random drop Full drop

Probability
100%
Maximum
Drop
Probability
10%
20 40 Average
Queue
Size
Minimum Maximum
Threshold Threshold
The probability of a packet being dropped is based on three configurable

parameters:
n Minimum threshold - When the average queue depth is above the minimum
threshold, RED starts dropping packets. The rate of packet drop increases
linearly as the average queue size increases, until the average queue size
reaches the maximum threshold.
n Maximum threshold - When the average queue size is above the maximum
threshold, all packets are dropped. If the difference between the maximum
threshold and the minimum threshold is too small, many packets might be
dropped at once, resulting in global synchronization.
n Mark probability denominator - This is the fraction of packets dropped when
the average queue depth is at the maximum threshold. For example, if the
denominator is 512, one out of every 512 packets is dropped when the average
queue is at the maximum threshold.
These parameters define the RED profile, which implements the packet dropping
strategy, based on the average queue length.

RED Modes
• RED has three modes:

– No drop – when the average queue size is between
0 and the minimum threshold
– Random drop - when the average queue size is
between the minimum and the maximum threshold
– Full drop (tail-drop) – when the average queue size
is at maximum threshold or above
• Random drop should prevent congestion
(prevent tail-drops)
As seen in the previous figure, RED has three dropping modes, based on the
average queue size:
n When the average queue size is between 0 and the configured minimum
threshold, no drops occur and all packets are queued.
n When the average queue size is between the configured minimum threshold,
and the configured maximum threshold, random drop occurs, which is linearly
proportional to the average queue length. The maximum probability of drop
(when the queue is almost completely full) is 15% in Cisco IOS software.
n When the average queue size is at or higher than the maximum threshold, RED
performs full (tail) drop in the queue. This event is unlikely, as RED should
slow down TCP traffic ahead of congestion. If a lot of non-TCP traffic is
present, RED cannot effectively drop traffic to reduce congestion, and tail-
drops are likely to occur.

Before RED
Average link Flow A

utilization
Flow B
Flow C
• TCP synchronization prevents average link

utilization close to the link bandwidth
• Tail-drops cause TCP sessions to go into
slow-start
The figure shows TCP throughput behavior compared to link bandwidth in a

scenario of congestion, and simple tail-dropping on a router. The global
synchronization phenomenon causes all sessions to slow down when congestion
occurs, as all sessions are penalized when tail-drop is used because it drops
packets with no discrimination between individual flows.
When all sessions slow down, the interface becomes uncongested, and all TCP
sessions restart their transmission at roughly the same time. The interface quickly
becomes congested again, causing tail-dropping, and all TCP sessions back off
again. This behavior cycles constantly, resulting in a link that is always
underutilized on the average.

After RED
Average link
utilization
Flow A
Flow B
Flow C
• Average link utilization is much closer to link

bandwidth
• Random drops cause TCP sessions to
reduce window sizes
The figure shows TCP throughput behavior compared to link bandwidth in a

scenario of congestion, and RED configured on a router. RED randomly drops
packets, influencing a small number of sessions at a time, before the interface
reaches congestion. Overall throughput of sessions is increased, as well as average
link utilization. Global synchronization is very unlikely to occur, as there is selective,
but random dropping of adaptive traffic.

Summary
n Tail-drop does not perform adequate congestion avoidance on router
interfaces.
n RED randomly drops packets before an interface is congested, punishing
aggressive flows.
n RED prevents interface congestion and prevents TCP global synchronization,
but works well only in predominantly TCP-based environments.
Lesson Review
1. What are the main drawbacks of using tail-drop as a means of congestion
control?
2. What does RED do to prevent TCP synchronization?
3. What are the three modes of RED?

Weighted Random Early Detection
Overview
The section describes the WRED mechanism available in Cisco IOS.
Objectives
n Describe the Weighted Random Early Detection (WRED) mechanism
n Configure WRED on Cisco routers
n Monitor and troubleshoot WRED on Cisco routers

Weighted Random Early
Detection
• WRED uses a different RED profile for each weight

• Each profile is identified by:
– minimum threshold
– maximum threshold
– maximum drop probability
• Weight can be
– IP precedence (8 profiles)
– DSCP (64 profiles)
• WRED drops less important packets more
aggressively than more important packets
Weighted Random Early Detection (WRED) combines RED with IP Precedence

or DSCPs and does packet drops based on IP Precedence or DSCP markings.
As with RED, WRED monitors the average queue depth in the router and
determines when to begin packet drops based on the queue depth. When the
average queue depth crosses the user-specified “minimum threshold,” WRED
begins to drop packets (both TCP and UDP) with a certain probability. If the
average queue depth ever crosses the user-specified ”maximum threshold,” then
WRED reverts to ”tail drop,” where all incoming packets might be dropped. The
idea behind using WRED is to maintain the queue depth at a level somewhere
between the minimum and maximum thresholds, and to implement different drop
policies for different classes of traffic.
WRED can selectively discard lower priority traffic when the interface becomes
congested and provide differentiated performance characteristics for different
classes of service. WRED can also be configured so that non-weighted RED
behavior is achieved.
For interfaces configured to use the Resource Reservation Protocol (RSVP),
WRED chooses packets from other flows to drop rather than the RSVP flows.
Also, IP Precedence or DSCPs govern which packets are dropped − traffic that is
at a lower priority has a higher drop rate and therefore is more likely to be throttled
back.
WRED reduces the chances of tail drop by selectively dropping packets when the
output interface begins to show signs of congestion. By dropping some packets
early rather than waiting until the queue is full, WRED avoids dropping large
numbers of packets at once and minimizes the chances of global synchronization.
Thus, WRED maximizes the utilization of transmission lines.

In addition, WRED statistically drops more packets from large users than small
ones. Therefore, traffic sources that generate the most traffic are more likely to be
slowed down than traffic sources that generate little traffic.
WRED avoids the global synchronization problems that occur when tail drop is
used as the congestion avoidance mechanism. Global synchronization manifests
when multiple TCP hosts simultaneously reduce their transmission rates in
response to packet dropping, then increase their transmission rates again once the
congestion is reduced.
WRED is only useful when the bulk of the traffic is TCP traffic. With TCP,
dropped packets indicate congestion, so the packet source reduces its transmission
rate. With other protocols, packet sources might not respond or might re-send
dropped packets at the same rate, and so dropping packets does not decrease
congestion.
WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore,
non-IP traffic, in general, is more likely to be dropped than IP traffic.
WRED should be used wherever there is a potential bottleneck (congested link),
which could very well be an access/edge link. However, WRED is normally used
in the core routers of a network rather than at the network’s edge. Edge routers
assign IP Precedences to packets as they enter the network. WRED uses these
precedences to determine how to treat different types of traffic.
Note that WRED is not recommended for any voice queue, although it may be
enabled on an interface carrying voice traffic. RED will not throttle back voice
traffic, because it is UDP-based, and the network itself should not be designed to
lose voice packets since lost voice packets result in reduced voice quality. WRED
controls congestion by impacting other prioritized traffic, and avoiding congestion
helps to ensure voice quality.

WRED Profiles
Drop
Probability
100%
10%
10 20 40 Average
Queue
Size
• WRED profiles can be manually set
• WRED has 8 default value sets for IP precedence based WRED
• WRED has 64 default value sets for DSCP based WRED
The figure shows two WRED profiles, used for traffic of different QoS classes.
The RED class has a much lower minimum and maximum threshold. Traffic of
that class will be dropped much earlier and more aggressively. When heavy
congestion occurs, the RED class will ultimately be tail dropped. The BLUE class
has a higher minimum and maximum thresholds, therefore dropping occurs later
and is less likely, compared to the RED class. This maintains differentiated levels
of service in the event of congestion.
To avoid the need of setting all WRED parameters in a router, 8 default values are
already defined for precedence-based WRED, and 64 DiffServ-aligned values are
defined for DSCP-based WRED. Therefore, the default settings should suffice in
the vast majority of deployments.

IP Precedence and Class Selector
Profiles
Drop
Probability
100%
10%
IP precedence 0 1 2 3 4 5 6 7 RSVP Average

20 22 24 26 28 31 33 35 37 40 Queue
Size
A Per-Hop Behavior (PHB) is the externally observable forwarding behavior

applied at a DiffServ-compliant node to a DiffServ Behavior Aggregate (BA).
With the ability of the system to mark packets according to DSCP setting,
collections of packets − each with the same DSCP setting and sent in a particular
direction − can be grouped into a DiffServ BA. Packets from multiple sources or
applications can belong to the same DiffServ BA.
In the Assured Forwarding PHB (as defined in RFC 2474,) WRED uses the Drop
Preference (second digit of the AF number) to determine drop probability. This
enables differentiated dropping of AF traffic classes, which have different drop
preference.

DSCP-based WRED
(Expedited Forwarding)
Drop
Probability
100%
10% EF
Average
20 36 40 Queue
Size
The Expedited Forwarding PHB is identified based on the following parameters:

n Ensures a minimum departure rate to provide the lowest possible delay to
delay-sensitive applications
n Guarantees bandwidth to prevent starvation of the application if there are
multiple applications using Expedited Forwarding PHB
n Polices bandwidth to prevent starvation of other applications or classes that are
not using this PHB
n Packets requiring Expedited Forwarding should be marked with DSCP binary
value “101110” (46 or 0x2E)
For the Expedited Forwarding DiffServ traffic class, WRED configures itself by
default so that the minimum threshold is very high, increasing the probability of no
drops being applied to that traffic class. EF-traffic is therefore expected to be
dropped very late, compared to other traffic classes, in the event of congestion.

DSCP-based WRED
(Assured Forwarding)
Drop
Probability
100%
AF Low Drop
AF Medium Drop
AF High Drop
10%
Average
20 24 28 32 40 Queue
Size
The Assured Forwarding PHB is identified based on the following parameters:

n Guarantees a certain amount of bandwidth to an AF class
n Allows access to extra bandwidth, if available
n Packets requiring AF PHB should be marked with DSCP value “aaadd0”
where “aaa” is the number of the class and “dd” is the drop probability or drop
preference of the traffic class.
There are four standard-defined AF classes. Each class should be treated
independently and have bandwidth allocated based on the QoS policy.
For the Assured Forwarding DiffServ traffic class, WRED configures itself by
default for three different profiles, depending on the Drop Preference DSCP
marking bits. AF-traffic should therefore be classified into the three possible
classes based on the application sensitivity to dropping. WRED implements a
congestion avoidance PHB in agreement with the initial classification.

WRED Building Blocks
Calculate Average
Queue Size Current
Queue
Size
Queue No
IP packet WRED FIFO Queue
Full?
IP precedence
Yes
or
DSCP
Select
WRED
Min. threshold
Profile Random Drop Tail Drop
Max. threshold
Max prob. denom.
The figure shows how WRED is implemented, and the parameters that influence
WRED dropping decisions. The WRED algorithm is constantly updated with the
calculated average queue size, which is based on the recent history of queue sizes.
The configured WRED profiles define the dropping thresholds (and therefore the
WRED probability slopes). When a packet arrives at the output queue, the IP
precedence of DSCP-value is used to select the correct WRED profile for the
packet. The packet is then passed to WRED to perform a drop/enqueue decision.
Based on the profile and the average queue size, WRED calculates the probability
for dropping the current packet and either drops it or passes it to the output queue.
If the queue is already full, the packet is tail-dropped. Otherwise, it is eventually
transmitted out onto the interface.

Configuring WRED and dWRED
Router(config-if)#
random-detect
random-detect
• Enables IP precedence based WRED

• Default service profile is used
• Non-distributed WRED cannot be combined
with fancy queuing - FIFO queuing has to be
used
• WRED can run distributed on VIP-based
interfaces (dWRED)
• dWRED can be combined with dWFQ
The random-detect command is used to enable WRED on an interface. By

default, WRED is precedence-based, using eight default WRED profiles.
Used on VIP-based interfaces, this command enables distributed WRED
(dWRED), where the VIP CPU performs WRED dropping. This can significantly
increase router performance, when used in the context of distributed CEF
switching, which is a prerequisite for dWRED functionality. Also, dWRED can be
combined with dWFQ, enabling truly distributed queuing and congestion avoidance
techniques, running independently from the central CPU.
With centralized platforms, WRED, if configured, cannot be combined with other
queuing methods (priority, custom, and weighted-fair queuing). Those methods use
either tail-dropping or their own dropping methods. Therefore, WRED can only be
configured with FIFO queuing on an interface. This is not a major issue, because
WRED is usually applied in the network core, where there should be no queuing
configured. WRED is suited for the network core as it has a relatively low
performance impact on routers.

Changing WRED profile
Router(config-if)#
random-detect precedence
precedence precedence
precedence min-threshold max-threshold
mark-prob-denominator
mark-prob-denominator
• Changes RED profile for specified IP

precedence value
• Packet drop probability at maximum
threshold is
1 / mark-prob-denominator
• Non-weighted RED is achieved by using the
same RED profile for all precedence values
In this example, WRED is enabled with default values, and then the values are
changed for each IP Precedence level. The configured values, which are
described above under Random Early Detection, are repeated here for
convenience:
n Mark probability denominator - This is the fraction of packets dropped when
the average queue depth is at the maximum threshold. For example, if the
denominator is 512, one out of every 512 packets is dropped when the average
queue is at the maximum threshold.
It is interesting to note, that the maximum probability of drop at the maximum
threshold can be expressed as 1/mark-prob-denominator. The maximum drop
probability is 10%, if default settings are used.
If required, RED can be configured as a special case of WRED, by assigning the
same profile to all eight precedence values.

Changing WRED Sensitivity
to Bursts
Router(config-if)#
random-detect exponential-weighting-constant n
Qavg ( t + 1) = Qavg (t ) ⋅ (1 − 2 − n ) + Qt ⋅ 2 − n
New average Previous average Current queue

queue size queue size size
• WRED takes the average queue size to determine the current

WRED mode (no drop, random drop, full drop)
• High values of N allow short bursts
• Low values of N make WRED more burst-sensitive
• Default value (9) should be used in most scenarios
• Average output queue size with N=9 is
average t+1 = average t * 0.998 + queue_sizet * 0.002
As mentioned previously, WRED does not calculate the drop probability using the
current queue length, but rather uses the average queue length. The average queue
length is constantly recalculated, using two terms: the previously calculated
average queue size and the current queue size. An exponential weighting constant
N influences the calculation by weighing the two terms, therefore influencing how
the average queue size follows the current queue size, in the following way:
n A low value of N makes the current queue size more significant in the new
average size calculation, therefore allowing larger bursts
n A high value of N makes the previous average queue size more significant in
the new average seize calculation, so that bursts influence the new value to a
smaller degree.
The default value is 9 and should suffice for most scenarios, except perhaps those
involving extremely high-speed interfaces (like OC12), where it can be increased
slightly (to about 12) to allow more bursts.

Configuring DSCP-based WRED
Router(config-if)#
random-detect
random-detect {prec-based
{prec-based || dscp-based}
dscp-based}
• Selects WRED mode

• Precedence-based WRED is the default
mode
• DSCP-based uses 64 profiles
The random-detect dscp-based command is used to enable DSCP-based

WRED on an interface, using the 64 default DSCP-based WRED profiles.

Changing WRED Profile
Router(config-if)#
random-detect dscp
dscp dscp
dscp min-threshold max-threshold mark-prob-
denominator
denominator
• Changes RED profile for specified DSCP value

• Packet drop probability at maximum threshold is
The DSCP-weighted WRED profiles can be changed, again using the known three
WRED parameters. The mask-prob-denominator defines the packet drop
probability at the WRED maximum threshold. The maximum drop probability is
10%, if default settings are used. Normally, the DSCP-weighed profiles should be
left at their default settings, as those settings are appropriate for most situations, if
traffic is classified according to the DiffServ service specification.

WRED Case Study
• WRED is applied to a core link in a network with the

following IP precedence definitions
IP prec. Meaning
0 High-
High-drop best effort traffic
1 Low-
Low -drop best
best-effort traffic
2 Premium
Premium traffic
traffic outside
outside of the contract
3 Premium
Premium traffic
traffic in
in the
the contract
contract
4 Unused
5 Voice-
Voice-over-
over -IP
6 Routing protocol traffic

7 Routing protocol
protocol traffic
traffic
This WRED case study presents a network carrying traffic with eight different
service levels, each assigned a precedence value, with which packets are marked.
The figure shows the precedence to traffic -type mapping, where higher
precedence values are assigned to more important traffic. Voice traffic, for
example, is ranked just below essential routing protocol traffic, whereas other IP
traffic is divided into premium and best-effort levels, also depending on drop-
sensitivity. Traffic is classified at the edge of the network, and WRED provides
differentiated handling of traffic in the core, if core interfaces are nearing
congestion.
This information is used to build a custom WRED profile, based on the above
policy. When congestion is about to occur, WRED will drop packets, preferring
lower-precedence traffic, which is either drop-resistant or part of a best-effort
service. Premium traffic should experience few drops, and voice and routing
protocol traffic are unlikely to get dropped, because they are assigned a very high
minimum dropping threshold.
While it is not recommended to use WRED with voice traffic, this example
aggregates many types of traffic, including voice, on a single access line. WRED is
configured so that voice is unlikely to be dropped, and other aggressive flows are
dropped first. Ideally, there would also be a separate voice queue configured, and
voice traffic priority scheduled against other traffic.

WRED Case Study
Guidelines
• Best-effort traffic should be dropped before premium

traffic
• Out-of-contract or high-drop best -effort traffic
should be dropped very aggressively
• Voice traffic should be dropped only under extreme
congestion
• Routing protocol traffic should be less drop-
resistant than VoIP (depends on the routing protocol
and control over amount of VoIP traffic)
• Configure WRED with default values on an interface
first and tune the per -precedence parameters based
on default values
The WRED dropping strategy for different traffic classes can be outlined as
n Best-effort traffic should be dropped before premium traffic.
n Out-of-contract or high-drop best-effort traffic should be dropped very
aggressively.
n Voice traffic should be dropped only under extreme congestion.
n Routing protocol traffic should be less drop-resistant than VoIP (depends on
the routing protocol and control over amount of VoIP traffic).
To implement this dropping policy, WRED is configured with default parameters
and then tuned to comply with the above policy.

Sample WRED Profile
Packet Discard
Probability
VoIP
Precedence 3
Routing
Precedence 1
0.1
Precedence 2
Precedence 0
Average
Queue Size RSVP
10
15
20
25
30
35
37
The figure presents the values chosen to tune WRED dropping according to the
case study policy. Different precedence traffic will be assigned different minimum
and maximum threshold values to reflect the relative dropping strategies outlined in
the requirements. Note that the maximum drop probability is 10% (default) and the
same for all precedence levels. This setting should not be changed in most
implementations.

WRED Configuration
interface
interface Serial
Serial 0/1/0
0/1/0
ip address
address 200.200.14.250
200.200.14.250 255.255.255.252
255.255.255.252
random-detect
random-detect precedence 0 10 10 25
25 10
10
35 10
10
25 10
10
35 10
10
precedence 44 11 2 11
40 10
10
40 10
10
40 10
10
This configuration excerpt shows the implementation of the dropping policy,

illustrated by the case study. The threshold values reflect the values chosen in the
previous figure. Note that precedence 4 is not used to mark traffic in the case
study network, so the drop probability of precedence 4 traffic is 100% (1 divided
by 1 times 100%).

Monitoring WRED
• Show interface
– displays the queuing/dropping mechanism in use
displays WRED parameters (VIP only)
• Show queueing
– displays the RED profile for each interface
• Show queue
– displays the interface output queue
• Show interface random-detect
– displays RED statistics (VIP only)
The listed commands provide means to monitor WRED configuration and

operation.

Interface Parameters
Router#
show interface intf
• Displays interface parameters

Router#show
interface serial
serial 1/0
1/0
Serial1/0
Serial1/0 is up,up, line
line protocol
protocol is up
Hardware
Hardware is
is CD2430
CD2430 in
in sync
sync mode
mode
Internet
Internet address
address is
is 192.168.1.2/30
192.168.1.2/30
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 128
128 Kbit,
Kbit, DLY
DLY 200
200 usec,
usec, rely
rely 255/255
255/255 ...
...
Encapsulation
Encapsulation HDLC,
HDLC, loopback
loopback not
not set,
set, keepalive
keepalive setset (10 sec)
Last
Last input 00:00:07, output 00:00:07, output hang never
Last
Last clearing
clearing of "show
"show interface"
interface" counters never
Input
Input queue:
queue: 2/75/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: random
random early
early detection
detection (WRED)
(WRED)
55 minute
minute input
input rate
rate 00 bits/sec,
packets/sec
55 minute output rate 0 bits/sec,
packets/sec
337102
337102 packets
packets input,
input, 27357987
27357987 bytes,
bytes, 00 no
no buffer
buffer
Received
Received 265169
265169 broadcasts,
broadcasts, 00 runts,
runts, 00 giants,
giants, 0 throttles
throttles
00 input
input errors,
errors, 00 CRC,
CRC, 00 frame,
frame, 00 overrun,
overrun, 00 ignored,
ignored, 00 abo
abort
rt
...
... rest
rest deleted
deleted ...
...
The show interface command will display whether or not WRED is the preferred
congestion avoidance mechanism on the interface.

WRED Parameters and Statistics
Router#
show queueing random-detect
• Displays per-interface parameters WRED statistics

Router#show
queueing random-detect
random-detect
Current
Current random-detect
random -detect configuration:
configuration:
Serial1/0
Serial1/0
Queueing
Queueing strategy:
strategy: random
random early
early detection
detection (WRED)
(WRED)
Exp-weight-constant:
Exp-weight-constant: 99 (1/512)
(1/512)
Mean
Mean queue
queue depth:
depth: 38
38
Class
Class Random Tail Minimum Maximum Mark
drop
drop drop
drop threshold
threshold threshold
threshold probability
probability
00 174 34 20 40 1/10
11 00 00 22
22 40
40 1/10
1/10
22 00 00 24
24 40
40 1/10
1/10
33 0 0 26 40 1/10
44 0 0 28 40 1/10
55 0 0 31 40 1/10
66 6 3 33 40 1/10
77 00 00 35
35 40
40 1/10
1/10
rsvp
rsvp 00 00 37
37 40
40 1/10
1/10
The show queuing command shows the configuration and statistics for configured
WRED profiles.

dWRED Parameters and Statistics
Router#show
interfaces random-detect
random-detect
FastEthernet1/0/0
FastEthernet1/0/0 queue
queue size
size 00
packets
packets output
output 29692,
29692, drops
drops 00
WRED:
WRED: queue
queue average
average 00
weight
weight 1/512
Precedence
Precedence 0:0: 109
109 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
11 packets
packets output,
output, drops:
drops: 00 random,
random, 00 threshold
threshold
Precedence
Precedence 1:1: 122
122 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
(no
(no traffic)
traffic)
Precedence
Precedence 2:2: 135
135 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
14845
14845 packets
packets output,
output, drops:
drops: 0 random,
random, 0 threshold
threshold
Precedence
Precedence 3:3: 148
148 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
(no
(no traffic)
traffic)
Precedence
Precedence 4:4: 161
161 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
(no
(no traffic)
traffic)
Precedence
Precedence 5:5: 174
174 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
(no
(no traffic)
traffic)
Precedence
Precedence 6:6: 187
187 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
14846
14846 packets
packets output,
output, drops:
drops: 0 random,
random, 0 threshold
threshold
Precedence
Precedence 7:7: 200
200 min
min threshold,
threshold, 218
218 max
max threshold,
threshold, 1/10
1/10 ma
mark
rk weight
weight
(no
(no traffic)
traffic)
The show interfaces random-detect command shows the dWRED profile

configuration for the specified interface. Use this command to display dWRED
statistics on interfaces performing distributed services.

Queue Details
Router#
show queue
queue intf
• Displays queue contents
Router#show
Router#show queue
queue serial
serial 1/0
1/0
Output
Output queue
queue for
for Serial1/0
Serial1/0 is
is 65/0
65/0
Packet
Packet 1,
1, linktype:
linktype: ip,
ip, length:
length: 1504,
1504, flags:
flags: 0x48
0x48
source:
source: 192.168.1.2,
192.168.1.2, id:
id: 0x001A,
0x001A, ttl:
ttl: 255,
255, prot:
prot: 11
data:
data: 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
Packet
Packet 2,
2, linktype:
linktype: ip,
ip, length:
length: 1504,
1504, flags:
flags: 0x48
0x48
source:
source: 192.168.1.2,
192.168.1.2, id:
id: 0x001A,
0x001A, ttl:
ttl: 255,
255, prot:
prot: 11
data:
data: 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
Packet
Packet 3,
3, linktype:
linktype: ip,
ip, length:
length: 1504,
1504, flags:
flags: 0x48
0x48
source:
source: 192.168.1.2,
192.168.1.2, id:
id: 0x001A,
0x001A, ttl:
ttl: 255,
255, prot:
prot: 11
data:
data: 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
...
... rest
rest deleted
deleted ...
...
The show queue command will display the output queue contents.

WRED caveats and restrictions
• Since the same policy is applied to all flows,

a single non-adaptive flow can monopolize
the buffer resources at an interface
– RED is suitable when TCP represents at least 80%
of the traffic
– Non-TCP traffic should be rate-limited
• Non-distributed RED implementation is
mutually exclusive with PQ, CQ and WFQ
WRED is very effective in achieving congestion avoidance, but only when at least
80% of traffic is based on the TCP protocol, which can quickly react to selective
random drops in some of the sessions. If non-adaptive flows, using for example the
UDP protocols, arrive at the interface, those flows do not react to WRED
dropping, but can instead monopolize the interface (and its buffers). Such traffic
should be rate-limited to enforce a steady traffic mix.
Also, WRED cannot be used together with fancy queuing with centralized
switching. dWRED and dWFQ can coexist, however, on most distributed
applications, sometimes even implemented in interface (line card) hardware.

Summary
n WRED uses precedence or DSCP-dependent dropping slopes to differentiate

RED dropping for different classes of traffic.
n WRED is configured on router interfaces and can run distributed on VIP-
based interfaces.
Lesson Review
1. What are the key differences between RED and WRED?
2. What can be used as weight in WRED?
3. Which dropping modes does WRED have?

Flow-based Weighted Random Early Detection
Overview
The section describes the Flow-based WRED mechanism available in Cisco IOS.
Objectives
n Describe the Flow-based WRED mechanism.
n Describe the benefits of Flow-based RED over normal WRED.
n Configure Flow-based WRED on Cisco routers.
n Monitor and troubleshoot Flow-based WRED on Cisco routers.

Flow-based WRED
• WRED differentiates between packets of

different priority
• WRED does not differentiate between
packets of different flows
• Aggressive flows can monopolize the queue
and cause other flows to starve
• Flow-based WRED is used to keep track of
flows
• Flow-based WRED drops packets of
aggressive flows ahead of other packets
WRED relies on a measurement called the average queue length to determine

when to drop packets. When the packet count of the average queue length is in the
upper range, WRED begins dropping packets. At this point, WRED applies a non-
zero drop probability to all packets that arrive on an interface, indiscriminate of the
kinds of flows to which the packets belong. Therefore, normal WRED applies the
same loss rate to all kinds of flows, adaptive and non-adaptive.
Flow-based Weighted Random Early Detection (FRED) is a feature of WRED
that forces WRED to afford greater fairness to all flows on an interface with
regard to how packets are dropped.
Flow-based WRED relies on these two main approaches to remedy the problem of
unfair packet drop:
n It classifies incoming traffic into flows based on parameters such as destination
and source addresses and ports.
n It maintains state information about active flows, which are flows that have
packets in the output queues.
Flow-based WRED uses this classification and state information to ensure that
each flow does not consume more than its permitted share of the output buffer
resources. Flow-based WRED determines which flows monopolize resources, and
more heavily penalizes these flows.
Here is how flow-based WRED ensures fairness among flows: it maintains a count
of the number of active flows that exist through an output interface. Given the
number of active flows and the output queue size, flow-based WRED determines
the number of buffers available per flow. To allow for some burstiness, flow-based
WRED scales the number of buffers available per flow by a configured factor and

allows each active flow to have a certain number of packets in the output queue.
This scaling factor is common to all flows. The outcome of the scaled number of
buffers becomes the per-flow limit. When a flow exceeds the per-flow limit, the
probability that a packet from that flow will be dropped increases.

Types of Flows
• There are three types of flows

–Robust flows - adapt to packet loss by
slowing down (WRED is effective);
consistent buffer usage
–Fragile flows - cannot adapt to drops
(WRED should not be used); low buffer
usage
–Non-adaptive flows - do not adapt to
packet loss (WRED is not effective); high
and constant buffer usage
Before you consider the advantages that flow-based WRED offers, it helps to
think about how WRED (without flow-based WRED configured) affects different
kinds of packet flows. Even before flow-based WRED classifies packet flows,
flows can be thought of as belonging to one of these categories:
n Nonadaptive flows, which are flows that do not respond to congestion.
n Robust flows, which on average have a uniform data rate and slow down in
response to congestion.
n Fragile flows, which, though congestion-aware, have fewer packets buffered
at a gateway than do robust flows.
Because of its packet-drop behavior − that is, that all flows, even those with
relatively fewer packets in the output queue, are susceptible to packet drop during
periods of congestion − WRED tends toward a bias against fragile flows. Though
fragile flows have fewer buffered packets, they are dropped at the same rate as
packets of other flows.

Flow-based WRED Objective
• Per-active-flow loss rate that increases with

the flow’s buffer usage
–Robust: normal loss rate
–Fragile: very light loss rate
–Non-adaptive: very high loss rate
As FRED takes a flow’s buffer usage in consideration, it bases its dropping

strategy on the amount of buffers used by active flows. The router therefore
classifies flows based on their amount of buffer usage, and is able to penalize
aggressive flows. All flows are characterized as robust flows, which can adapt to a
normal loss rate; fragile flows, which need a very light loss rate; and non-adaptive
flows, which can survive a very high loss rate. Therefore, FRED tries to identify
non-adaptive flows and impose a higher drop rate onto them, compared to other,
better-behaved flows.

Flow-based WRED
Building Blocks
Calculate Average
WFQ Per-flow Queue Size
Classifier
(hash) Scaling
Factor
Calculate Maximum Current Number of

IP src&dst addr, PID Per-flow Queue Size Queue + Active
TCP/UDP src&dst port Size Flows
Queue No
Full?
IP precedence
Yes
or
DSCP
Select
WRED
Min. threshold
Max. Threshold
Max prob. Denom.
This block diagram shows how FRED performs its dropping calculations based on
the flow classification and queue sizes. An incoming packet is first classified into
an active flow. A default WRED profile is chosen for the packet based on the
precedence/DSCP value. FRED then determines the characteristics of the flow,
by calculating the average per-flow buffer usage (average per-flow queue size) in
the system, and based on it, the maximum per-flow queue size, using a scaling
factor.
By default, FRED computes the maximum per-flow queue size directly from the
average queue per-flow queue size (the average size of queue used by flows in the
router, calculated as the number of used buffers divided by the number of active
flows), using a multiplicative factor of 4. If a flow uses more buffers than the
maximum per-flow queue size, Cisco IOS deems the flow non-adaptive, and
chooses a more aggressive RED profile for that flow, lowering the maximum
threshold by half the difference between the current maximum and minimum
threshold difference.
In short, a flow is considered non-adaptive when its flow-depth is larger than the
expected maximum due to burstiness, which depends on the scaling factor:
average-flow-depth * (scaling factor) < flow-depth

Configuring Flow-based WRED
Router(config-if)#
random-detect
random-detect flow
flow IOS
IOS 12.0(3)T
• Configures Flow-based Weighted Random Early

Detection on the specified interface
• Disables distributed WRED on VIP-based interfaces
• Disables all queuing and reverts to FIFO queuing
To enable flow-based WRED, use the random-detect flow interface configuration

command.
You must use this command to enable flow-based WRED before you can use the
random-detect flow average-depth-factor and random-detect flow count
commands to further configure the parameters of flow-based WRED.

Tuning Flow-based WRED
Router(config-if)#
random-detect flow average-depth-factor scaling-factor
scaling-factor
• Specifies the scaling factor used to compute

maximum per-flow queue size from average per-
flow queue size
• Default value is 4
Router(config-if)#
random-detect flow
flow count
count number
• Specifies the maximum number of flows tracked by

the flow-based WRED
• Default value is 256
Two FRED tuning parameters, the random-detect flow average-depth-factor,

and the random-detect flow count, are available to change the default behavior of
FRED. The first parameter changes the multiplicative scaling factor used in
calculating the maximum per-flow queue size, used to differentiate non-adaptive
flows from adaptive and fragile flows. If there is a large number of low-bandwidth
flows over an interface (resulting in a very low average per-flow queue size), the
scaling factor could be increased to detect truly aggressive flows.
The second parameter specifies the maximum amount of flows, tracked by FRED
at any given instant (snapshot of the queue). This parameter may be increased to
support an interface, carrying a large number of concurrent flows.

Monitoring Flow-based WRED
• All standard WRED commands

– show interface
– show queueing
– show queue
– show interface random-detect
• Displays flow parameters
– show queueing random-detect
To monitor FRED, use the standard (W)RED monitoring commands.

Displays Flow Parameters
Router#
CPE_1# show queueing

CPE_1#show queueing random-detect
random -detect
Current
Current random-detect
random -detect configuration:
configuration:
Serial0
Serial0
Queueing
Queueing strategy: random
strategy: random early
early detection
detection (WRED)
(WRED)
Exp-weight-constant:
Exp-weight -constant: 99 (1/512)
(1/512)
Mean
Mean queue
queue depth:
depth: 00
Max
Max flow
flow count:
count: 256
256 Average
Average depth
depth factor:
factor: 44
Flows
Flows (active/max
(active/max active/max):
active/max): 0/0/256
0/0/256
Class
Class Random
Random Tail
Tail Minimum
Minimum Maximum
Maximum Mark
Mark
drop
drop drop
drop threshold
threshold threshold
probability
00 00 00 20
20 40
40 1/10
1/10
11 00 00 22
22 40
40 1/10
1/10
22 00 00 24
24 40
40 1/10
1/10
33 00 00 26
26 40
40 1/10
1/10
44 00 00 28
28 40
40 1/10
1/10
55 00 00 31
31 40
40 1/10
1/10
66 00 00 33
33 40
40 1/10
1/10
77 00 00 35
35 40
40 1/10
1/10
rsvp
rsvp 00 00 37
37 40
40 1/10
1/10
The show queuing command shows the configuration and statistics for configured
WRED profiles, together with FRED parameters, such as the number of active
flows in the queue, and the depth scaling factor.

Benefits of Flow-based WRED
• Ensures that flows that respond to WRED

packet drops by backing off packet
transmission are protected from flows that
do not respond to WRED packet drops
• Prohibits a single flow from monopolizing the
buffer resources at an interface
– Flow-based WRED punishes aggressive UDP
flows
FRED therefore has substantial benefits compared to WRED, as it can also be

used in environments that do not exhibit a predominantly TCP-based traffic mix.
FRED enables differentiated dropping between fragile and non-adaptive flows, in
which the loss rate is higher with non-adaptive flows. This is something that
WRED is unable to do, because it drops packets without regard to flow buffer
usage. Therefore, FRED protects fragile and adaptive flows from non-adaptive
flows, which may, in the case of RED, monopolize router queues in their path.

Drawbacks of Flow-based WRED
• Flow-based WRED is not distributed

• Works only in combination with FIFO
queuing
• Not predictable
• Depends on host behavior for effectiveness
Since FRED does not yet run in a distributed mode, and only works in combination
with FIFO queuing, its applications are limited. FRED is also not predictable in its
operation, and somewhat depends on the behavior of endpoints, which must
properly adapt their sending rate based on loss signals from the network.

Summary
n Flow-based WRED differentiates flows and keeps state information about
current flows in the output queue.
n Flow-based WRED can penalize non-adaptive flows by dropping their packets
more aggressively.
n Flow-based WRED is configured on router interfaces
Lesson Review
1. What is the difference between WRED and Flow-based WRED?
2. How many queues does Flow-based WRED have?
3. What are the benefits and drawbacks of Flow-based WRED?

Summary
n RED randomly drops packets before an interface is congested, punishing
aggressive flows.
n WRED uses precedence or DSCP-dependent dropping slopes to differentiate
RED dropping for different classes of traffic.
n WRED is configured on router interfaces and can run distributed on VIP-
based interfaces.
n Flow-based WRED differentiates flows and keeps state information about
current flows in the output queue.


Question: What are the main drawbacks of using tail-drop as a means of
congestion control?
Answer: Tail drop causes global synchronization of TCP session, TCP
starvations, and jitter.
Question: What does RED do to prevent TCP synchronization?
Answer: RED performs random dropping of packets, as the average queue
length indicates a possible trend towards congestion. As aggressive flows usually
have more packets in the queue compared to non-aggressive flows, random
dropping punishes aggressive flows with higher probability by dropping their
packets. Packet drops signal the aggressive TCP sender to slow down and
adapt its sending rate.
Question: What are the three modes of RED?
Answer: RED has three queue management modes: no drop, when the average
queue length is below the minimum threshold, random drop, when the average
queue length is between the minimum and maximum thresholds and full drop,
when the average queue length is above the maximum threshold.
Weighted Random Early Detection

Question: What are the key differences between RED and WRED?
Answer: WRED can perform differentiated dropping, taking IP precedence or
DSCP value into account. RED drops are based only on the average queue
length and all packets share the same drop profile.
Question: What can be used as weight in WRED?
Answer: IP precedence or DSCP value can be used as the weight in WRED.
Question: Which dropping modes does WRED have?
Answer: As is the case with RED, WRED has three queue management modes:
no drop, when the average queue length is below the minimum threshold, random
drop, when the average queue length is between the minimum and maximum
thresholds and full drop, when the average queue length is above the maximum
threshold.
With WRED different threshold values are used for each weight (IP precedence
or DSCP) value, establishing differentiated dropping profiles.
Flow-based Weighted Random Early Detection

Question: What is the difference between WRED and Flow-based WRED?
Answer: Flow-based WRED is able to differentiate between different flows
based on their buffer usage. Therefore, it is more precise than WRED when
differentiating between different senders, and can more appropriately punish
aggressive sessions.
Question: How many queues does Flow-based WRED have?
Answer: By default, Flow-based WRED maintains 256 flow queues.
Question: What are the benefits and drawbacks of Flow-based WRED?
Answer: Flow-based WRED has the potential to punish aggressive UDP
sessions by freeing the queue resources early. It can not, however, lower their
sending rate. Also, Flow-based WRED currently does not run distributed on the
VIP.

6
Link Efficiency
Mechanisms
Overview
The module describes one approach to handling congested links; compression. It
discusses link efficiency mechanisms that either compress the payload of packets
(Stacker and Predictor) or reduce packet overhead by compressing their headers
(TCP and RTP header compression). It also discusses two different layer-2 link
fragmentation mechanisms (PPP Multilink and Frame Relay Fragmentation).
Objectives
n Describe and configure Stacker payload compression
n Describe and configure Predictor payload compression
n Describe and configure TCP header compression
n Describe and configure RTP header compression
n Describe and configure PPP Multilink with interleaving
n Describe and configure Frame Relay Fragmentation
Payload Compression
Overview
This lesson describes two payload compression mechanisms. It describes the
Stacker and Predictor mechanisms that can be used to reduce the size of data in
packets or frames.
Objectives
n Describe and configure Stacker compression
n Describe and configure Predictor compression
n Monitor and troubleshoot compression
6-2 IP QoS Link Efficiency Mechanisms Copyright  2001, Cisco Systems, Inc.
Payload Compression
QoS does not create bandwidth. Payload

compression does.
Payload compression uses a
compression algorithm to squeeze the
payload of layer-2 frames
Payload compression increases
perceived throughput and decreases
perceived latency
© 2001, Cisco Systems, Inc. IP QoS Link Efficiency Mechanisms -5
While many mechanisms exist for optimizing throughput and reducing delay in
network traffic within the QoS portfolio, QoS does not create bandwidth. QoS
optimizes the use of existing resources, and enables the differentiation of traffic
according to the operator policy.
Payload compression does create additional bandwidth, because it squeezes packet
payloads, and therefore increases the amount of data that can be sent through a
transmission resource in a given time period. Payload compression is mostly
performed on layer-2 frames and therefore compresses the entire layer-3 packet.
Note that IP PCP (Payload Compression Protocol) is a fairly new technique for
compressing payloads on layer 3, and can handle out-of-order data. The IP PCP
compression method is not discusses in this lesson.
As compression squeezes payloads, it both increases the perceived throughput, and
decreases perceived latency in transmission, because smaller, packets (with
compressed payloads) take less time to transmit (than the larger, uncompressed
packets).
Copyright  2001, Cisco Systems, Inc. IP QoS Link Efficiency Mechanisms 6-3
Compression Building Blocks
Compression Output
Forwarder Algorithm Queue
FH IP FH cIP
Compression is a
CPU-intensive task Packets reduced in
It adds to the size take less time
overall delay to transmit.
experienced by IP More packets can
packets. be transmitted.
Compression reduces the size of the frame payload

Entire IP packet is compressed
Compression adds delay due to its complexity
Serialization delay is reduced, overall latency might be
reduced
The figure shows a basic block diagram of a compression method. When a router
forwards a packet, it is subjected to the layer-2 compression method after it has
been encapsulated at the output. The compression method squeezes the payload of
the layer-2 frame (the entire layer-3 packet), and transmits the packet on the
interface. Layer-2 compression requires serialization of packet delivery, which
means that packets must be received by the remote layer-2 station in the same
order as they were sent.
Compression is a CPU-intensive task and can add per-packet delay due to the
application of the compression method to each frame. The transmission
(serialization) delay, however, is reduced, because the resulting frame is smaller.
Depending on the complexity of the payload compression algorithm, overall latency
might be reduced, especially on low-speed links.
Compression Results
NO COMPRESSION Link bandwidth

Throughput
256 kbps
256 kbps
Delay=1 ms Delay=8 ms Total Delay=9 ms
COMPRESSION
COMPRESSION Link bandwidth
256 kbps Throughput
500 kbps
HARDWARE
HARDWARE COMPRESSION
COMPRESSION Link bandwidth
256 kbps Throughput
500 kbps
Compression increases throughput

Compressions may increase delay
The figure compares three throughput/latency scenarios on a point-to-point link. If

no compression is used, the perceived throughput is limited by the link bandwidth,
and the average delay is influenced only by the forwarding/buffering delay and the
serialization (transmission) delay.
If compression is enabled, the packet latency between the two hops is a function of
forwarding delay, compression delay, and transmission delay. Even if the
transmission delay is now shorter, the compression/decompression delay may
increase the overall latency between the two hops. Throughput is generally
increased and is limited by the effectiveness of the compression algorithm.
If hardware-assisted compression is used, the compression/decompression delays
may become insignificant compared to transmission and forwarding delays, and
overall latency may decrease. Throughput is again limited by the effectiveness of
the compression method and may be significantly higher than the link bandwidth
limit.
Compression Algorithms
Cisco routers support the following

compression algorithms:
• STAC or Stacker (STAC Electronics or Hi/fn,
Inc.)
• MPPC (Microsoft Point-to-point
Compression)
• Predictor (public domain algorithm)
These algorithms differ in compression
capabilities, CPU and memory utilization
Cisco IOS supports three different compression algorithms used in layer-2

compression: STAC (or Stacker), Microsoft Point-to-Point Compression (MPPC),
and predictor. These algorithms differ vastly in their compression efficiency, and in
utilization of router resources.
Stacker and MPPC Compression
Stacker or STAC is a compression algorithm

developed by STAC Electronics
Stacker uses the LZ (Lempel-Ziv) algorithm that
searches for redundant strings and replaces
them with short tokens
It builds a dictionary where token values are
mapped to these strings
MPPC is developed by Microsoft and also uses
the LZ algorithm
The STAC (or Stacker) algorithm is based on the well-known LZ (Lempel-Ziv)

compression algorithm. The LZ (sometimes also called LZW) algorithm searches
the byte stream for redundant strings, and replaces them with shorter dictionary
tokens. The dictionary is built in real time, and there is no need to exchange the
dictionary between the compression peers, because the dictionary is reconstructed
from the data received by the remote peer. The MPPC method also uses the same
LZ algorithm. The STAC and MPPC algorithms yield very good compression
results, but are CPU-intensive.
Predictor Compression
Predictor is a public domain

compression algorithm
Predictor uses a hashed sequence of
characters as an index into the
compression dictionary
The entry in the dictionary is compared
to the next sequence of characters
© 2001, Cisco Systems, Inc. IP QoS Link Efficiency Mechanisms-10
The predictor is a simple, very fast, and CPU-friendly algorithm, but this algorithm
yields a lower compression ratio. It is based on predicting the next byte-sequence
in the stream based on a simple dictionary, which is rebuilt from the source or the
compressed data without the need to exchange a dictionary between the peers.
Stacker/MPPC vs. Predictor
Stacker and MPPC are very CPU-intensive

• Good average compression ratio
• Slower
• Produces more delay
• Should be used on slower links
• Stacker has more tuning capabilities
Predictor requires more memory
• Less efficient than Stacker or MPPC
• Faster, uses less CPU time
• Produces less delay
• Can be used on faster links
The STAC, MPPC, and predictor algorithms are usually used to perform layer-2
payload compression on point-to-point links between Cisco IOS routers. The
STAC and MPPC methods are CPU-intensive. However these methods yield very
good compression rates on the average, produce more compression/decompression
delay in the router, and should be used on slower links if software compression is
used.
Predictor is a leaner and simpler algorithm, which can be deployed on faster links
with software compression, and which introduces less delay in the packet path.
However, predictor yields considerably lower compression ratios compared to the
STAC algorithm.
Compression and Layer-2
Encapsulation
STAC Predictor MPPC
PPP ü* ü ü
Frame Relay ü* O O
HDLC ü O O
LAPB ü ü O
X.25 ü O O
* PPP and Frame Relay Stacker is also supported by

hardware compression modules
The figure shows a comparison of different compression methods used by Cisco

IOS to perform layer-2 payload compression. The STAC method is the most
versatile, because it runs on any supported point-to-point layer-2 encapsulation.
Predictor only supports PPP and LAPB, while MPPC only runs within PPP.
Hardware-accelerated compression substantially increases compression throughput
for CPU-intensive compression methods (such as STAC and MPPC, both based
on the LZ algorithm) and is recommended when used on high-bandwidth links.
Performance
Compression performance depends on

the following factors:
• Router platform (CPU power)
• Compression algorithm (Stacker, MPPC or
Predictor)
• Hardware compression support
Real-life compression performance depends on many factors, the most important

being:
n Router CPU performance, if compression is performed in software. The router
runs the compression algorithm for each packet on an interface, configured for
compression.
n The compression algorithm because there are large differences in the
performance of the algorithm itself. Generally, CPU-intensive algorithms
produce better compression ratios.
n Hardware compression support offloads the task of compression from the
CPU, which decreases forwarding latency and frees the CPU to perform
other tasks.
n Data compressibility, which influences both the compression ratio and
sometimes the performance of the algorithm itself.
On average, Stacker and MPPC can yield up to 50% reduction in data size (a
compression ratio of 2), when used on real network traffic. Predictor can
theoretically achieve such a rate, if network traffic includes mostly predictive text
data. In most networks, predictor compression ratio is much lower than Stacker’s,
and usually in the 30-40% range of data size reduction (that is, compression ratios
less than 1.8).
Configuring Stacker
Interface configuration steps:

• Select one of the supported layer-2
encapsulations (PPP, F/R, HDLC, LAPB or
X.25)
• Enable Stacker compression
• Optionally select the ratio, force software
based compression or enable distributed
compression
Monitor compression
Stacker (STAC) compression is configured on interfaces with the appropriate

supported encapsulation. The STAC method can be tuned, and software or
hardware compression can be selected. After STAC has been enabled on an
interface, Cisco IOS provides a means to monitor the compression ratios in real
time.
Configuring Stacker with PPP
Encapsulation
Router(config-if)#
compress stac
stac
• Enables STAC with default parameters

Router(config-if)#
compress stac
stac distributed
distributed
• Offloads compression to a VIP

• Supported on VIP2-40 or newer
Router(config-if)#
compress stac
stac ratio
ratio {high
{high || low
low || medium}
medium}
• Balance throughput with delay

• Low compression ratio is the default
The compress stac command enables STAC compression on an interface with

supported encapsulation.
STAC can also run distributed on the VIP processor.
The compress stac ratio command tunes STAC so that the compression ratio is
traded for delay. For example, selecting a low compression ratio produces less
CPU usage, while the high compression ratio performs better compression, but
increases the CPU load and adds delay, which may decrease throughput. The
recommended ratio depends on the type of network traffic and its sensitivity to
delay. The rule of thumb is to start with the default low ratio, and try to increase
the ratio and measure throughput. If observed compression ratios increase (as
shown by the show compression command), but throughput actually decreases,
the configured ratio should be lowered again.
Configuring Stacker with Frame
Relay Encapsulation
Router(config-if)#
frame-relay payload-compression
payload-compression FRF9
FRF9 stac
stac
• Enables STAC with default parameters

Router(config-if)#
FRF9 stac
stac distributed
distributed
• Offloads compression to a VIP

• Supported on VIP2-40 or newer
Router(config-if)#
FRF9 stac
stac ratio
ratio {high
{high || low}
low}
• Balance throughput with delay

• Low compression ratio is the default
Cisco IOS supports the native Frame Relay compression protocol according to the
FRF.9 standard. The compression method used is equivalent to STAC
compression. Also, the commands required to configure Frame Relay STAC
compression are analogous to the command used to configure STAC with other
supported encapsulations. This command should be used when using the default
Frame Relay encapsulation over Frame Relay networks.
Configuring Predictor or MPPC
Router(config-if)#
compress predictor
predictor
• Enables Predictor compression
Router(config-if)#
compress mppc
mppc [ignore-pfc]
[ignore-pfc]
• Enables MPPC compression

• Use the ignore-pfc option to ignore the protocol
number negotiation
The compress predictor command configures predictor compression. No tuning

parameters are available for this command.
The compress mppc command configures MPPC compression, and is used
mainly with Windows clients and when running a layer-2 tunneling session (for
example, the Point-to-Point Tunneling Protocol (PPTP). The ignore -pfc keyword
instructs the router to ignore the protocol field compression flag negotiated by
LCP. For example, the uncompressed standard protocol field value for IP is
0x0021 and 0x21 when compression is enabled. When the ignore -pfc option is
enabled, the router will continue to use the uncompressed value (0x0021). Using
the ignore -pfc option is helpful for some asynchronous driver devices that use an
uncompressed protocol field (0x0021), even though the pfc is negotiated between
peers. If protocol rejects are displayed when the debug ppp negotiation command
is enabled, setting the ignore -pfc option may remedy the problem.
Hardware Compression
Hardware compression is available using

the following modules:
• Compression Advanced Interface Module (CAIM)
is a daughter-board module for Cisco 2600 series
routers
• Compression Service Adapter (CSA) module for
Cisco 7x00 series routers
• Compression Network Module (NM-COMPR2) for
Cisco 3620 and Cisco 3640 series routers
• AIM-COMPR4 is a daughter-board compression
module for Cisco 3660 series routers
There are a number of hardware compression modules and daughter boards

available for use in Cisco routers.
n The Compression Advanced Interface Module (CAIM) is a daughter board
that is placed in the AIM motherboard slot on Cisco 2600-series routers. It
does not occupy any network interface slots, and accelerates the STAC and
MPPC compression methods.
n The Compression Service Adapter (CSA) is a port adapter for the Cisco 7x00
series routers. The CSA offloads the compression task from the main CPU or
the VIP2 (using distributed compression). When used in the Cisco 7200-series
router, the CSA can offload compression at any interface. If used on the
VIP2, it offloads compression at the adjacent port adapter on the same VIP
only.
n The Compression Network Module is a network module for the Cisco 3600-
series routers. The Compression Network Module occupies a network module
slot in the router, and can offload compression at any router interface.
n The AIM-COMPR4 is a hardware-compression daughter board used in the
Cisco 3660 router. The AIM-COMPR4 integrates with the router motherboard
and does not occupy any network module slots in the chassis.
interface
interface Serial1/0
Serial1/0 Software compression using the
encapsulation
encapsulation ppp
ppp STAC algorithm
compress
compress stac
!! Hardware compression using the
interface
interface Serial1/1
Serial1/1 STAC algorithm on the CAIM
encapsulation
encapsulation ppp
ppp module (Cisco 2600 routers)
compress
compress stac
stac caim
caim 00
!! Software compression using the
interface
interface Serial1/2
Serial1/2 Predictor algorithm
encapsulation
encapsulation ppp
ppp
compress
compress predictor
predictor
!!
interface
interface Serial1/2
Serial1/2
encapsulation
encapsulation frame -relay
frame-relay
frame-relay
frame-relay map
map ip
ip 1.1.1.1
1.1.1.1 102
102 broadcast
broadcast ietf
ietf payload-compress
payload-compress frf9 stac
stac
!!
interface
interface Serial1/2.1
Serial1/2.1 point-to-point
point-to-point Software compression using
frame-relay
interface-dlci 101 ietf the STAC algorithm
frame-relay
frame-relay payload-comp
payload-comp FRF9
FRF9 stac
stac
!!
The figure shows configuration examples that specify different compression

configurations.
In the example, the Serial1/0 interface uses software compression (this setting may
automatically use hardware compression on high-end series).
The Serial1/1 interface performs compression with the assistance of the CAIM (in
a Cisco 2600-series router).
Interfaces Serial1/2 and its Serial 1/2.1 sub-interface both use software STAC
compression on the frame-relay level.
Monitoring Compression
Router#
show compression
compression
• Displays compression statistics

Router#show
Router#show compression
compression
Serial5/1/0
Serial5/1/0
Software
Software compression
compression enabled
enabled
uncompressed
uncompressed bytes
bytes xmt/rcv
xmt/rcv 21339/21339
21339/21339
compressed
compressed bytes
bytes xmt/rcv
xmt/rcv 0/0
0/0
11 min
min avg ratio xmt/rcv 2.110/2.110
55 min
min avg
avg ratio
ratio xmt/rcv
xmt/rcv 2.143/2.143
2.143/2.143
10
10 min
min avg
avg ratio
ratio xmt/rcv
xmt/rcv 2.143/2.143
2.143/2.143
no
no bufs
bufs xmt 0 no bufs rcv 0
resyncs
resyncs 00
Additional
Additional Stacker
Stacker Stats:
Stats:
Transmit
Transmit bytes:
bytes: Uncompressed
Uncompressed == 00 Compressed
Compressed == 9109
9109
Received
Received bytes:
bytes: Compressed
Compressed == 9953
9953 Uncompressed
Uncompressed == 00
The show compression command displays per-interface compression statistics.

The ratio shown in the output indicates the compression ratio (the ratio of
uncompressed over the actual compressed byte stream size) on the input and the
output of an interface.
Summary
n Stacker and MPPC payload compression methods yield better compression
ratios, is more CPU-intensive, and may introduce additional delay
n The predictor payload compression method is faster, can be used in higher-
bandwidth scenarios, but generally yields lower average compression ratios
Lesson Review
1. What is the purpose of using payload compression?
2. List the payload compression algorithms than can be used.
3. What are some of the benefits and drawbacks of Stacker?
4. What are some of the benefits and drawbacks of Predictor?
Header Compression
Overview
This lesson describes the mechanisms that are used to reduce overhead on slow
links by compressing IP and TCP headers in TCP header compression, or IP,
UDP and RTP headers in RTP header compression.
Objectives
n Describe and configure TCP header compression
n Monitor and troubleshoot TCP header compression
n Describe and configure RTP header compression
n Monitor and troubleshoot RTP header compression
Header Compression
Header compression reduces the overhead by

compressing packet and segment headers
TCP Header compression compresses the IP
and TCP headers
RTP header compression compresses the IP,
UDP and RTP headers
Header compression is especially effective on
slow links with interactive traffic or delay
sensitive traffic (many short packets)
All compression methods are based on eliminating redundancy when sending the
same or similar data over a transmission medium. One piece of data, which is often
repeated, is the protocol header. In a flow, the header information of packets in the
same flow does not change much over the lifetime of that flow. Therefore, most of
header information could be sent only at the beginning of the session, stored in a
dictionary, and then referenced in later packets by a short dictionary index.
Two methods were standardized by the IETF (Internet Engineering Task Force)
for use with IP protocols:
n TCP header compression (also known as the Van Jacobson or VJ header
compression) is used to compress the packet TCP headers over slow links,
thus considerably improving the interactive application performance.
n RTP header compression is used to compress UDP and RTP headers, thus
lowering the delay for transporting real-time data, such as voice and video over
slower links.
Header Compression Basics
Compression is performed by eliminating

static or predicable header information
Session indices are used instead
Only changing parameters in headers are
still sent
Header compression is enabled on a link-
by-link basis
Header compression methods work by not transmitting repeated information in

packet headers throughout a session. For a TCP session, such parameters are the
IP header and the TCP port numbers. The two peers on a point-to-point layer-2
connection (such as a dial-up link) agree on session indices, which index a
dictionary of packet headers. The dictionary is built at the start of every session,
and is used for all subsequent (non-initial) packets. Only changing (non-constant)
parameters in the headers are actually sent with the session index.
It is important to note that header compression is performed on a link-by-link basis.
Header compression cannot be performed across multiple routers, because routers
need full Layer-3 header information to be able to route packets to the next hop.
Header Compression
Building Blocks
Header
Output
Forwarder Compression
Queue
Algorithm
FH IP L4 (L5) payload FH cH payload
The header
compression IP and higher-layer
algorithm keeps headers are
track of flows and compressed
static parameters
in headers
Compression reduces the size of packet

headers
The payload is not changed
The figure shows a block diagram of a header compression method. The header
compression algorithm tracks active transport-layer connections over an interface.
After the packet has been forwarded, the header compression algorithm
compresses the layer-3 and layer-4 headers within the frame, and replaces them
with a session index from the session dictionary (table). The packet is then sent to
the output queue, and transmitted to the remote peer. When the remote peer
receives the packet, the header is decompressed using the local session table, and
passed to the forwarding process.
Header Compression Results
NO COMPRESSION Throughput
Link bandwidth 64 kbps
64 kbps
Delay=8 ms
Delay=1 ms
COMPRESSION
COMPRESSION Throughput
Link bandwidth
100 kbps
64 kbps
Delay=4 ms
Delay=2 ms
Header compression increases throughput

Header compressions reduces delay
By compressing the header, the layer-2 frame gets smaller and therefore more
data is sent through a channel in a given time period. Also, the packet transmission
time is smaller; therefore header compression both increases the throughput and
reduces the overall delay of a transmission line.
Header Compression Algorithms
TCP Header Compression (RFC 1144)

• Used to reduce the overhead of TCP
segments
• Most effective on slow links with a lot of
TCP sessions with small payloads (for
example, Telnet)
RTP Header Compression (RFC 1889)
• Used to reduce delay and increase
throughput for Real Time Protocol (RTP)
• Improves voice quality
• Most effective on slow links
The two header compression methods available in Cisco IOS are the TCP header
compression (standardized by RFC 1144), and the RTP header compression
(standardized by RFC 1889). TCP header compression is usually used to improve
the interactive session response over low-speed links, where layer-3 and layer-4
headers represent a significant portion of the layer-2 frame. RTP header
compression is used mostly on slow links, to reduce delay and increase throughput
of an RTP-based application (usually voice traffic).
Most Internet Applications use TCP as

the transport protocol
Most of the information in the headers (IP
and TCP) is static or predictable
throughout the session
IP (20 bytes) and TCP (20 bytes) use 40
bytes
TCP Header Compression can squeeze
these two headers into 3 to 5 bytes
With TCP header compression, the IP and TCP headers, which normally use 20
bytes each, is reduced to a session index, and the changing part of the header.
With all optimizations, the combined header length of 40 bytes can be reduced to a
3 to 5-byte compressed header.
Case Study
Link bandwidth is 64 kbps

The link is used for a number of
interactive TCP sessions
PPP encapsulation is used
Average packet size is 5 bytes
Each segment has 46 bytes of overhead
(PPP, IP and TCP headers)
This case study illustrates the benefits of TCP header compression on slow links.
A 64 kbps link is used to transport a TCP-based application using PPP as the
layer-2 framing protocol. For the case study application (telnet), the average
packet payload size is 5 bytes. Since PPP has 6 bytes of frame header, the total
header overhead is 6+20+20=46 bytes, counting the PPP, IP, and TCP headers.
Case Study
6 20 20 5 6 4 5
PPP IP TCP Telnet PPP cT Telnet
46 5 10 5
Overhead = 46/(46+5) Overhead = 10/(10+5)
Overhead = 90% Overhead = 67%
Delay = (46+5) / 64 kbps Delay = (10+5) / 64kbps
Delay = 6 ms Delay = 2 ms
IP packet Overhead Delay on Overhead Delay on

size No comp. 64 kbps Comp. 64 kbps
10 82% 7 ms 50% 2 ms
50 48% 12 ms 17% 7 ms
100 32% 18 ms 9% 13 ms
500 8% 67 ms 2% 62 ms
1500 3% 189 ms 1% 184 ms
The figure shows the packet size before and after header compression. The IP and
TCP headers are reduced to 4 bytes, resulting in 10 bytes of overall headers. The
overhead is reduced from 90% to 67%, when small packets are used. Because of
size reduction, the transmission delay decreases from 6 ms to 2 ms on the same
link.
The table in the figure shows how header compression impacts performance when
different packet sizes are used. Header compression is most effective on small
packets, used on slow links.
Configuring TCP Header
Compression
Router(config-if)#
ip tcp header-compression [passive]
• Enables TCP Header Compression on an interface

using PPP or HDLC encapsulation
• Use the passive option to enable TCP Header
Compression only if initiated by the peer
Router(config-if)#
frame-relay ip tcp header-compression [passive]
• Enables TCP Header Compression on an interface

using Frame Relay encapsulation
• Use the passive option to enable TCP Header
TCP header compression is configured with the ip tcp header-compression

command. The passive option instructs the peer to use header compression only if
the remote peer initiates header compression. This is often used in a dialup
environment, where this option is enabled on the access server.
On frame relay, the frame-relay ip tcp header-compression configures header
compression with interfaces using pure frame relay encapsulation.
In Cisco IOS, TCP header compression is now fast and CEF-switched. Up to 256
connections, which is also the default value, can be compressed over a point-to-
point link.
Example
interface Serial0/0
interface Dialer1
ip address 10.2.1.2 255.255.255.252
ip address negotiated
encapsulation frame-relay
ip tcp header-compression
frame-relay ip tcp header -compress
!
!
Frame Relay POTS / ISDN
RouterA RouterC
RouterB
interface Serial0
ip address 10.2.1.1 255.255.255.252
frame-relay ip tcp header -compression
!
interface Virtual-template1
ip address 10.1.1.1 255.255.0.0
ip tcp header-compression passive
!
The figure shows an example configuration of three peers using TCP header
compression.
RouterC uses header compression on a dialer interface, connecting to the central
access server (RouterB).
The access server (RouterB) is configured to perform header compression only if
the remote peer (RouterC) initiates it, and therefore supports peers using header-
compression, and peers using plain layer-2 transmission.
The access server (RouterB) connects to a remote site (RouterA) over frame-
relay. Both frame-relay endpoints (RouterA and RouterB) are configured to
perform TCP header compression over the frame-relay link.
Monitoring
Router#
show ip
ip tcp
tcp header-compression
header-compression [interface]
• Displays TCP Header Compression statistics

Router#show
Router#show ip
ip tcp
header-compression serial0/0
serial0/0
TCP/IP
TCP/IP header
header compression
compression statistics:
statistics:
Interface
Interface Serial0/0:
Serial0/0:
Rcvd:
Rcvd: 24 total, 20 compressed,
compressed, 0 errors
errors
00 dropped,
dropped, 00 buffer
buffer copies,
copies, 00 buffer
buffer failures
failures
Sent:
Sent: 24
24 total,
total, 20
20 compressed,
compressed,
679
679 bytes
bytes saved,
saved, 249
249 bytes
bytes sent
sent
3.72
3.72 efficiency
efficiency improvement
improvement factor
factor
Connect:
Connect: 255
255 rx slots, 255 tx
tx slots,
slots,
12
12 long
long searches,
searches, 44 misses
misses 00 collisions
collisions
83%
83% hit
hit ratio,
ratio, five
five minute
minute miss
miss rate
rate 00 misses/sec,
misses/sec, 00 max
The show ip tcp header-compression command displays the statistics of TCP

header compression on an interface.
Monitoring
Router#
show frame-relay ip
ip tcp
• Displays TCP Header Compression statistics on

frame-relay (sub)interfaces
Router#show
frame-relay ipip tcp
header-compression
DLCI
DLCI 100
100 Link/Destination
Link/Destination info:
info: point-to-point
point -to-point dlci
dlci
Interface
Interface Serial0/0:
Serial0/0:
Rcvd:
Rcvd: 24 total, 23 compressed,
errors
00 dropped,
dropped, 00 buffer
buffer copies,
copies, 00 buffer
buffer failures
failures
Sent:
Sent: 27
27 total,
total, 26
26 compressed,
compressed,
864
864 bytes
bytes saved,
saved, 225
225 bytes
bytes sent
sent
4.84
4.84 efficiency
improvement factor
factor
Connect: 256
Connect: 256 rx slots, 256 tx slots,
tx slots,
11 long searches,
searches, 1 misses 0 collisions
collisions
96%
96% hit
hit ratio,
ratio, five
five minute
minute miss
miss rate
rate 00 misses/sec,
misses/sec, 00 max
The show frame -relay ip tcp header-compression command displays the

statistics of TCP header compression on a Frame Relay interface.
Voice sessions use Real-time Transport

Protocol (RTP)
RTP uses UDP for transport
Most of the information in the headers (IP, UDP
and RTP) is static throughout the session
IP (20 bytes), UDP (8 bytes) and RTP (12 bytes)
use 40 bytes
RTP header compression can squeeze these
three headers into 3 to 5 bytes
Real-Time Protocol (RTP) is the Internet Standard (RFC 1889) protocol for the
transport of real-time data. It is intended to provide end-to-end network transport
functions for applications that support audio, video, or simulation data over
multicast or unicast network services. RTP is used in most Voice over IP
applications to transport packetized voice.
RTP includes a data portion and a header portion. The data portion of RTP is a
thin protocol that provides support for the real-time properties of applications, such
as continuous media, and includes timing reconstruction, loss detection, and content
identification.
RTP contains a relatively large sized header. The 12 bytes of the RTP header,
combined with 20 bytes of IP header (IPH) and 8 bytes of the User Datagram
Protocol (UDP) header, create a 40-byte IP/UDP/RTP header.
For compressed-payload audio applications, the RTP packet typically has a 20-byte
to 160-byte payload. Given the size of the IP/UDP/RTP header combinations, it is
inefficient to send the IP/UDP/RTP header without compressing it.
To avoid the unnecessary consumption of available bandwidth, the RTP header
compression feature (CRTP) is used on a link-by-link basis. CRTP can reduce the
header from 40 bytes to a 3 to 5-byte header, which significantly reduces delay on
slow links.
Case Study
Link bandwidth is 64 kbps

The link is used for Voice over IP
PPP encapsulation is used
G.729 codec is used (8 kbps of voice
data, 50 samples per second, 20 bytes
per sample)
Each segment has 46 bytes of overhead
(PPP, IP, UDP and RTP headers)
This case study illustrates the benefits of RTP header compression on slow links.
A 64 kbps link is used to transport Voice over IP using PPP as the layer-2 framing
protocol.
For the case study application (voice using the G.729 audio compression codec),
the average payload size is 20 bytes. Since PPP has 6 bytes of frame header, the
total header overhead is 6+20+20=46 bytes, counting the PPP, IP, UDP, and RTP
headers.
Case Study
6 20 8 12 20 6 4 20
PPP IP UDP RTP Voice PPP cR Voice
46 20 10 20
Overhead = 46 / (46 + 20) = 70% Overhead = 10 / (10 + 20) = 33%

Delay = (46 + 20) / 64 kbps = 8 ms Delay = (10 + 20) / 64kbps = 4 ms
BW = (46 + 20) * 50 * 8 = 26 kbps BW = (10 + 20) * 50 * 8 = 12 kbps
2 voice sessions / 64 kbps 5 voice sessions / 64 kbps
Codec Voice RTP RTP CRTP CRTP

Bandwidth Bandwidth Overhead Bandwidth Overhead
G.711 64 kbps 82 kbps 22% 68 kbps 3%
G.729 8 kbps 26 kbps 61% 12 kbps 33%
The figure shows the packet size before and after header compression. The IP,
UDP, and RTP headers are reduced to 4 bytes, resulting in 10 bytes of overall
headers. The overhead is reduced from 70% to 33%, when small packets are
used. Because of size reduction, the transmission delay decreases from 8 ms to 4
ms, and the bandwidth used to transport a single voice call (using the G.729 codec)
is reduced from 26 to 12 kbps.
The table in the figure shows how header compression impacts performance when
a different audio codec is used. For the traditional G.711 voice codec, CRTP still
optimizes its transmission over slow links. However, the difference is more obvious
when using advanced, low-bandwidth codecs are used.
Configuring RTP Header
Compression
Router(config-if)#
ip rtp header-compression [passive]
• Enables RTP Header Compression on an interface

using PPP or HDLC encapsulation
• Use the passive option to enable RTP Header
Router(config-if)#
frame-relay ip rtp header-compression [passive]
• Enables RTP Header Compression on an interface

using Frame Relay encapsulation
• Use the passive option to enable RTP Header
RTP header compression is configured with the ip rtp header-compression

command. The passive option instructs the peer to use RTP header compression
only if the remote peer initiates RTP header compression.
On frame relay, the frame-relay ip rtp header-compression configures header
compression with interfaces using pure frame relay encapsulation.
In Cisco IOS, RTP header compression is now fast and CEF-switched. If
distributed CEF (dCEF) is configured, CRTP also runs in distributed mode. Up to
256 connections, which is also the default value, can be compressed over a point-
to-point link.
Example
interface Serial0/0 interface Serial0/0

ip address 10.2.1.2 255.255.255.252 ip address 10.1.1.2 255.255.255.252
encapsulation frame-relay encapsulation ppp
frame-relay ip rtp header-compression ip rtp header-compression
! !
RouterB RouterC
Frame Relay TDM
(leased line)
RouterA
ip cef distributed
!
interface Serial5/1/0
ip address 10.2.1.1 255.255.255.252
frame-relay ip rtp header-compression
!
ip address 10.1.1.1 255.255.0.0
encapsulation ppp
ip rtp header-compression
!
The figure shows an example implementation of CRTP on a two-tiered scenario,

where two sites (using routers Router A and RouterC) are interconnected over a
TDM and Frame Relay network.
Over the TDM network, a leased line carries all (including packetized voice)
traffic. RTP header compression is used within the PPP session between RouterA
and RouterB.
Over the frame-relay network, the point-to-point Frame Relay channel between
RouterB and RouterC uses CRTP over the native Frame Relay encapsulation.
Monitoring
Router#
show ip
ip rtp
rtp header-compression
• Displays RTP Header Compression statistics

Router#show
Router#show ipip rtp
rtp header-compression
header-compression serial0/0
serial0/0
RTP/UDP/IP
RTP/UDP/IP header
header compression
compression statistics:
statistics:
Interface
Interface Serial1:
Rcvd:
Rcvd: 00 total,
total, 00 compressed,
errors
00 dropped,
dropped, 00 buffer
buffer copies, 0 buffer failures
Sent:
Sent: 430 total 429 compressed,
15122
15122 bytes
bytes saved,
saved, 139318
139318 bytes
bytes sent
sent
1.10
1.10 efficiency
improvement factor
factor
Connect:
Connect: 16 rx slots,
slots, 16 tx
tx slots,
slots, 1 long searches, 1 misses
99%
99% hit
hit ratio,
ratio, five
five minute
minute miss
miss rate 0 misses/sec, 0 max.
The show ip rtp header-compression command displays the statistics of CRTP

on an interface.
Monitoring
Router#
show frame-relay ip
ip tcp
• Displays RTP Header Compression statistics on

frame-relay (sub)interfaces
Router#show
frame-relay ipip tcp
header-compression
DLCI
DLCI 17
17 Link/Destination
Link/Destination info:
info: ipip 165.3.3.2
165.3.3.2
Interface
Interface Serial0:
Serial0:
Rcvd:
Rcvd: 00 total,
total, 00 compressed,
errors
00 dropped,
dropped, 00 buffer
buffer copies,
copies, 00 buffer
buffer failures
failures
Sent:
Sent: 6000
6000 total,
total, 5998
5998 compressed,
compressed,
227922
227922 bytes
bytes saved,
saved, 251918
251918 bytes
bytes sent
sent
1.90
1.90 efficiency
improvement factor
factor
Connect:
Connect: 16 rx slots, 16 tx slots, 2 long searches, 22 misses
16 rx slots, 16 tx slots, 2 long searches, misses
99%
99% hit
hit ratio,
ratio, five
five minute
minute miss
miss rate
rate 00 misses/sec,
misses/sec, 00 max
The show frame -relay ip rtp header-compression command displays the

statistics of CRTP on a frame-relay interface.
Summary
n TCP header compression optimizes performance of interactive TCP-based
applications on slow links, by shrinking IP and TCP headers to 3-5 byte indices
n RTP header compression optimizes performance of delay-sensitive RTP-based
applications, such as voice, on slow links, by shrinking IP, UDP, and RTP
headers to 3-5 byte indices
n TCP and RTP header compression methods can be implemented with Cisco
IOS software
Lesson Review
1. List the different header compression methods than can be used.
2. Where are header compression mechanisms most effective?
3. What type of traffic benefits most by using TCP Header Compression?
4. What type of traffic benefits most by using RTP Header Compression?
Link Fragmentation and Interleaving
Objectives
This lesson describes the mechanism used to reduce the maximum size of PPP or
Frame Relay frames. It also explains the interleaving of multiple frames of large
packets with frames of small packets.
Objectives
n Describe Link Fragmentation and Interleaving (LFI)
n Describe and configure Multilink PPP
n Monitor and troubleshoot Multilink PPP
n Describe and configure Frame Relay Fragmentation
n Monitor and troubleshoot Frame Relay Fragmentation
Queuing and Serialization Delay
8ms 8ms
Empty
Network
64 kbps
Delay
Variation
Queuing Delay
8ms 184 ms 8ms

Congested
Network
64 kbps
Problems:
• Large delay due to slow link and MTU-sized packets
• Jitter (variable delay) due to variable link utilization
When considering delay between two hops in a network, queuing delay in a router
must be considered, because it may be comparable to, or even exceed the
transmission delay on a line. In an empty network, an interactive or voice session
experiences low or no queuing delay, because it does not compete with other
applications on an interface output queue. Also, the small delay does not vary
enough to produce considerable jitter on the receiving side.
In a congested network, interactive data and voice applications compete in the
router queue with other applications. Queuing mechanisms may prioritize voice
traffic in the software queue, but the hardware queue (Tx ring) always uses a
FIFO scheduling mechanism. Therefore, after packets of different applic ations
leave the software queue, they will mix with other packets in the hardware queue,
even if their software queue processing was expedited. Thus, a voice packet may
be immediately sent to the hardware queue, where two large FTP packets may still
be waiting for transmission. The voice packet must wait until the FTP packets are
transmitted, thus producing a delay in the voice path.
Because links are variably utilized, this delay varies with time and may produce
unacceptable jitter in jitter-sensitive applications such as voice.
Voice Reassembly
Probability of
Less delay
arrival
More loss More delay
Less loss
Usable Jitter
packets
Unusable
packets
Min. Avg. Delay

Delay Delay
Playback Point
(max. Acceptable Delay)
Jitter can be offset by more buffering

More buffering causes even more delay which
is not acceptable for two-way communication
Jitter can always be offset by more buffering on the receive side. However, more
buffering produces more overall delay. This delay must not cross certain
thresholds in delay-sensitive applications, such as packetized voice. The voice
delay threshold (usually around 150 ms of one-way delay) represents the limit at
which the quality of packetized voice telephony is still regarded as acceptable by
end users.
Voice Reassembly
Probability of
Less delay
arrival
More loss More delay
Less loss
Usable Jitter
packets
Unusable
packets
Min. Avg. Delay

Delay Delay
Playback Point
(max. Acceptable Delay)
The right solution is to reduce average

delay
A better solution than adding additional buffering is to reduce the average delay
along the packet path. This allows for more jitter before packets are deemed
unusable by the voice reassembly on the receiving endpoint (IP telephone).
Reduced average delay can be provided through link fragmentation and
interleaving, by reducing delays on critical links in the packet path.
Link Fragmentation and
Interleaving
Delay to large
B2 A3 B1 A2 A1 TxQ
Fragmentation Interleaving
A3 A3 A3 A3 A2 B3 A2 A2 A2 B2 A1 A1 A1 B1 A1 TxQ
Acceptable
Delay
Reduce delay and jitter by fragmenting large
frames and prioritizing small frames
Link fragmentation and interleaving (LFI) is a layer-2 technique, where all layer-2
frames are broken into small, equal-size fragments, and transmitted over the link in
an interleaved fashion. The figure shows the interface hardware output queue,
populated by frames of differing sizes; large and small.
When fragmentation and interleaving is in effect, all frames waiting in the queuing
system are fragmented, smaller frames are prioritized, and a mixture of fragments
is sent over the link. Small frames may be scheduled behind larger frames in the
WFQ system. LFI fragments all frames, and this reduces the queuing delay of
small frames, as they are sent almost immediately. Link fragmentation therefore
reduces delay and jitter by expediting transfer of smaller frames through the
hardware queue.
LFI with WFQ
MTU=1500
WFQ TxQ
TxQ is sized in
the number of
packets
WFQ TxQ
MTU=1500, LFI MTU=160

Maximum delay caused by the TxQ is the number of packets multiplied by
the time it takes to transmit the longest frame (usually MTU-sized)
The longest delay, used with the WFQ scheduling algorithm, is the product of the
number of packets in the queue and the size of the maximum packet (to calculate
the worst-case delay at any instant).
Before LFI, the maximum possible size of a packet was limited by the interface
MTU, which might be set to a value up to 1500 bytes on a serial line. LFI MTU is
considerably smaller, because it reflects the maximum size of a fragment in a LFI
implementation. For example, an LFI MTU of 160 bytes (which is commonly used)
reduces the worst-case maximum delay to one tenth of the delay of a normal non-
LFI-enabled link, because the next scheduled fragment now has to wait only until
the previous fragment has been transmitted. Before using LFI, any packet had to
wait until the whole previous frame has been transmitted, which might be up to the
full MTU in size.
Fragmentation Options
Three types of LFI mechanisms are

available:
• Multilink PPP with Interleaving
• FRF.11 Annex C specification for VoFR PVCs
• FRF.12 specification for data PVCs
Using separate PVCs for voice and data
can be used to interleave packets in ATM
networks
There are three LFI mechanisms implemented in Cisco IOS:

n Multilink PPP with Interleaving is by far the most common and widely used
form of LFI.
n FRF.11 Annex C LFI is used with Voice over Frame Relay (VoFR).
n FRF.12 Frame Relay LFI is used with Frame Relay data connections.
n In an ATM network, using separate PVCs carrying voice and data can be
used to interleave packets when they are output on an interface.
Configuring MLP with Interleaving
Configuration steps:
• Enable Multilink PPP on an interface (using a
Multilink Group interface)
• Enable PPP Multilink interleaving on the
Multilink interface
• Specify maximum fragment size by setting
the maximum delay on the Multilink interface
To configure Multilink PPP (MLP) with interleaving, the following configuration

steps must be performed:
Step 1 First, enable multilink on an interface (using a multilink group interface).
Step 2 Second, in the multilink interface, enable interleaving within Multilink PPP.
Step 3 Third, in the multilink interface configuration, specify the maximum
fragment size of MLP by specifying the maximum desired delay on the
point-to-point link.
Configuring MLP with Interleaving
Router(config-if)#
ppp multilink
• Enables Multilink PPP

• Also requires WFQ or CB-WFQ to be enabled on the interface
Router(config-if)#
ppp multilink interleave
• Enables interleaving of frames with fragments

Router(config-if)#
ppp multilink
multilink fragment-delay
fragment-delay delay
delay
• Configure maximum fragment delay in milliseconds

• The router calculates the maximum fragment size from the
bandwidth and the maximum fragment delay
• Default is 30 ms
The ppp multilink command enables PPP multilink on an interface. This requires
either Weighted Fair Queuing (WFQ) or CB-WFQ (Class-Based Weighted Fair
Queuing) to be enabled on the same interface.
The ppp multilink interleave command enables interleaving of fragments within
the multilink connection.
The ppp multilink fragment delay command specifies the maximum desired
fragment delay for the interleaved multilink connection. The maximum fragment
size is calculated from the interface bandwidth and the specified maximum delay.
The default is set at 30 milliseconds.
If dCEF is configured on a VIP interface, MLP with interleaving runs distributed
on the VIP.
MLP with Interleaving
Example
interface
interface Multilink1
Multilink1
ip
ip address 10.1.1.1
10.1.1.1 255.255.255.252
255.255.255.252
fair-queue
fair-queue
ppp
ppp multilink
multilink
multilink-group
multilink-group 1
ppp
ppp multilink
multilink fragment-delay 20
ppp
ppp multilink
multilink interleave
interleave
!!
interface
interface Serial0/0
Serial0/0
no
no ip address
address
encapsulation
encapsulation ppp
ppp
ppp multilink
multilink
multilink-group
multilink-group 1
!!
The figure shows an example configuration of MLP with interleaving on a multilink

group interface. A non-default maximum desired delay of 20 ms is configured.
MLP Interleaving
Router#
show interface
interface [intf]
[intf]
• Displays statistics including the number of interleaved frames
Router #show interfaces
Router#show interfaces multilink
multilink 11
Multilink1
Multilink1 isis up,
up, line
line protocol
protocol is
is up
up
Hardware
Hardware is multilink group
is multilink group interface
interface
Internet
Internet address
address isis 172.22.130.1/30
172.22.130.1/30
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 6464 Kbit,
Kbit, DLY
DLY 100000
100000 usec,
usec,
reliability
255/255, txload
txload 27/255,
27/255, rxload
rxload 1/255
1/255
Encapsulation
Encapsulation PPP, loopback
loopback not
not set
set
Keepalive set (10 sec)
DTR
DTR is
is pulsed
pulsed for 2 seconds on reset
LCP
LCP Open,
Open, multilink
multilink Open
Open
Open:
Open: IPCP
IPCP
Last
Last input
input 00:00:03,
00:00:03, output
output never,
never, output
output hang
hang never
never
Last
Last clearing
clearing of "show interface" counters 6d00h
Input
Input queue:
queue: 0/75/0/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 0/1000/64/0/2441
0/1000/64/0/2441 (size/max
(size/max total/threshold/drops/interleaves)
total/threshold/drops/interleaves)
Conversations
0/7/16 (active/max
active/max total)
total)
Reserved
Reserved Conversations 0/0 (allocated/max allocated)
Conversations 0/0 (allocated/max allocated)
55 minute
minute input
input rate
rate 00 bits/sec,
packets/sec
55 minute
minute output
output rate
rate 7000
7000 bits/sec,
packets/sec
The show interface command output includes MLP statistics information and
indicates whether MLP Interleaving is enabled on the interface.
MLP Interleaving
Router#
debug ppp multilink
multilink fragments
• Displays information about individual multilink fragments and
interleaving events
Router#debug
Router#debug ppp
ppp multilink
multilink fragments
fragments
Multilink
Multilink fragments
fragments debugging
debugging is
is on
on
Mar
Mar 17
17 20:03:08.995:
20:03:08.995: Se0/0
Se0/0 MLP -FS: II
MLP-FS: seq
seq C0004264
C0004264 size
size 70
70
Mar
Mar 17
17 20:03:09.015:
20:03:09.015: Se0/0
Se0/0 MLP -FS: II
MLP-FS: seq
seq 80004265
80004265 size
size 160
160
Mar
Mar 17
17 20:03:09.035:
20:03:09.035: Se0/0
Se0/0 MLP -FS: II
MLP-FS: seq
seq 4266
4266 size
size 160
160
Mar
Mar 17
17 20:03:09.075: Se0/0 MLP -FS: II
20:03:09.075: Se0/0 MLP-FS: seq 4267 size 160
seq 4267 size 160
Mar
Mar 17
17 20:03:09.079: Se0/0 MLP -FS: II
20:03:09.079: Se0/0 MLP-FS: seq
seq 40004268
40004268 size
size 54
54
Mar
Mar 17
17 20:03:09.091:
20:03:09.091: Se0/0
Se0/0 MLP -FS: II
MLP-FS: seq
seq C0004269
C0004269 size
size 70
70
Mar
Mar 17
17 20:03:09.099:
20:03:09.099: Se0/0
Se0/0 MLP -FS: II
MLP-FS: seq
seq C000426A
C000426A size
size 70
70
Mar
Mar 17
17 20:03:09.103:
20:03:09.103: Mu1
Mu1 MLP:
MLP: Packet
Packet interleaved
interleaved from queue 24
Mar
Mar 17
17 20:03:09.107: Se0/0 MLP -FS: II
20:03:09.107: Se0/0 MLP-FS: seq C000426B size
seq C000426B size 7070
Mar
Mar 17
17 20:03:09.119:
20:03:09.119: Se0/0 MLP-FS: II
Se0/0 MLP -FS: seq
seq C000426C
C000426C size
size 70
70
Mar
Mar 17
17 20:03:09.123:
20:03:09.123: Mu1
Mu1 MLP:
MLP: Packet
Packet interleaved
interleaved from queue 24
Mar
Mar 17
17 20:03:09.131:
20:03:09.131: Mu1
Mu1 MLP:
MLP: Packet
Packet interleaved
interleaved from
from queue 24
queue 24
Mar
Mar 17
17 20:03:09.135:
20:03:09.135: Se0/0
Se0/0 MLP -FS: II
MLP-FS: seq
seq C000426D
C000426D size
size 70
70
Mar
Mar 17
17 20:03:09.155:
20:03:09.155: Se0/0 MLP-FS: II
Se0/0 MLP -FS: seq C000426E size
seq C000426E size 7070
The debug ppp multilink fragments command is a valuable troubleshooting tool

when monitoring MLP operations. The command outputs the result of every
fragmentation operation, indicating whether the interleave operation fragments
packets into correct-sized fragments. This command should be used with extreme
caution in a production environment, because of the amount of output created.
Frame Relay
Fragmentation
FRF.11 Annex C specifies fragmentation of
voice frames (VoFR):
• Only frames with data payload type are
fragmented
• Voice bypasses the fragmentation engine
regardless of frame size
FRF.12 specifies fragmentation of data frames:
• Data frames that exceed the specified
fragmentation size are fragmented
• Smaller time -sensitive packets can be interleaved
• VoIP packets do not get a special treatment
In Frame Relay networks, two fragmentation standards are available on layer-2

(within the Frame Relay encapsulation):
n When Voice over Frame Relay (FRF.11) and fragmentation are both
configured on a PVC, Frame Relay fragments are transmitted in the FRF.11
Annex C format. This fragmentation method is used when FRF.11 voice
traffic is transmitted on the PVC and uses the FRF.11 Annex C fragmentation
standard. With FRF.11, all data packets contain fragmentation headers
regardless of size. This form of fragmentation is not recommended for use
with Voice over IP.
n FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement.
The FRF.12 Implementation Agreement was developed to allow long data
frames to be fragmented into smaller pieces and interleaved with real-time
frames. In this way, real-time voice and non-real-time data frames are carried
together on lower-speed links without causing excessive delay to the real-time
traffic. As a result, FRF.12 is the recommended fragmentation to be used with
VoIP.
FRF.12 versus FRF.11 Annex-C
Fragmentation
FRF.11 Annex-C Fragmentation FRF.12 Fragmentation

Used on DLCIs configured for Used on DLCIs carrying data
VoFR traffic only (including VoIP)
Does not fragment voice Fragments voice packets if the
packets regardless of what fragmentation size parameter
fragmentation size is is set to a value smaller than
configured the voice packet size
Must be supported by platforms Predominantly used for VoIP –
that support VoFR Must be supported only by
Cisco IOS platforms that
transport VoIP over slow
speed WAN links
If a PVC is not configured for VoFR, it uses normal Frame Relay (FRF.3.1) data
encapsulation. If fragmentation is turned on for this DLCI, it uses FRF.12 for the
fragmentation headers. PVCs carrying VoIP use FRF.12 fragmentation because
VoIP is a layer 3 technology that is transparent to layer 2 Frame Relay. VoIP and
VoFR can be supported on different PVCs on the same interface, but not on the
same PVC.
FRF.12 fragments voice packets if the fragmentation size parameter is set to a
value smaller than the voice packet size. FRF.11 Annex-C (VoFR) does not
fragment voice packets regardless of what fragmentation size is configured.
FRF.11 Annex-C needs only to be supported by platforms that support VoFR.
Because FRF.12 is predominantly used for VoIP, it is important to use FRF.12 as a
general feature on Cisco IOS platforms that transport VoIP over slow speed
WAN links.
Implementation Notes
When Frame Relay fragmentation is configured, the

following conditions and restrictions apply:
• WFQ at the PVC level is the only queuing strategy that
can be used.
• FRTS must be configured to enable FR fragmentation
• VoFR frames are never fragmented, regardless of size.
• When using FRF.12 fragmentation, the VoIP packets will
not include the FRF.12 header, provided the size of the
VoIP packet is smaller than the fragment size
configured. However, when using FRF.11 Annex C or
Cisco proprietary fragmentations, VoIP packets will
include the fragmentation header.
• If fragments arrive out of sequence, packets are
dropped
When deploying a solution using Fragmentation and Interleaving on a Frame Relay

backbone, it is a good idea to be aware of the following key issues:
n At the PVC level, WFQ is the only permitted queuing strategy when used
together with Frame Relay fragmentation
n Frame Relay Traffic Shaping must be enable d together with Frame Relay
Fragmentation
n If native voice over Frame Relay (VoFR) is used, its frames are never
fragmented
n In VoIP applications, FRF.11 Annex C adds an additional fragmentation
header to packets, while FRF.12 does not
n If the Frame Relay network delivers fragments out of sequence, fragments are
dropped and a lost frame results.
Configuring Frame Relay
Fragmentation (FRF.11 C)
Router(config)#
• Enter Map Class configuration mode
frame-relay fragment size
• Set the maximum fragment size
frame-relay voice
voice bandwidth
bandwidth bps
• Set aside an amount of bandwidth for FRF.11 voice

traffic (VoFR)
FRF.11 Annex C fragmentation is configured within the Frame Relay map class.
The frame-relay fragment command sets the maximum fragment size. The
frame-relay voice bandwidth command reserves an amount of bandwidth used
only for FRF.11-encapsulated VoFR traffic.
Fragmentation (FRF.11 C)
Router(config-if)# | (config-subif)# | (config-fr-dlci)#

frame-relay class name
name
• Apply the Frame Relay Map Class to an interface, subinterface

or DLCI
Router(config-fr-dlci)#
vofr
• Enable FRF.11 encapsulation
service-policy output name
• Use distributed Class-based Low Latency Queuing on Cisco

7500 routers to prioritize VoFR frames
• Traditional WFQ can be used on all other platforms
On an interface, the frame-relay class command applies the map class to the
interface, subinterface, or a DLCI. The vofr interface command changes the
encapsulation on a DLCI to support only FRF.11 VoFR traffic.
The service-policy output command, used within a map class, applies a QoS
policy to the frame relay traffic class. Low Latency Queuing (configured within
CB-WFQ) is recommended on a VoFR circuit.
Fragmentation (FRF.12)
Router(config)#
• Enter Map Class configuration mode
frame-relay fragment size
• Set the maximum fragment size
Router(config-if)# | (config-subif)# | (config-fr-dlci)#

frame-relay class name
name
• Apply the Frame Relay Map Class to an interface or

subinterface
FRF.11 Annex C fragmentation is also configured within the Frame Relay map
class. The frame-relay fragment command sets the maximum fragment size. On
an interface, the frame-relay class command applies the map class to the
interface, sub-interface, or a DLCI.
Frame Relay Fragmentation
FRF.11 C Example
interface
interface serial
serial 0/0
0/0
frame-relay
frame-relay traffic shaping
!!
interface
interface serial
serial 0/0.1
0/0.1 point-to-point
point-to-point
frame-relay
interface-dlci 100
100
vofr
class
class FRF11
FRF11
!!
map-class
frame-relay FRF11
FRF11
frame-relay
frame-relay fragment
fragment 160
160
frame-relay
frame-relay cir
cir 65536
65536
frame-relay
frame-relay bc
bc 2600
2600
frame-relay
frame-relay fair-queue
fair-queue
!!
The figure shows a configuration example where FRF.11 Annex C fragmentation

is applied to a VoFR circuit configured on the Serial0/0.1 interface. The maximum
fragment size is set to 160 bytes.
FRF.12 Example
interface
interface serial
serial 0/0
0/0
frame-relay
frame-relay traffic shaping
!!
interface
interface serial
serial 0/0.1
0/0.1 point-to-point
point-to-point
frame-relay
interface-dlci 100
100
class
class FRF12
FRF12
!!
map-class
map-class frame-relay FRF12
frame-relay
fragment 160
160
frame-relay
frame-relay cir
cir 65536
65536
frame-relay
frame-relay bc
bc 2600
2600
frame-relay
frame-relay fair-queue
fair-queue
!!
The figure shows a configuration example where FRF.12 fragmentation is applied

to a data Frame Relay circuit configured on the Serial0/0.1 interface. The
maximum fragment size is also set to 160 bytes. This would be used in a VoIP
over Frame Relay environment.
Router#
show frame-relay pvc
pvc [interface intf] [dlci]
• Displayst PVC parameters and statistics

The following values are
Router#
Router# show
show frame -relay pvc
frame-relay pvc interface
interface serial
serial 1 45 possible:
• VoFR – FRF.11 Annex C
PVC
PVC Statistics
Statistics for
for interface
interface Serial1
Serial1 (Frame
(Frame Relay DTE)
Relay DTE) • VoFR-cisco – Cisco
proprietary fragmentation
DLCI
DLCI == 45,
45, DLCI
DLCI USAGE
USAGE == LOCAL,
LOCAL, PVC
PVC STATUS
STATUS == STATIC,
STATIC, INTERFACE
INTERFACE• =end-to-end
= Serial1
Serial1– FRF.12
fragmentation
input
input pkts
pkts 85
85 output
output pkts
pkts 289
289 in
in bytes
bytes 1730
1730
out
out bytes
bytes 6580
6580 dropped
dropped pkts
pkts 11
11 in
in FECN
FECN pkts
pkts 00
in
in BECN
BECN pkts
pkts 00 out
out FECN
FECN pkts
pkts 00 out
out BECN
BECN pkts
pkts 00
in
in DE
DE pkts
pkts 00 out
out DE
DE pkts
pkts 00
out
out bcast
bcast pkts
pkts 00 out
out bcast
bcast bytes
bytes 00
pvc
pvc create
create time
time 00:02:09,
00:02:09, last
last time
time pvc
pvc status
status changed
changed 00:02:09
00:02:09
Service type VoFR
Service type VoFR
configured
configured voice
voice bandwidth
bandwidth 25000,
25000, used
used voice
voice bandwidth
bandwidth 22000
22000
fragment
fragment type
type VoFR
VoFR fragment
fragment size
size 100
100
cir
cir 20000
20000 bc
bc 1000
1000 be
be 00 limit 125 interval
interval 50
50
mincir 20000
mincir 20000 byte increment
byte increment 125125 BECN
BECN response
response no
no
fragments 290
fragments 290 bytes 6613
bytes 6613 fragments delayed
fragments delayed 1 1 bytes
bytes delayed
delayed
33
33
shaping
shaping inactive
inactive
...
...
The show frame -relay pvc command output includes settings related to either
FRF.11 Annex C or FRF.12 fragmentation. The output shows the fragment size
used on the Frame Relay PVC.
Router#
show frame-relay fragment
fragment [interface intf] [dlci]
• Displayst PVC parameters and statistics

Router#show
fragment
interface
interface dlci
dlci frag-type
frag-type frag-size
frag-size in-frag
in-frag out-frag
out-frag dropped-frag
dropped-frag
Serial0
Serial0 108
108 VoFR-cisco
VoFR-cisco 100
100 1261 1298 0
Serial0
Serial0 109
109 VoFR
VoFR 100
100 0 243 0
Serial0
Serial0 110
110 end-to-end
end-to-end 100
100 0
0 0
0 0
0
Router#show
fragment interface
interface Serial1/0
Serial1/0
fragment-size
fragment-size 4545 fragment
fragment type
type end-to-end
end-to-end
in
in fragmented
fragmented pkts
pkts 00 out
out fragmented
fragmented pkts
pkts 00
in
in fragmented
fragmented bytes
bytes 00 out
out fragmented
fragmented bytes
bytes 00
in
in un-fragmented
un-fragmented pkts
pkts 00 out
out un -fragmented pkts
un-fragmented pkts 00
in un-fragmented bytes
in un-fragmented bytes 0 0 out
out un-fragmented bytes
un -fragmented bytes 00
in
in assembled
assembled pkts
pkts 00 out
out pre-fragmented
pre-fragmented pkts
pkts 00
in
in assembled
assembled bytes 0 out
out pre-fragmented
pre-fragmented bytes
bytes
in
in dropped reassembling pktspkts 00 out
out dropped
dropped fragmenting
fragmenting pkts
pkts 00
in
in timeouts
timeouts 0
in out-of-sequence fragments
in out -of-sequence fragments 0 0
in
in fragments
fragments with
with unexpected
unexpected BB bit
bit set
set 00
out
out interleaved
interleaved packets
packets 00
The show frame -relay fragment command displays statistics of Frame Relay
fragmentation methods. This output shows whether Frame Relay fragmentation is
in effect and working as configured. The output also shows possible fragmentation
timeouts, indicating that some fragments were lost in the Frame Relay network and
could not be reassembled. If the number of timeouts is significant, this may indicate
significant frame loss in the Frame Relay network.
Summary
n Link fragmentation and interleaving methods reduce the average delay on a
transmission line by fragmenting frames into small fragments and scheduling
their transfer in an interleaved fashion
n Multilink PPP with Interleaving is the preferred LFI method, used with the
PPP protocol
n FRF.11 C and FRF.12 are the preferred LFI methods, used in a Frame Relay
environment
n Multilink PPP with Interleaving, FRF.11 C, and FRF.12 methods are available
in Cisco IOS
Lesson Review
1. List the different link fragmentation methods that can be used.
2. What mechanism is needed to implement link fragmentation with PPP
encapsulation?
3. What are the differences between different Frame Relay link fragmentation
mechanisms?
Summary
n Stacker and MPPC payload compression methods yield better compression
ratios, is more CPU-intensive, and may introduce additional delay
n The Predictor payload compression is faster, can be used in higher-bandwidth
scenarios, but generally yields lower average compression ratios
n TCP header compression optimizes performance of interactive TCP-based
applications on slow links, by shrinking IP and TCP headers to 3-5 byte indices
n RTP header compression optimizes performance of delay-sensitive RTP-based
applications, such as voice, on slow links, by shrinking IP, UDP, and RTP
headers to 3-5 byte indices
n Multilink PPP with Interleaving is the preferred LFI method, used with the
PPP protocol
n FRF.11 C and FRF.12 are the preferred LFI methods, used in a Frame Relay
environment
Payload Compression
Question: What is the purpose of using payload compression?
Answer: The purpose of payload compression is primarily to increase throughput
of a link, and secondarily, to decrease propagation delay on a link.
Question: List the payload compression algorithms than can be used.
Answer: Cisco IOS supports Stacker, predictor, and MPPC algorithms to
compress Layer-2 link data.
Question: What are some of the benefits and drawbacks of Stacker?
Answer: Stacker provides good compression ratios with most types of traffic and
works on most Layer-2 encapsulations. On the downside, Stacker is very CPU
intensive and may have throughput limitations and increase processing delay.
Question: What are some of the benefits and drawbacks of Predictor?
Answer: Predictor is very fast and works well on text-type traffic. Predictor does
not yield very good compression ratios with all types of traffic, and supports only
select encapsulations.
Header Compression
List the different header compression methods than can be used.
Where are header compression mechanisms most effective?
What type of traffic benefits most by using TCP Header Compression?
What type of traffic benefits most by using RTP Header Compression?
Link Fragmentation and Interleaving

Question: List the different link fragmentation methods that can be used.
Answer: Cisco IOS supports TCP and RTP header compression.
Question: What mechanism is needed to implement link fragmentation with PPP
encapsulation?
Answer: PPP link fragmentation is implemented with PPP Multilink with
Interleaving.
Question: What are the differences between different Frame Relay link
fragmentation mechanisms?
Answer: The FRF.11 Annex C method is used only to fragment Voice over
Frame Relay (VoFR). The FRF.12 method is used only to fragment data over
Frame Relay, including Voice over IP.
7
Signaling Mechanism
Overview
The module describes RSVP as the signaling mechanism used in QoS enabled
networks. The module builds on knowledge about the IntServ model with the
addition of Common Open Policy Service (COPS) discussed in the introductory
module.
Objectives
n Describe Resource Reservation Protocol (RSVP).
n Configure RSVP.
n Describe and configure RSVP on shared media using Subnet Bandwidth
Management (SBM).
n Monitor and troubleshoot RSVP.
Resource Reservation Protocol (RSVP)
Overview
The section introduces Resource Reservation Protocol (RSVP) as the signaling
mechanism in QoS-enabled networks using the Integrated Services model.
Objectives
n Describe Resource Reservation Protocol (RSVP).
n Configure RSVP.
n Monitor and troubleshoot RSVP.
7-2 IP QoS Signaling Mechanism Copyright  2001, Cisco Systems, Inc.

Resource Reservation Protocol
• RSVP is a protocol used to reserve resources in a

path between a source and a destination
• RSVP signals all network devices that a certain
application needs certain QoS guarantees
• RSVP requires applications to initiate the request
• RSVP by itself does not provide any guarantees
• An RSVP-interoperable QoS mechanism (WFQ, CB-
WFQ) must be used to implement guarantees
according to RSVP reservations
© 2001, Cisco Systems, Inc. IP QoS Signaling Mechanism-5
RSVP is an Internet Engineering Task Force (IETF) signaling protocol, used to

reserve bandwidth in a path between a source and a destination. In RSVP, the
end-node (the application node) station reserves bandwidth for a flow along its path
to a destination in a network. The user can supply the information about how much
capacity to reserve.
RSVP mechanisms enable real-time traffic to reserve bandwidth necessary for
consistent latency. A video conferencing application can use settings in the router
to propagate a request for a path with the required bandwidth and delay for video
conferencing destinations. RSVP then signals all network devices along the path,
and confirms or rejects the reservation. RSVP will check and repeat reservations
at regular intervals. When RSVP is used, the routers sort and prioritize packets
much as a statistical time-division multiplexer would sort and prioritize several
signal sources that share a single channel.
RSVP requires RSVP-aware applications, as signaling is performed by the end-
node. In addition, RSVP does not provide any guarantees by itself. RSVP is the
protocol used to communicate QoS requirements between the end-node and the
layer-3 network, assessing the ability or inability of the network to support the
requested level of service.
RSVP is the signaling protocol underlying the IntServ QoS reference model.
Together with appropriate QoS-enforcing mechanisms in the network, such as
WFQ, it forms a foundation for implementation of IntServ-based services.
Copyright  2001, Cisco Systems, Inc. IP QoS Signaling Mechanism 7-3

End-to-end RSVP
Local Local Local

Admission Admission Admission
Control Control Control
• All network devices have to be enabled for

RSVP
• Each network device determines whether it
has enough resources
If end-to-end RSVP is desired in a network, all devices in the reservation path

must be RSVP-enabled. When a device receives an RSVP message, it determines
whether it has enough resources to satisfy the reservation request at the local
level.
There are two main RSVP messages used for signaling. When a reservation is
needed, the sending client sends an RSVP PATH message into the network
requesting a specific bandwidth to a specific destination (or multicast address, in
the case of IP multicast application). The purpose of the PATH message is to
discover all RSVP-enabled routers along the path from the sender to the receiver,
and to create initial reservations. The PATH message is forwarded along the flow
path and every intermediate RSVP-capable router adds its identification to the
PATH message. When the receiving end-node receives the PATH message, it
confirms the reservation by replying with an RSVP RESV message. The RESV
message is forwarded back upstream towards the initial sender using the list of
RSVP-enabled routers generated by the PATH message. If the RESV message
successfully arrives at the initial sender, each hop in the end-to-end connection has
reserved the appropriate resources and an end-to-end reservation is established. If
the appropriate resources are not available, the reservation is refused and the
application must default to traditional, best effort communications.
RSVP keeps track of the soft state of reservations in routers. This soft state
provides dynamic membership information, adapts to routing changes, and, as the
number of flows increases, enables dynamic changes in reservations to meet those
changing needs. RSVP reservations time out unless periodically refreshed by the
communication endpoint, usually at 30-second intervals.
The benefits of soft state behavior are:

n Connectionless behavior − routers automatically adapt to route changes.
n Timeliness − state changes propagate immediately, but only as far as needed.
n Robustness − the method is self-correcting, because incorrect reservations
will always time-out even in the most unexpected situations.
n Flexibility − provides easy dynamic reservation changes.
The cost of this approach is that it requires ongoing refresh processing for
established states by the endpoints.

Pass-through RSVP
Local Local
Local
Admission Admission
Admission
Control Control
Control request
request request RSVP request request

not
enabled
reserve
Best-effort
forwarding
• Part of the network may not support RSVP

• Best-effort delivery is used in those parts
When a part of the network does not support RSVP, that is, when the RSVP
messages are not processed by every intermediate hop between the two
application endpoints, some other mechanism may be employed to try to meet the
application requirements in the non-RSVP-enabled part of the network. One such
possibility may be to perform only best-effort delivery between RSVP-enabled
networks using an undersubscribed network in between. The PATH messages
discover all RSVP-aware routers, and are forwarded as plain IP packets on non-
RSVP-enabled hops. The RESV messages are then interpreted only by the RSVP-
aware hops, discovered via the PATH message.

Pass-through RSVP
with Class of Service
Local Local
Local Admission Admission
Admission Control Control
Control request
request request RSVP request request

not
enabled
reserve
Mark RSVP flow Class-based

with DSCP guarantee
• Part of the network may not support RSVP

• Mark RSVP flows with a Class-of-service
marker (e.g. IP precedence or DSCP)
• Make sure the core provides guarantees to
the RSVP class
Another option may be to apply class-of-service based delivery on a non-RSVP-

enabled part of the network. In that case, RSVP-based application traffic is
marked with appropriate class markers (IP precedence or DSCP bits) at the entry
to the non-RSVP-enabled part. The core network can then be engineered to
provide special service to the RSVP class, using, for example, WFQ and WRED.
IP precedence and DSCP are packet markers, located in the ToS byte of the IP
header, which identify traffic classes on each hop in the network. IP precedence
or DSCP bits are usually set at the network edge, where traffic is classified and
marked, and the markers used to identify traffic classes in downstream network
devices. Each device along the path may apply appropriate QoS mechanisms
based on the packet marker, resulting in differentiated per-hop behaviour (PHB)
for each class of traffic. The DiffServ model defines several standard PHBs,
based on marking traffic with the DSCP header bits.

RSVP Applications
• RSVP is used for applications where

bandwidth and delay related guarantees are
necessary
• Typical applications are:
– Voice over IP (Cisco phones, Microsoft
NetMeeting, ...)
– MPLS Traffic Engineering
RSVP allows end systems to request QoS guarantees from the network. The need
for network resource reservations differs for data traffic versus real-time traffic,
as described in the following paragraphs:
n Data traffic seldom needs reserved bandwidth because internetworks provide
datagram services for data traffic. This asynchronous packet switching may
not need guarantees of service quality. End-to-end controls between data
traffic senders and receivers help ensure adequate transmission of bursts of
information.
n Real-time traffic (that is, voice or video information) experiences problems
when using datagram services. Because real-time traffic sends an almost
constant flow of information, the network “pipes” must be consistent. Some
guarantee must be provided that service between real-time hosts will not vary.
Routers operating on a first-in, first-out (FIFO) basis risk unrecoverable
disruption of the real-time information that is being sent.
Many network-aware applications today use RSVP for signaling. Some well-
known examples include Cisco IP telephones, Microsoft NetMeeting, and MPLS
Traffic Engineering.

Configuring Simple RSVP
Router(config-if)#
ip rsvp
rsvp bandwidth
bandwidth [total-BW [per-flow-BW]]
• Set the amount of reservable bandwidth (total-BW) and the

maximum per-flow reservable bandwidth (per-flow-BW) in kbps
• Both default to 75% of the configured bandwidth
• Total reservable bandwidth cannot exceed 75% of the
configured bandwidth
Router(config-if)#
bandwidth bandwidth
• Set the interface bandwidth in kbps

• This value should reflect the real bandwidth of the link
Basic RSVP is configured by two interface commands. The ip rsvp bandwidth

command sets the maximum total amount of reservable bandwidth on an interface.
By default, it is configured to 75% of the configured bandwidth, which is also its
maximum allowed value. A per-flow reservable bandwidth can also be configured,
setting the maximum bandwidth a single flow can reserve over this interface. By
default, it is also set to 75% of the configured bandwidth.
Note RSVP cannot be configured with VIP-distributed Cisco Express Forwarding

(dCEF).
The bandwidth interface command sets the interface bandwidth and is used by
routing protocols (to calculate costs) and by a variety of QoS mechanisms. With
RSVP, this is used as the configured bandwidth parameter, referenced by the limits
in the ip rsvp bandwidth command.

Configuring Proxy RSVP
Router(config)#
ip
ip rsvp
rsvp sender
sender session-IP sender-IP
sender-IP protocol
protocol dport
dport sport
sport src-hop-
src-hop-
IP
IP src-intf bandwidth burst
• Simulates a host sending a PATH message

• Generates a PATH message on behalf of a host or an
application
Router(config)#
ip
ip rsvp reservation
reservation session-IP sender-IP protocol dport sport
next-hop-IP next-hop-intf {ff
{ff | se | wf} {rate | load} bw burst
• Simulates a host sending a RESV message

• Generates a RESV message on behalf of a host or an
application
RSVP typically requires both host and network implementations, although Cisco
IOS software provides an RSVP command line interface that allows you to
statically set up RSVP reservations without host involvement.
Use the ip rsvp sender command to make the router simulate that it is receiving
RSVP PATH messages from an upstream host. The command can be used to
proxy RSVP PATH messages for non-RSVP-capable senders. By including a
local (loopback) previous hop address and previous hop interface, you can also use
this command to proxy RSVP for the router you are configuring.
To enable a router to simulate receiving and forwarding Resource Reservation
Protocol (RSVP) RESV messages, use the ip rsvp reservation global
configuration command. To disable this feature, use the no form of this command.
Use this command to make the router simulate receiving RSVP RESV messages
from a downstream host. This command can be used to proxy RSVP RESV
messages for non-RSVP-capable receivers. By giving a local (loopback) next hop
address and next hop interface, you can also use this command to proxy RSVP for
the router you are configuring. Several different reservation types can be specified.
For detailed reservation settings, consult the Cisco IOS documentation.

RSVP Admission Control
• RSVP has two tasks:

– Determine if there are enough available resources
– Determine if the application in question is allowed
access to these resources
• RSVP-enabled devices keep track of existing
reservations locally
• RSVP-enabled devices can offload the
authorization part of admission control to
central servers (COPS)
A RSVP-enabled router therefore needs to perform two tasks:

n The router needs to determine whether there are currently available resources,
which can be used to satisfy the reservation request.
n The router needs to be able to authorize an application to make the reservation
request (admission control).
The first task can be performed by keeping track of existing reservations, and of
total reservable capacity locally on each device. If a reservation request exceeds
the locally available reservable resources, the reservation request is denied.
Authorization of reservations could be performed locally, but such an approach
would not scale to more than a few devices. Fortunately, there is a standardized,
centralized framework for policy networking, which includes authorization within
admission control. This framework is based on a set of services and protocols
called the Common Open Policy Service (COPS).

Common Open Policy Service
Local Remote Admission Local

Admission Control Admission
Control Control
Policy Enforcement
Point (PEP)
request
reply
Policy Decision
Point (PDP)
• COPS allows a more centralized approach to

building RSVP enabled networks (more scalable)
• COPS provides additional control over who can
reserve what
Common Open Policy Service (COPS) is an open framework designed for

management in policy networking. COPS provides a service to network devices
and implements management protocols, which enable scalable provisioning of
Quality of Service policies in a network.
COPS is designed so that it provides a centrally managed, but distributed system
for configuring network devices according to centralized policy decisions. In the
case of RSVP, COPS provides centralized databases, which network devices
query for reservation/admission control information. RSVP-enabled devices
therefore need no locally stored configuration, but receive this information in real-
time from the appropriate COPS server. COPS, therefore, scales QoS
provisioning, and enables a device-independent QoS policy throughout the network.
COPS defines the following types of policy services:
n The Policy Enforcement Point (PEP) is the device that enforces network
policy (a router performing RSVP admission control, a firewall filtering traffic).
n The Policy Decision Point (PDP) is the device that stores policy information
and makes it available to the PEP devices.

Configuring RSVP for COPS
ip rsvp policy local acl Reject Message

Process Yes Yes Send an error
Reject?
Locally? message to the
source
No No
ip rsvp policy local
ip rsvp policy local local-override
Default
Yes Local Yes
Local
Override?
Policy?
No No
Process Ask Yes

Reject?
Remotely? PDP
No No
Process
Message
Default Yes Yes
Default
Remote
Reject?
Policy?
No
No
The figure shows the flowchart used to consult either the local policy settings, or
the COPS service. Both the local policy and the COPS service can be used
simultaneously on the same router. Individual COPS commands are also presented
in the flowchart, next to the functions they enable.
The admission process in policy networking proceeds as follows for locally
processed messages:
n The router receives a PATH or RESV message and first tries to adjudicate it
locally (that is, without referring to the policy server). If the router has been
configured to adjudicate specific access control lists (ACLs) locally and the
message matches one of those lists, the policy module of the router applies the
operators with which it had been configured. Otherwise, policy processing
continues.
n For each message rejected by the operators, the router sends an error
message to the sender and removes the PATH or RESV message from the
database. If the message is not rejected, policy processing continues.
n If the local override flag is set for this entry, the message is immediately
accepted with the specified policy operators. Otherwise, policy processing
continues.

Configuring RSVP for COPS
(cont.)
Reject Message
Process Yes Yes Send an error
Reject?
Locally? message to the
source
No No
Default
Yes Local Yes
Local
Override?
Policy?
No No
ip rsvp policy cops acl servers
Process Ask Yes

Reject?
Remotely? PDP
No No
ip rsvp policy cops servers
Process
Message
Default Yes Yes
Default
Remote
Reject?
Policy?
ip rsvp policy default-reject
No
No
If policy decisions are offloaded to a policy server, policy processing continues as

follows:
n If the message does not match any ACL configured for local policy, the router
applies the default local policy. However, if no default local policy has been
configured, the message is directed toward remote policy processing.
n If the router has been configured with specific ACLs against specific policy
servers (more specifically, PDPs), and the message matches one of these
ACLs, the router sends that message to the specific PDP for adjudication.
Otherwise, policy processing continues.
n If the PDP specifies a “reject” decision, the message is discarded and an error
message is sent back to the sender, indicating this condition. If the PDP
specifies an “accept” decision, the message is accepted and processed using
normal RSVP processing rules.
n If the message does not match any ACL configured for specific PDPs, the
router applies the default PDP configuration. If a default COPS configuration
has been entered, policy processing continues. Otherwise, the message is
considered to be unmatched.
n If the default policy decision for unmatched messages is to reject, the message
is immediately discarded and an ERROR message is sent to the sender
indicating this condition. Otherwise, the message is accepted and processed
using normal RSVP processing rules.
Whenever a request for adjudication (of any sort) is sent to a PDP, a 30-second
timer associated with the PATH or RESV message is started. If the timer runs out

before the PDP replies to the request, the PDP is assumed to be down and the
request is given to the default policy.

RSVP
Example
interface Serial0/0
bandwidth 128
ip address 10.10.3.33 255.255.255.252
encapsulation ppp
fair-queue 64 256 10
ip rsvp bandwidth 80
interface Serial0/0
bandwidth 256
ip address 10.5.8.65 255.255.255.252
encapsulation ppp
The figure shows a basic example of RSVP configuration in Cisco IOS routers.
The two routers in the figure are both configured for RSVP, and both utilize WFQ
to guarantee bandwidth to RSVP flows in RSVP-reserved queues. Different
maximum reservable bandwidths are allocated, based on the real bandwidth of the
link.

RSVP with COPS
Example
COPS
COPS (PDP)
(PEP)
interface Serial0/0
bandwidth 2048
ip address 10.1.1.1 255.255.255.252
encapsulation ppp
!
ip rsvp policy cops 100 servers 10.100.1.1 10.101.1.1
ip rsvp policy default-reject
ip rsvp policy cops minimal
ip rsvp policy cops timeout 600
ip rsvp policy cops report-all
!
access-list 100 permit udp any any
This figure shows a COPS-enabled RSVP configuration. The RSVP interface

configuration does not change, and COPS parameters are defined with the ip rsvp
policy commands. In this example, the COPS PDP adjudicates all UDP traffic
reservations.

RSVP
Router#
show ip rsvp installed [detail]
• Lists installed reservations per interface

Router#show
Router#show ip
ip rsvp
rsvp installed
installed
RSVP:Ethernet2/1
RSVP:Ethernet2/1
BPS
BPS To
To From
From Protoc
Protoc DPort
DPort Sport
Sport Weight
Conversation
Conversation
44K
44K 145.20.0.202
145.20.0.202 145.10.0.201
145.10.0.201 UDP 1000 1000 0 264
264
44K
44K 145.20.0.202
145.20.0.202 145.10.0.201
145.10.0.201 UDP 1001
1001 1001
1001 13
13 266
266
98K
98K 145.20.0.202
145.20.0.202 145.10.0.201
145.10.0.201 UDP
UDP 1002
1002 1002
1002 66 265
265
1K
1K 145.20.0.202
145.20.0.202 145.10.0.201
145.10.0.201 UDP
UDP 10
10 10
10 00 264
264
RSVP:Serial3/0
RSVP:Serial3/0 has
has no
no installed
installed reservations
reservations
The show ip rsvp installed command shows all active conversations over an
RSVP-enabled path, which has resource reservations installed. The actual
reserved bandwidth is shown, along with the session parameters (endpoints and
applications).

RSVP
Router#
show ip rsvp installed [detail] [interface]
Router#show
Router#show ip
ip rsvp
rsvp installed
installed detail
detail
RSVP:Ethernet2/1
RSVP:Ethernet2/1 has
has the
the following
following installed
installed reservations
reservations
RSVP
RSVP Reservation.
Reservation. Destination
Destination is
is 145.20.0.202,
145.20.0.202, Source
Source is
is 145.10.0.201,
145.10.0.201,
Protocol
Protocol is
is UDP,
UDP, Destination
Destination port
port is
is 1000,
1000, Source
Source port
port is
is 1000
1000
Reserved
Reserved bandwidth:44K
bandwidth:44K bits/sec,
bits/sec, Maximum
Maximum burst:1K
burst:1K bytes,
bytes, Peak
Peak rate:
rate: 44K
44K bits/sec
bits/sec
QoS
QoS provider
provider for
for this
this flow:WFQ.
flow:WFQ. Conversation
Conversation number:264.
number:264. Weight:
Weight:00 (PQ)
(PQ)
Conversation supports 1 reservations
Data
Data given
given reserved
reserved service:316
service:316 packets
packets (15800
(15800 bytes)
bytes)
Data
Data given
given best-effort
best-effort service:0
service:0 packets
packets (0
(0 bytes)
bytes)
Reserved
Reserved traffic
traffic classified
classified for
for 104
104 seconds
seconds
Long-term
Long-term average
average bitrate
bitrate (bits/sec):1212
(bits/sec):1212 reserved,
reserved, 0M
0M best-effort
best-effort
RSVP
RSVP Reservation. Destination is 145.20.0.202, Source
Reservation. Destination is 145.20.0.202, Source is
is 145.10.0.201,
145.10.0.201,
Protocol
Protocol is
is UDP,
UDP, Destination
Destination port
port is
is 1001,
1001, Source
Source port
port is
is 1001
1001
Reserved
Reserved bandwidth:44K
bandwidth:44K bits/sec,
bits/sec, Maximum
Maximum burst:3K
burst:3K bytes,
bytes, Peak
Peak rate:
rate: 44K
44K bits/sec
bits/sec
QoS
QoS provider
provider for
for this
this flow:WFQ.
flow:WFQ. Conversation
Conversation number:266.
number:266. Weight: 13
Weight:13
Conversation
Data
Data given
given reserved
reserved service:9
service:9 packets
packets (450
(450 bytes)
bytes)
Data
Data given
given best-effort
best-effort service:0
service:0 packets
packets (0
(0 bytes)
bytes)
Reserved
Reserved traffic
traffic classified
classified for
for 107
107 seconds
seconds
Long-term
Long-term average
average bitrate
bitrate (bits/sec):33
(bits/sec):33 reserved,
reserved, 0M0M best-effort
best-effort
...
...
The show ip rsvp installed detail command shows detailed information about
active conversations currently installe d in the RSVP reservation table. Detailed
timing and accounting for every conversation is displayed, together with the QoS
mechanism used to provide service guarantees.

RSVP
Router(config)#
show ip rsvp reservation [detail]
• List RSVP reservations
Router(config)#
show ip rsvp request [detail]
• List pending RSVP requests
The show ip rsvp reservation command lists all existing RSVP reservations over
an interface. The show ip rsvp request command shows all pending RSVP
requests that have no fixed reservation in place.

RSVP with COPS
Router#
show ip rsvp policy [{cops | local} [acl]]
• Lists all policies

Router#show
Router#show ip
ip rsvp
rsvp policy
policy cops
cops
COPS/RSVP
COPS/RSVP settings:
settings:
Generate
Generate reports for all decisions
Do
Do not
not query
query PDP
PDP for
for error
error messages
messages
COPS/RSVP
COPS/RSVP entry.
entry. ACLs:
ACLs: 100
100
PDPs: 10.100.1.1 10.101.1.1
PDPs: 10.100.1.1 10.101.1.1
Current
Current state:
state: Connected
Connected
Currently
Currently connected
connected to
to PDP
PDP 10.100.1.1,
10.100.1.1, port
port 00
COPS/RSVP
COPS/RSVP entry.
entry. ACLs:
ACLs: 101
101
PDPs:
PDPs: 10.102.1.1
10.102.1.1
Current
Current state:
state: In
In reconnect
reconnect loop
loop wait
wait
Reconnect
Reconnect timer
timer is
is 960
960 seconds
seconds
The show ip rsvp policy command shows the policy settings, whether the policy
is locally defined or policy decisions are offloaded to the COPS server. The output
shows associations between flow specifications and associated COPS servers,
which perform admission control for those flows. This command is used to verify
connectivity to COPS services and the associations between the local device and a
COPS server.

RSVP with COPS
Router#
show cops servers
• Lists all COPS servers

Router#show
Router#show cops
cops servers
servers
COPS
COPS SERVER:
SERVER: Address:
Address: 10.100.1.1.
10.100.1.1 . Port:
Port: 3288.
3288. State: 0. Keepalive: 120 sec
Number
Number of
of clients:
clients: 1.
1. Number
Number of
of sessions:
sessions: 1.
1.
COPS
COPS CLIENT:
CLIENT: Client
Client type:
type: 1.
1. State:
State: 0.
0.
The show cops servers command displays the state of all configured COPS
servers.

Summary
n RSVP enables end-stations to signal QoS requirements to the network.
n RSVP does not provide any guarantees; router QoS mechanisms do.
n RSVP does not necessarily require an end-to-end RSVP-aware path.
n COPS provides scalable QoS provisioning.
Lesson Review
1. What is RSVP used for?
2. Does RSVP provide QoS guarantees?
3. What QoS mechanism should be used to provide QoS guarantees to RSVP
reservations?
4. What are the benefits of using COPS with RSVP?

Subnet Bandwidth Management
Overview
This section describes a mechanism that is used on shared media where more
complex reservation is required. SBM protocol is used between RSVP devices
reachable over the same subnet.
Objectives
n Describe Subnet Bandwidth Management (SBM).
n Configure SBM.
n Monitor and troubleshoot RSVP with SBM.

• RSVP manages unidirectional reservation of

resources
• RSVP on shared media can result in
oversubscription
• SBM is an add-on to RSVP on shared media
to prevent oversubscription
RSVP is used to manage reservation of resources unidirectionally, between Layer-

3 hops. On a shared medium, many Layer-3 hops can be active between many
routers on the shared segment. The shared medium is shared between all routers,
therefore the routers need to keep track about all routers’ usage of the shared
medium, in order to maintain a consistent picture of available bandwidth on that
medium. If routers were independently reserving bandwidth over a shared medium,
oversubscription would occur if each router had full access to the medium
bandwidth.
Subnet Bandwidth Management (SBM) is an add-on to the RSVP protocol, which
provides arbitration of bandwidth allocation on a shared medium to prevent RSVP-
caused oversubscription. SBM specifies a signaling method and protocol for LAN-
based admission control for RSVP flows. SBM allows RSVP-enabled routers and
Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVP-
enabled data flows. The SBM signaling method is similar to that of RSVP itself.

Without SBM
Ethernet bandwidth 10Mbps

7.5 Mbps is reservable
Reserve 6 Mbps
Mbps
eserve 6
R
6 Mbps booked
0
7.5 Mbps free
1.5
Ethernet
Reserv
e 7 Mb
ps
Reserve 7 Mbps
7 Mbps booked
0
7.5 Mbps
512 kbps free
• Both routers are within the 75% reservable limit

• Total reserved bandwidth is 13 Mbps (above Ethernet bandwidth)
• Ethernet should be treated carefully because it is impossible to
achieve 100% utilization (collisions; depending on implementation)
The figure shows a possible scenario of RSVP oversubscription on a shared

segment. Both right-hand routers think of the Ethernet segment as a link with a
bandwidth of 10 Mbps. Based on the 75% rule, by default 7.5 Mbps of that
bandwidth is reservable. The upper router reserves 6 Mbps of the reservable
bandwidth, and the bottom router reserves 7 Mbps of the reservable bandwidth.
Obviously, the combined reserved bandwidth exceeds the Ethernet media
bandwidth and results in an unwanted oversubscription.

With SBM
Reserve 6 Mbps
bps
e 6M
erv
Reserve 6 Mbps Res
6 Mbps booked
0
7.5 Mbps free
1.5
Re
6 Mbps booked
0 ser
ve
7.5 Mbps free
1.5 6 Mb
ps
Erro
One of the routers on the r Reserve 7 Mbps
segment is elected to be the
Designated Subnet 7 Mbps booked
0
Bandwidth Manager (DSBM) 7.5 Mbps
512 kbps free
The shared media is
effectively transformed into a
star of point-to-point links
SBM’s solution to the problem is to introduce a Designated Subnet Bandwidth

Manager (DSBM) router, which tracks all reservations over a shared segment.
The DSBM is one of the existing subnet routers, designated to be the DSBM via
an election process on the subnet. When a DSBM is used, the shared medium is
effectively transformed into a virtual mesh of point-to-point links.
When a DSBM client sends or forwards an RSVP PATH message over an
interface attached to a managed segment, it sends the PATH message to the
segment’s DSBM instead of to the RSVP session destination address, as is done in
conventional RSVP processing. As part of its message processing procedure, the
DSBM builds and maintains a PATH state for the session and notes the previous
Layer 2/Layer 3 hop from which it received the PATH message. After processing
the PATH message, the DSBM forwards it toward its destination address.
n The DSBM receives the RSVP reservation request (RSVP RESV) message
and processes it in a manner similar to the way RSVP itself handles
reservation request processing, basing the outcome on available bandwidth.
The procedure is as follows:
n If it cannot grant the request because of lack of resources, the DSBM returns
a RESVERR message to the requester.
n If sufficient resources are available and the DSBM can grant the reservation
request, it forwards the RESV message toward the PHOP(s) using the local
PATH state for the session.

DSBM Election
• DSBM is elected based on the DSBM priority

• Each DSBM candidate advertises its priority
in the range from 64 to 128
• The candidate with the highest priority is
elected to be the DSBM
• RSVP enabled devices can participate in
Subnet Bandwidth Management without
being DSBM candidates
On a LAN segment configured for SBM, a DSBM is elected based on each

router’s DSBM-candidate priority. All RSVP messages of participating routers are
sent to the DSBM to adjudicate the reservation requests. Such a LAN segment is
called a managed segment in SBM terms.
Of all SBM-enabled routers on a segment, some or all routers are DSBM
candidates; that is, not all routers need to be configured as DSBM candidates to
perform SBM-assisted RSVP. A DSBM is chosen among the candidates based on
the configured DSBM priority, which ranges from 64 to 128, the latter being the
highest priority.

Configuring DSBM
Router(config-if)#
ip rsvp dsbm candidate priority
• Configures the router to bid in the election of the DSBM

• Default priority is 64
Router(config)#
ip rsvp
rsvp dsbm
dsbm non-resv-send-limit {burst | max-unit | min-
unit | peak | rate} value
• The NonResvSendLimit object specifies how much traffic can be

sent onto a managed segment without a valid RSVP reservation
• All values are unlimited by default
The ip rsvp dsbm candidate interface command specifies this router as a

DSBM candidate on the attached LAN network. A priority used in the DSBM
election process is assigned, the default being the lowest priority of 64.
The ip rsvp dsbm non-resv-send-limit command limits the amount of traffic,
which can be sent to a managed segment without an RSVP reservation. By
default, any amount of traffic can be sent to the segment. This command should be
used in a network, where RSVP is predominantly used for signaling to allow some
non-RSVP traffic to transit shared LAN segments.

SBM
Example
interface
Ethernet0/0
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
255.255.255.0
ip
ip rsvp
rsvp bandwidth
bandwidth 7500
7500 7500
7500
ip
ip rsvp
rsvp dsbm
dsbm candidate 100
ip
ip rsvp
rsvp dsbm
dsbm non-resv-send-limit rate 100
ip
ip rsvp
rsvp dsbm
dsbm non-resv-send-limit
non-resv-send-limit burst
burst 1000
1000
ip
ip rsvp
rsvp dsbm
dsbm non-resv-send-limit peak 100
!!
The figure shows an interface configuration example, where SBM is used to signal
RSVP across a shared LAN segment. The local router is configured as a DSBM
candidate, and RSVP with SBM is enabled using the ip rsvp bandwidth
command. In this example, non-reserved traffic is limited to a mere 100 Kbps, with
one-megabyte bursts allowed. Such an example configuration could be used in a
fully RSVP-enabled network, where some bandwidth needs to be provisioned for
network control (routing protocols, time management, and so forth).

SBM
Router#
show ip sbm [detail]
• Lists interfaces where SBM is active
• The detailed option displays detailed information about local
configuration and the DSBM configuration
Router#show
Router#show ipip rsvp
rsvp sbm
sbm
Interface
Interface DSBM
DSBM Addr
Addr DSBM
DSBM Priority
Priority DSBM
DSBM Candidate
Candidate My
My Priority
Priority
Et0/0
Et0/0 10.1.1.1
10.1.1.1 100
100 yes
yes 100
100
Et0/1
Et0/1 10.1.2.1
10.1.2.1 100
100 yes
yes 100
100
Router#show
Router#show ipip rsvp
rsvp sbm
sbm detail
detail
Interface:Ethernet
Interface:Ethernet0/00/0
Local Configuration
Local Configuration Current
Current DSBM
DSBM
IP
IP Address:10.1.1.1
Address:10.1.1.1 IP
IP Address:10.1.1.1
Address:10.1.1.1
DSBM
DSBM candidate:yes
candidate:yes II Am
Am DSBM:yes
DSBM:yes
Priority:100
Priority:100 Priority: 100
Priority:100
Non
Non Resv
Resv Send
Send Limit
Limit Non
Non Resv
Resv Send
Send Limit
Limit
Rate:100 Kbytes/sec
Rate:100 Kbytes/sec Rate:100
Rate:100 Kbytes/sec
Kbytes/sec
Burst:1000
Burst:1000 Kbytes Burst:1000
Burst:1000 Kbytes
Kbytes
Peak:100
Peak:100 Kbytes/sec
Kbytes/sec Peak:100
Peak:100 Kbytes/sec
Kbytes/sec
Min
Min Unit:unlimited
Unit:unlimited Min
Min Unit:unlimited
Unit:unlimited
Max
Max Unit:unlimited
Unit:unlimited Max
Max Unit:unlimited
Unit:unlimited
The show ip sbm command shows per-interface SBM parameters, displaying

other SBM-enabled routers on the attached segment. The show ip sbm detail
command also shows the non-reserved sending limits of discovered neighbors.
In this output, all routers on the segment have the same DSBM priority. In that
case, the tiebreaker is a router’s IP address on that segment, and the router with
the highest IP address will win the election.

Summary
n SBM enables RSVP to run over shared LAN segments.
n DSBM routers provide shared LAN adjudication of RSVP-reservations.
n SBM can limit the amount of non-RSVP traffic sent into a network.
Lesson Review
1. What is the purpose of Subnet Bandwidth Management?
2. How do routers on a common subnet communicate reservation requests?
3. What is a DSBM?
4. How do routers elect a DSBM?

Summary
n RSVP enables end-stations to signal QoS requirements to the network
n RSVP does not provide any guarantees; router QoS mechanisms do.
n SBM enables RSVP to run over shared LAN segments.

Resource Reservation Protocol (RSVP)
Question: What is RSVP used for?
Answer: RSVP is used by applications to signal their QoS requirements to the
network and to set up reservations along the application path.
Question: Does RSVP provide QoS guarantees?
Answer: No, RSVP is only used for signaling. Per-hop mechanisms, such as
WFQ, are used to guarantee a service level to a RSVP-enabled application.
Question: What QoS mechanism should be used to provide QoS guarantees to
RSVP reservations?
Answer: Usually, WFQ and CB-WFQ are used to provide per-hop guarantees.
Question: What are the benefits of using COPS with RSVP?
Answer: Using COPS-compliant policy management software enables scaling of
RSVP-enabled networks by offloading part of the admission control functions to
a centralized database.

Question: What is the purpose of Subnet Bandwidth Management?
Answer: The purpose of SBM is to prevent oversubscription of a shared segment
by introducing an arbiter, which keeps tracks of all reservations over a shared
segment.
Question: How do routers on a common subnet communicate reservation
requests?
Answer: Routers communicate reservation requests by forwarding all RSVP
messages to the arbiter (the DSBM).
Question: What is a DSBM?
Answer: The DSBM (Designated Subnet Bandwidth Manager) is an elected layer-
3 device on a shared segment, which keeps tracks of all reservations.
Question: How do routers elect a DSBM?
Answer: Routers elect a DSBM with a priority-based election system. Router IP
address is the final tiebreaker.

8
Modular QoS CLI

Classification
Overview
This chapter focuses on the classification element of the modular QoS command-
line interface.
n Introduction to Modular QoS CLI
n Classification Options
n Network Based Application Recognition (NBAR)
Objectives
n Describe the classification element of the Modular QoS CLI
n Describe and configure all currently supported classification options within the
MQC
n Understand Network-based Application Recognition (NBAR)
n Monitor and troubleshoot class maps
Introduction to Modular QoS CLI
Objectives
n Describe the MQC concepts and structure
n Configure class maps
8-2 IP QoS—Modular QoS CLI Classification Copyright  2001, Cisco Systems, Inc.
Modular QoS CLI
• The Modular QoS CLI (MQC) provides a

modular approach to configuration of QoS
mechanisms
• Classification is configured separately from
the QoS service policy
• MQC also provides modularity to
implementation of QoS mechanisms in the
Cisco IOS:
– New QoS mechanisms can reuse old classification
options
– New QoS classification options can also be used
by older QoS mechanisms
© 2001, Cisco Systems, Inc. IP QoS - Modular QoS CLI Classification -5
The Quality of Service mechanisms that have been added to the Cisco IOS all had
their own set of classification options. For example:
n Committed Access Rate (CAR) can classify packets by using:
– Access lists
– QoS group
– DSCP
– Rate limit access list
n Traffic Shaping (GTS) can classify packets by using access lists
n Priority Queuing (PQ) and Custom Queuing (CQ) can classify packets by
using:
– Access lists
– Packets size
– Fragment
– TCP or UDP port number
The Modular Quality of Service Command Line Interface (MQC) was introduced
to allow any supported classification to be used with any QoS mechanism.
The separation of classification from the QoS mechanism allows new IOS versions
to introduce new QoS mechanisms and reuse all available classification options. On
the other hand, old QoS mechanisms can benefit from new classification options.
Another important benefit of the MQC is the reusability of configuration. MQC
allows the same QoS policy to be applied to multiple interfaces. CAR, for example,
Copyright  2001, Cisco Systems, Inc. IP QoS—Modular QoS CLI Classification 8-3
required entire configurations to be copy-pasted between interfaces and modifying
configurations was tiresome.
The Modular QoS CLI, therefore, is a consolidation of all the QoS mechanisms
that have so far only been available as standalone mechanisms.
This module focuses on the classification element of the Modular QoS CLI.
Separation of Classification
Classification Traffic Policy
packet Class 1? CB-WFQ
Class 2? CB-LLQ Interface

or
Forwarding
Class N? CB-Policing
Implementing QoS by using the MQC consists of three steps:

Step 1 Configuring classification by using the class-map command
Step 2 Configuring traffic policy by associa ting the traffic class with one or more QOS
features using the policy-map command
Step 3 Attaching the traffic policy to inbound or outbound traffic on interfaces,
subinterfaces or virtual circuits by using the service-policy command
Class maps are used to create classification templates that are later used in policy
maps where QoS mechanisms are bound to classes.
Routers can be configured with a large number of class maps (currently limited to
256). Each traffic policy, however, may support a limited number of classes (for
example: Class-based Weighted Fair Queuing and Class-based Low-latency
Queuing are limited to 64 classes).
The figure illustrates an implementation where traffic is classified into N classes.
Each class is handled by one or more QoS mechanisms (for example, Class-based
Weighted Fair Queuing, Class-based Low-latency Queuing, Class-based Policing).
Class Maps
• Each class is identified using a Class Map

• Each Class Map is identified by a case-
sensitive name
• Class maps can operate in two modes
– Match All – all conditions have to succeed
– Match Any – at least one condition must succeed
• The default mode is Match all
A class map is created using the class-map global configuration command. Class
maps are identified by case-sensitive names. Each class map contains one or more
conditions that determine if the packet belongs to the class.
There are two ways of processing conditions when there is more than one
condition in a class map:
n Match all—all conditions have to be met to bind a packet to the class
n Match any—at least one condition has to be met to bind the packet to the
class
The default match strategy of class maps is “Match all”.
Classification using Class Maps
Match all Yes

conditions? Match
Match all No
Class Map Match

Mode?
name
Match any Yes
Match at
No
least one No Match
condition?
The figure illustrates the full process of determining if a packet belongs to a class
(match) or not (no match).
The process goes through the list of conditions and:
n Returns a “match” result if one of the conditions is met and the match-any
strategy is used
n Returns a “match” result if all conditions are met and the match-all strategy is
used
n Otherwise it returns “no match”
Classification Using Match All
Strategy
Class Map Yes More No
Conditions? Match
name
Match Yes
Condition?
No
No Match
• Match-all requires all conditions to return a

positive answer
• If one condition is not met the class map will
return a “no match” result
© 2001, Cisco Systems, Inc. IP QoS - Modular QoS CLI Classification-9
The figure illustrates a simplified flowchart for the match-all strategy.

The processing of a match-all class map can be divided into the following steps:
Step 1 Evaluate a condition
Step 2 Return a “no match” result and stop processing the class map if the condition is
not met
Step 3 Go to Step 1 if there are more conditions
Step 4 Returns a “match” result
Classification Using Match Any
Strategy
Class Map
Match
name
Match Yes
Condition?
No More No
Conditions? No Match
Yes
• Match-any requires at least one condition to

return a positive answer
• If no condition is met the class map will
return a “no match” result
The figure illustrates a simplified flowchart for the match-any strategy.

The processing of a match-all class map can be divided into the following steps:
Step 1 Evaluate a condition
Step 2 Return a “match” result and stop processing the class map if the condition is met
Step 3 Go to Step 1 if there are more conditions
Step 4 Return a “no match” result
Classification Options
The main classification options include

the following:
• Access list (all access lists are available)
• IP Precedence value
• IP DSCP value
• QoS group number
• MPLS experimental bits
• Protocol (including NBAR)
Class maps can classify packets by using the following classification tools:
n Access lists for any protocol can be used within the class-map configuration
mode. The Modular QoS CLI can be used for other protocols, not only IP.
n IP packets can be classified directly by specifying IP precedence values.
n IP packets can also be classified directly by specifying IP DSCP
(differentiated services code point) values. DiffServ enabled networks can
have up to 64 classes if DSCP is used to mark packets.
n A QoS group parameter can be used to classify packets in situations where up
to 100 classes are needed or the QoS group parameter is used as an
intermediary marker (for example, MPLS to QoS group translation on input
and QoS group to class translation on output).
n Packets can also be matched based on the value in the experimental bits of the
MPLS header of labeled packets.
n Classification can be performed by identifying a Layer-3 or Layer-4 protocol.
Advanced classification is also available by using the Network-based
Application Recognition (NBAR) tool where dynamic protocols are identified
by inspecting higher-layer information.
Other Classification Options
The other classification options include

the following:
• Using another Class Map
• Frame Relay DE bit
• IEEE 802.1Q/ISL CoS/Priority values
• Input interface
• Source MAC address
• Destination MAC address
• RTP (UDP) port range
• Any packet
There are many other classification options:

n Another class map can used to implement template-based configurations
n Packets can be matched based on the underlying Frame Relay DE bit
n Packets can be matched based on the information contained in the three Class
of Service bits (when using IEEE 802.1Q encapsulation) or Priority bits (when
using the ISL encapsulation)
n Packets can be classified according to the input interface
n Packets can be matched based on their source or destination MAC addresses
n RTP (real-time protocol) packets can be matched based on a range of UDP
port numbers
n MQC can also be used to implement a QoS mechanism for all traffic in which
case classification will put all packets into one class
Configuring Class Maps
router(config)#
class-map [{match-all | match-any}] name
name
• Enter the class-map configuration mode

• Specify the matching strategy
• Match-all is the default matching strategy
router(config-cmap)#
match condition
• Use at least one condition to match packets

description description
• It is recommended to use descriptions in large and complex

configuration
• The description has no operational meaning
Use the class-map global configuration command to create a class map and enter
the class map configuration mode. A class map is identified by a case-sensitive
name; therefore, all subsequent references to the class map must use exactly the
same name.
At least one match command should be used within the class-map configuration
mode (match none is the default).
The description command is used for documenting a comment about the
class-map.
Configuring Class Maps
rename new-name
• Complex class-maps can easily be renamed by using

the rename class-map command
• All references to the class map are also renamed
Large implementations may use a number of class maps and there are many
references to the class maps. Renaming a class map would normally require a
change to all references to the class map as well. The rename command can be
used to rename class maps and all references to it.
Class Map Example
class-map
class-map match-any
match-any Test1
Test1
match
match access-group
access-group 101
match
match access-group
access-group 102
class-map
class-map match-all
match-all Test2
Test2
match
match access-group
access-group 101
match
match access-group
access-group 102
• This example simply illustrates how class-

maps are configured
• Class-maps on their own have no function
The example shows two class maps with two conditions:

n Class map Test1 matches all packets that are permitted by at least one of the
access lists
n Class map Test2 matches only those packets that are permitted by both
access lists
Class Maps
router#
show class-map [class-map]
• Lists all class-maps or the selected class-map

Router#show
Router#show class-map
class-map
Class
Class Map
Map match-all
match-all Test2
Test2 (id
(id 0)
0)
Match access-group
access-group 101
101
Match access-group
access-group 102
102
Class
Class Map
Map match-any
match-any Test1 (id 1)
Match access-group
access-group 101
101
Match access-group
access-group 102
102
Router#
Router#
n The show class-map command lists all class maps with their match
statements
n The show class-map command with a name of a class map displays the
configuration of the selected class map
Summary
The Modular QoS CLI (MQC) is used to separate the classification from the QoS
service policy. A unified classification tool can be used by multiple different QoS
mechanisms.
The classification is configured using class maps, which are used within policy
maps to apply QoS mechanisms to classes.
Review Questions
n What are the benefits of the Modular QoS CLI?
n Which two matching strategies do class maps support?
n Which classification options do class maps support?
Objectives
n Describe and configure classification using access lists
n Describe and configure classification using the IP precedence
n Describe and configure classification using the DSCP
n Describe and configure classification using the QoS group
n Describe and configure classification using the MPLS experimental bits
n Describe and configure classification based on the input interface
n Describe and configure classification based on the source MAC address
n Describe and configure classification based on the destination MAC address
n Describe and configure classification based on IEEE 802.1Q/ISL CoS
n Describe and configure classification using another class map, negation or any
keyword
n Describe and configure classification based on the Frame Relay DE bit
n Describe and configure classification based on RTP port
Classification Using
Access Lists
• Access lists are the oldest classification tool

that has been used with QoS mechanisms
• Class Maps support all types of access lists
• Class Maps are multi protocol
• Class Maps can use named access lists and
numbered access lists (in the range from 1 to
2699) for all protocols
Access lists were originally used for filtering of inbound or outbound packets on
interfaces. They were later reused for filtering of routing updates and also for
classification with early QoS tools (for example, Priority Queuing, Custom Queuing
and Traffic Shaping).
Access lists are still one of the most powerful classification tools. Class maps can
use any type of access list (not only IP access lists).
Access lists, on the other hand, also have a drawback. Compared to other
classification tools they are one of the most CPU-intensive. For this reason it is not
recommended that access lists for classification be used on high-speed links where
they could severely impact performance of routers. Access lists are typically used
on low-speed links at network edges where packets are classified and marked (for
example, with IP precedence). Classification in the core is done based on the IP
precedence value.
Configuring Classification Using
Access Lists
Router(config-cmap)#
match access-group {number | name
name name}
• Select an access list to be used for classification
class-map
class-map Telnet
Telnet
match
match access-group
access-group 100
!!
class-map
class-map IPX_Printers
IPX_Printers
match
match access-group
access-group IPX
!!
access-list
access-list 100
100 permit
permit tcp
tcp any
any any
any eq 23
access-list
access-list 100
100 permit
permit tcp
tcp any
any eq
eq 23
23 any
any
!!
ipx
ipx access-list extended IPX
permit
permit netbios any
any
!!
Keep All Graphics Inside This Box
© 2001, Cisco Systems, Inc. www.cisco.com Course acronym 2.0—Chapter#-22
Use the match access-group command to attach an access list to a class-map.

The example in the figure shows how numbered or named access list can be used
for classification.
IP Precedence
match ip precedence precedence [prec [prec [prec]]]
• Select up to four IP precedence values or names

• All packets marked with one of the selected IP
precedence values are matched by this class map
IP Precedence IP Precedence class-map
class-map VoIP
match
match ip
ip precedence
precedence 55
Value Name !!
0 routine class-map
class-map Gold
1 priority match
match ip
ip precedence
precedence 33 44
!!
2 immediate class-map Silver
class-map
3 flash match
match ip
ip precedence
precedence 11 22
4 flash-override !!
class-map
class-map Bronze
5 critical
match
match ip
ip precedence
precedence routine
routine
6 internet !!
7 network
A much faster method of classification is by matching the IP precedence. Up to

four IP precedence values or names can be used to classify packets based on the
IP precedence field in the IP header.
The figure contains a mapping between IP precedence values and names. The
running configuration, however, only shows IP precedence values (not names).
DSCP
match ip dscp dscp [dscp ...]
• Select up to eight DSCP values or names

• All packets marked with one of the selected DSCP
values are matched by this class map
DSCP DSCP Class DSCP DSCP Class
Value Name Value Name
0 (000000) default 10 (001010) af11
1 (001000) cs1 12 (001100) af12
2 (010000) cs2 14 (001110) af13
3 (011000) cs3 18 (010010) af21
4 (100000) cs4 20 (010100) af22
5 (101000) cs5 22 (010110) af23
6 (110000) cs6 26 (011010) af31
7 (111000) cs7 28 (011100) af32
46 (101110) ef 30 (011110) af33
34 (100010) af41
36 (100100) af42
38 (100110) af43
IP packets can also be classified based on the IP DSCP field. A QoS design can
be based on IP precedence marking or DSCP marking. DSCP marking can include
backward compatibility with IP precedence by using the Class Selector (CS)
values (most significant three bits of the DSCP value).
A sample design that includes backward compatibility would use the following
values to mark packets belonging to class Gold, which is guaranteed Assured
Forwarding (AF) Per-hop Behavior (PHB):
n af11 marks low-drop packets
n af12 marks medium-drop packets
n af13 marks high-drop packets
n cs4 marks low-drop packets (for backward compatibility with IP precedence
4)
n cs3 marks high-drop packets (for backward compatibility with IP precedence
5)
A sample configuration on the next page shows implementation of a similar design.
DSCP
class-map
class-map Voice
Voice
match ip dscp ef
!!
class-map
class-map Gold
Gold
match
match ip
ip dscp
dscp af11
af11 af12
af12 af13
af13 cs3
cs3 cs4
cs4
!!
class-map
class-map Silver
Silver
match
match ip
ip dscp
dscp af21
af21 af22
af22 af23
af23 cs1
cs1 cs2
cs2
!!
class-map
class-map Bronze
Bronze
match ip dscp af31 af32 af33
!!
class-map
class-map Best-effort
Best-effort
match ip
ip dscp
dscp default
default
!!
The figure illustrates implementation of a design with five classes:

n Voice, which is identified by DSCP value ef, which looks like IP precedence
value 5 in non-DSCP compliant devices.
n Gold, which is identified by DSCP values af11, af12 and af13. The class is
also identified by IP precedence values 3 and 4.
n Silver, which is identified by DSCP values af21, af22 and af23. The class is
also identified by IP precedence values 1 and 2.
n Bronze , which is identified by DSCP values af31, af32 and af33.
n Best Effort, which is identified by the default DSCP value that is equal to the
default IP precedence value (0).
From a non-DSCP compliant device the design looks slightly different:
n Voice—IP precedence 5
n Gold—IP precedence 3 and 4
n Silver—IP precedence 1 and 2
n Best Effort—IP precedence 0
A DSCP-compliant device treats packets marked by a non-DSCP compliant
device according to the design.
A non-DSCP compliant device does not treat packets marked by a
DSCP-compliant device correctly:
n AF1 (001xx0) looks like IP precedence 1. Therefore, class Gold appears as
class Silver in a non-DSCP compliant device.
n AF2 (010xx0) looks like IP precedence 2. Therefore, class Silver correctly
appears as class Silver in a non-DSCP compliant device.
n AF3 (011xx0) looks like IP precedence 3. Therefore, class Bronze appears as
class Gold in a non-DSCP compliant device.
n EF (101110) looks like IP precedence 5, which is also used for voice in a non-
DSCP compliant device.
As can be seen from the example it is very important to understand the impact of
DSCP on non-DSCP compliant devices. A DiffServ-based QoS design should
include the impact of DSCP on parts of the networks where all routers are not
DSCP compliant.
The example shows that a network core, if upgraded to support DSCP, can
correctly handle packets classified by edge devices that have not yet been
upgraded.
QoS Group
match ip qos-group
qos-group qos-group
qos-group
• Select the QoS group identifying the class

• Allowed values are from 0 to 99
• All packets marked with the QoS group value are matched by
this class map
• The QoS group is a prameter local to the router; it has to be set
by some other QoS mechanism (CAR, PBR, CB-Marking, CB-
Policing, QPPB)
class-map
class-map QoS1
QoS1
match
match qos-group
qos-group 1
!!
class-map
class-map QoS2
QoS2
match
match qos-group
qos-group 2
!!
A QoS group is another marker with support for a large number of classes. Up to
100 classes can be configured by using the QoS group parameter. The main
drawback of QoS-group marking is that it has to be performed on every hop since
this parameter is not part of any header. The QoS group is an internal parameter in
the router and it is lost the moment a packet is sent.
The QoS group parameter can be used in situations where one parameter can be
seen on input, but not on output where another parameter has to be set. For
example:
n Match MPLS experimental bits on input and set QoS group based on the value
n Match QoS group on output and set IP DSCP based on the value
Matching on QoS group can also be used in combination with QoS Policy
Propagation through BGP (QPPB) where up to 100 classes are propagated by
BGP and marked by QoS group values on all BGP-enabled routers. Class maps
are then used to match on QoS group values.
match mpls experimental exp [exp ...]
• Select up to eight MPLS experimental values

• All MPLS labeled packets marked with the selected
MPLS experimental bits are matched by this class
map
class-map
class-map MPLS1
MPLS1
match
match mpls
mpls experimental
experimental 33 4
!
class-map
class-map MPLS2
MPLS2
match
match mpls
mpls experimental
experimental 11 2
!
Class maps can also be used in MPLS-enabled networks where all packets are
labeled. There are three experimental bits in the label header that are currently
being used for IP precedence. When an IP packet is labeled, the IP precedence
value is copied into MPLS experimental bits.
A transparent design can be created where class maps can match on both the IP
precedence value and the MPLS experimental bits:
class-map match-any Voice
match ip precedence 5
match mpls experimental 5
!
class-map match-any Gold
match ip precedence 3 4
match mpls experimental 3 4
!
class-map match-any Silver
match mpls experimental 1 2
!
class-map Best-effort
match ip precedence 0
match mpls experimental 0
!
Input Interface
match input-interface intf
• All packets received through the selected input

interface are matched by this class map
class-map
class-map match -any Ethernets
match-any
match
match input-interface
input-interface Ethernet0/0
Ethernet0/0
match
input-interface Ethernet0/1
Ethernet0/1
!!
class-map
class-map match -any FastEthernets
match-any FastEthernets
match
input-interface FastEthernet1/0
FastEthernet1/0
match
input-interface FastEthernet1/1
FastEthernet1/1
!!
class-map
class-map match -any Serials
match-any Serials
match
input-interface Serial2/0
Serial2/0
match
Serial2/1
match
Serial2/2
match input-interface Serial2/3
match input-interface Serial2/3
!!
A packet can also be classified based on the input interface.
MAC Addresses
match source-address mac mac-address
• Classifies packets based on the source MAC address

• This classification option can only be used on interfaces using MAC
addresses (e.g. Ethernet, FastEthernet)
match destination-address mac
mac mac-address
• Classifies packets based on the destination MAC address

• This classification option can only be used on interfaces using MAC
addresses (e.g. Ethernet, FastEthernet)
class-map
class-map RTR1_dst
RTR1_dst
match
match destination-address
destination-address mac
mac 00f0.64e2.2860
00f0.64e2.2860
!!
class-map
class-map RTR2_src
RTR2_src
match source-address mac
mac 00f0.64e2.3321
00f0.64e2.3321
!!
Classification can be done based on source or destination MAC addresses. This

type of classification is only possible on interfaces that use MAC addresses (for
example, Ethernet or FastEthernet).
It is especially useful in situations where packets from a certain device have to be
matched but the device does not have a static IP address (for example, DHCP-
derived IP address) or it has too many IP addresses.
802.1q or ISL CoS/Priority bits
match cos
cos cos [cos [cos [cos ]]]
• Select up to four CoS/Priority values

• Allowed values are 0 to 7
• This classification option can only be used on interfaces using
802.1Q or ISL encapsulation
class-map
class-map Strict-priority
Strict-priority
match
match cos
cos 5
!!
class-map
class-map High-priority
High-priority
match
match cos
cos 44 6 7
!!
class-map
class-map Low-priority
Low-priority
match
match cos
cos 00 11 2 3
!!
Routers can also match on the three Class of Service bits in 802.1Q header or
Priority bits in the ISL header. These bits can be used in a LAN-switched
environment to provide differentiated quality of service.
Special Options
match not condition
• The “not” keyword inverts the condition

match class-map class-map
• One class map can use another class map for classification
• Nested class maps allow generic template class maps to be
used in other class maps
match any
• The “any” keyword can be used to match all packets
There are some additional options that give extra power to class maps:
n Any condition can be negated by inserting the keyword not
n A class map can use another class map to match packets
n The any keyword can be used to match all packets.
Special Options
class-map
class-map Well-known-services
Well-known-services
match
match access-group
access-group 100
!!
Class-map
Class-map Unknown-services
Unknown-services
match
match not
not class-map
class-map Well-known-services
!!
Class-map
Class-map All-services
All-services
match
match any
any
!!
access-list
access-list 100
100 permit
permit tcp
tcp any
any any
any lt
lt 1024
access-list
access-list 100
100 permit
permit tcp
tcp any
any lt
lt 1024
1024 any
The example shows three class maps:

n Class map Well-known-services uses an access list to match all the packets
with the source or destination port number lower than 1024.
n Class map Unknown-services uses the first class map but negates the result.
The same could be achieved by using the same access list with a negation.
n Class map All-services actually matches all the packets.
Frame Relay DE Bit
match fr-de
• Use this command to match all frames with the

Frame Relay DE bit set
class-map
class-map FR_Out_of_Contract
FR_Out_of_Contract
match
match fr-de
!!
class-map
class-map FR_Within_Contract
FR_Within_Contract
match
match not
not fr-de
fr-de
!!
Class maps used on Frame Relay interfaces can classify packets based on the
setting of the Discard Eligibility (DE) bit.
The example illustrates how to classify packets that have the DE bit se (match
fr-de) and those that do not (match not fr-de).
a UDP Port Range
match ip rtp starting-port port-range
• Use this command to implement classification equal to IP RTP

Prioritization
• All UDP packets with source or destination port numbers within the
specified range are matched
• Range is between the starting-port (values from 2000 to 65535) and the
sum of the starting-port and the port-range (values from 0 to 16383)
• The command should be used in combination with Class-based Low-
latency Queuing to implement RTP Prioritization using the Modular
QoS CLI
class-map
class-map RTP
match
match ip
ip rtp
rtp 16384
16384 16383
!
IP RTP Prioritization was introduced to provide low-latency queuing in combination

with Weighted Fair Queuing (WFQ). The match ip rtp command can be used to
match packets in the same way as with IP RTP prioritization. It should also be
combined with Class-based Low-latency Queuing (CB-LLQ) to generate a similar
result as IP RTP Prioritization.
Summary
Class maps are used within service policies to classify packets. Class maps support
the following classification options:
n Access lists
n IP precedence
n DSCP
n QoS group
n Input interface
n Source MAC address
n Destination MAC address
n IEEE 802.1Q/ISL CoS or Priority bits
n RTP port
Review Questions
n Which classification options are available using class maps?
n What command is used to configure classification?
Network Based
Application Recognition (NBAR)
Objectives
n Describe and configure NBAR
n Describe and configure classification of FTP and TFTP
n Describe and configure complex classification of HTTP sessions
Network-based Application
Recognition (NBAR)
• The IntServ model uses RSVP to signal QoS

requirements including application
definition
• The DiffServ model relies on the network to
recognize applications
• Recognizing simple applications is possible
by matching on the static source or
destination TCP/UDP port numbers
• Some applications use multiple sessions
and dynamic port numbers
The two IETF standards that describe guidelines and protocols used to implement
quality of service in IP networks are:
n Integrated Services model
n Differentiated Services model
The Integrated Services model uses the Resource Reservation Protocol
(RSVP), which signals the network with the QoS requirements for a specific flow.
Part of the request contains information that helps network devices recognize
packets belonging to the flow.
The Differentiated Services model, however, relies on the network to be able to
recognize packets belonging to traffic classes that require the same quality of
service. If there is a need to classify a certain protocol it is usually done by using
an access list where packets are matched based on the source or destination TCP
or UDP port numbers.
A problem arises when trying to classify packets belonging to applications that use
multiple sessions and dynamically negotiate TCP or UDP port numbers.
NBAR Capabilities
• NBAR was introduced to enable recognition

of applications using dynamic port
numbers (e.g. FTP, Exchange, SQL*net)
• NBAR supports a number of applications
that use static port numbers (e.g. Telnet)
• NBAR also allows recognition of sessions
based on higher-layer information (e.g.
HTTP by URL, Host or MIME, Citrix by
application)
NBAR can be used to recognize packets belonging to different types of

applications:
n Static applications establish sessions to well known TCP or UDP destination
port numbers. Such applications used to be classified by using access lists.
n Dynamic applications use multiple sessions, which use dynamic TCP or UDP
port numbers. Typically, there is a control session to a well-know port number
and the other sessions are established to destination port numbers negotiated
through the control sessions. NBAR inspects the port number exchange
through the control session.
n Some non-IP protocols can also be recognized by NBAR.
n NBAR also has the capability to inspect some applications for other
information and classify based on that information. For example, NBAR can
classify HTTP sessions based on the requested URL, included MIME
(Multipurpose Internet Mail Extensions) type or hostname.
The following table lists the non-TCP and non-UDP protocols supported by
NBAR:
Protocol Network Protocol ID Description
protocol
EGP IP 8 Exterior Gateway Protocol
GRE IP 47 Generic Routing Encapsulation
ICMP IP 1 Internet Control Message Protocol
IPINIP IP 4 IP in IP
IPSec IP 50, 51 IP Encapsulating Security
Payload/Authentication Header
EIGRP IP 88 Enhanced Interior Gateway Routing Protocol
NBAR Support for Static
Protocols
• NBAR supports a number of applications

that are recognized based on a well known
destination port number
• Such applications were previously matched
by using extended IP access lists
Although access lists can also be used for this purpose, NBAR is easier to
configure and can provide classification statistics that are not available when using
access lists.
The following table contains the static IP protocols supported by NBAR:
Protocol Transport TCP or Description
protocol UDP port
BGP TCP/UDP 179 Border Gateway Protocol
CU-SeeMe TCP/UDP 7648, Desktop videoconferencing
7649
CU-SeeMe UDP 24032 Desktop video conferencing
DHCP/ BOOTP UDP 67, 68 Dynamic Host Configuration Protocol/
Bootstrap Protocol
DNS TCP/UDP 53 Domain Name System
Finger TCP 79 Finger user information protocol
Gopher TCP/UDP 70 Internet Gopher Protocol
HTTP TCP 80 Hypertext Transfer Protocol
HTTPS TCP 443 Secured HTTP
IMAP TCP/UDP 143, 220 Internet Message Access Protocol
IRC TCP/UDP 194 Internet Relay Chat
Kerberos TCP/UDP 88, 749 Kerberos Network Authentication Service
L2TP UDP 1701 L2F/L2TP tunnel
LDAP TCP/UDP 389 Lightweight Directory Access Protocol
MS-PPTP TCP 1723 Microsoft Point-to-Point Tunneling
Protocol for VPN
MS- SQLServer TCP 1433 Microsoft SQL Server Desktop
Videoconferencing
NetBIOS TCP 137, 139 NetBIOS over IP (MS Windows)
NetBIOS UDP 137, 138 NetBIOS over IP (MS Windows)
NFS TCP/UDP 2049 Network File System
NNTP TCP/UDP 119 Network News Transfer Protocol
Protocol Transport TCP or Description
protocol UDP port
Notes TCP/UDP 1352 Lotus Notes
Novadigm TCP/UDP 3460- Novadigm Enterprise Desktop
3465 Manager (EDM)
NTP TCP/UDP 123 Network Time Protocol
PCAnywhere TCP 5631, Symantec PCAnywhere
65301
PCAnywhere UDP 22, 5632 Symantec PCAnywhere
POP3 TCP/UDP 110 Post Office Protocol
Printer TCP/UDP 515 Printer
RIP UDP 520 Routing Information Protocol
RSVP UDP 1698,17 Resource Reservation Protocol
SFTP TCP 990 Secure FTP
SHTTP TCP 443 Secure HTTP
SIMAP TCP/UDP 585, 993 Secure IMAP
SIRC TCP/UDP 994 Secure IRC
SLDAP TCP/UDP 636 Secure LDAP
SNNTP TCP/UDP 563 Secure NNTP
SMTP TCP 25 Simple Mail Transfer Protocol
SNMP TCP/UDP 161, 162 Simple Network Management Protocol
SOCKS TCP 1080 Firewall security protocol
SPOP3 TCP/UDP 995 Secure POP3
SSH TCP 22 Secured Shell
STELNET TCP 992 Secure Telnet
Syslog UDP 514 System Logging Utility
Telnet TCP 23 Telnet Protocol
X Windows TCP 6000- X11, X Windows
6003
NBAR Support for Dynamic
Protocols
• NBAR is primarily used to recognize

applications that use multiple sessions and
dynamic port numbers
– Such applications usually start with a control
session on a well-known port number
– Additional ports are negotiated through the
control session
• NBAR inspects the negotiation of additional
ports
• Most of these applications could previously
not be matched by any mechanism
The following table lists the dynamic (or stateful) protocols supported by NBAR:
Stateful protocol Transport Description
protocol
FTP TCP File Transfer Protocol
Exchange TCP MS-RPC for Exchange
HTTP TCP HTTP with URL, MIME, or Host classification
Netshow TCP/UDP Microsoft Netshow
Realaudio TCP/UDP RealAudio Streaming Protocol
r-commands TCP rsh, rlogin, rexec
StreamWorks UDP Xing Technology Stream Works audio and video
SQL*NET TCP/UDP SQL*NET for Oracle
SunRPC TCP/UDP Sun Remote Procedure Call
TFTP UDP Trivial File Transfer Protocol
VDOLive TCP/UDP VDOLive Streaming Video
Use the match protocol ? command to display the list of supported protocols with
the Cisco IOS version you are using.
Packet Description Language
Module
• An external Packet Description Language

Module (PDLM) can be loaded at run time to
extend the NBAR list of recognized protocols
• PDLMs can also be used to enhance an
existing protocol recognition capability
• PDLMs allow NBAR to recognize new
protocols without requiring a new IOS image
or a router reload
New features are usually added to new versions of the Cisco IOS software.
NBAR is the first mechanism that supports dynamic upgrades without having to
change the IOS version or restart a router.
Packet Description Language Modules (PDLMs) contain the rules used by NBAR
to recognize an application and can be used to bring new or changed functionality
to NBAR.
Configuring NBAR
match protocol protocol
• Use the protocol keyword and the name of the

protocol to match
• Static protocols are recognized based on the well-
known destination port number
• Dynamic protocols are recognized by inspecting the
session
When configuring NBAR the administrator does not need to understand the way a
certain protocol works. The configuration simply requires the administrator to enter
the name of the protocol (static or stateful).
Configuring NBAR
router(config)#
ip nbar pdlm pdlm-file
pdlm-file
• Enter the location of the Packet Description

Language Module file to extend the NBAR
capabilities of the router
• The file name is in the URL format (e.g.
flash://citrix.pdlm)
router(config)#
ip nbar port-map protocol
protocol {tcp | udp} new-port [new-port ...]
• Specify an additional port for a well-known protocol

• Up to 16 additional port numbers can be specified
Use the ip nbar pdlm command to configure the routers with the new
functionality brought by the PDLM file. The pdlm-file parameter should be in the
URL format and can point to the flash where the IOS is stored (for example,
flash://nbar.pdlm). The file can also be located on a TFTP server (for example,
tftp://10.1.1.1/nbar.pdlm).
Some protocols (static or stateful) can use additional TCP or UDP ports. Use the
ip nbar port-map command to extend the NBAR functionality for well-known
protocols to new port numbers.
Configuring NBAR for HTTP
match protocol http url url
• Recognizes the HTTP GET packets containing the URL, and then
matches all packets that are part of the HTTP GET request
• Include only the portion of the URL following the address or hostname
in the match statement
match protocol http host hostname
• Performs a regular expression match on the host field contents inside
an HTTP GET packet and classifies all packets from that host
match protocol
protocol http
http mime
mime mime-type
• Select the mime-type to be matched
• Matches a packet containing the MIME-type and all subsequent
packets until the next HTTP transaction
NBAR has enhanced classification capabilities for HTTP. It can classify packets
belonging to HTTP flows based on:
n URL portion after the hostname which appears in the GET request of the
HTTP session
n Hostname specified in the GET request
n MIME type specifying the type of object in the HTTP response
NBAR for FTP
Case Study
class-map FTP
class-map FTP
match protocol ftp
match protocol ftp
Open control session to well-known port 21

GET file; use port 1050
Open data session to negotiated port 1050

Sending file
• FTP control sessions can be recognized based on the well-

known port number 21
• FTP data sessions may be recognized by the well-known
source port number 20
• Not all implementations of FTP use port 20
• NBAR recognizes FTP data sessions by inspecting the FTP
control session
The figure illustrates the process of a file download using FTP. FTP sessions use
the well-known TCP port number 21 to open a control session. A new session is
opened to transfer a file. The client in the example tells the server to open a data
session to TCP port 1050. Although the server should use the well-known source
port 20 for the data session, which would simplify classification of FTP, many
implementations of FTP use random source port numbers.
NBAR inspects the communication between the client and the server to learn
about dynamically negotiated port numbers (1050 in the example). NBAR is then
able to classify all packets (control and data) as FTP packets.
NBAR for TFTP
Case Study
class-map FTP
class-map FTP
match protocol tftp
match protocol tftp
Send first packet to port 69, source port 1060

GET file
Send packet to port 1060, source port 1035
Sending file
Acknowledge
Sending file
• TFTP uses UDP for transport

• The first packet uses a well-known destination port number
69 and a random source port (>1023)
• The receiver responds to the received source port and uses a
new source port for its packets (>1023)
• The session from there on uses those port numbers
TFTP is another file transfer protocol (a trivial one), which is not trivial to classify.
TFTP uses UDP to transfer files.
Step 1 The first TFPT packet (sent from the client to the server) uses a random source
port number and the well-known destination port number 69. This is the only
information that can be used to recognize TFTP.
Step 2 A router configured for NBAR recognizes port 69 but remembers the source port
(1060 in the example).
Step 3 The server responds by sending a packet to the client where its source port
number is also random (1035 in the example). The router can, however,
recognize this as part of a TFTP session because it previously recorded the
client’s source port number (now the destination port number 1060).
Step 4 All subsequent packets use this pair of port numbers (1060<->1035).
NBAR for HTTP
Case Study #1
ip nbar port-map http tcp 80 8080 ip nbar port-map http tcp 80 8080
! !
class-map HTTP class-map HTTP
match protocol http match protocol http
Open HTTP session to port 80

GET page
GET page
• HTTP is a static protocol using a well-known port

number 80
• Some web servers are using HTTP on other ports
• Use the “ip nbar port-map” command to inform the
router that other ports are also used for HTTP
The example illustrates a simple classification of all HTTP sessions. HTTP

sessions using the default well-known port number 80 are simple to classify (it is a
static protocol).
HTTP is often used on other port numbers. The example shows the usage of the
ip nbar port-map command to also enable HTTP recognition on port 8080.
NBAR for HTTP
Case Study #2
ip nbar port-map http tcp 80 8080
!
class-map HTTP
match protocol http url *xxx.(jpg|gif)

GET /images/xxx.gif
GET /images/xxx.jpg
• The class map matches all HTTP requests that contain either
xxx.gif or xxx.jpg
• It does so on both ports: 80 and 8080
Classification of HTTP by URL, host, or Multipurpose Internet Mail Extension

(MIME) type, is an example of subport classification.
Step 1 NBAR classifies HTTP traffic by text within the URL or host fields of a GET
request using regular expression matching. NBAR uses the UNIX filename
specification as the basis for the URL or host specification format.
Step 2 The NBAR engine converts the specified match string into a regular expression.
Step 3 NBAR recognizes HTTP GET packet(s) containing the URL and classifies all
packets that are sent to the source of the HTTP GET request.
The example shows a class-map that classifies only those HTTP sessions that
request files with filenames ending in xxx.gif or xxx.jpg.
The allowed regular expressions include the following special characters:
Special Description
character
* Match any zero or more characters in this position.
? Match any one character in this position.
| Match one of a choice of characters.
(|) Match one of a choice of characters in a range. For example,
foo.(gif | jpg) matches either foo.gif or foo.jpg.
[] Match any character in the range specified, or one of the
special characters. For example, [0-9] is all of the digits. [*] is
the "*" and [[] is the "[" character.
NBAR for HTTP
Case Study #3
ip nbar port-map http tcp 80 8080
!
class-map HTTP
match protocol http mime *jpeg

GET /html/pictures.html
GET /html/pictures.html
• The class map matches all HTTP requests containing MIME

type that contains jpeg (e.g. image/jpeg)
• It does so on both ports: 80 and 8080
This example shows how HTTP sessions can also be filtered based on the MIME
type.
Summary
Network-based Application Recognition (NBAR) is a tool used primarily to
classify packets belonging to applications using dynamically assigned TCP or UDP
port numbers. Additionally, NBAR can classify packets (or flows) on application
layer information (for example, HTTP can be classified based on URL, hostname
or MIME contents).
Review Questions
n What is NBAR used for?
n What types of applications can NBAR recognize?
n How can support for recognizing new applications be included into existing
IOS versions?
n What additional classification options are available for HTTP?
n Which special characters are available with regular expressions for matching
HTTP flows?
Summary
n Describe the classification part of the Modular QoS CLI
n Describe and configure all currently supported classification options within the
MQC
n Understand Network-based Application Recognition (NBAR)
Introduction to Modular QoS CLI
Question: What are the benefits of the Modular QoS CLI?
Answer: Template-based configuration; new classification options can be used
with any MQC-based QoS mechanism.
Question: Which two matching strategies do class maps support?
Answer: When using multiple match commands in one class map a logical “or” is
configured using the match-any keyword and a logical “and” is configured using
the match-all keyword.
Question: Which classification options do class maps support?
Answer: Class maps support classification using: access lists, IP Precedence
value, IP DSCP value, QoS group number, MPLS experimental bits, protocol
(including NBAR) etc.
Question: Which classification options are available using class maps?
Answer: Class maps support classification using: access lists, IP Precedence
value, IP DSCP value, QoS group number, MPLS experimental bits, protocol
(including NBAR) etc.
Question: What command is used to configure classification?
Answer: The match command is used in the class-map configuration mode to
specify the classification parameters.
Network Based Application Recognition (NBAR)

Question: What is NBAR used for?
Answer: NBAR is primarily used to recognize sessions that dynamically negotiate
TCP or UDP port numbers.
Question: What types of applications can NBAR recognize?
Answer: NBAR can recognize static protocols, dynamic protocols and sessions
based on higher-layer information.
Question: How can support for recognizing new applications be included into
existing IOS versions?
Answer: By using Packet Language Description Modules (PDLMs) to include
new or changed functionality into existing Cisco IOS.
Question: What additional classification options are available for HTTP?
Answer: Classification based on URL, hostname or MIME type.
Question: Which special characters are available with regular
expressions for matching HTTP flows?
Answer: The special characters include:
– “*” to match any sequence of characters
– “?” to match any single character
– “|” to match the expression on the left or
the expression on the right
– “[]” to match a character from the
specified range
– “()” to group a number of characters
9
Modular QoS CLI

Service Policy
Overview
This module describes the policy part of the Modular QoS CLI (MQC). The
module describes all the mechanisms that are currently supported by the MQC. As
well, the module describes the class-based approach to the marking, shaping,
policing, dropping and/or scheduling of IP packets using the modular QoS CLI.
Objectives
n Describe the policy part of the Modular QoS CLI
n Configure packet marking with modular CLI
n Configure policing and shaping with modular CLI
n Configure class-based WFQ with modular CLI
n Configure congestion avoidance mechanisms (WRED) with modular CLI
n Configure low-latency queuing
n Monitor and troubleshoot policy maps
Service Policy
Overview
This lesson introduces the part of the MQC that is used to enable QoS mechanisms
for classified traffic.
Objectives
n Describe and configure policy maps.
n List all the QoS mechanisms currently available in the MQC.
n Monitor and troubleshoot policy maps.
9-2 IP QoS Modular QoS CLI Service Policy Copyright  2001, Cisco Systems, Inc.
Service Policy
• One aspect of modularity of the MQC is the

configuration part
• MQC is split into two modules:
– Configuration of classification
– Configuration of service policies
• Classification is configured by using class
maps
• Service Policy is configured by using policy
maps
© 2001, Cisco Systems, Inc. IP QoS Modular QoS CLI Service Policy-5
The Cisco IOS Modular QoS CLI (MQC) is the new, unified method of QoS
mechanism configuration in Cisco IOS. MQC separates classification and QoS
mechanism configuration by separating the configuration tasks into:
n Configuration of class-maps, which define the classification of traffic
n Configuration of service policies, which define how QoS mechanisms are
applied to traffic classes
This creates a flexible environment for the modular configuration of many QoS
features, and significantly reduces overhead and the possibility of errors because
configuration information is not unnecessarily duplicated.
Copyright  2001, Cisco Systems, Inc. IP QoS Modular QoS CLI Service Policy 9-3
Modular QoS CLI
Classification Service Policy Service Policy

implements per-hop
Class 1? CB-WFQ behaviors (PHBs) for
all traffic classes
Supported mechanisms:
Class 2? CB-LLQ
• CB-WFQ
• CB-LLQ
• CB-Policing
Class N? CB-Policing
• CB-Shaping
• CB-Marking
• Up to 256 classes can be used within one service policy
The service policy is used to configure QoS mechanisms, which may be applied to
classes. The QoS mechanisms implement local per-hop behaviors (PHBs) for
attached traffic classes. The QoS system, which implements PHB configured via
the MQC, is the Class-Based Weighted Fair Queuing system, which integrates
many QoS features in a single system, configured via a common (MQC) interface.
A service policy can have up to 256 classes used within it and attached to an
interface. Class-based Weighted Fair Queuing and Class-based Low-latency
Queuing are an exception – only 64 classes can be used with one service policy.
PHB Mechanisms
• MQC Supports the following QoS

mechanisms:
– Class-based Weighted Fair Queuing (CB-WFQ) to
guarantee bandwidth
– Class-based Low-latency Queuing (CB-LLQ) to
guarantee bandwidth and low-latency
– Class-based Policing (CB-Policing) to limit traffic
rate by dropping excess traffic
– Class-based Shaping (CB-Shaping) to limit traffic
rate by delaying excess traffic
– Class-based Marking (CB-Marking) to mark
packets
© 2001, Cisco Systems, Inc. IP QoS Modular QoS CLI Service Policy -7
The MQC configures the CB-WFQ system, which in turn implements the following
QoS functions:
n Class-based Weighted Fair Queuing, which is used to guarantee bandwidth
within the CB-WFQ system
n Class-based Low-latency Queuing, which is used to guarantee bandwidth and
provide low latency to time-critical traffic
n Class-based Policing, which performs rate limiting by traffic policing
n Class-based Shaping, which performs rate limiting by traffic shaping
n Class-based Marking, which performs packet and frame marking
Configuring Policy Maps
Router(config)#
policy-map name
• Enter policy-map configuration mode
• Policy maps are identified by a case-sensitive name
Router(config-pmap)#
class class-map
• Enter the per-class policy configuration mode by using the name of a
previously configured class-map
• Use the name “class-default” to configure the policy for the default class
class class-map condition
• Optionally you can define a new class-map by entering the condition
after the name of the new class map
• Class map will use the match-any strategy
Service policies are configured using the policy-map command. Up to 256 classes
can be used within one policy-map using the class command with the name of a
preconfigured class-map.
A non-existent class can also be used within the policy-map configuration mode if
the match condition is specified after the name of the class. The running
configuration will reflect such a configuration by using the match any strategy and
inserting a full class-map configuration.
The following table shows starting and resulting configuration modes for the class-
map, policy-map and class commands:
Starting configuration Command Configuration mode
mode
Router(config)# class-map Router(config-cmap)#
Router(config)# policy-map Router(config-pmap)#
Router(config-pmap)# class Router(config-pmap-c)#
All traffic that is not classified by any of the class-maps used within the policy map
is part of the default class class-default. This class has no QoS guarantees by
default. The default cla ss, when used on output, can use one FIFO queue of
flow-based WFQ. The default class is part of every policy-map even if not
configured.
description description
• It is recommended to use descriptions in large and complex
configurations
• The description has no operational meaning
rename policy-map
• Complex policy-maps can be renamed by using the rename policy-map
command
• All references to the policy map are also renamed
Router(config-pmap-c)#
<PHB mechanism>
• Per-class service policies are configured within the per-class policy-
map configuration mode
Policy maps, like class maps, should use descriptions in large QoS implementations
where a large number of different policy maps are used.
Renaming a policy map would normally require the renaming of all the references
to the policy map. Using the rename command simplifies the renaming process by
automatically renaming all references.
The remainder of this module focuses on the various QoS mechanisms that are
configured per-class within the policy-map configuration mode (config-pmap-c).
Router(config-if)#
service-policy {input | output} policy-map
• Attaches the specified service policy map to the input

or output interface
• The interface should be in the default queuing mode
prior to using this command if it is used on output
class-map
class-map HTTP
HTTP interface
interface Serial0/0
Serial0/0
match
match protocol
protocol http service-policy
service-policy output
output PM
PM
!! !!
policy-map
policy-map PM
PM
class
class HTTP
HTTP
bandwidth
bandwidth 2000
2000
class class-default
bandwidth
bandwidth 6000
6000
!!
The last configuration step when configuring QoS mechanisms using the Modular
QoS CLI, is to attach a policy map to the inbound or outbound packets, using the
service-policy command.
The router immediately verifies the correctness of parameters used in the policy
map. If there is a mistake in the policy-map configuration, the router will display a
message explaining what is wrong with the policy map.
The sample configuration shows how a policy map is used to separate HTTP from
other traffic. HTTP is guaranteed 2Mbps. All other traffic belongs to the default
class and is guaranteed 6Mbps.
Attaching Policy Maps to ATM
PVCs
Router(config-subif)#
• Service policies can be attached to an ATM (sub)interface

• Using service policies on the main interface and subinterfaces
at the same time is not supported in the distributed (VIP-based)
version
Router(config-if-atm-vc)#
• Service policies can also be attached to an ATM PVC

interface
interface atm
atm 5/0/0.1
5/0/0.1 point-to-point
point-to-point
service-policy
output PM1
PM1
!!
interface atm 5/0/0.2 point-to-point
interface atm 5/0/0.2 point-to-point
pvc
pvc 1/40
1/40
service-policy
output PM2
PM2
!!
Service policies can be applied to interfaces, subinterfaces or individual ATM

virtual circuits. Refer to the “IP QoS – IP over ATM” module for a more detailed
description of MQC usage on ATM interfaces.
Attaching Policy Maps to Frame
Relay Interfaces
Router(config-subif)#
• Service policy can be attached to an interface and/or

to a subinterface
• Service policy attached to a subinterface can not
include CB-WFQ or CB-LLQ except in the distributed
(VIP-based) version
• Using service policies on the main interface and
subinterfaces at the same time is not supported in
the distributed (VIP-based) version
Service policies can also be used on Frame Relay interfaces or subinterfaces.
Attaching Policy Maps to Frame
Relay PVCs
• Service policy can be attached to a Frame Relay map class

class-map
class-map Voice
Voice
match
match protocol
protocol vofr
vofr
!!
policy-map
policy-map LLQ
class
class Voice
Voice
priority
priority 100
!!
interface
interface Serial0/0
Serial0/0
encapsulation
encapsulation frame -relay
frame-relay
!!
interface
interface Serial0/0.1
Serial0/0.1 point-to-point
point-to-point
frame-relay
frame-relay class
class Voice
!!
map-class
frame-relay Voice
Voice
service-policy
service-policy output LLQ
!!
A Frame Relay map class is needed when attaching a policy map to an individual
virtual circuit.
The sample configuration illustrates how per-VC Low-latency queuing can be
configured on Frame Relay virtual circuits.
Policy Map
Example
class-map
class-map match-all
match-all Test1
Test1
match protocol
protocol http
match
match access-group
access-group 100
100
class-map
class-map match-any
match-any Test2
Test2
match
match protocol
protocol http
match
match access-group
access-group 101
101
!!
policy-map
policy-map Test
class Test1
bandwidth 100
100
class Test2
bandwidth 200
200
class Test3 access-group 100
bandwidth 300
300
!!
access-list
permit tcp
tcp any
any host
host 10.1.1.1
10.1.1.1
access-list
permit tcp
tcp any
any host
host 10.1.1.2
10.1.1.2
The example shows the configuration of a policy map using three classes. The first
two classes were separately configured using the class-map command. The third
class was configured “on the fly” by specifying the match condition after the name
of the class.
Class Test1 has two match conditions evaluated in the match-all strategy.
Classes Test2 and Test3 use the match-any strategy.
Policy Maps
Router#
show policy-map [policy-map]
Router#show
Router#show policy-map
policy-map
Policy Map Test
Class Test1
Test1
Weighted Fair Queueing
Queueing
Bandwidth
Bandwidth 100
100 (kbps)
(kbps) Max
Max Threshold
Threshold 64
64 (packets)
(packets)
Class Test2
Test2
Queueing
Bandwidth
Bandwidth 200
200 (kbps)
(kbps) Max
Max Threshold
Threshold 64
64 (packets)
(packets)
Class Test3
Test3
Queueing
Bandwidth
Bandwidth 300
300 (kbps)
(kbps) Max
Max Threshold
Threshold 64
64 (packets)
(packets)
The show policy-map command can be used to verify the configuration of a

policy map.
Policy Maps
Router#
show policy-map interface [intf] {input | output}
Router #show policy
Router#show -map interface
policy-map interface FastEthernet0/0
FastEthernet0/0 output
output
FastEthernet0/0
FastEthernet0/0
Service-policy
Service-policy output:
output: Test
Test (1101)
(1101)
Class-map:
Class-map: Test1
Test1 (match-all)
(match-all) (1103/3)
(1103/3)
00 packets,
packets, 00 bytes
bytes
55 minute offered rate
minute offered rate 0 bps,
bps, drop rate 0 bps
Match:
Match: access-group
access-group 101
101 (1107)
(1107)
Match:
Match: access-group
access-group 102
102 (1111)
(1111)
Match:
Match: protocol
protocol http
http (1115)
(1115)
Weighted
Weighted Fair
Fair Queueing
Queueing
Output
Output Queue:
Queue: Conversation 265
Bandwidth
Bandwidth 100 (kbps)
100 (kbps) Max
Max Threshold
Threshold 64
64 (packets)
(packets)
(pkts
(pkts matched/bytes
matched/bytes matched)
matched) 0/0
0/0
(depth/total
(depth/total drops/no-buffer
drops/no-buffer drops)
drops) 0/0/0
0/0/0
...
...
Class-map:
Class-map: class-default
class -default (match-any)
(match-any) (1143/0)
(1143/0)
25
25 packets,
packets, 19310
19310 bytes
bytes
55 minute
minute offered
offered rate
rate 1000
1000 bps,
bps, drop
drop rate
rate 00 bps
bps
Match:
Match: any
any (1147)
(1147)
The show policy-map command also displays live information if the interface
keyword is used. The sample output shows the parameters and statistics of the
policy map attached to outbound traffic on interface FastEthernet0/0.
Summary
All QoS mechanisms using the Modular QoS CLI (MQC) are configured using the
following three commands:
n Class-map global configuration command to configure classification
n Policy-map global configuration command to create a service policy
n Class command in the policy-map configuration mode to attach QoS
mechanisms to a class
The MQC supports the following QoS mechanisms:
n Class-based Weighted Fair Queuing
n Class-based Low-latency Queuing
n Class-based Weighted Random Early Detection
n Class-based Shaping
Lesson Review
1. What are the benefits of using MQC?
2. How many classes can be used for one service policy?
Class-based Weighted Fair Queuing
Overview
This lesson describes the enhanced queuing mechanism in Cisco IOS using the
Modular QoS CLI.
Objectives
n Describe Class-based Weighted Fair Queuing (CB-WFQ)
n Configure CB-WFQ
n Monitor and troubleshoot CB-WFQ
Class-based Weighted Fair
Queuing
• Class-based Weighted Fair Queuing (CB-WFQ) is a

mechanism that is used to guaranetee bandwidth to
classes
• CB-WFQ extends the standard WFQ functionality to
provide support for user-defined traffic classes
– Classes are based on user-defined match criteria
– Packets satisfying the match criteria for a class constitute
the traffic for that class
• A queue is reserved for each class, and traffic
belonging to a class is directed to that class's queue
CBWFQ extends the standard WFQ functionality to provide support for user-
defined traffic classes. For CBWFQ, the user defines the traffic classes based on
match criteria including protocols, access control lists (ACLs), and input interfaces.
Packets satisfying the match criteria for a class constitute the traffic for that class.
A queue is reserved for each class, and traffic belonging to a class is directed to
that class's queue.
Once a class has been defined according to its match criteria, you can assign it
characteristics. To characterize a class, you assign it bandwidth, weight, and
maximum packet limit. The bandwidth assigned to a class is the minimum
bandwidth delivered to the class during congestion.
To characterize a class, you also specify the queue limit for that class, which is the
maximum number of packets allowed to accumulate in the class's queue. Packets
belonging to a class are subject to the bandwidth and queue limits that characterize
the class. After a queue has reached its configured queue limit, enqueuing of
additional packets to the class causes tail drop or packet drop to take effect,
depending on how the class policy is configured.
CB-WFQ
Forwarded Packets
CB-WFQ
Hardware
Class 2? Tail-drop Queue 2 Queuing System
CB-WFQ
Class-default? Tail-drop Default Queue
• Up to 64 classes (class maps) and one default class
CB-WFQ uses up to 64 class maps to classify traffic into their corresponding FIFO
queues. Tail-drop is the default dropping scheme of CB-WFQ although it can be
combined with WRED.
The CB-WFQ scheduler is used to guarantee bandwidth based on the configured
weights.
CB-WFQ Classification
• Classification uses class-maps

• Availability of certain classification options depends
on the Cisco IOS version
• Some classification options depend on type of
interface and encapsulation where service policy is
used
• For example:
– Matching on Frame Relay DE bits can only be used on
interfaces with Frame Relay encapsulation
– Matching on MPLS experimental bits has no effect if MPLS is
not enabled
– Matching on ISL Priority bits has no effect if ISL is not used
Any classification option can be used depending on the availability in the Cisco IOS
version and the support on the selected interface and encapsulation.
CB-WFQ
Insertion Policy

packets that it can hold (queue size)
• The default maximum queue size is 64
queues, the router will enqueue the packet if
the queue limit has not been reached (tail-
drop within each class)
• WRED can be used in combination with CB-
WFQ to prevent congestion of the class
CB-WFQ reserves 64 FIFO queues in the WFQ system. The default queue limit is
64 (tail-drop) and can be configured with WRED (random drop).
CB-WFQ Scheduling
• CB-WFQ guarantees bandwidth according to

weights assigned to traffic classes
• Weights can be defined by specifying:
– Bandwidth (in kbps)
– Percentage of bandwidth (percentage of
configured interface bandwidth)
– Percentage of available bandwidth
• One service policy can not have mixed types
of weights
• The “show interface” command can be used
to display the available bandwidth
The configuration of bandwidth guarantees can be done using one of the following
commands:
n The bandwidth command allocates a fixed amount of bandwidth by specifying
the amount in kilobits per second (kbps). The reserved bandwidth is subtracted
from the available bandwidth of the interface where the service policy is used.
The allocated bandwidth must also be within the default or configured
reservable limit (75% by default).
n The bandwidth percent command can be used to allocate a percentage of
the default or configured bandwidth of an interface. The default bandwidth
usually equals the maximum speed of an interface. Sometimes it actually
reflects the real speed of an interface (for example: Ethernet or FastEthernet).
The default value can be replaced by using the bandwidth interface
command. It is recommended that the bandwidth reflect the real speed of the
link. The allocated bandwidth is subtracted from the available bandwidth of the
interface where the service policy is used.
n The bandwidth remaining percent command can be used to allocate a
portion of the available bandwidth. The allocated bandwidth is not subtracted
from the available bandwidth of the interface where the service policy is used.
A single service policy cannot mix different bandwidth commands.
Available Bandwidth
• Available bandwidth is calculated according

to the following formula:
Configured using the Configured using the interface
interface “bandwidth” max-reserved -bandwidth command
command 75% is the default value
BWavail = BW * MaxReservable – SUM(all fixed guarantees)
Sum of all fixed guarantees using

CB-WFQ, CB-LLQ, IP RTP
Prioritization
The available bandwidth displayed by the show interface command is calculated

by subtracting all fixed bandwidth reservations from 75% of the default or
configured bandwidth of an interface.
Available Bandwidth
Example 1
• Ethernet interface uses default bandwidth 10000

(kbps) and WFQ
BWavail = 10000 kbps * 75% – 0 kbps = 7500 kbps
Router#show
interface Ethernet
Ethernet 0/0
0/0
Ethernet0/0
Ethernet0/0 is
is up,
up, line
line protocol
protocol isis up
up
Hardware is
Hardware is AmdP2, address is 00b0.64e2.2860 ((bia
bia 00b0.64e2.2860)
00b0.64e2.2860)
Internet
Internet address is 192.168.20.1 255.255.255.0
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 10000
10000 Kbit,
Kbit, DLY
DLY 1000
1000 usec,
usec,
reliability
255/255, txload
txload 1/255,
1/255, rxload
rxload 1/255
1/255
Encapsulation
Encapsulation ARPA,
ARPA, loopback
loopback not
not set
set
Keepalive
ARP
ARP type:
type: ARPA,
ARPA, ARP
ARP Timeout
Timeout 04:00:00
04:00:00
Last
Last input
input 00:00:04,
00:00:04, output
output 00:00:08,
00:00:08, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0/0
Total output
output ddrops:
rops: 0
0
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Conversations
0/0/256 (active/max
active/max total)
total)
Reserved
Conversations 0/00/0 (allocated/max
allocated)
Available
Available Bandwidth
Bandwidth 7500 kilobits/sec
...
...
The figure illustrates a situation where there are no fixed guarantees on the
interface. The show interface command confirms that there are 7.5 Mbps of
bandwidth available (only 75% of 10Mbps is reservable by default).
Available Bandwidth
Example 2
• Ethernet interface uses default bandwidth 10000 (kbps) with
WFQ
• Maximum Reservable bandwidth is set to 50%
• IP RTP Prioritization is used to guarantee 1 Mbps to VoIP
BWavail = 10000 kbps * 50% – 1000 kbps = 4000 kbps
ip address 192.168.20.1 255.255.255.0
half-duplex
max-reserved-bandwidth 50
fair-queue
ip rtp priority 16384 16383 1000
After enabling IP RTP Prioritization with 1Mbps of guaranteed bandwidth and

reducing the reservable limit to 50% there are only 4Mbps left.
The IP RTP Priority feature provides a strict priority queueing scheme that allows
delay-sensitive data such as voic e to be dequeued and sent before packets in other
queues are dequeued. This feature can be used with either WFQ or CBWFQ on
the same outgoing interface. In either case, traffic matching the range of UDP
ports specified for the priority queue is guaranteed strict priority over other
CBWFQ classes or WFQ flows; packets in the priority queue are always serviced
first.
Available Bandwidth
Example 2
Router#show
Ethernet0/0
Ethernet0/0
Ethernet0/0 is up, line
line protocol
protocol is up
up
Hardware
Hardware is
is AmdP2,
AmdP2, address
address is
is 00b0.64e2.2860
00b0.64e2.2860 (bia
(bia 00b0.64e2.2860)
00b0.64e2.2860)
Internet
Internet address
address isis 192.168.20.1
192.168.20.1 255.255.255.0
255.255.255.0
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 10000
10000 Kbit,
Kbit, DLY
DLY 1000
1000 usec,
usec,
reliability
255/255, txload
txload 1/255,
1/255, rxload
rxload 1/255
1/255
Encapsulation
Encapsulation ARPA,
ARPA, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
ARP
ARP type:
type: ARPA,
ARPA, ARP
ARP Timeout
Timeout 04:00:00
04:00:00
Last
Last input 00:00:04, output
input 00:00:04, output 00:00:06,
00:00:06, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0/0
(size/max/drops/flushes); Total output drops:
d rops: 0
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 0/1000/64/0
0/1000/64/0 (size/max
Conversations
0/1/256 (active/max
active/max total)
total)
Reserved
Conversations 0/0
0/0 (allocated/max
allocated)
Available
Available Bandwidth
Bandwidth 4000
4000 kilobits/sec
kilobits/sec
...
...
The show interface command confirms the calculation of available bandwidth for
Example 2.
Configuring CB-WFQ
bandwidth bandwidth
• Allocate a fixed amount of bandwidth to a class

• Set the value in kbps
bandwidth percent percent
• Allocate a percentage of bandwidth to a class

• The configured (or default) interface bandwidth is used to
calculate the guaranteed bandwidth
bandwidth remaining
remaining percent
percent percent
• Allocate a percentage of available bandwidth to a class
Bandwidth guarantee is configured in the cla ss policy-map configuration mode

(config-pmap-c). All classes belonging to one policy map should use the same type
of bandwidth guarantee (fixed in kbps, in percentage of interface bandwidth, in
percentage of available bandwidth).
Configuring CB-WFQ
queue-limit queue-limit
• Set the maximum number of packets this queue can hold

• The default maximum is 64
• Sets the discard threshold in the “class-default” if flow-based
WFQ is used
fair-queue [dynamic-queues]
• The “class-default” class can be configured to use flow-based
WFQ
• WFQ can be configured with 16 to 4096 dynamic queues
The default queue limit of 64 packets can be changed using the queue-limit
command. It is recommended not to change the default value.
The default class can be selected by specifying the class-default name of the
class. The default class supports two types of queuing: one FIFO queue (Default)
or a Flow-based WFQ system. Both types can be combined with WRED. FIFO
queue can also get a bandwidth guarantee.
The following example shows the configuration of FIFO queuing within the default
class. The default class is also guaranteed 1 Mbps of bandwidth and the maximum
queue size is limited to 40 packets.
policy-map A
class A
bandwidth 1000
class class-default
bandwidth 1000
queue-limit 40
This next example shows the configuration of WFQ queuing within the default
class. The number of dynamic queues is set to 1024 and the discard threshold is set
to 50.
policy-map A
class A
bandwidth 1000
class class-default
fair-queue 1024
queue-limit 50
CB-WFQ
Example 1
policy-map
policy-map Policy1
Policy1
class
class Class1
Class1
bandwidth 2000
2000
class
class Class2
Class2
bandwidth 2000
2000
!
interface FastEthernet0/0
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
duplex
duplex auto
speed
speed 10
10
max-reserved-bandwidth
service-policy
service-policy output Policy1
ip
ip rtp
rtp priority
priority 16384
16384 16383
16383 1000
1000
!
BWavail = 10000 kbps * 80% - (2000+2000+1000) kbps = 3000 kbps
The sample configuration shows how CB-WFQ is used to guarantee 2Mbps to

each of the two classes.
The FastEthernet interface (in Ethernet mode) allows up to 80% of the interface
bandwidth (10Mbps) to be reserved. IP RTP Prioritization together with the two
classes consumes 5Mbps. The available bandwidth, therefore, is 3Mbps.
CB-WFQ
Example 2
policy-map
policy-map Policy1
Policy1
class
class Class1
Class1
bandwidth percent
percent 20
20
class
class Class2
Class2
bandwidth percent
percent 20
20
!
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
duplex
duplex auto
speed
speed 10
10
service-policy
ip
ip rtp
rtp priority
priority 16384
16384 16383
16383 1000
1000
!
BWavail = 10000 kbps * 80% - (10000*(20%+20%)+1000) kbps = 3000 kbps
This implementation is equal to CB-WFQ Example 1. The main benefit of using the
percentage keyword is that this policy map can easily be used on another interface
with a different link speed (bandwidth).
CB-WFQ
Examples 1 and 2
Router#show
fastethernet 0/0
0/0
FastEthernet0/0
FastEthernet0/0 is up, lineline protocol
protocol isis up
up
Hardware
Hardware isis AmdFE,
AmdFE, address
address is
is 0030.8546.aa00
0030.8546.aa00 (bia(bia 0030.8546.aa00)
0030.8546.aa00)
Internet
Internet address
address is
is 10.1.1.1
10.1.1.1/24
/24
MTU
MTU 1500
1500 bytes, BWBW 10000
10000 Kbit,
Kbit, DLY
DLY 1000
1000 usec,
usec,
reliability
255/255, txload
txload 1/255,
1/255, rxload
rxload 1/255
1/255
Encapsulation
Encapsulation ARPA,
ARPA, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Half-duplex,
Half-duplex, 10Mb/s,
10Mb/s, 100BaseTX/FX
100BaseTX/FX
ARP
ARP type: ARPA, ARP Timeout
type: ARPA, ARP Timeout 04:00:00
04:00:00
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:09,
00:00:09, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0/0
(size/max/drops/flushes); Total output drops:d rops: 0
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 0/1000/64/0
0/1000/64/0 (size/max
Conversations
0/1/256 (active/max
active/max total)
total)
Reserved
Conversations 2/2
2/2 (allocated/max
allocated)
Available
Available Bandwidth
Bandwidth 3000
3000 kilobits/sec
kilobits/sec
...
...
The show interface command confirms the calc ulation of available bandwidth on
the previous CB-WFQ examples.
CB-WFQ
Example 3
policy-map
policy-map Policy1
Policy1
class
class Class1
Class1
bandwidth remaining
remaining percent 20
20
class
class Class2
Class2
bandwidth remaining
remaining percent 20
20
!
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
duplex
duplex auto
speed
speed 10
10
80
service-policy
ip
ip rtp
rtp priority
priority 16384
16384 16383
16383 1000
1000
!
BWavail = 10000 kbps * 80% - 1000 kbps = 7000 kbps
Example 3 shows how the available bandwidth can be distributed among the
classes configured with the bandwidth remaining percent command. The
reservation does not affect the calculation of available bandwidth (it is not a fixed
guarantee).
The bandwidth remaining percent command allows you to allocate bandwidth

as a relative percentage of the total bandwidth available on the interface. This
command allows you to specify the relative percentage of the bandwidth to be
allocated to the classes of traffic. In this example, 20 percent of the available
bandwidth is allocated to Class1 and 20 percent to Class2. Essentially, you are
specifying the ratio of the bandwidth to be allocated to the traffic class. The sum
of the numbers used to indicate this ratio cannot exceed 100 percent. This way,
you need not know the total amount of bandwidth available, just the relative
percentage you want to allocate for each traffic class.
Each traffic class gets a minimum bandwidth as a relative percentage of the

remaining bandwidth. The remaining bandwidth is the bandwidth available after
the priority queue, if present, is given its required bandwidth, and after any
Resource Reservation Protocol (RSVP) flows are given their requested
bandwidth.
CB-WFQ
Example 3
Router#show
fastethernet 0/0
0/0
FastEthernet0/0
FastEthernet0/0 is up, lineline protocol
protocol isis up
up
Hardware
Hardware isis AmdFE,
AmdFE, address
address is
is 0030.8546.aa00
0030.8546.aa00 (bia(bia 0030.8546.aa00)
0030.8546.aa00)
Internet
Internet address
address is
is 10.1.1.1
10.1.1.1/24
/24
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 10000
10000 Kbit,
Kbit, DLY
DLY 1000
1000 usec,
usec,
reliability
255/255, txload
txload 1/255,
1/255, rxload
rxload 1/255
1/255
Encapsulation
Encapsulation ARPA,
ARPA, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Half-duplex,
Half-duplex, 10Mb/s,
10Mb/s, 100BaseTX/FX
100BaseTX/FX
ARP
ARP type: ARPA, ARP Timeout
type: ARPA, ARP Timeout 04:00:00
04:00:00
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:03,
00:00:03, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0/0
(size/max/drops/flushes); Total output drops:d rops: 0
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 0/1000/64/0
0/1000/64/0 (size/max
Conversations
0/1/256 (active/max
active/max total)
total)
Reserved
Conversations 2/2
2/2 (allocated/max
allocated)
Available
Available Bandwidth
Bandwidth 7000
7000 kilobits/sec
kilobits/sec
...
...
The show interface command confirms the calculation of available bandwidth for
Example 3.
CB-WFQ
Router#
show policy-map interface [intf]
• Displays parameters and statistics of CB-WFQ

Router#show
Router#show policy -map interface
policy-map interface
FastEthernet0/0
FastEthernet0/0
Service-policy
Service-policy output: Policy1
Class-map:
Class-map: Class1
Class1 (match-any)
(match-any)
00 packets,
packets, 00 bytes
bytes
55 minute
minute offered
offered rate
rate 0 bps,
Match:
Match: any
any
Weighted
Weighted Fair
Fair Queueing
Queueing
Output
Output Queue:
Queue: Conversation 265
Bandwidth
Bandwidth remaining
remaining 2020 (%)
(%) Max
Max Threshold
Threshold 64
64 (packets)
(packets)
(pkts
(pkts matched/bytes
matched) 0/0
0/0
(depth/total
drops) 0/0/0
0/0/0
Class-map:
(match-any)
42 packets, 4439 bytes
42 packets, 4439 bytes
55 minute
minute offered
offered rate
rate 00 bps,
bps, drop
drop rate
rate 0
0 bps
bps
Match:
Match: any
any
The show policy-map interface command displays all service policies applied to
the interface. Among the settings, policing parameters and statistics are displayed.
CB-WFQ
Router#
show queueing fair
• Displays queuing parameters on interfaces

Router#show
queueing fair
fair
Current
Current fair
fair queue
configuration:
Interface
Interface Discard
Discard Dynamic
Dynamic Reserved
Reserved Link
Link Prio
Priority
rity
threshold
threshold queues
queues queues
queues queues
queues queues
queu es
FastEthernet0/0
FastEthernet0/0 64
64 256
256 64
64 88 11
Serial0/0
Serial0/0 64
64 32
32 00 88 11
Serial0/1
Serial0/1 64
64 32
32 00 88 11
CB-WFQ reserves 64 queues One queue is reserved for

in the WFQ system IP RTP Prioritization
The show queueing fair command displays all interfaces using Weighted Fair
Queuing. The FastEthernet interface show there are 64 reserved queues (for
CB-WFQ). One queue is used for IP RTP prioritization.
The discard threshold is the number of packets than have to be in the queuing
system to start dropping packets in the longest queue.
The number of dynamic queues specifies how many queues are used in the default
class if flow-based WFQ is used.
WFQ reserves 8 queues (link queues) for PAK_Priority packets (link-level
messages and keepalives, routing protocol hello messages and keepalives etc.).
CB-dWFQ
Router#
show queueing interface [intf]
• Displays queuing parameters on a specific VIP-based

interface
c7500#show
c7500#show queueing
queueing interface
interface serial
serial 5/1/0
5/1/0
Interface
Interface Serial5/1/0
Serial5/1/0 queueing
queueing strategy:
strategy: VIP -based fair
VIP-based fair queueing
queueing
Serial5/1/0
Serial5/1/0 queue
queue size
size 00
pkts
pkts output
output 0,
0, wfq
wfq drops
drops 0, nobuffer
nobuffer drops
drops 00
WFQ:
WFQ: aggregate
aggregate queue
queue limit
limit 00 max
max available
available buffers
buffers 00
Class
Class 0:
0: weight
weight 50
50 limit
limit 250
250 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 23:
23: weight
weight 30
30 limit
limit 150
150 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 24:
24: weight
weight 20
20 limit
limit 100
100 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
The show queueing interface command can be used to display the parameters
and statistics of distributed Weighted Fair Queuing (dWFQ) on Cisco 7x00 series
routers using Versatile Interface Processors (VIPs).
Summary
Class-based Weighted Fair Queuing (CB-WFQ) is a queuing mechanism that can
provide bandwidth guarantees for up to 64 classes on one interface.
Bandwidth guarantees can be configured by specifying:
n A fixed guarantee in kbps
n A fixed guarantee in a percentage of interface bandwidth
n A dynamic guarantee by specifying a percentage of available bandwidth
Lesson Review
1. What type of guarantee does CB-WFQ provide?
2. Which DiffServ PHB can be implemented using CB-WFQ?
3. What configuration steps are needed to configure CB-WFQ?
Class-based WRED
Overview
This lesson describes the WRED feature and shows how and where it can be used
in the MQC.
Objectives
n Describe Class-based Weighted Random Early Detection (CB-WRED)
n Configure CB-WRED
n Monitor and troubleshoot CB-WRED
Class-based WRED
• Class-based WRED can be used in

combination with CB-WFQ
• Using CB-WFQ with WRED allows the
implementation of DiffServ’s Assured
Forwarding PHB
• Class-based configuration of WRED is
identical to standalone WRED
• Flow-based WRED is not available with the
Modular QoS CLI
Congestion avoidance techniques monitor the network interface load in an effort to

anticipate and avoid congestion at common network bottlenecks. Congestion
avoidance is achieved through packet dropping using more complex techniques.
Traditionally, Cisco IOS used standalone RED and WRED mechanisms, as
described in the A_QoS_CongestAvoid module, to avoid congestion on an
interface. Those mechanisms can perform a differentiated drop based on the IP
precedence or DSCP-value.
The Class-Based Weighted Fair Queueing (CB-WFQ) system supports the use of
WRED inside the queueing system, therefore implementing Class-based WRED.
Each class is queued in its separate queue, and has a queue limit, performing tail-
drop by default. WRED can be configured as the preferred dropping method in a
queue, implementing a differentiated drop based on traffic class and further on the
IP precedence or DSCP value.
Note The combination of CB-WFQ with WRED on a single device is currently the only
way to implement the DiffServ’s Assured Forwarding Per-Hop Behavior (AF PFB)
using Cisco IOS software.
The class-based configuration of WRED is analogous to standalone WRED

configuration. Flow-based WRED (FRED) is not available within the CB-WFQ
queueing system and the Cisco IOS MQC.
RED Profile
Drop No drop Random drop Full drop

Probability
100%
Maximum
Drop
Probability
10%
20 40 Average
Queue
Size
Minimum Maximum
Threshold Threshold
• WRED starts randomly dropping packets when the

average queue size is above the minimum threshold
RED is currently the primary congestion avoidance method used on router

interfaces. Random Early Detection is a dropping mechanism that randomly drops
packets before a queue is full. The dropping strategy is based primarily on the
average queue length. When the average queue gets longer (fuller), RED will be
more likely to drop an incoming packet than when the queue is shorter.
Because RED drops packets randomly, it has no per-flow intelligence. The
rationale behind this is that an aggressive flow will represent most of the arriving
traffic. Therefore it is more probable that RED will drop a packet of an aggressive
session. RED therefore punishes more aggressive sessions with higher statistical
probability, and is able to somewhat selectively slow down the most significant
cause of congestion. Directing one TCP session at a time to slow down allows for
the full utilization of the bandwidth, rather than a utilization that manifests itself as
crests and troughs of traffic.
As a result, the TCP global synchronization is much less likely to occur, and TCP
can utilize the bandwidth more efficiently. The average queue size also decreases
significantly, because the possibility of the queue filling up is very small. This is due
to very aggressive dropping in the event of traffic bursts, when the queue is
already quite full.
RED distributes losses over time and maintains normally low queue depth while
absorbing spikes. RED can also utilize IP precedence or DSCP bits in packets to
establish different drop profiles for different classes of traffic.
The probability of a packet being dropped is based on three configurable
parameters:
n Minimum threshold: When the average queue depth is above the minimum
n Maximum threshold: When the average queue size is above the maximum
n Mark probability denominator: This is the fraction of packets dropped
when the average queue depth is at the maximum threshold. For example, if
the denominator is 512, one out of every 512 packets is dropped when the
average queue is at the maximum threshold.
These parameters define the RED profile, which implements the packet dropping
strategy, which is based on the average queue length.
RED Modes
• RED has three modes:

– No drop: when the average queue size is between
0 and the minimum threshold
– Random drop: when the average queue size is
between the minimum and the maximum threshold
– Full drop (tail-drop): when the average queue size
is at maximum threshold or above
• Random drop should prevent congestion
(prevent tail-drops)
RED has three dropping modes, based on the average queue size:
n When the average queue size is between 0 and the configured minimum
threshold, no drops occur and all packets are queued.
n When the average queue size is between the configured minimum threshold,
and the configured maximum threshold, random drop occurs. Random drop is
linearly proportional to the average queue length. The maximum probability of
drop (when the queue is almost completely full) is 10% in Cisco IOS software
if the default settings are used.
n When the average queue size is at maximum or higher than the maximum
threshold, RED performs full (tail) drop in the queue. This event is unlikely,
because RED should slow down TCP traffic ahead of the congestion. If a lot
of non-TCP traffic is present, RED cannot effectively drop traffic to reduce
congestion, and tail-drops are likely to occur.
WRED Building Blocks
Calculate Average
Queue Size Current
Queue
Size
Queue No
Full?
IP precedence
Yes
or
DSCP
Select
WRED
Min. threshold
Max. threshold
Max prob. denom.
The figure shows how WRED is implemented, and what parameters influence
WRED dropping decisions. The WRED algorithm is constantly updated with the
calculated average queue size, which is based on the recent history of queue sizes.
The configured WRED profiles define the dropping thresholds (and therefore the
WRED probability slopes). When a packet arrives at the output queue, the IP
precedence or the DSCP-value is used to select the correct WRED profile for the
packet, and the packet is passed to WRED to perform a drop/enqueue decision.
Based on the profile and the average queue size, WRED calculates the probability
for dropping the current packet and then either drops it or passes it to the output
queue. If the queue is already full, the packet is tail-dropped. Otherwise, it is
eventually transmitted out on the interface.
Weighted Random Early
Detection
• WRED uses a different RED profile for each

weight
• Each profile is identified by:
– minimum threshold
– maximum threshold
– maximum drop probability
• Weight can be
– IP precedence (8 profiles)
– DSCP (64 profiles)
• WRED drops less important packets more
aggressively than more important packets
Weighted Random Early Detection (WRED) combines RED with IP Precedence

or DSCP and does packet drops based on IP Precedence or DSCP markings.
WRED can selectively discard lower priority traffic when the interface begins to
get congested and provide differentiated performance characteristics for different
classes of service. WRED can also be configured so that non-weighted RED
behavior is achieved.
WRED Profiles
Drop
Probability
100%
10%
10 20 40 Average
Queue
Size
• WRED profiles can be manually set

• WRED has 8 default value sets for IP precedence based WRED
• WRED has 64 default value sets for DSCP based WRED
The figure shows two WRED profiles, used with traffic of different QoS classes.
One class has a much lower minimum and maximum threshold, and traffic of that
class will be dropped much earlier and more aggressively, and will ultimately be tail
dropped early, when heavy congestion occurs. The other class has a higher
minimum and maximum threshold. Therefore dropping occurs later and is less
likely to occur. These two classes maintain differentiated levels of service in the
event of congestion.
To avoid the need for setting all WRED parameters in a router, 8 default values
are already defined for precedence-based WRED, and 64 DiffServ-aligned values
are defined for DSCP-based WRED. Therefore, the default settings should suffice
in the vast majority of deployments.
IP Precedence and Class Selector
Profiles
Drop
Probability
100%
10%
IP precedence 0 1 2 3 4 5 6 7 RSVP Average

20 22 24 26 28 31 33 35 37 40 Queue
Size
The Class selector range of DSCP values is used for backward compatibility with
IP precedence. The same WRED profiles are applied to equal IP precedence and
Class selector values:
IP precedence DSCP (Class selector) Default minimum
threshold
(three bits) (six bits)
0 Default (0) 20
1 cs1 (8) 22
2 cs2 (16) 24
3 cs3 (24) 26
4 cs4 (32) 28
5 cs5 (40) 31
6 cs6 (48) 33
7 cs7 (56) 35
RSVP RSVP 37
DSCP-based WRED
(Expedited Forwarding)
Drop
Probability
100%
10% EF
Average
20 36 40 Queue
Size
For the Expedited Forwarding DiffServ traffic class, WRED configures itself by
default so that the minimum threshold is very high, thus increasing the probability of
no drops being applied to that traffic class. EF-traffic is therefore expected to be
dropped very late, compared to other traffic classes, and is therefore prioritized in
the event of congestion.
DSCP Default minimum
threshold
(six bits)
EF (101110) 36
DSCP-based WRED
(Assured Forwarding)
Drop
Probability
100%
AF Low Drop
AF Medium Drop
AF High Drop
10%
Average
20 24 28 32 40 Queue
Size
For the Assured Forwarding DiffServ traffic class, WRED configures itself by
default, for three different profiles, depending on the Drop Preference DSCP
marking bits. AF-traffic should therefore be classified into the three possible
classes based on the application sensitivity to dropping. WRED implements a
congestion avoidance PHB in agreement with the initial classification.
DROP Class #1 Class #2 Class #3 Class #4
Precedence
Low Drop Prec (AF11) (AF21) (AF31) (AF41)

001010 010010 011010 100010
Medium Drop (AF12) (AF22) (AF32) (AF42)
Prec 001100 010100 011100 100100
High Drop Prec (AF13) (AF23) (AF33) (AF43)
001110 010110 011110 100110
Configuring WRED
random-detect
• Enables IP precedence based WRED in the selected

class within the service policy configuration mode
• Default service profile is used
The random-detect command is used to enable WRED on an interface. By

default, WRED is IP precedence-based, using eight default WRED profiles.
Within the CB-WFQ system, WRED is used to perform per-queue drop in the
class queues. Therefore, each class queue has its own WRED method, which can
be further weighed based on the IP precedence or DSCP-value. Each queue can
therefore be configured with a separate dropping policy, to implement different
drop policies for every class of traffic.
Changing WRED Profile
random-detect precedence precedence min-threshold
max-threshold mark-prob-denominator
• Changes RED profile for specified IP precedence

value
• Non-weighted RED is achieved by using the same
RED profile for all precedence values
In the example in the figure, WRED is enabled with default values, and then the
values are changed for each IP Precedence level. The configured values are the
same as for Random Early Detection, and are:
n Mark probability denominator - This is the fraction of packets dropped
It is interesting to note, that the maximum probability of drop at the maximum
threshold can be expressed as 1/mark-prob-denominator. The maximum drop
probability is 10%, if default settings are used which have a mark probability
denominator value of 10.
If required, RED can be configured as a special case of WRED, by assigning the
same profile to all eight IP precedence values.
Changing WRED Sensitivity
to Bursts
random-detect exponential-weighting-constant n
Qavg ( t + 1) = Qavg (t ) ⋅ (1 − 2 − n ) + Qt ⋅ 2 − n
New average Previous average Current queue

queue size queue size size
• WRED takes the average queue size to determine the current

WRED mode (no drop, random drop, full drop)
• High values of N allow short bursts
• Low values of N make WRED more burst-sensitive
• Default value (9) should be used in most scenarios
• Average output queue size with N=9 is
average t+1 = average t * 0.998 + queue_sizet * 0.002
WRED does not calculate the drop probability using the current queue length, but
rather uses the average queue length. The average queue length is constantly
recalculated using two terms: the previously calculated average queue size and the
current queue size. An exponential weighting constant N influences the calculation
by weighing the two terms, therefore influencing how the average queue size
follows the current queue size, in the following way:
average size calculation, therefore more sensitive to bursts
the new average seize calculation, so that bursts influence the new value to a
smaller degree.
involving extremely high-speed interfaces (e.g. OC12), where it can be increased
slightly (to about 12) to allow more bursts.
Configuring DSCP-based WRED
random-detect {prec-based | dscp-based}
• Selects WRED mode

• Precedence-based WRED is the default mode
• DSCP-based uses 64 profiles
The random-detect dscp-based command is used to enable DSCP-based

WRED on an interface, using the 64 default DSCP-based WRED profiles.
Changing the WRED Profile
random-detect precedence precedence min-threshold
max-threshold mark-prob-denominator
• Changes RED profile for specified IP precedence

value
• Non-weighted RED is achieved by using the same
RED profile for all precedence values
The DSCP-weighted WRED profiles can be changed, using the known three
WRED parameters. The mask-prob-denominator defines the packet drop
probability at the WRED maximum threshold. The maximum drop probability is
10%, if default settings are used which have a mark probability denominator value
of 10. Normally, the DSCP-weighed profiles should be left at their default settings,
because those settings are appropriate for most situations, if the traffic is classified
according to the DiffServ service specification.
IP prcecdence Default minimum
threshold
0 20
1 22
2 24
3 26
4 28
5 31
6 33
7 35
RSVP 37
CB-WFQ with WRED
Example 1
• Enable CB-WFQ to prioritize traffic according

to the following requirements:
– Class Gold is marked with IP precedence values 3
and 4 (3 is high drop, 4 is low drop) and should get
30% of interface bandwidth
– Class Silver is marked with IP precedence values 1
and 2 (1 is high drop, 2 is low drop) and should get
20% of interface bandwidth
– All other traffic should be per -flow fair-queued
• Use differentiated WRED to prevent
congestion in all three classes (try to set up
your own WRED profiles for Gold and Silver)
The first CB-WFQ with WRED example focuses on a network, which provides
three different service levels for three traffic classes
n The Gold class, marked with IP precedence values of 3 and 4 (3 is used for
high drop, and 4 is used for low drop within the service class) should get 30%
of an interface bandwidth
n The Silver class, marked with IP precedence values of 1 and 2 (1 being high-
drop, and 2 being low-drop service) should get 20% of the interface bandwidth.
n Best effort traffic should get the remaining bandwidth share, and should be
fair-queued.
To enforce this service policy, a router will use CB-WFQ to perform bandwidth
sharing, and WRED within service classes to perform differentiated drop.
CB-WFQ with WRED
Example 1
class-map
class-map Gold
Gold
match
match ip
ip precedence
precedence 33 4
4
!!
class-map
class-map Silver
Silver
match
!!
policy-map
policy-map Policy1
Policy1
class
class Gold
Gold
bandwidth
bandwidth percent
percent 30
30
random-detect
random-detect
random-detect
random-detect
class
class Silver
Silver
bandwidth
bandwidth percent
percent 20
20
random-detect
random-detect
random-detect
random-detect
class
class class-default
class-default
fair-queue
fair-queue
random-detect
random-detect
!!
The figure shows a configuration implementing the example service policie s. The
traffic is classified based on the precedence bits, and all non-contract traffic is
classified into the default class.
n The Gold class is guaranteed at least 30 percent of bandwidth, with a custom
WRED profile, which establishes a low-drop and a high-drop per-hop behavior.
n The Silver class is guaranteed at least 20 percent of bandwidth, is configured
with somewhat lower WRED drop thresholds, and is therefore more likely to
be dropped than the Gold class in the event of interface congestion.
n All other traffic is part of the default class, is fair-queued, with default WRED
parameters.
CB-WFQ with WRED
Example 2
• Use the QoS design from the previous

example
• Implement it using DSCP:
– Class “Gold” is using AF1
– Class “Silver” is using AF2
• Make sure the new configurations still
conform to the design and implementation
from the previous example
CB-WFQ with WRED Example 1 was implemented using a CoS based on the
precedence bit. In this example, the same policy is configured, but DSCP-based
CoS classification and QoS services are used. Remember that the DiffServ model
itself provides defined traffic classes and their associated PHB. DiffServ-based
classification is used in this example.
CB-WFQ with WRED
Example 2
class-map
class-map Gold
Gold class
class Silver
Silver
match
match ip
ip dscp
dscp af11
af11 af12
af12 af13
af13 cs3
cs3 cs4
cs4 bandwidth
bandwidth percent
percent 20
20
!! random-detect
random-detect dscp -based
dscp-based
class-map
class-map Silver
Silver random-detect
random-detect dscp
dscp af11
af11 25
25 35
35 10
10
match
match ip dscp
dscp af21
af21 af22
af22 af23
af23 cs1
cs1 cs2
cs2 random-detect
random-detect dscp
dscp af12
af12 20
20 35
35 10
10
!! random-detect
random-detect dscp
dscp af13
af13 15
15 35
35 10
10
policy-map
policy-map Policy1
Policy1 random-detect
random-detect dscp
dscp cs3
cs3 15
15 35
35 10
10
class
class Gold
Gold random-detect
random-detect dscp
dscp cs4
cs4 25
25 35
35 10
10
bandwidth
bandwidth percent
percent 30
30 class
class class-default
class-default
random-detect
dscp-based fair-queue
fair-queue
random-detect
random-detect dscp
dscp af11
af11 30
30 40
40 10
10 random-detect
dscp-based
random-detect
random-detect dscp
dscp af12
af12 25
25 40
40 10
10 !!
random-detect
random-detect dscp
dscp af13
af13 20
20 40
40 10
10
random-detect
random-detect dscp
dscp cs3
cs3 20
20 40
40 10
10
random-detect
random-detect dscp cs4 30 40 10
The configuration example shows how traffic classification is performed using

DSCP-based classes, representing the Gold class as the AF1 class, and using the
AF2 class as the Silver class. WRED DSCP-based parameters are sent reflecting
the class-dependent drop strategy.
CB-WRED
Router#show
policy-map interface fastEthernet
fastEthernet 0/0
0/0
FastEthernet0/0
FastEthernet0/0
Service-policy
Service-policy output: Policy1
Class-map:
Class-map: Gold (match-all)
(match -all)
00 packets,
packets, 00 bytes
bytes
55 minute
minute offered rate
offered rate 0 bps,
Match:
Match: ip
ip precedence
precedence 33 44
Match:
Match: ip
ip dscp
dscp 10
10 12
12 14 14 24
24 32
32
Weighted
Weighted Fair
Fair Queueing
Queueing
Output
Output Queue:
Queue: Conversation
Conversation 265
265
Bandwidth
Bandwidth 30
30 (%)
(%)
(pkts
(pkts matched/bytes
matched) 0/0
0/0
(depth/total
drops) 0/0/0
0/0/0
exponential
exponential weight:
weight: 99
mean queue depth:
mean queue depth: 0 0
Dscp
Dscp Random
Random drop
drop Tail drop Minimum Maximum Mark
(Prec)
(Prec) pkts/bytes
pkts/bytes pkts/bytes
pkts/bytes threshold
threshold threshold
probability
0(0)
0(0) 0/0
0/0 0/0
0/0 20
20 40
40 1/10
1/10
11 0/0
0/0 0/0
0/0 22
22 40
40 1/10
1/10
22 0/0
0/0 0/0
0/0 24
24 40
40 1/10
1/10
33 0/0
0/0 0/0
0/0 26
26 40
40 1/10
1/10
...
...
The show policy-map interface command shows the service policy applied to an
interface, including all WRED parameters implementing the dropping policy on that
interface.
Summary
n WRED can be used inside the Cisco IOS CB-WFQ, configured via the MQC
n WRED can be applied per-service policy
n All WRED parameters are inherited from the traditional Cisco IOS WRED
implementation
Lesson Review
1. How does WRED supplement CB-WFQ?
2. Can WRED be combined with flow-based WFQ in the default class?
3. Which two operational modes does WRED support?
4. How many profiles does WRED support?
Class-based Low-latency Queuing
Overview
This lesson describes the Low-latency Queueing (LLQ) feature within the CB-
WFQ system.
Objectives
n Describe Class-based Low-latency Queuing (CB-LLQ)
n Configure CB-LLQ
n Monitor and troubleshoot CB-LLQ
• VoIP or other multimedia applications should

not be fair-queued with other data
• IP RTP Prioritization has a number of
drawbacks:
– It is not selective enough (filters only on UDP port
range)
– It does not support TCP or other protocols
– You can only specify overall high-priority traffic
rate
• Class-based Low-latency Queuing (CB-LLQ)
removes most of the drawbacks of IP RTP
Prioritization
While Weighed Fair Queuing (WFQ) provides a fair share of bandwidth to every
flow, and provides fair scheduling of its queues, it cannot provide guaranteed
bandwidth and low delay to select applications. Voice traffic, for example, may still
compete with other aggressive flows in the WFQ queuing system, which lacks
priority scheduling for time-critical traffic classes.
IP RTP Prioritization is one Cisco IOS feature designed to guarantee priority of
voice traffic. However, because it only can only prioritize pure RTP traffic (IP
RTP Prioritization uses a UDP port range heuristic to distinguish RTP from the
rest of the traffic), and lacks flexibility in policing, it does not present a via ble
solution when multiple non-RTP time-critical applications are deployed in the
network.
Class-based Low-latency Queueing (CB-LLQ) is a method, used within the CB-
WFQ framework, which can prioritize traffic flows with the flexibility of the Cisco
IOS MQC interface.
Low-Latency Queueing
Queuing and Scheduling
Class BW Priority
Forwarder Priority Yes Policing Yes
queue
(FIFO)
No
Class BW
Priority Yes Policing
No
WFQ
Class
Yes
Flow queue Scheduling
N? (FIFO)
No
Class
Default?
WFQ/FIFO
When CB-WFQ is configured as the queueing system, it creates a number of

queues, into which it classifies traffic classes. These queues are then scheduled
with a WFQ-like scheduler, which can guarantee bandwidth to each class.
If Class-based Low-latency Queuing is used within the CB-WFQ system, it
creates additional, priority queues in the WFQ system, which are serviced by a
strict priority scheduler. Any class of traffic can therefore be attached to a service
policy, which uses priority scheduling, and hence can be prioritized over other
classes.
CB-LLQ Scheduling
• High-priority classes are guaranteed:

– Low-latency propagation of packets
– Bandwidth
• High-priority classes are also policed – they
can not exceed the guaranteed bandwidth
The CB-LLQ priority scheduler guarantees both low-latency propagation of

packets and bandwidth to high-priority classes. Low-latency is achieved by
expediting traffic using a priority schedule r. Bandwidth is also guaranteed by the
nature of priority scheduling, but is policed to a user-configurable value. Policing of
priority queues also prevents the priority scheduler from monopolizing the CB-
WFQ scheduler and starving non-priority classes, like legacy Priority Queuing
does.
Configuring CB-LLQ
priority bandwidth
• Allocate a fixed amount of bandwidth (in kbps) to a

class and ensure expedited forwarding
• Traffic exceeding the specified bandwidth is dropped
priority percent percent
• Allocate a percentage of configured or default

interface bandwidth to a class and ensure expedited
forwarding
• Traffic exceeding the specified bandwidth is dropped
Configured by the priority command, LLQ enables the use of a single priority
queue within CBWFQ at the class level, allowing the user to direct traffic
belonging to a class to the CBWFQ priority queue. To enqueue class traffic to the
priority queue, configure the priority command for the class after the named class
is specified within a policy map. Classes to which the priority command is applied
are considered priority classes. One or more classes can be given priority status
within a policy map. When multiple classes within a single policy map are
configured as priority classes, all traffic from these classes is enqueued to the
same, single, priority queue.
The bandwidth and percent options allocate a fixed amount of bandwidth (in
kbps) to the priority class, using absolute or relative bandwidth respectively. The
priority queue is policed using this bandwidth parameter and all exceeding packets
are dropped.
Keep the following guidelines in mind when using the priority command:
n Layer 2 encapsulations are accounted for in the amount of bandwidth specified
with the priority command. However, ensure a bandwidth is configured that
has room for cell-tax overhead and possible jitter introduced by the routers in
the voice path.
n Use the priority command for VoIP on serial links and ATM PVCs. It does
not support VoIP over Frame Relay links.
n Use the priority command in conjunction with the set command. You cannot
use the priority command in conjunction with any other command, including
the random-detect, queue-limit, and bandwidth commands.
n You can configure the priority command in multiple classes, but you should
only use it for voice-like, constant bit rate (CBR) traffic. If the traffic is not
CBR, you must configure a large enough bandwidth parameter to absorb the
data bursts.
CB-LLQ
Example
class-map
class-map VoIP
VoIP
match
match ip
ip precedence
precedence 55
!!
class-map
class-map Gold
Gold
match
!!
class-map
class-map Silver
Silver
match
match ip
ip precedence
precedence 11 22
!!
policy-map
policy-map Policy1
Policy1
class
class VoIP
priority
priority percent
percent 10
10
class
class Gold
Gold
bandwidth
bandwidth percent
percent 30
30
random-detect
random-detect
class
class Silver
bandwidth
bandwidth percent
percent 20
20
random-detect
random-detect
class
class class-default
class-default
fair-queue
fair-queue
random-detect
random-detect
!!
This figure shows a configuration example, where the VoIP traffic class, classified
by the IP precedence of 1, is queued in a priority queue within the CB-WFQ
system. The priority class received priority scheduling compared to other classes’
queues, and is guaranteed, but limited to 10 percent of bandwidth.
CB-LLQ
Router#show
Router#show policy-map
fastethernet 0/0
0/0
FastEthernet0/0
FastEthernet0/0
Service-policy
output: LLQ
LLQ
Class-map:
Class-map: LLQ
LLQ (match -any)
(match-any)
00 packets,
packets, 00 bytes
bytes
55 minute
minute offered
offered rate
rate 00 bps,
bps, drop
drop rate
rate 0 bps
0 bps
Match:
Match: any
Weighted
Weighted Fair
Fair Queueing
Queueing
Strict
Strict Priority
Priority
Output
Output Queue: Conversation 264
Bandwidth
Bandwidth 1000
1000 (kbps)
(kbps) Burst
Burst 25000
25000 (Bytes)
(Bytes)
(pkts
(pkts matched/bytes
matched) 0/0
0/0
(total
(total drops/bytes
drops/bytes drops)
drops) 0/0
0/0
Class-map:
Class-map: class -default (match
class-default -any)
(match-any)
00 packets,
packets, 0 bytes
55 minute
minute offered
offered rate
rate 0
0 bps,
bps, drop
drop rate
rate 0 bps
0 bps
Match:
Match: any
any
The show policy-map interface command shows the service policy settings on an
interface. The priority scheduling method is listed, if enabled.
Summary
n CB-LLQ guarantees priority scheduling with guaranteed bandwidth on an
interface
n CB-LLQ is integrated with CB-WFQ and configured via the Cisco IOS MQC
n CB-LLQ is more flexible than IP RTP Prioritization
Lesson Review
1. What advantages does CB-LLQ have over IP RTP Prioritization?
2. What guarantees does CB-LLQ provide?
Overview
This lesson section describes the Class-based Policing mechanism used within the
CB-WFQ system. The lesson also compares Class-based Policing implementation
with the standalone CAR mechanism.
Objectives
n Describe Class-based Policing
n Configure CB-Policing
n Monitor and troubleshoot CB-Policing
• Class-based Policing is used to limit a traffic

class to a configured bit rate
• It uses a Token Bucket model to measure the
arrival rate of packets
• Class-based Policing is an improved version
of the Committed Access Rate (CAR)
mechanism
• Class-based Policing is configured using the
Modular QoS CLI
Class-based Policing allows the servic e provider to rate-limit traffic in and out of
the router interfaces to a configured bit rate, thereby enabling various forms of
ingress and egress rate-limiting in a network. Class-based policing is implemented
within the CB-WFQ queueing method, and configured via the Cisco IOS MQC.
Like Committed Access Rate (CAR), Class-based Policing simply rate-limits
traffic according to a simple “forward or drop” policy, according to the
configuration. Class-based policing also uses a token-bucket metering mechanism,
similar to CAR, but with some modification and added flexibility.
How do Routers Measure Traffic
Rate
Bandwidth
Link bandwidth
Exceeding traffic
Rate limit
Conforming Traffic
Time
• Routers use the Token Bucket mathematical model to keep
track of packet arrival rate
• The Token Bucket model is used whenever a new packet is
processed
• The return value is conform or exceed
In order to perform rate limiting, routers must meter (or measure) traffic rates
through its interfaces. To enforce a rate limit, metered traffic is said to:
n Conform to the rate limit, if the rate of traffic is below the configured rate limit
n Exceed the rate limit, if the rate of traffic is above the configured rate limit
The metering is usually performed with an abstract mathematical model called a
token bucket, which is used when processing each packet. The token bucket can
calculate whether the current packet conforms or exceeds the configured rate limit
on an interface.
Token Bucket
700
500 bytes Conform Action 500 bytes
The token bucket is a mathematical model used in a device that regulates the data
flow. The model has two basic ingredients:
n Tokens, where each token represents the permission to send a fixed number of
bits into the network
n The bucket, which has the capacity to hold a specified amount of tokens
Tokens are put into the bucket at a certain rate by the operating system. Each
incoming packet, if forwarded, takes tokens from the bucket, representing the
packet’s size. If not enough tokens are available in the bucket to send the packet,
the policer discards the packet. If the bucket fills to capacity, newly arriving tokens
are discarded, and discarded tokens are not available to future packets.
The figure shows a token bucket, with the current capacity of 700 bytes. When a
500-byte packet arrives at the interface, its size is compared to the bucket capacity
(in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), the
packet is forwarded, and 500 bytes worth of tokens are removed from the bucket.
Token Bucket
200
300
byte
s
When the next packet arrives immediately after the first packet, and because no
new tokens have been added to the bucket (which is done periodically), there are
not enough tokens in the bucket to represent the current packet. The current
packet therefore exceeds the rate limit and is dropped.
Token Bucket
Be
Link BW
Bc of tokens is added Link
Utilization
every Tc [ms]
Bc Bc Bc Bc Bc Bc Average BW
Tc = Bc / CIR (CIR)
Tc 2*Tc 3*Tc 4*Tc 5*Tc Time
Be
• Bc is normal burst size (specifies sustained rate)

• Be is excess burst size (specifies length of burst)
Token bucket implementations usually rely on three parameters: CIR, Bc and Be.
CIR is the Committed Information Rate (also called the committed rate), which
represents the long-term average rate of traffic. Bc is known as the burst capacity.
Be is known as the excess burst capacity. Tc is a time interval constant.
In the token bucket metaphor, tokens are put into the bucket at a certain rate,
which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If
the bucket fills to capacity (Bc + Be), newly arriving tokens are discarded. Each
token is permission for the source to send a certain number of bits into the
network. To send a packet, the regulator must remove, from the bucket, the
number of tokens equal in representation to the packet size.
For example, if 8000 bytes worth of tokens are placed in the bucket every 125
milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if
traffic constantly arrives at the router.
If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the
bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore
collects 64000 bytes worth of tokens, which can be transmitted immediately in the
case of a burst. The upper limit, Bc+Be, defines the maximum amount of data,
which can be transmitted in a single burst, at the line rate.
A token bucket permits burstiness but bounds it. It guarantees that the burstiness is
bounded so that the flow will never send faster than the token bucket's capacity.
This means, that in the long-term, the transmission rate will not exceed the
established rate at which tokens are placed in the bucket (the committed rate).
• CAR uses one single token bucket to

determine if a packet conforms to or exceeds
the bit-rate policy
• CB-Policing uses one or two token buckets
to determine if a packet:
– Conforms – is within the average bit rate
– Exceeds – exceeds the average bit rate but is
within the allowed excess burst
– Violates – exceeds both the average bit rate and
the allowed excess burst (optional)
When CAR is in effect, its metering code uses a single token bucket, and is able to
determine whether incoming traffic conforms or exceeds the configured rate-limit.
Class-based Policing introduces a two-token-bucket scheme in the policer. Using
two token buckets, traffic can:
n Conform to the rate limit, when it is within the average bit rate
n Exceed the rate limit, when it exceeds the average bit rate, but does not
exceed the allowed excess burst
n Violate the rate limit, when it exceeds both the average rate and the excess
bursts.
The double token bucket method is explained later in the lesson.
Class-based Policing Actions
• CB-Policing can execute three different

actions (conform, exceed or violate)
• Each action can be one of the following:
– Transmit
– Drop
– Set IP Precedence and transmit
– Set IP DSCP and transmit
– Set QoS group and transmit
– Set MPLS experimental bits and transmit
– Set Frame Relay DE bit and transmit
– Set ATM CLP bit and transmit
Based on the current packet conforming, exceeding, or violating the rate limit, an
action can be taken by the policer. The CB-WFQ policer supports the following
actions:
n Transmit—the packet is transmitted
n Drop—the packet is dropped
n Set precedence (or DSCP value) and transmit: the IP Precedence (ToS)
or DSCP bits in the packet header are rewritten. The packet is then
transmitted. This action can be used to either color (set precedence) or
recolor (modify existing packet precedence) the packet.
n Set QoS group and transmit: the QoS group can be set and then used only
locally within the router. The QoS group can be used in later QoS mechanisms
and performed in the same router, such as CB-WFQ. The packet is then
transmitted.
n Set MPLS experimental bits and transmit: the MPLS experimental bits
can be set. The packet is then transmitted. These are usually used to signal
QoS parameters in a MPLS cloud.
n Set Frame Relay DE bit and transmit: the Frame Relay Discard Eligibility
(DE) bit is set in the Layer-2 (Frame Relay) header and the packet is
transmitted. This setting can be used to mark excessive or violating traffic
(which should be dropped with preference on Layer-2 switches) at the edge of
a Frame Relay network.
n Set ATM CLP bit and transmit: the ATM Cell Loss Priority (CLP) bit is
set in the Layer-2 (ATM) header and the packet is transmitted. This setting
can be used to mark excessive or violating traffic (which should be dropped
with preference on Layer-2 switches) at the edge of an ATM network.
Single Token Bucket with
700 BE
500 bytes Conform Action
• Packet conforms to the policy if the size of

the packet is less or equal to the number of
tokens in the TB
Class-based Policing can use a single or double token bucket method as the
metering mechanism. The one token bucket algorithm is used when the violate-
action option is not specified in the police MQC command.
If one token bucket is used, the meter can only differentiate between conforming
and exceeding traffic. Therefore, in a simple single token bucket algorithm, a
packet conforms to the line rate, if the size of the packet is less or equal to the
number of tokens in the token bucket.
The actual metering algorithm used by CB-Policing is somewhat different from a
pure token bucket, described above, and used by CAR. With CAR, the token
bucket is refilled at periodic intervals (Tc) with a fixed number of tokens (Bc).
Class-based policing employs a different method, which calculates the bucket size
and adds tokens on every processed packet. The Class-based policing works in the
following manner:
n The token bucket is initially set to the full size (the full size is the number of
bytes specified as the normal burst size or Bc)
n When a packet of size B bytes arrives at time t the following actions occur:
– Tokens are updated in the conform bucket. If the previous arrival of
the packet was at t1 and the current time is t, the bucket is updated
with (t-t1) worth of bits based on the token arrival rate. The per-
packet token arrival rate is calculated as:
(time between consecutive packets * policer rate)/8 bytes
– If the number of bytes in the conform bucket - B is greater than or
equal to 0, the packet conforms and the conform action is taken on the
packet. If the packet conforms, B bytes are removed from the
conform bucket and the conform action is completed for the packet.
– If the number of bytes in the conform bucket - B is less than 0, the
exceed action is taken.
Single Token Bucket with
200 BE
• Packet exceeds the policy if the size of the

packet is more than the number of tokens in
the TB
When a packet size is more than the available number of tokens in a TB, the
packet exceeds the rate limit. Again, this is a simplified algorithm for a pure token
bucket. Class-based policing uses a slightly different algorithm, which was
described previously.
Double Token Bucket with
700 BC 400 BE
500 bytes Conform Action
• Packet conforms to the policy if the size of

the packet is less or equal to the number of
tokens in the first TB
Cisco IOS Class-based policing uses a double token bucket metering method, when
the violate action is specified in the police MQC command. One bucket is used to
meter conforming traffic (the conform bucket), and is of size BC. The other bucket
is used to meter exceeding traffic, and is of size BE.
The conform bucket is initially full (the full size is the number of bytes specified as
the normal burst size, BC). The exceed bucket is also initially full (the full exceed
bucket size is the number of bytes specified in the maximum burst size, BE). The
tokens for both the conform and exceed token buckets are updated based on the
token arrival rate (or CIR).
In simple terms, with the double token bucket system, an incoming packet
conforms to the rate limit, if the conform bucket has enough tokens for the size of
the packet.
Looking into the details of the algorithm, the actual processing which occurs is as
follows:
n A packet of size B bytes arrives at time t
n Tokens are updated in the conform bucket. If the previous arrival of the packet
was at t1 and the current arrival of the packet is at t, the bucket is updated
with t-t1 worth of bits based on the token arrival rate. The refill tokens are
placed in the conform bucket. If the tokens overflow the conform bucket, the
overflow tokens are placed in the exceed bucket.
The token arrival rate is calculated as follows:
(time between packets<which is equal to t-t1> * policer rate)/8 bytes
n If the number of bytes in the conform bucket - B is greater than or equal to 0,
the packet conforms and the conform action is taken on the packet. If the
packet conforms, B bytes are removed from the conform bucket and the
conform action is taken. The exceed bucket is unaffected in this scenario.
n If the number of bytes in the conform bucket - B is less than 0, the excess
token bucket is checked for bytes by the packet. If the number of bytes in the
exceed bucket - B is greater than or equal to 0, the exceed action is taken and
B bytes are removed from the exceed token bucket. No bytes are removed
from the conform bucket.
n If the number of bytes in the exceed bucket - B is less than 0, the packet
violates and the violate action is taken. The action is complete for the packet.
200 BC 400 BE
• Packet exceeds the policy if the size of the packet is

more than the number of tokens in the first TB and
less or equal to the number of tokens in the second
TB
If looking at the double token bucket in a simplified way, an incoming packet would
exceed the rate limit, if the conform bucket does not have enough tokens for the
size of the packet, but the exceed bucket does.
For a detailed insight, consult the previously laid-out algorithm.
200 BC 100 BE
400 bytes Violate Action
• Packet violates the policy if the size of the

packet is more than the number of tokens in
the first and the second TB
In simple terms, the double token bucket system means that an incoming packet
violates the rate limit, if neither the conform nor the exceed buckets have enough
tokens for the size of the packet.
For a detailed insight, consult the previously laid-out algorithm
Refilling the Token Buckets
Add tokens at the Excess spills over

configured bit rate into the second
token bucket
BC TB1
TB2 BE
• The number of tokens that have to be added is actually

calculated every time a new packet has to be processed:
TB1 = min(B C, TB1 + (Tnow -TLastPacket) * BitRate / 8)
Time of the
New size of Previous Time now last packet
the token size of the [seconds] [seconds]
bucket token bucket
The detailed token bucket algorithms are somewhat different from the classic
token bucket algorithms used by CAR and GTS. Token refilling is done per packet,
which can considerably smooth out rate limiting, because there is no fixed interval
(Tc) for bucket refills.
Instead, the calculation
TB1_after = min(BC, TB1_before + (Tnow -TLastPacket ) * BitRate / 8)
where TB1 is the token bucket size, BC is the maximum conform token bucket
size, Tnow is the current time, TLastPacket is the time of arrival of the previous packet,
and the BitRate is the CIR of the rate limit, defines the new size of the conform
bucket, and is calculated for each incoming packet. If the number of tokens
exceeds the size of the conform bucket (BC), excess tokens spill over and fill the
second (exceed) bucket. If the exceed bucket overflows with tokens, those tokens
are lost.
The new token bucket size, therefore, equals to the BC (Conform Bucket Size) or
the “Previous bucket size + added tokens since the last packet was transmitted”,
which ever is smaller.
Configuring Class-based Policing
police avg-rate [BCC [BEE]] [conform-action [action]
[exceed-action [action] [violate-action [action]]]]
• avg-rate – traffic rate in bps (8.000 to 200.000.000)
• BC – normal burst sets the size of the first token bucket in bytes
(default is 1500 or avg-rate/32; whatever is higher)
• BE – excess burst sets the size of the second token bucket in
bytes (equals BC if not configured)
• action – can be:
• transmit (default conform action)
• drop (default exceed and violate action)
• set-prec-transmit ip-precedence
• set-dscp-transmit dscp
• set-qos-transmit qos-group
• set-mpls-exp-transmit mple-exp
• set frde-transmit
• set-clp-transmit
The police MQC command defines policing parameters for a traffic class. The
avg-rate parameter defines the policed average traffic rate (CIR), the BC and
BE define the double token bucket sizes, and the action defines an action for
conforming, exceeding, and optionally violating traffic.
Class-based Policing Example
• The customer can locate his server at service

provider premises (switched LAN)
• CB-Policing is used to limit the amount of traffic the
web server can generate (more flexible per-
bandwidth pricing)
• Unknown traffic is rate-limited to 64 kbps to allow
remote configuration of new servers
This example uses Class-based Polic ing to perform rate-limiting of end-station

traffic. The example setting is a hosting-farm, where a service provider needs to
limit the amount of traffic a web-server can send towards its clients. All traffic
from a particular server will be rate-limited according to a contract, and 64 kbps of
bandwidth will be reserved for unknown traffic, such as future provisioning and
configuration of new servers in the farm.
Class-based Policing Example
class-map
class-map www.acme.com
www.acme.com
match
match source-address
source-address mac
mac 000d.dddf.0480
000d.dddf.0480
!!
class-map
class-map www.void.com
www.void.com
match
match source-address
source-address mac
mac 000d.dddc.ad21
000d.dddc.ad21
!!
policy-map
policy-map ServerFarm
class www.acme.com
police
police 128000
128000 conform-action
conform-action transmit
transmit exceed-action
exceed-action drop
class www.void.com
police
police 256000
256000 conform-action
transmit exceed-action
exceed-action drop
class class-default
police 64000
!!
interface
interface FastEthernet
FastEthernet 0/0
service-policy input ServerFarm
!!
The configuration example shows three configured traffic classes, two based on
upstream MAC addresses, and one on the default traffic class. Traffic from
particular servers is policed to a fixed bandwidth, and exceeding traffic is dropped.
If Bc and Be are not specified within the police command, the default value will
be used.
CB-Policing
Router #show policy
Router#show policy interface
fastethernet 0/0
0/0
FastEthernet0/0
FastEthernet0/0
Service-policy input: ServerFarm (1207)
Service-policy input: ServerFarm (1207)
Class-map:
Class-map: www.acme.com
www.acme.com (match-all)
(match-all) (1209/6)
(1209/6)
00 packets,
packets, 00 bytes
bytes
55 minute
minute offered
offered rate
rate 0 bps,
Match:
Match: ip
ip precedence
precedence 44 (1213)
(1213)
Match:
Match: source-address
source-address macmac 000D.DDDF.0480
000D.DDDF.0480 (1217)
(1217)
police:
police:
128000
128000 bps,
bps, 4000
4000 limit,
limit, 4000
4000 extended
extended limit
limit
conformed
packets, 00 bytes;
bytes; action:
action: transmit
transmit
exceeded
packets, 00 bytes;
bytes; action:
action: drop
drop
conformed
conformed 0 bps, exceed 0 bps violate 0 bps
0 bps, exceed 0 bps violate 0 bps
...
...
Class-map:
(match-any) (1229/0)
(1229/0)
00 packets,
packets, 00 bytes
bytes
55 minute offered rate
minute offered rate 0 bps,
Match:
Match: any
any (1233)
(1233)
police:
police:
64000
64000 bps,
bps, 2000 limit, 2000 extended limit
conformed
packets, 00 bytes;
bytes; action:
action: transmit
transmit
exceeded
packets, 00 bytes;
bytes; action:
action: drop
drop
conformed
conformed 0 bps, exceed 0 bps violate 0 bps
0 bps, exceed 0 bps violate 0 bps
...
...
the interface. Among the settings, policing parameters and statistics are displayed.
For the www.acme.com class, the CIR was set to 128000 bps, the BC defaults to
128000/32 or 4000 bytes and BE defaults to BC or 4000 bytes also.
Summary
n Like CAR, Class-based Policing provides rate limiting of traffic
n Class-based policing is integrated with CB-WFQ
n Class-based policing uses a modified double token bucket mechanism for
metering
Lesson Review
1. What do CAR and Class-based Policing do?
2. What are the main differences between CAR and Class-based Policing?
3. What marking options does Class-based Policing support?
4. What actions does do Class-based Policing support?
Class-based Shaping
Overview
This lesson describes the Class-based Shaping mechanism. The lesson also
compares the Class-based Shaping implementation with the standalone GTS
mechanism.
Objectives
n Describe Class-based Shaping
n Configure CB-Shaping
n Monitor and troubleshoot CB-Shaping
Class-based Shaping
• Use of Class-based Shaping is similar to that

of Class-based Policing
• CB-Shaping is used to rate-limit packets
• Delays exceeding packets rather than
dropping them
• Has no marking capabilities
• CB-Shaping is a version of Generic Traffic
Shaping (GTS) using the Modular QoS CLI
Class-based Shaping, like Class-based Policing, is used to rate-limit traffic within

the CB-WFQ queueing system. Class-based Shaping works by metering the traffic
rate and delaying excessive packets until they conform to the configured shaped
rate.
Class-based Shaping is very similar to Generic Traffic Shaping (GTS), but is
implemented as a part of the CB-WFQ system and is configured via the Cisco IOS
MQC. Like GTS, Class-based Shaping has no packet marking capability.
CB-Shaping
CB-Shaping
Check
Add tokens shaping
queue N
Token
BC+BE Bucket Enough
Do nothing
Tokens? No
Tokens Yes
Packet
size
Shaping Queue N packet Forward Queue N
• Router periodically updates the token bucket (every TC ) and

checks if any packets can be forwarded to the main queue
• T C = BC / BitRate
CB-Shaping uses the basic token bucket mechanism, where BC tokens are added
at every TC time interval. If enough tokens are present in the bucket when a
packet arrives, the packet is immediately forwarded. Otherwise, the packet is
delayed in the shaping queue, until enough tokens are available.
The router periodically checks the shaping queue by doing the following:
1. Add BC of tokens to the token bucket.
2. Check if there are enough tokens to forward a packet from the shaping
queue to the main class queue. The size of the first packet in the shaping
queue must be smaller or equal to the number of tokens in the token
bucket. Repeat this step until there is no longer enough tokens to forward a
packet or the shaping queue is empty.
3. If there are not enough tokens the router stops processing the shaping
queue for another period of TC.
Refilling the Token Bucket
• CB-Shaping has two shaping methods:

– Shaping to the configured average rate (adds B C
tokens every TC)
– Shaping to the peak rate (adds BC+B E tokens every
TC)
• Average rate is forwarding packets at the
configured average rate with allowed
bursting up to B E when there are extra
tokens available
• Peak rate is forwarding packets at the peak
rate which is calculated using this formula:
PeakRate = AvgRate * (1+BE/BC)
Class-based Shaping can be configured in two different ways:

n Shaping to the average rate, which uses the normal token bucket refilling
method, adding BC tokens every TC time interval
n Shaping to the peak rate, which adds BC+BE tokens every TC time interval
Shaping to the average rate behaves like standard GTS; it establishes a long-term
average rate, with bursts of up to BE allowed, when enough tokens are in the
bucket. Shaping to the peak rate sends traffic at the peak rate, which is defined as
the average rate, multiplied by (1+BE/BC). This translates to sending packets at the
average rate of the excess burst size all the time, which may result in dropping in
the WAN cloud.
Configuring CB-Shaping
shape {average | peak} bit-rate [BCC [BEE]]
• BC and BE can be omitted to let the router select the

optimal values
shape max-buffers queue-limit
• Set the maximum number of packets that can be

stored in the shaping queue
The shape average and shape peak commands configure average and peak
shaping respectively within the CB-WFQ system.
The shape max-buffers command specifies the maximum size of the shaping
queue. The shaping queue delays packets until they conform to the shaping rate. If
the shaping queue is full, packets are tail-dropped.
CB-Shaping Frame Relay
Adaptation
shape adaptive mir-rate
• Adapts the shaping rate when BECN bits are

received
• Each BECN bit causes the shaping rate to be
reduced to three quarters of the previous rate but not
below the min-rate
• This command has effect only if used on Frame
Relay interfaces
shape
shape fecn-adapt
fecn-adapt
• Responds to FECN bits by creating test frames in the

opposite direction with the BECN bit set
Class-based Shaping is able to respond to Layer-2 congestion by reducing its

shaping rate to three-quarters of the current rate, until the Layer-2 network
recovers from congestion. When BECN flags are no longer received, the rate is
slowly ramped up again to the original shaping rate. This is also a lower limit of
rate reduction, which bounds the reduction process so that at least some throughput
is maintained. The BECN-integrating functionality is performed on a per sub-
interface (DLCI) basis.
The shape adaptive command configures the Class-based Shaping system to
adapt the shaping rate to BECN indications, as described above. The min-rate
parameter specifies the minimum shaping rate allowed.
However, if the congestion was caused by simplex traffic (such as a multicast
video stream) or by an aggressive TCP connection, it is expected that the reverse
traffic (frames flowing from the receiver to the sender, marked with the BECN
bit) might come by less frequently than required to feed the integration. So the
receiving DTE (the receiving router) can help matters when it receives a message
with FECN set by first checking to see if it has any data, and if it does not,
originating a message with BECN set. This message might be a Q.922 TEST
RESPONSE message, which would, by virtue of its message type, be understood
to be a message to discard and not reply to. This feature is called FECN-to-BECN
propagation.
The shape fecn-adapt command configures the Class-based Shaping system to
respond to FECN-marked frames with BECN TEST frames.
CB-Shaping
Example
class-map
class-map Shape
Shape
match
match access-group
access-group 123123
!!
policy-map
policy-map ShapeAvg
S hapeAvg
class Shape
Shape
shape
shape average 16000
16000 1024
1024 2048
!!
policy-map
policy-map ShapePeak
S hapePeak
class Shape
Shape
shape
shape peak
peak 16000
16000 1024 2048
!!
interface
interface Serial0/0
Serial0/0
service-policy
service-policy output ShapeAvg
!!
interface
interface Serial0/1
Serial0/1
service-policy
service-policy output ShapePeak
!!
access-list
access-list 123 permit udp any any
This figure shows an example configuration for Class-based Shaping. All UDP
traffic is classified into one class, which is shaped differently on two interfaces. On
the Serial0/0 interface, all UDP traffic is shaped to the average rate, while on the
Serial0/1 interface, all UDP traffic is shaped to the peak rate.
CB-Shaping
Router#show
Serial0/0
Serial0/0
Service-policy
output: ShapeAvg
Class-map:
Class-map: Shape
Shape (match-all)
(match-all)
782
782 packets,
packets, 728824
728824 bytes
bytes
55 minute
minute offered rate
offered rate 24000
24000 bps,
bps, drop
drop rate
rate 22000
22000 bps
bps
Match:
Match: access-group
access -group 123
123
Traffic
Traffic Shaping
Target
Target Byte
Byte Sustain Excess Interval Increment
Increment Adapt
Adapt
Rate
Rate Limit bits/int
bits/int bits/int
bits/int (ms)
(ms) (bytes)
(bytes) Active
Active
16000
16000 384
384 1024
1024 2048
2048 64
64 128
128 --
Queue
Queue Packets
Packets Bytes
Bytes Packets
Packets Bytes
Bytes Shapin
Shapingg
Depth
Depth Delayed
Delayed Delayed
Delayed Active
Active
64
64 135
135 125820
125820 134
134 124888
124888 yes
yes
Class-map:
Class-map: class -default (match
class-default -any)
(match-any)
99 packets,
packets, 3234
3234 bytes
bytes
55 minute
minute offered
offered rate
rate 0 bps, drop rate 0 bps
Match:
Match: any
the interface. Among the settings, shaping parameters and statistics are displayed.
Summary
n Class-based Shaping rate-limits traffic by delaying it in a shaping queue
n Class-based Shaping meters traffic like GTS, using a single token bucket
n Class-based Shaping is integrated into the CB-WFQ queuing system,
configured via the Cisco IOS MQC
Lesson Review
1. What are the main differences between CB-Policing and CB-Shaping?
2. What two shaping methods does CB-Shaping support?
Class-based Marking
Overview
This lesson describes the Class-based Marking capability of the Cisco IOS
Modular QoS CLI (MQC).
Objectives
n Describe Class-based Marking
n Configure CB-Marking
n Monitor and troubleshoot CB-Marking
Class-based Marking
• Class-based Marking is an additional tool

available with the Modular QoS CLI that
allows static per-class marking of packets
• It can be used to mark inbound or outbound
packets
• It can be combined with any other QoS
feature on output
• It can be combined with CB-Policing on input
Marking packets or frames lets you set information in the Layer 2, 3, or 4 headers,
or even set information within the payload of a packet, so the packet or frame can
be identified and distinguished from other packets or frames.
The CB-WFQ queuing system provides packet marking capabilities, using Class-
based Marking, which is configured within the Cisco IOS MQC feature. It is
perhaps the most flexible IOS marking tool, extending the marking functionality of
CAR and policy routing.
Class-based Marking can be used on input or output of interfaces, as a part of an
input or an output service policy. On input, Class-based Marking can be combined
with Class-based Policing, and on output, with any other CB-WFQ QoS feature.
Class-based Marking
• Packets can be marked with one of the

following markers:
– IP Precedence
– IP DSCP
– QoS Group
– MPLS Experimental bits
– IEEE 802.1Q or ISL CoS/Priority bits
– ATM CLP bit
Class-based Marking supports the following markers:

n IP precedence
n IP DSCP value
n QoS group
n ATM CLP bit
n IEEE 802.1Q or ISL CoS/priority bits
Class-based marking can be combined with other mechanisms available in the
Modular QoS CLI.
Configuring IP Precedence
Marking
set ip precedence ip-precedence
• Mark IP packets with the specified IP precedence value
• IP precedence can be set using a value (0 to 7) or a
corresponding name (e.g. routine, priority, immediate)
policy-map
policy-map SetPrec
SetPrec
class
class Class1
Class1
set ip precedence priority
class
class Class2
Class2
set
set ip
ip precedence
precedence flash
flash
class
class Class3
Class3
set ip precedence 5
!!
IP precedence is encoded into the three high-order bits of the ToS field in the IP
header. It supports eight classes of which two are reserved and should not be used
for user-defined classes (IP precedence 6 and 7). IP precedence 0 is the default
value and is usually used for the best-effort class. The set ip precedence
command marks packets of a class with the specified precedence value.
Configuring IP DSCP Marking
set ip dscp dscp
• Mark IP packets with the specified DSCP value
• DSCP can be set using a value (0 to 63) or a corresponding
name (e.g af11, af12, af13, af21, ef, cs1, default)
policy-map
policy-map SetDSCP
SetDSCP
class
class Class1
Class1
set ip dscp af11
class
class Class2
Class2
set ip dscp af21
class
class Class3
Class3
set ip dscp ef
!!
DiffServ is a new model that supercedes, and is backward compatible with, IP

Precedence. DiffServ uses 6 prioritization bits, which permits classification of up to
64 values (0-63). A DiffServ value is called a Differentiated Services Code Point
(DSCP).
The set ip dscp command is used to mark packets of a class with a DSCP value.
Configuring QoS Group Marking
set qos-group qos-group
• Mark packets with the specified QoS group value (0

to 99)
policy-map
policy-map SetQoS
SetQoS
class
class Class1
Class1
set qos-group 1
class
class Class2
Class2
set qos-group 2
class
class Class3
Class3
set qos-group 3
!!
Class-based Marking can mark packets with the QoS group value. The QoS
group is a parameter that is local to the router where it is set. It is not part of any
header. It is usually set on an input interface and later examined (matched) on
output interfaces. Once the packet is transmitted, the QoS-group information is
lost, and the next router must reclassify and mark the packet. QoS group supports
up to 100 distinct values (classes). The set qos-group command is used to set
the QoS group value to a packet inside a router. Values from 0 to 99 can be used
to mark packets.
Configuring MPLS Marking
set mpls experimental exp-bits
• Mark labeled packets with the specified value (0 to 7)

• MPLS marking can only be used on input
policy-map
policy-map SetMPLS
SetMPLS
class
class Class1
Class1 qos-group
qos-group 11
set mpls
mpls experimental
experimental 11
class
class Class2
Class2 qos-group
qos-group 22
set mpls
mpls experimental
experimental 22
class
class Class3
Class3 qos-group
qos-group 22
set mpls
mpls experimental
experimental 33
!!
Cisco IOS also supports marking of MPLS frames, which is used to set MPLS
CoS parameters. The three EXP(erimetal) bits inside the MPLS label are used,
and the set mpls experimental command is used within the MQS to mark MPLS
frames with CoS information. Values from 0 to 7 can be used to mark MPLS
frames.
Configuring LAN Marking
set cos cos
• Mark frames with the specified value (0 to 7)
• The value applies to the Class of Service bits with the IEEE
802.1Q encapsulation or Priority bits with the ISL encapsulation
• The command can only be used on output LAN interfaces that
are using one of the two mentioned encapsulations
policy-map
policy-map SetCoS
SetCoS
class
class Class1
Class1
set cos 1
class
class Class2
Class2
set cos 2
class
class Class3
Class3
set cos 3
!!
The IEEE 802.1p standard specifies a standard for delivering QoS in local area
networks (LANs). Packets are marked with three CoS bits, where CoS values
range from zero for low-priority to seven for high-priority. CoS can only be applied
on trunks, because only there is an encapsulation available with space for the bits:
n Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries
the CoS value in the three least significant bits.
n IEEE 802.1p and 802.1q frame headers have a 2-byte Tag Control Information
field that carries the CoS value in the three most significant bits, which are
called the User Priority bits.
Other frame types cannot carry CoS values.
In general, Layer 2 switches can examine, use, or alter MAC layer markings, not
IP precedence or DSCP settings, since those are Layer 3. Layer 2 markings are
generally applied on egress trunk ports.
Configuring Frame Relay DE
Marking
set fr-de
• Mark packets with the Frame Relay Discard Eligibility (DE) bit
value 1
• Do not use the command to mark frames with the default value 0
• The command can only be used on output Frame Relay
interfaces
policy-map
policy-map SetFR
SetFR
class
class Class1
Class1
set fr-de
fr-de
class
class Class2
Class2
class
class Class3
Class3
set fr-de
fr-de
!!
The user can specify which Frame Relay packets have low priority or low time
sensitivity and will be the first to be dropped when a Frame Relay switch is
congested. The mechanism that allows a Frame Relay switch to identify such
packets is the discard eligible (DE) bit. This bit is set for all packets of a class with
the set fr-de command.
This feature requires that the Frame Relay network be able to interpret the DE bit.
Some networks take no action when the DE bit is set. Other networks use the DE
bit to determine which packets to discard. The most desirable interpretation is to
use the DE bit to determine which packets should be dropped first and also which
packets have lower time sensitivity.
Configuring ATM CLP Marking
set atm-clp
• Mark cells of packets with the ATM Cell Loss Priority (CLP) bit
value 1
• Do not use the command to mark cells with the default value 0
• The command can only be used on output ATM interfaces
policy-map
policy-map SetATM
SetATM
class
class Class1
Class1
set atm-clp
atm-clp
class
class Class2
Class2
class
class Class3
Class3
set atm-clp
atm-clp
!!
The ATM CLP Setting feature somewhat allows users to extend their IP QoS
policies into an ATM network by setting the ATM CLP bit in ATM cells based on
the IP Precedence value of the packets being sent. As congestion occurs in the
ATM network, cells with the CLP bit set are more likely to be dropped, resulting in
improved network performance for high priority traffic and applications. The set
atm-clp command marks packets of a class with the ATM CLP bit as a part of an
input or output policy.
CB-Marking
Router #show policy

Router#show -map interface
policy-map interface serial
serial 0/0
0/0
Serial0/0
Serial0/0
Service-policy
Service-policy input:
input: SetMPLS
SetMPLS (1837)
(1837)
Class-map:
Class-map: Class1
Class1 (match-any)
(match-any) (1839/12)
(1839/12)
00 packets,
packets, 00 bytes
bytes
30
30 second
second offered
offered rate
rate 00 bps,
bps, drop
drop rate
rate 00 bps
bps
Match:
Match: qos-group
qos-group 11 (1843)
(1843)
00 packets,
packets, 00 bytes
bytes
30
30 second
second rate
rate 00 bps
bps
QoS
QoS Set
Set
mpls
mpls experimental
experimental 11
Class-map:
Class-map: Class2
Class2 (match-any)
(match-any) (1847/13)
(1847/13)
00 packets,
packets, 00 bytes
bytes
30
30 second
second offered
offered rate
rate 00 bps,
bps, drop
drop rate
rate 00 bps
bps
Match:
Match: qos-group
qos-group 22 (1851)
(1851)
00 packets,
packets, 00 bytes
bytes
30
30 second
second rate
rate 00 bps
bps
QoS Set
QoS Set
mpls
mpls experimental
experimental 22
...
...
the interface. Among the settings, marking parameters and statistics are displayed.
MQC
Compatibility Matrix
CB QoS Configuration Supported Can be combined with the following
mechanism command directions Class--based mechanisms
Class
WFQ bandwidth output WRED, Shaping, Policing, Marking
LLQ
LLQ priority output Shaping, Policing, Marking
WRED random--detect
random output WFQ, LLQ
Policing police input/output
input/output WRED, Shaping, WFQ, LLQ, Marking
Shaping shape output WRED, Policing, WFQ,
WFQ, LLQ,
LLQ, Marking
Marking
Marking set input/output
input/output WRED, Policing, Shaping, WFQ, LLQ
Output Classify Mark Police Shape WRED Queue Schedule
Input Classify Mark Police Forward
The figure shows the compatibility matrix of all QoS mechanisms within the
CB-WFQ system that can be configured via the Cisco IOS MQC. Supported
combinations of features are shown, as well as their processing sequence, and
applicability on input and output interfaces.
Summary
n Class-based Marking is the most flexible Cisco IOS marking tool
n Class-based Marking is implemented as a part of the CB-WFQ system
n Class-based Marking supports marking of IP packets and a variety of Layer-2
frames
Lesson Review
1. Which parameters can be set using CB-Marking?
2. Can CB-Marking be used on input?
3. Can CB-Marking be combined with any other QoS mechanisms?
Summary
n Describe the policy part of the Modular QoS CLI
n Configure packet marking with modular CLI
n Configure policing and shaping with modular CLI
n Configure class-based WFQ with modular CLI
n Configure congestion avoidance mechanisms (WRED) with modular CLI
n Configure low-latency queuing
n Monitor and troubleshoot policy maps
Service Policy
Question: What are the benefits of using MQC?
Answer: Template-based configuration; new classification options can be used
with any MQC-based QoS mechanism.
Question: How many classes can be used for one service policy?
Answer: The MQC allows up to 256 classes to be defined. One service policy
can use any number of classes. CB-WFQ is limited to 64 classes.
Class-based We ighted Fair Queuing

Question: What type of guarantee does CB-WFQ provide?
Answer: CB-WFQ provides bandwidth guarantees.
Question: Which DiffServ PHB can be implemented using CB-WFQ?
Answer: Assured Forwarding (AF) PHB can be implemented using CB-WFQ.
Question: What configuration steps are needed to configure CB-WFQ?
Answer:
a. Create class maps for all classes that require individual bandwidth
guarantees
b. Create a policy map and specify the bandwidth for each class
c. Apply the policy map to one or more interfaces where the same
policy is needed
Class-based WRED
Question: How does WRED supplement CB-WFQ?
Answer: WRED is used to prevent congestion within a class queue.
Question: Can WRED be combined with flow-based WFQ in the default class?
Answer: Yes.
Question: Which two operational modes does WRED support?
Answer: IP-precedence-based and DSCP-based.
Question: How many profiles does WRED support?
Answer: 8 profiles for IP-precedence-based WRED and 64 profiles for DSCP-
based WRED.
Question: What advantages does CB-LLQ have over IP RTP Prioritization?
Answer: CB-LLQ can use any classification supported by class maps. IP RTP
Prioritization can only classify based on a range of UDP port numbers.
Question: What guarantees does CB-LLQ provide?
Answer: CB-LLQ provides a bandwidth guarantee and minimum-delay
forwarding of packets.
Question: What do CAR and Class-based Policing do?
Answer: CAR and Class-based policing are primarily used to limit the rate of a
traffic cla ss by dropping excess packets.
Question: What are the main differences between CAR and Class-based Policing?
Answer: Class-based Policing uses the MQC and supports three different actions
(confirm, exceed and violate).
Question: What marking options does Class-based Policing support?
Answer: IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay
DE bit, ATM CLP bit.
Question: What actions does do Class-based Policing support?
Answer: CB-Policing supports the following actions: transmit, drop and set
(marker). A different action can be used depending on whether a packet conforms,
exceeds or violates the policy.
Class-based Shaping
Question: What are the main differences between CB-Policing and CB-Shaping?
Answer: CB-Shaping polices bandwidth by delaying exceeding packets instead
of dropping them.
Question: What two shaping methods does CB-Shaping support?
Answer: CB-Shaping supports shaping to average or peak rate.
Class-based Marking
Question: Which parameters can be set using CB-Marking?
Answer: CB-Marking can mark packets with the following markers: IP
Precedence, IP DSCP, QoS Group, MPLS Experimental bits, IEEE 802.1Q or ISL
CoS/Priority bits, Frame Relay DE bit, ATM CLP bit
Question: Can CB-Marking be used on input?
Answer: Yes.
Question: Can CB-Marking be combined with any other QoS mechanisms?
Answer: Yes. CB-Marking can be combined with WRED, Policing, Shaping,
WFQ, LLQ.
10
IP over ATM
Overview
This module focuses on IP QoS mechanisms that can be used on ATM interfaces.
n Introduction to IP over ATM
n Per-VC WRED
n VC Bundling
n Per-VC CB-WFQ
n RSVP to SVC Mapping
Objectives
n List the requirements of IP QoS in combination with ATM QoS
n Describe the hardware and software requirements for advanced IP QoS
mechanisms on ATM interfaces
n Describe per-VC queuing
n Describe and configure per-VC WRED
n Describe and configure VC bundling
n Describe and configure per-VC CB-WFQ
n Describe RSVP to SVC mapping
n Monitor and troubleshoot IP QoS on ATM interfaces
Introduction to IP over ATM
Objectives
n Describe the QoS-related problems when using ATM networks
10-2 IP QoS IP over ATM Copyright  2001, Cisco Systems, Inc.

IP vs. ATM
Technology comparison
IP ATM
• Connectionless • Connection oriented
• Per-packet QoS (IP • Per-connection (virtual
precedence) circuit) QoS
• Small number of service • Large number of QoS
classes traffic classes (CBR,
• IP precedence or DSCP VBR, UBR, ABR)
does not encode • Rich traffic parameters
service parameters (PCR, MCR, SCR ...)
specified for each VC
© 2001, Cisco Systems, Inc. IP QoS IP over ATM-5
The Internet Protocol (IP) is a routed protocol that is used to transmit data in
packets. It uses the best-effort delivery for individual packets without any flow
control. Transmission Control Protocol (TCP) is used with IP to provide a
connection-oriented service.
Asynchronous Transfer Mode (ATM), on the other hand, provides connections
between endpoints in the ATM network. The connections are called virtual circuits
(VCs).
IP’s default best effort service can be supplemented by differentiated quality of
service based on IP precedence or DSCP marking. A QoS solution using IP
precedence is limited to 8 classes, 2 of which are reserved and 1 should be used
for the default best-effort class. A QoS solution using DSCP scales up to 64
classes.
ATM provides a wider range of services:
n Constant Bit Rate (CBR) is useful for delay-sensitive applications such as
voice. This service provides bandwidth and delay guarantees.
n Variable Bit Rate—Real Time (VBR-RT) is useful for burstier delay-sensitive
applications. This service provides bandwidth and delay guarantees.
n Variable Bit Rate—Non Real Time (VBR-NRT) is useful for bursty traffic.
This service provides bandwidth guarantees.
n Available Bit Rate (ABR) is useful for best-effort traffic that is allowed more
bandwidth, when available or configured. This service provides bandwidth
guarantees and access to extra bandwidth.
n Unspecified Bit Rate is useful for the real best effort where there are no
guarantees.
Copyright  2001, Cisco Systems, Inc. IP QoS IP over ATM 10-3

IP’s IP precedence or DSCP are only used to mark packets. They do not include
any service parameters. Servic e parameters depend on the QoS mechanism being
deployed.
ATM’s services also include various per-connection service parameters, such as:
n Sustained Cell Rate (SCR) for CBR, VBR and ABR services
n Minimum Cell Rate (MIR) for ABR
n Peak Cell Rate (PCR) for VBR, ABR and UBR services
n Maximum Burst Size (MBS)
Both IP and ATM can implement Quality of Service (QoS). The decision on which
technology to use for quality of service should be based on a number of factors,
such as:
n Availability of ATM
n Interaction between ATM and IP
n Scalability options of the technology
n Performance limitations
This module introduces the possibilities of combining IP QoS with ATM.

Integrating IP and ATM
• Overlay model (ATM forum)

– ATM VC’s are manually established between pairs
of devices
– IP packets are sent across these VC’s
– ATM switches are not IP aware
• Peer model (MPLS)
– ATM switches are IP aware on control (but not
data) plane
– ATM VC’s are established on-demand based on IP
routing tables
There are two main approaches to integration of IP with/over ATM:

n The traditional way (overlay model) is to use individual permanent virtual
circuits (PVC) to establish point-to-point adjacencies between IP routers. IP
routing protocols are used to provide reachability across a network of ATM
connections. ATM has no knowledge of IP and cannot use IP information to
optimize its links.
n The newer approach (MPLS) is to make ATM switches IP aware. ATM
switches run an IP routing protocol to establish virtual circuits.
This module focuses on the QoS available with traditional permanent and switched
virtual circuits (PVCs and SVCs).
The IP QoS- IP over MPLS module discusses QoS possibilities when using the
peer model.

IP QoS and ATM
• Routers can be interconnected over an ATM

backbone using different ATM services:
– UBR – congestion management is virtually
impossible because routers are allowed to
transmit packets at line speed
– VBR – congestion management is easier, but it
requires conservative setting of transmit rates
– CBR – similar to VBR from IP perspective
– ABR – pushes congestion back to the source,
requires dynamic adjustment to available
bandwidth
Achieving good quality of service for IP classes greatly depends on the type of
ATM network and services used.
n Using UBR, prevents routers from detecting congestion in the network. It is
therefore difficult to manage congestion based on IP precedence or DSCP.
The reason for this is because all packet drops happen on the congested link
somewhere in the ATM network.
n VBR makes it easier to push congestion back to the source where it can be
managed by routers.
n CBR is typically used for non-bursty delay sensitive traffic. It is therefore
more important to prevent congestion by correctly provisioning the class that is
using CBR.
n ABR is a good solution where bandwidth can be utilized to the maximum
without having many drops in the ATM network.

UBR Virtual Circuits
Random Unintelligent drops

CLP marking based on CLP
No congestion
Router allowed to Congestion
send at full speed
• Solution:
– Set CLP on the router based on IP information to minimize the
effect of cell drops
A solution using UBR can be improved in terms of IP QoS, by marking less

important packets with the CLP bit for congestion control. In case of congestion,
the ATM switches will drop the less important packets to give more bandwidth for
the higher-priority packets.
The ATM FORUM also calls the UBR service category a “best effort” service,
which requires neither tightly constrained delay nor delay variation. In fact, UBR
provides no specific quality of service or guarantee throughput whatsoever. This
traffic is therefore “at risk” since the network provides no performance guarantees
for UBR traffic. The Internet and Local Area Networks are examples of this type
of “best effort” delivery performance. Examples of this are LAN emulation
(LANE), IP over ATM, and non-mission-critical traffic.
This solution is fairly limited, since it allows for only two classes on the IP layer
where congestion should be managed.

VBR Virtual Circuits
Congestion! Unintelligent random

drops
Router is sending Congestion is

at configured rate possible
• Solution:
– Set CLP on the router based on IP information
– Use available IP QoS mechanisms to manage congestion at the
source
A solution using VBR is better at providing feedback to routers sending cells into
the ATM network. Congestion will occur on a router’s virtual circuit, where it can
be managed by using the QoS mechanisms available in the Cisco IOS software.
CLP marking can be used for less-important packets or for those packets above
the Sustained Cell Rate (SCR) to improve the chances for higher-priority packets
when congestion occurs in the ATM network.
The rt-VBR service category supports time-sensitive applications, which also
requires constrained delay and delay variation requirements, but which transmit at
a time varying rate constrained to a PCR, SCR, and MBS define a traffic contract
in terms of the worst-case source traffic pattern for which the network guarantees
a specified QOS. Examples of such bursty, delay-variation-sensitive sources are
voice and variable -bit-rate video.
The nrt-VBR service category supports applications that have no constraints on
delay and delay variations, but which still have variable -rate, bursty traffic
characteristics. This class of application expects a low Cell Loss Ratio (CLR).
The traffic contract is the same as that for rt-VBR. Applications include packet
data transfers, terminal sessions, and file transfers. Networks may statistically
multiplex these VBR sources effectively.

CBR and ABR Virtual Circuits
Congestion!
Router is sending
at configured rate.
• Solution:
– Use available IP QoS mechanism to handle congestion at the
source
CBR virtual circuits, are used for delay-sensitive traffic. This traffic should not
experience congestion due to keeping the quality of data being transmitted. If
congestion occurs, it can be managed by the IP layer using the IP QoS
mechanisms on the router’s ATM interface.
The CBR service category supports real-time applications requiring a fixed
amount of capacity defined by the PCR. CBR supports tightly constrained
variations in delay. Example applications are voice, constant-bit-rate video, and
Circuit Emulation Services (CES). Normally, networks must allocate the peak rate
to these types of source.
The ABR service category works in cooperation with sources that can change
their transmission rate in response to rate-based network feedback used in the
context of closed-loop flow control. The aim of ABR service is to dynamically
provide access to capacity currently not in use by other service categories to users
who can adjust their transmission rate in response to feedback. In exchange for
this cooperation by the user, the network provides a service with very low loss.
Applications specify a maximum transmit-rate (PCR_ and the minimum required
rate, called the Minimum Cell Rate (MCR). ABR service does not provide
bounded delay variation; hence real-time applications are for ABR are LAN
interconnection, high-performance file transfers, database archival, non-time-
sensitive traffic, and web browsing.

Congestion Management in ATM
Networks
• Congestion management on routers should

be performed on a per-VC basis
• Design options:
– Make sure there is no congestion in the ATM
network (ABR, CBR, VBR) and use IP QoS
mechanisms at the source (CB-WFQ, WRED)
– Mark less important packets with the CLP bit in
case there is congestion in the ATM network (CB-
Policing, CB-Marking)
– Use multiple parallel (per-CoS) virtual circuits with
ATM QoS (VC Bundling)
This module discusses three different approaches to designing QoS in IP networks

on ATM:
1. Using IP QoS mechanisms to ensure there is no congestion in the AMT
network
2. Using ATM QoS mechanisms with IP precedence used for classification (VC
Bundling)
3. Combining both IP and ATM QoS mechanisms

Per-VC Queuing
VIP Memory ATM Port Adapter

ATM interface
Frame queue VC 1/50 Cell queue VC 1/50
VC 1/50
Frame queue VC 1/64 Cell queue VC 1/64 VC 1/64
VC 1/76
Frame queue VC 1/76 Cell queue VC 1/76 VC 1/39
Frame queue VC 1/39 Cell queue VC 1/39
ATM
Per-VC queuing with per-VC hardware
congestion management shaping
• Per-VC queuing is required in order to handle congestion on per-VC

basis
• Per-VC queuing prevents head-of-line blocking by slow virtual circuits
One of the most important parts of implementing QoS is to make ATM virtual
circuits appear as physical interfaces on routers; that is, each VC must have its
own queue (per-VC queuing). Per-VC queuing prevents one congested VC from
slowing down other VCs (head-of-line blocking).
Per-VC queuing can then be supplemented by various IP QoS mechanisms, such
as:
n WRED
n CAR
n CB-WFQ
n CB-LLQ
n CB-Policing
n CB-Shaping
n CB-Marking
CB-Marking and CB-Policing can also be used to set the CLP bit.

Summary
The following steps have to be taken prior to the designing of a QoS solution for IP
over ATM:
n Implement Per-VC queuing (to prevent head-of-line blocking and allow for IP
QoS mechanisms to be implemented on individual virtual circuits)
n Decide on the technology that will be used to implement QoS
Review Questions
1. What are the main differences between IP and ATM?
2. Which QoS services does ATM support?
3. How should congestion be handled when an ATM backbone is used?
4. Why is per-VC queuing so important?

Per-VC WRED
Objectives
n Describe per-VC WRED
n Configure per-VC WRED
n Monitor and troubleshoot per-VC WRED

Per-VC WRED
• Single ATM VC is established over an ATM

cloud between a pair of routers
– ABR, VBR, UBR or CBR
– Using UBR will not result in proper operation, as
there is no ATM shaping in UBR
• All IP traffic toward a next-hop router is
forwarded across a single ATM VC
• Congestion is managed entirely on the IP
layer using WRED on each individual ATM
VC, resulting in differentiated IP services
A simple addition to best-effort service on ATM interfaces is Weighted Random

Early Detection (WRED). WRED is most efficient when the majority of the traffic
is TCP (TCP reacts to random drops and slows down the transmission rate). With
other protocols, packet sources may not respond or may resend dropped packets at
the same rate. Thus, dropping packets does not decrease congestion. WRED
treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP
traffic is more likely to be dropped than IP traffic
UBR would probably result in congestion somewhere in the ATM network, thus
preventing any intelligent congestion management on the IP layer.
Any other ATM service (CBR, VBR or ABR) will push congestion back to the
source where WRED can be used to drop packets based on the IP precedence or
DSCP value.

Per-VC WRED : Intelligent
IP Packet Discard
Traffic
Threshold Exceeded Shaping
VIP2-50 PA-A3-XX
VC1
VC2
VC3
No discard
Per-VC Per-VC on PA
WRED: Queues
Intelligent Discard
Per-VC queuing requires an Enhanced ATM Port Adapter that support up to 4096
cell queues. Each virtual circuit is assigned a queue and the ATM scheduler
forwards cells according to the ATM service and shaping parameters.
The router (or VIP on Cisco 7x00 series routers) also assigns one queue per virtual
circuit.
Cell departure is shaped if ABR, VBR or CBR services are used, thus causing
congestion in the frame queue if packet arrival is greater than the shaping rate in
ATM. Per-VC WRED can be used to manage congestion within individual queues
(classes).

Configuring
Configuring Per-VC WRED
• The following configuration steps are needed

to enable per-VC WRED:
– Create a Random-Detect-Group template with a
WRED profile
– Apply the WRED template to an ATM interface or
to individual ATM VCs
– Verify and monitor the operation of per-VC WRED
Applying WRED to individual VCs is slightly different than applying WRED to

interfaces. A Random Detect Group must be created if non-default WRED
profiles need to be used on VCs. Standard WRED parameters (per-precedence
minimum threshold, maximum threshold and maximum drop probability) are set in
the random-detect-group configuration mode.

Create and configure RED-group
Router(config)#
random-detect-group name
name
• Creates a WRED template

Router(cfg-red-group)#
exponential-weighting-constant
exponential-weighting-constant exp
• Defines WRED weighting constant

• Default: 9
Router(cfg-red-group)#
precedence
precedence IP-prec min-threshold max-threshold
max-threshold prob-denominator
• Defines RED profile for specified precedence

• Default: as with per-interface WRED
The random-detect-group global configuration command creates a WRED

profile and enters the red-group configuration mode. WRED per-precedence
profiles are configured in the red-group configuration mode, using similar
commands as with per-interface WRED, except the commands are not preceded
by the random-detect keyword.
Any class (IP precedence) can be configured with a RED profile different from
the default by using the precedence command in the red-group configuration
mode:
n Minimum threshold—When the average queue depth is above the minimum
n Maximum threshold—When the average queue size is above the maximum
n Mark probability denominator—This is the fraction of packets dropped
WRED does not calculate the drop probability using the current queue length, but
instead uses the average queue length. The average queue length is constantly
recalculated, using two terms:
n The previously calculated average queue size
n The current queue size

An exponential weighting constant N influences the calculation by weighing the
two terms. It therefore influences how the average queue size follows the current
queue size, in the following way:
average size calculation, therefore allowing larger bursts
the new average size calculation, so that bursts influence the new value to a
smaller degree
involving extremely high-speed interfaces (such as OC12), where it can be
increased slightly (to about 12) to allow more bursts.
Note The default WRED parameter values are based on the best available data.
Cisco recommends that you do not change the parameters from their default
values unless you have determined that your applications will benefit from the
changed values.

Apply WRED group to
an ATM PVC
Router(config-if-atm-vc)#
random-detect
random-detect [attach
[attach random-detect-group]
random-detect-group]
• Enables WRED on a PVC using the selected WRED

profile
• Default WRED parameters are used if the group
name is omitted or refers to non-existent group
• Default: no WRED is used on the ATM PVC
The last step in the configuration of per-VC WRED is to attach a random-detect-

group to a virtual circuit. The random-detect command is used in the VC
configuration mode to enable WRED. If no random-detect-group is specified
WRED will use the default WRED profiles.

Per-VC WRED
Router#
show
random-detect [interface
[interface intf [vc vpi vci
vci ]]
]]
• Displays WRED parameters for an ATM

(sub)interface or for individual VC
Router#
show
show queueing interface
interface interface [vc vpi
vpi vci]
vci]
• Displays interface queues or individual per-VC

queue
The show queuing random-detect command display WRED parameters and

statistics for a specific interface or virtual circuit. There is only a single queue into
which packets from all IP precedences are placed after dropping has taken place.
The show queuing interface command displays per-VC queue parameters and
statistics. The “Queuing strategy” reported by the command lists “random early
detection (RED)” as the queuing mechanism. The default minimum thresholds are
spaced evenly between half and the entire maximum threshold. Thresholds are
specified in terms of packet count.

WRED Case Study
• WRED is applied to a ATM PVCs in a network with

the following IP precedence definitions
IP prec. Meaning
0 High-loss best-effort traffic
1 Low-loss best-effort traffic
2 Premium traffic outside of the contract
3 Premium traffic in the contract
4 Unused
5 Voice-over-IP
• WRED queue length is 100 packets for PVCs with
SCR > 10 Mbps and 40 packets for slower PVCs
The case study shows a QoS design where packets are classified into three user
classes:
n Best-effort class
n Premium class
n Voice class
The Best-effort and Premium classes use two IP precedence values to mark
high-drop (out-of-contract) traffic and low-drop (within contract) traffic.
IP precedence values 6 and 7 are reserved for control messages (for example,
routing protocols) and should not be used for user traffic.
The design lists these two additional requirements:
n Virtual circuits faster than 10Mbps should have queues that can hold up to 100
packets
n Slower virtual circuits can store up to 40 packets in the queue
All virtual circuits should manage congestion by using WRED.

Case Study WRED Profile
Packet Discard
Probability
VoIP
Precedence 3
Routing
Precedence 1
0.1
Precedence 2
Precedence 0
Average
Queue Size RSVP
10
15
20
25
30
35
37
The figure illustrates the WRED parameters that should be implemented for fast
and slow virtual circuits. The minimum and maximum thresholds should reflect a
different maximum queue size for fast VCs (100 instead of 40).
High drop Best-effort and Premium packets start being dropped when the average
queue size reaches 10 or 15 respectively (25 or 37 on fast VCs). If the queue still
grows the low-drop Best-effort packets start being dropped when the queue size
reaches 20 (50 on fast VCs). High drop packets, of course, are more aggressively
dropped than low-drop packets.
Control packets, VoIP packets and packets of RSVP flows are only dropped in
extreme situations when the average queue size is close to the maximum (40 for
slow VCs and 100 for fast VCs).

Router Configuration
• Step #1 - configure WRED profile for slow

PVCs
random-detect-group
random-detect-group slow-wred-profile
slow-wred-profile
precedence
The figure shows the configuration of WRED profiles used for slow VCs.

• Step #2 - configure WRED profile for fast

PVCs
random-detect-group
random-detect-group fast-wred-profile
fast-wred-profile
precedence
precedence 00 25
25 6262 10
10
precedence
precedence 11 50
50 100
100 10
10
precedence
precedence 22 37
37 6262 10
10
precedence
precedence 33 62
62 100
100 10
10
precedence
precedence 55 87
87 100
100 10
10
precedence
precedence
precedence 66 75
75 100
100 10
10
precedence
precedence 77 75
75 100
100 10
10
The figure shows the configuration of WRED profiles used for fast VCs.
Note This configuration simply uses scaled thresholds to support up to 100 packets
in the queue.

• Step #3 - Apply WRED profile on various

PVCs
interface
interface ATM11/0/0
ATM11/0/0
ip address 17.1.0.1
17.1.0.1 255.255.255.0
255.255.255.0
atm pvc
pvc 50 0 50 aal5snap 25000 50000 10 inarp
inarp
random-detect
random-detect fast-wred-profile
fast-wred-profile
!!
interface
interface ATM11/0/0.100
ATM11/0/0.100 point-to-point
ip address 17.1.1.1 255.255.255.252
atm pvc
pvc 100
100 0 100 aal5snap 17000 34000 10 inarp
inarp
random-detect
random-detect fast-wred-profile
fast-wred-profile
!!
interface
ip address 17.1.1.5 255.255.255.252
atm
atm pvc 101
101 55 101
101 aal5snap
aal5snap 2000
2000 4000
4000 10
10 inarp
random-detect
random-detect slow-wred-profile
slow-wred-profile
The figure shows the configuration of three virtual circuits. Two are using the
WRED profile for fast VCs and the third is using the WRED profile for slow VCs.

Summary
Weighted Random Early Detection (WRED) is one of the IP QoS mechanisms
that can be applied to individual virtual circuits.
A Random Detect Group is used to configure a WRED profile that is attached to
individual VCs using the random-detect command in the VC configuration mode.
Review Questions
1. What are the benefits of per-VC WRED?
2. What are the configuration steps needed to enable per-VC WRED?

VC Bundling
Objectives
n Describe VC bundling
n Configure VC bundling
n Monitor and troubleshoot VC bundling

VC Bundling
• VC Bundling is a solution where ATM QoS

mechanisms are used
• Classes of Service are identified by IP
precedence
• Each VC uses an ATM service based on the
requirements of the class
• Routers automatically map packets in VCs
based on their IP precedence value
• Multiple parallel VCs are needed for each IP
adjacency
VC Bundling is a solution where the task of providing differentiated quality of

service is offloaded to the ATM switches. Classes are identified by using IP
precedence values. The routers then perform classification based on IP
precedence values. Up to eight parallel virtual circuits can be used for one IP
adjacency. Appropriate ATM services are used for each IP precedence value,
depending on the QoS requirements and provisioning.
An IP precedence value or a range of IP precedence values are mapped to one
virtual circuit. Non-contiguous IP precedence ranges are not supported.

VC Bundling Case Study
ATM VC ATM VC type IP prec.

Control VC (routing updates) VBR 6-7
Voice CBR 5
VPN traffic VBR 4
Premium Internet traffic VBR 2-3
Best-effort Internet traffic ABR 0-1
Control (routing)
Voice
VPN traffic
Premium Internet
Best-effort Internet
The figure illustrates a case study where there are four user classes and one class
for control traffic.
Routers perform classification based on IP precedence values:
n IP precedence 6 and 7 traffic is forwarded through the Control VC
n IP precedence 5 traffic is forwarded through the Voice VC
n IP precedence 4 traffic is forwarded through the VPN VC
n IP precedence 2 and 3 traffic is forwarded through the Premium VC
n IP precedence 0 and 1 traffic is forwarded through the Best-effort VC

VC Bundling
Routing Adjacency
Routing protocol packets are exchanged over

control VC as they are sent with IP precedence 6
Control (routing)
Voice
VPN traffic
Premium Internet
Each VC has its own HW queue in the
router, managed with WRED
Whole bundle is treated as one routing adjacency

and is covered by a single ATM map
All five classes are separated in the ATM network and receive different quality of
service. Routers have to perform per-VC queuing to prevent head-of-line blocking.
All five virtual circuits, though, appear as one single point-to-point link on the IP
layer.

VC Provisioning
• VCs are dimensioned based on expected

load for the precedence(s) level transported
on that VC
• More isolation between classes
• At the expense of
– less statistical multiplexing,
– more complex provisioning/engineering
VC Bundling provides an efficient utilization of QoS capabilities provided by

ATM. IP classes are effectively isolated by being transported over different virtual
circuits. The drawbacks of this approach are:
n Less statistical multiplexing. One class cannot use another class’s bandwidth
(unless ABR is used).
n More complex provisioning. Each IP adjacency, which normally requires one
point-to-point virtual circuit, now requires multiple virtual circuits of different
types and QoS.
As much as IP QoS is simplified to classification and marking using IP precedence,
ATM QoS is more complex because there are up to eight times more virtual
circuits to be configured.

VC Bundle Management
• Integrity of each individual VC is verified with

end-to-end OAM cells
Control (routing)
Voice
VPN traffic
Premium Internet
Most Layer-2 technologies include some type of link management. Keepalive

frames are typically used as a last resort to determine if end-to-end connectivity
works. For example:
n HDLC and PPP use link-level keepalive frames to determine if the link is
operational.
n Frame Relay uses keepalive frames to determine if the link between a router
and a switch is operational. Frame Relay can also have end-to-end keepalive
messages to determine if the virtual circuit is operational.
n ATM uses two types of Operation Administration and Maintenance (OAM)
cells to determine if link-level and end-to-end connectivity works.
VC bundling is more complex since there are multiple parallel virtual circuits used
for one single IP adjacency.
The question is: what should happen if only one VC goes down?

VC Bundle Management
Control (routing)
Voice
VPN traffic
Two ways of handling loss of VC in the bundle:

• The whole bundle is declared down
• Traffic from the lost VC is bumped onto another VC
• IP routing model does not allow the traffic for a single
precedence value to be rerouted over another path
There are two possible ways of handling lost VCs:

n All VCs are declared inactive
n The traffic for the lost VC is rerouted onto another VC within the same bundle
IP forwarding decisions are based solely on the destination address and cannot
reroute packets based on their IP precedence values.

VC Bumping
• VC bumping = possibility for a traffic

mapped to VC X to be forwarded onto
another VC Y, in case of failure of X
• Traffic can be bumped based on implicit
or explicit rules
• Individual VC or a group of VCs can be
protected
Keep All Graphics Inside This Box
© 2001, Cisco Systems, Inc. www.cisco.com Course acronym 2.0 —Chapter#-38
n VC bumping is one approach to handling lost VCs. If one of the VCs goes
down the traffic from that VC is forwarded through another VC in the same
bundle.
n Implicit bumping is the default behavior where packets are forwarded
through the first available VC of a lower IP precedence value.
n Explicit bumping requires manual configuration where the IP precedence of
a backup VC is set.

Implicit Bumping
Control (routing)
Voice
VPN traffic
• Traffic from the lost VC is bumped onto the VC

carrying traffic with the next lower precedence
The figure illustrates how routers automatically reroute Premium traffic to the first
VC with a lower IP precedence value (Best-effort in the example).

Reject Bumping
Rejects
Voice
bumping
VPN traffic
Premium Internet
• Problem: Control traffic shall not be bumped onto

voice VC (implicit rule)
• Solution #1: Voice VC can reject bumping, bumped
traffic goes to next lower VC
Some virtual circuits can be configured to reject bumped traffic.

The figure illustrates how the Voice VC rejects bumped traffic (mixing delay
sensitive, well-provisioned traffic with other types of packets is not desired and
should be prevented). Implicit bumping searches down the “ladder” for the first
available VC (it has to be operational and accept bumped traffic).

Explicit Bumping
Bump explicitely
to precedence 0
Voice
VPN traffic
Premium Internet
• Problem: Control traffic shall not be bumped onto

voice VC (implicit rule)
• Solution #2: Specify explicitely onto which VC the
traffic will be bumped
Another approach is to explicitly set the backup VC.

The Control VC in the figure was configured to use the Best-effort VC as backup.

Bundle Failure Scenarios
When a bundle is declared down, no

traffic is forwarded out of the
bundle, even if some VCs are still up (routing)
Control
Voice
VPN traffic
Premium Internet
Whole bundle
Precedence 0 traffic
is lost cannot be implicitly
bumped
• Problem: under default settings, the whole bundle is

declared down if the lowest-precedence VC is lost
• Solution: be sure that the lowest-precedence VC is
always bumped via explicit bumping rule
In this figure the VC used for IP precedence 0 does not have a lower-precedence
VC to be used as backup. It is recommended to use explicit bumping for this VC.

Protected VC
Control (routing)
Voice VC is
protected VC
VPN traffic
Premium Internet
Whole bundle
is lost Best-effort Internet
• Problem: voice traffic shall not be bumped onto data

VC
• Solution: failure of protected VC brings down the
whole bundle, IP routing will find alternate path
Some VCs have special QoS requirements that cannot be accommodated by any
other VC.
The Voice VC in the figure cannot be bumped to any other VC because the voice
quality would no longer meet the requirements. It is better to declare the entire
bundle down and let the IP routing protocol find another path where guarantees
can be met. Classes that under no circumstances should be mixed with other
classes should reject bumped traffic (if a higher-precedence VC fails) and be
protected (if their VC fails).

Protected group
Control (routing)
Voice
All VCs in the

protected group
Whole bundle are lost
is lost
• Problem: if most of the VC’s are lost, it does not make

sense to bump traffic onto low-volume VC’s
• Solution: failure of all VC’s in a protected group will
bring down the bundle
One group of VCs can be protected in a way where the bundle is declared down
but only if all of the VCs in the group fail.

VC Bumping – Final Details
• If the VC which carries the bumped traffic

fails, the traffic will follow the bumping rules
specified for that VC
• Traffic is restored to the original VC when
that VC becomes operational
To summarize bumping:
n Default implicit bumping is used to find the first-lower precedence VC that
accepts bumped traffic and is operational.
n Explicit bumping can be used to select the backup VC. If the backup VC is
down, that VC’s rules are used to find the backup of the backup VC.
n Individual VCs can be configured to reject bumped traffic. Bumped traffic will
skip such VCs.
n An individual VC can be protected. If a protected VC fails the entire bundle is
declared down.
n A collection of VCs can belong to a protected group. If all VCs in the
protected group fail the entire bundle is declared down.
Traffic is restored to the original VC the moment it becomes operational.

Configuring VC Bundling
• Configuration steps:
– Configure ATM interface
– Configure VC bundle
– Configure individual VC in the bundle
– Optionally use VC-class object as VC parameter
template
The following configuration steps are needed to enable VC Bundling:

Step 1 Configure interface-wide parameters on an ATM interface
Step 2 Create a VC bundle
Step 3 Create up to eight VCs as members of the bundle
Step 4 Optionally, use the VC-class object as a template for bundle or VC configuration

VC Bundle Parameters
• Parameters configurable on the VC bundle or

vc-class applied to the bundle
– Layer-3 ATM maps
– Encapsulation
– Broadcast propagation
– ATM Inverse ARP
– OAM management
– Global bumping rules
The figure lists the parameters that can be set on a bundle or a vc-class template.
Individual member VCs inherits the parameters if they are not overridden in the
VC configuration.

Individual VC Parameters
• Parameters configurable on individual VC in

the bundle (or vc-class)
– IP precedence mapping
– VC protection mode
– VC bumping rules
– ATM VC mode and ATM QoS parameters
– WRED group
Individual VC parameters can be inherited from a vc-class configured on the

bundle, the bundle, or a vc-class configured on the VC. Parameters configured on
the VC override all inherited parameters.

Configuring Bundle-wide
VC Class
Router(config)#
class-vc
class-vc vc-class-name
vc-class-name
oam-bundle
oam-bundle [manage] [frequency]
[frequency]
bump
bump {implicit
{implicit | explicit precedence-level
precedence-level | traffic}
encapsulation
encapsulation atm-encap
atm-encap
protocol
protocol atm-map-parameters …
[no]
[no] broadcast
broadcast
inarp
inarp timeout
timeout
• Configures all parameters that can be specified on

an ATM VC bundle in a VC class
Use the class-vc global configuration command to create a template used to

configure common parameters on ATM interfaces, bundles or individual virtual
circuits.
VC classes can contain ATM specific configuration commands as well as
commands used for VC Bundle management.

Configuring ATM VC Bundle
Router(config-if)#
bundle
bundle bundle-name
bundle-name
class
class vc-class-name
vc-class-name
oam-bundle
[frequency]
bump
bump {implicit
{implicit || explicit
explicit precedence-level
precedence-level || traffic}
traffic}
encapsulation
encapsulation atm-encap
atm-encap
protocol
protocol atm-map-parameters …
[no]
[no] broadcast
broadcast
inarp
inarp timeout
timeout
• Configures ATM VC bundle

• If a vc-class is applied to the bundle, the bundle
inherits parameters specified in the vc-class
• Individual parameters specified in the vc-class can
be overwritten by bundle configuration commands
Use the bundle interface command to enter the bundle configuration mode.
Parameters specific to this bundle should be configured on the bundle. Parameters
that are common to multiple bundles should be configured in a template (VC class)
and attached to the bundle using the class-bundle command.
The command used to attach VC class templates differs, depending on which
configuration mode is used:
n The class-int interface command is used to attach a VC class to an interface
n The class-bundle command is used to attach a VC class to a bundle
n The class-vc command is used to attach a VC class to a virtual circuit

Configuring OAM Management in
the Bundle
Router(config-atm-vc)#
oam-bundle
[frequency]
• Enables VC management with end-to-end OAM cells

• Cells are sent but the bundle is not managed if the manage
keyword is omitted
• The frequency parameter specifies the cell generation rate in
seconds
oam
oam retry up-count
up-count down-count
down-count retry-frequency
retry-frequency
• Specifies the OAM management-related thresholds

• The up-count and down-count parameters specify the number of
consecutive cells that have to be received (or lost) before the
VC is declared up or down
• The frequency parameter specifies the cell send frequency
during VC state change verification
To enable end-to-end F5 Operation, Administration and Maintenance (OAM)

loopback cell generation and OAM management for a virtual circuit (VC) class
that can be applied to a VC bundle, use the oam-bundle vc-class configuration
command.
To enable end-to-end F5 OAM loopback cell generation and OAM management
for all VC members of a bundle, use the oam-bundle bundle configuration
command.
If the manage keyword is omitted, loopback cells are sent but the bundle is not
managed.
The frequency parameter specifies the number of seconds between sending OAM
loopback cells. Values range from 0 to 600 seconds.
To configure parameters related to OAM management for an ATM PVC, SVC, or
VC class, use the oam retry command in the appropriate command mode.
The up-count parameter specifies the number of consecutive end-to-end F5 OAM
loopback cell responses that must be received in order to change a PVC
connection state to up.
The down-count parameter specifies the number of consecutive end-to-end F5
OAM loopback cell responses that are not received in order to change a PVC
state to down.
The retry-frequency parameter specifies the frequency (in seconds) that the
end-to-end F5 OAM loopback cells are transmitted when a change in the
UP/DOWN state of a PVC is being verified. For example, if a PVC is up and a
loopback cell response is not received after the frequency (in seconds) specified
using the oam-pvc command, then loopback cells are sent at the retry-frequency
to verify whether or not the PVC is down.

Configuring Traffic Bumping
bump
bump implicit
implicit
• Configures implicit bumping rules for the bundle or
individual VC in the bundle
• If the VC fails, the traffic is bumped to the VC
carrying lower-precedence traffic
bump
bump explicit
explicit precedence
precedence
• Configures explicit bumping rules for the bundle or
individual VC in the bundle
• If the VC fails, the traffic is bumped to the VC
currently carrying packets with specified IP
precedence
The bump implicit command, depending on the mode, applies implicit bumping
rules, which is also the default, to a single VC bundle member (bundle -vc mode) or
all VCs in the bundle (bundle mode). The (default) implicit bumping rule stipulates
that bumped traffic is to be carried by a VC with a lower precedence.
The bump implicit command specifies the IP precedence level to which traffic on
a VC (bundle -vc mode) will be bumped when the VC goes down. It specifies a
single number as the value of the precedence-level argument.

Configuring Traffic Bumping
no
no bump
bump traffic
traffic
• Prevents the VC (or all VCs in a bundle) from

accepting bumped traffic
bump
bump traffic
traffic
• Allows the VC (or all VCs in a bundle) to accept

bumped traffic
Use the no bump traffic command to reject bumped traffic on the configured VC.
Use the bump traffic command to restore the default behavior.

Configuring VC-wide VC Class
Router(config)#
class-vc
class-vc vc-class-name
vc-class-name
precedence
precedence [other | range ]
bump
bump {implicit
{implicit | explicit precedence-level
protect
protect {group
{group | vc }
ubr
ubr || ubr+
ubr+ || vbr-nrt
vbr-nrt atm-qos-parameters
random-detect
random-detect [attach group-name]
• Configures all parameters that can be specified on

an ATM VC within the bundle in a VC class
Use the class-vc global configuration command to create a VC template.

Interface, VC or bundle specific parameters can be set within the VC class.

Configuring ATM VC in a Bundle
Bundle
Router(config-if)#
bundle bundle-name
pvc
pvc name
name [vpi/]vci
class vc-class-name
vc-class-name
precedence
precedence [other
[other || range
range ]
bump {implicit
{implicit || explicit
explicit precedence-level
protect {group | vc}
ubr
ubr || ubr+
ubr+ || vbr-nrt
vbr-nrt atm-qos-parameters
random-detect
random-detect [attach group-name]
group-name]
• Configures individual VC in an ATM VC bundle

• If a vc-class is applied to the VC, the VC inherits parameters
specified in the vc-class
• Individual parameters specified in the vc-class can be
overwritten by bundle configuration commands
• Unspecified VC parameters are inherited from the bundle or
from the ATM interface
Use the bundle command in the ATM interface or subinterface configuration

mode.
From within the bundle configuration mode the characteristics and attributes of the
bundle and its members, such as the encapsulation type for all virtual circuits
(VCs) in the bundle, the bundle management parameters and the service type, can
be configured. Attributes and parameters that are configured in the bundle
configuration mode are applied to all virtual circuit (VC) members of the bundle.
VCs in a VC bundle are subject to the following configuration inheritance
guidelines (listed in order of next highest precedence):
1. VC configuration in bundle -vc mode
2. Bundle configuration in bundle mode
3. Subinterface configuration in subinterface mode

Map IP Precedence to an
ATM VC
precedence
precedence [other
[other || range
range ]]
• Maps packets with specified range of IP precedence

into the configured ATM VC
• All the unmapped IP precedence values are mapped
to the VC specifying “other”
• Default: VC accepts all unspecified IP traffic
Assignment of precedence levels to VC bundle members provides the ability to

create a differentiated service, because the IP Precedence levels can be
distributed over the different VC bundle members. A single precedence level, or a
range of levels to each discrete VC in the bundle, can be mapped, thereby enabling
VCs in the bundle to carry packets marked with different precedence levels.
Alternatively, a VC can be configured with the precedence other command to
indicate that it can carry traffic marked with precedence levels not specifically
configured for it. Only one VC in the bundle can be configured with the
precedence other command to carry all precedence levels not specified. This
VC is considered the default.

VC Protection
protect
protect {{ group
group || vc
vc }}
• Configures the VC to be part of protected group or

to be individually protected
• Bundle is declared down if all VCs in the protected
group are lost or if any individually-protected VC is
lost
• Only one protected group can be configured in a
bundle
• Default: VC is not protected
Use the protect vc command to protect a virtual circuit. Use the protect group
command to make the VC a member of the protected group.
When a protected VC goes down, it takes the bundle down. When all members of
a protected group go down, the bundle goes down.

VC Inheritance Rules
• VC parameters are inherited in the following

order
– Parameters specified on individual VC
– Parameters in the VC class applied to the
individual VC
– Parameters specified on the bundle to which the
VC belongs
– Parameters specified in the VC class applied to
the bundle
– Parameters specified on an interface or
subinterface
The figure shows the inheritance rules for parameters set on interfaces, bundles,
VC classes or individual VCs. The parameters configured on individual VCs
override all inherited values.

ATM VC Bundle
Case Study
• IP traffic is transported across an international ATM

PVC with the following IP precedence values
Precedence Meaning
0-1 Best-effort Internet traffic
2-3 Premium Internet traffic
4 VPN traffic
5 VoIP traffic
6,7 Routing protocols
• Voice traffic, VPN traffic and Premium Internet traffic
shall be transported across dedicated PVCs for
easier provisioning
The figure illustrates a case study where there are four user classes and one class
for control traffic.
Routers perform classification based on IP precedence values:
n IP precedence 6 and 7 traffic is forwarded through the Control VC
n IP precedence 5 traffic is forwarded through the Voice VC
n IP precedence 4 traffic is forwarded through the VPN VC
n IP precedence 2 and 3 traffic is forwarded through the Premium VC
n IP precedence 0 and 1 traffic is forwarded through the Best-effort VC

Case Study Step 1: Bundle
Design
• Precedence 5 traffic (VoIP) is transported over a

separate VC, no bumping is possible
• Precedence 2-3 traffic (Premium Internet) is
transported over a separate VC, can be bumped onto
the best-effort VC
• Precedence 4 traffic (VPN) is transported over a
separate VC, can be bumped onto best -effort VC
• Control traffic is transported over a separate VC, can
be bumped onto the best-effort VC
• Best-effort VC can be bumped onto Premium Internet
VC
• WRED has to be deployed on all VCs to prevent
bumped best-effort traffic from congesting the VC
Per-VC WRED is the only IP QoS mechanism that will be used on the routers to
manage congestion.

• Case study step 2: configuring VC classes

vc-class
vc-class best_effort
best_effort vc-class
vc-class vpn
precedence other precedence
precedence 44
bump
bump explicitly
explicitly 22 bump explicitly
explicitly 00
protect group protect group
!! !!
vc-class
vc-class premium vc-class
vc-class voip
voip
precedence
precedence 2-3
2-3 precedence
precedence 55
bump implicitly no bump traffic
protect group protect vc
!! !!
vc-class
vc-class bundle vc-class
vc-class control
encapsulation aal5snap precedence
precedence 6-7
6-7
broadcast bump explicitly
explicitly 00
protocol ip
ip inarp
inarp protect group
oam-bundle
oam-bundle manage 3
The first part of the implementation shows the templates (VC classes) that will be
used for individual virtual circuits (classes) and one for the bundle.

• Case study step 3: configuring the WRED

profile Guaranteed_BW PVC
random-detect-group
random-detect-group guaranteed_bw_pvc
guaranteed_bw_pvc
precedence
precedence 00 20
20 40
40 10
precedence
precedence 11 25
25 40
40 10
precedence
precedence 22 35
35 40
40 10
precedence
precedence 66 30
30 40
40 10
precedence
precedence 77 30
30 40
40 10
A random-detect-group is created for the virtual circuits that need non-default

WRED profiles.

• Case study step 4: configure the bundle and individual PVC

interface
interface ATM
ATM 5/1/0.22
5/1/0.22 point-to-point
point -to-point
ip
ip address
address 216.23.45.5
216.23.45.5 255.255.255.252
255.255.255.252
bundle
bundle SanFrancisco
SanFrancisco
class
class bundle
pvc-bundle
pvc-bundle SF-control
SF-control 2266
class
class control
vbr-nrt
vbr-nrt 1000
1000 1000
1000
pvc-bundle
pvc-bundle SF-voip
SF-voip 25
25
class
class voip
voip
vbr
vbr 2000
2000 2000
2000
pvc-bundle
pvc-bundle SF-vpn
SF-vpn 24
class vpn
class vpn
vbr-nrt
vbr-nrt 4000
4000 4000
4000
pvc-bundle
pvc-bundle SF-guaranteed
SF-guaranteed 22
class
class guaranteed_bw
guaranteed_bw
random-detect
random -detect attach
attach guaranteed_bw_pvc
guaranteed_bw_pvc
vbr-nrt
vbr-nrt 8000
8000 8000
8000
pvc-bundle
pvc-bundle SF-best-effort
SF-best-effort 23
23
class
class best_effort
best_effort
random-detect
random -detect
The figure shows the configuration of the bundle with five individual VCs. Each
VC is configured with the PVC type and parameters. All other configuration
parameters are inherited from the VC classes attached to individual VCs and the
VC class attached to the bundle.

Summary
VC Bundling is a solution where the task of providing differentiated quality of
service is offloaded to ATM switches. Classes are identified by using IP
precedence values, then the routers perform classification based on IP
precedence values. Up to eight parallel virtual circuits can be used for one IP
adjacency. Appropriate ATM services are used for each IP precedence value,
depending on the QoS requirements and provisioning.
A range of IP precedence values or a single IP precedence value are mapped to
one virtual circuit. Non-contiguous IP precedence ranges are not supported.
Review Questions
1. How does VC Bundling classify IP packets?
2. Which QoS mechanisms are used when using VC Bundling?
3. How many parallel VCs can be used for one IP adjacency?
4. How many IP precedence values can map into one VC?

Per-VC CB-WFQ
Objectives
n Describe per-VC CB-WFQ
n Configure per-VC CB-WFQ
n Monitor and troubleshoot per-VC CB-WFQ

Per-VC CB-WFQ
• Class-based Weighted Fair Queuing (CB-WFQ) can

be used on ATM interfaces
• QoS service policies can be applied to:
– An interface
– A subinterface
– An individual virtual circuit
• Supported service policies are:
– CB-WFQ including WRED
– CB-LLQ
– CB-Marking including setting of ATM CLP bit
– CB-Shaping
– CB-Policing including setting of ATM CLP bit
Per-VC queuing can be supplemented by using the Modular QoS CLI (MQC).
ATM PVCs can be combined with any QoS mechanism available with the MQC:
n CB-WFQ for bandwidth management
n CB-LLQ for delay management
n CB-Marking
n CB-Shaping
n CB-Policing
CB-Marking and CB-Policing also include the capability to mark cells with the Cell
Loss Priority (CLP) bit.

Per-interface
Per-interface CB-WFQ
Subinterface
PVC 0/50 ATM1/0/0.1
PVC 0/51
Interface
CB-WFQ ATM1/0/0
PVC 0/52
PVC 0/53
Subinterface
PVC 0/54 ATM1/0/0.2
• CB-WFQ can be applied to an entire interface

class-map
class-map HTTP
HTTP
match
match http
http
!!
policy-map
policy-map LimitHTTP
LimitHTTP
class
class HTTP
HTTP
police
police 256000
256000 conform
conform transmit
transmit exceed
exceed set-clp-transmit
set-clp-transmit
!!
interface
interface ATM5/0/0
ATM5/0/0
service-policy
output LimitHTTP
LimitHTTP
!!
The figure illustrates an ATM interface with two configured subinterfaces. The
first subinterface uses two ATM PVCs, the second subinterface uses three ATM
PVCs.
A service policy can be applied to an entire ATM interface.

Per-subinterface CB-WFQ
Subinterface
PVC 0/50 ATM1/0/0.1
CB-WFQ
PVC 0/51
Interface
PVC 0/52 ATM1/0/0
PVC 0/53 CB-WFQ

Subinterface
PVC 0/54 ATM1/0/0.2
• CB-WFQ can be applied to subinterfaces

class-map
class-map CorporateTraffic
CorporateTraffic interface
point-to-point
match
match access -group 100
access-group 100 service-policy
output Smart
Smart
!! pvc
pvc Core
Core 0/51
0/51
policy-map
policy-map Smart
Smart vbr-nrt
vbr-nrt 10000
10000 2000
class
class CorporateTraffic
CorporateTraffic !!
bandwidth
bandwidth 10000
10000
class
class class-default
class-default
set
set atm-clp
atm-clp
!!
A service policy can also be applied to individual ATM subinterfaces.

Per-interface
Subinterface
CB-WFQ
PVC 0/50 ATM1/0/0.1
CB-WFQ
PVC 0/51
Interface
CB-WFQ
PVC 0/52 ATM1/0/0
CB-WFQ
PVC 0/53
Subinterface
CB-WFQ
PVC 0/54 ATM1/0/0.2
• CB-WFQ can be applied to an individual

virtual circuit
The highest QoS granularity is achieved by attaching service policies to individual

virtual circuits.

Per-interface
class-map
class-map MatchCorporate
MatchCorporate
match
access-group 100
!!
policy-map
policy-map MARK
MARK
class
class MatchCorporate
MatchCorporate
police
police 2000000 conform-action
transmit exceed -action set-clp-transmit
exceed-action set-clp-transmit
!!
interface
interface ATM5/0/0
ATM5/0/0
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
255.255.255.0
service-policy
output MARK
MARK
pvc
pvc 0/50
0/50
vbr-nrt
vbr-nrt 500
500 400
400 1000
1000
inarp
inarp 11
broadcast
broadcast
!!
access-list
access-list 100
100 permit
permit ip
ip 10.0.0.0
10.0.0.0 0.255.255.255
0.255.255.255 10.0.0.0
10.0.0.0 0.255.255.255
0.255.255.255
The example shows how a service policy is used in simple ATM configurations
where the main interface is used to establish IP adjacency. The service policy is
attached directly to the interface.

Per-VC CB-WFQ
class-map
class-map MatchCorporate
MatchCorporate
match
access-group 100
!!
policy-map
policy-map MARK
MARK
class
class MatchCorporate
MatchCorporate
police
police 2000000 conform-action
transmit exceed -action set-clp-transmit
exceed-action set-clp-transmit
!!
interface
interface ATM5/0/0
ATM5/0/0
no
no ip
ip address
address
!!
interface
point-to-point
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
255.255.255.0
pvc
pvc 0/50
0/50
vbr-nrt
vbr-nrt 500
500 400
400 1000
1000
inarp
inarp 11
service-policy
output MARK
MARK
broadcast
broadcast
!!
access-list
access-list 100
100 permit
permit ip
ip 10.0.0.0
10.0.0.0 0.255.255.255
0.255.255.255 10.0.0.0
10.0.0.0 0.255.255.255
0.255.255.255
The more common alternative to configuring ATM is to use subinterfaces. A

service policy can be attached to the subinterface or a virtual circuit.

Per-interface
Router#
show policy-map interface ATM-interface
• Displays the Service Policy parameters and statistics

for the selected interface or subinterface
Router#show
Router#show policy
policy interface
interface atm
atm 5/0/0.1
5/0/0.1
ATM5/0/0.1
ATM5/0/0.1
Service-policy
output: Smart
Smart (1755)
(1755)
Class-map:
Class-map: CorporateTraffic
CorporateTraffic (match-all)
(match -all) (1757/42)
(1757/42)
00 packets,
packets, 00 bytes
bytes
55 minute
minute offered
offered rate
rate 00 bps,
bps, drop
drop rate
rate 00 bps
bps
Match:
Match: access-group
access-group 100100 (1761)
(1761)
queue size 0, queue limit
queue size 0, queue limit 25002500
packets
packets output
output 0,
0, packet drops 0
tail/random
tail/random drops
drops 0,
0, no
no buffer
buffer drops
drops 0,
0, other
other drops
drops 00
Bandwidth:
Bandwidth: kbps
kbps 10000,
10000, weight
weight 29
29
...
...
Use the show policy-map interface command to display the parameters and
statistics of input and output policies attached to interfaces.
This command displays information about all classification options and the attached
QoS mechanisms.

Per-VC CB-WFQ
Router#
show queueing interface ATM-interface [vc [VPI/]VCI]
• Displays CB-WFQ parameters and statistics for the

selected interface, subinterface or VC
Router#show
queueing interface
interface atm5/0
atm5/0
Interface
Interface ATM5/0
ATM5/0 VC
VC 0/5
0/5
Queueing
Queueing strategy:
strategy: fifo
fifo
Output
Output queue
queue 0/40,
0/40, 00 drops
drops per
per VC
VC
Interface
Interface ATM6/0
ATM6/0 VC
VC 0/16
0/16
Queueing strategy: fifo
Queueing strategy: fifo
Output
Output queue
queue 0/40,
0/40, 00 drops
drops per
per VC
VC
Interface
Interface ATM6/0 VC 0/50
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Total
Total output
output drops
drops per
per VC:
VC: 00
Output
queue: 0/512/64/0 (size/max total/threshold/drops)
Conversations
0/1/32 (active/max
active/max total)
total)
Reserved
Conversations 0/00/0 (allocated/max
allocated)
Available
Available Bandwidth
Bandwidth 225
225 kilobits/sec
kilobits/sec
Use the show queueing exec command to list all, or selected, configured queuing
strategies.

Summary
Per-VC CB-WFQ allows the usage of the same QoS mechanisms as any other
technology using single physical interfaces. The same configuration steps are
needed to create a service policy. The policy can then be attached to an interface,
subinterface or an individual VC.
CB-Policing and CB-Marking also support the setting of the ATM CLP bit.
Review Questions
Answer the following question:
1. Where can CB-WFQ be attached on ATM interfaces?

RSVP to SVC Mapping
Objectives
n Configure RSVP to SVC mapping
n Monitor and troubleshoot RSVP to SVC mapping

RSVP to SVC Mapping
• RSVP-enabled flows have bandwidth and

delay requirements
• Pass-through RSVP could affect the quality
of service in case an ATM interface or PVC is
congested
• RSVP-enabled flows can get their own VCs
and queues to prevent congestion affecting
these flows
• RSVP reservations are mapped to SVCs
The RSVP-ATM QoS Interworking feature provides support for Controlled Load
Service using RSVP over an ATM core network. This feature requires the ability
to signal for establishment of switched virtual circuits (SVCs) across the ATM
cloud in response to RSVP reservation request messages. To meet this
requirement, RSVP over ATM supports mapping of RSVP sessions to ATM
SVCs.

RSVP to SVC Mapping
SVC
RSVP RSVP
• RSVP triggers SVC creation

• ATM SVC parameters are calculated from the
parameters in the RSVP reservation request
Traditionally, RSVP has been coupled with WFQ. WFQ provides bandwidth
guarantees to RSVP and gives RSVP visibility to all packets visible to it. This
visibility allows RSVP to identify and mark packets pertinent to it.
The RSVP-ATM QoS Interworking feature provides the capability to decouple
RSVP from WFQ, and instead associate it with ATM SVCs to handle reservation
request messages (and provide bandwidth guarantees), and NetFlow to make
packets visible to RSVP.

ATM SVC Parameters
Cell 1 Cell 2
ATM AAL5SNAP IP ATM
Voice Data Voice Data Unused
Header Header Header Header
5 5 43 5 48
Data Link Encapsulation

overhead
Sustained AAL5SNAP has 5 bytes
Cell
Cell Rate of overhead
overhead
Unused Cell
SCR = BW RSVP . (53/48) . (MPS + DLE + UCO)/MPS Overhead
Minimum IP packet
Bandwidth requested size
by RSVP
• Peak Cell Rate uses the same formula except it is based on the
line rate or the configured peak cell rate
To ensure correspondence between RSVP and ATM SVC values, the software
algorithmically maps the rate and burst size parameters in the RSVP service
parameters to the ATM Sustained Cell Rate (SCR) and Maximum Burst Size
(MBS). For the Peak Cell Rate (PCR), it uses the value that is configured or it
defaults to the line rate.
The figure illustrates the formula used to calculate the ATM service parameters
from the RSVP service parameters. RSVP does not include the Layer-2 overhead,
which is difficult to calculate for ATM. Layer-3 packets are first framed
(AAL5SNAP header is prepended) and then segmented in 48-byte cells. Each cell
has an additional 5 bytes of overhead.

RSVP to SVC Mapping
Optional QoS
• RSVP can mark conforming and exceeding

packets with different IP precedence or ToS
values
• Per-VC WRED can be used for differentiated
dropping
In addition to RSVP mapping into SVCs, individual virtual circuits can use IP
precedence or ToS marking and WRED for congestion management.

Configuring
RSVP to SVC Mapping
• The following configuration steps are needed

to enable RSVP to SVC mapping:
– Enable RSVP
– Enable SVC creation
– Optionally enable RSVP-based marking and WRED
– Verify and monitor RSVP/ATM
The RSVP-ATM QoS Interworking feature allows the following tasks to be

performed:
n Enable RSVP by specifying the total amount of bandwidth that can be
reserved by RSVP sessions and a maximum amount of bandwidth one session
can reserve.
n Configure an interface or subinterface to dynamically create SVCs in response
to RSVP reservation request messages. To ensure defined QoS, these SVCs
are established having QoS profiles consistent with the mapped RSVP flow
specifications.
n Optionally, attach distributed Weighted Random Early Detection (dWRED)
group definitions to the Enhanced ATM port adapter (PA-A3) interface to
support the per-VC dWRED drop policy. Use of per-VC dWRED ensures
that, if packets must be dropped, then best-effort packets are dropped first and
not those that conform to the appropriate QoS determined by the token bucket
of RSVP.
n Optionally, configure the IP Precedence and ToS values to be used for packets
that conform to or exceed QoS profiles. As part of its input processing, RSVP
uses the values specified to set the ToS and IP Precedence bits on incoming
packets. If per-VC DWRED is configured, it then uses the ToS and IP
Precedence bit settings on the output interface of the same router in
determining which packets to drop. Also, interfaces on downstream routers
use these settings in processing packets.

Enabling RSVP
Router(config-if)#
ip rsvp bandwidth reservable-bw max-flow-bw
• Enables RSVP reservation on an interface or

subinterface
• The reservable-bw parameters specifies the total
maximum amount of bandwidth that can be reserved
by RSVP flows
• The max-flow-bw parameter specifies the maximum
amount of bandwidth a single flow can reserve
The ip rsvp bandwidth interface command is used to enable RSVP on an

interface. The interface and per-flow maximum reservable bandwidth limits have
to be configured.
Note RSVP cannot reserve more than 75% of the default or configured interface
bandwidth.

Enabling Creation of SVCs
Router(config-if)#
ip rsvp svc-required
• Enables creation of SVC for RSVP reservation

• ATM QoS parameters are determined by using the
parameters in the RSVP request
Router(config-if)#
ip
ip rsvp
rsvp atm-peak-rate-limit
atm-peak-rate-limit limit
limit
• Sets the peak cell rate for all new SVC

• Uses the line rate as the default
Use the ip rsvp svc-required interface configuration command to enable the

creation of a Switched Virtual Circuit (SVC) to service any new Resource
Reservation Protocol (RSVP) reservation made on the ATM interface or
subinterface.
Use the ip rsvp atm-peak-rate-limit interface configuration command to set a
limit on the Peak Cell Rate (PCR) of reservations for all newly created Resource
Reservation Protocol (RSVP) switched virtual circuits (SVCs) established on the
ATM interface or any of its subinterfaces. The PCR, if it is not configured,
defaults to the line rate.

RSVP-based Marking and WRED
Router(config-if)#
ip rsvp precedence {conform | exceed} precedence
precedence
• Packets conforming to the reserved bandwidth are marked with

conform precedence
• Packets exceeding the reserved bandwidth are marked with
exceed precedence
• NetFlow has to be enabled
Router(config-if)#
random-detect attach random-detect-group
random-detect-group
• Enables per-VC WRED

• Uses the WRED profiles specified in the WRED group random-
detect-group
• CEF switching is required
Packets in an RSVP reserved path are divided into two classes: those that conform
to the reservation service parameters and those that correspond to a reservation
but exceed, or are outside, the reservation service parameters.
The ip rsvp precedence interface command allows the IP Precedence values to
be set to be applied to packets belonging to these two classes. The IP Precedence
value for at least one class of traffic must be set when this command is used. A
single instance of the command can be used to specify values for both classes, in
which case the conform and exceed keywords can be specified in either order.
As part of its input processing, RSVP uses the ip rsvp precedence command to
set the IP Precedence bits on conforming and nonconforming packets. If per-VC
dWRED is configured, the system uses the IP Precedence and ToS bit settings on
the output interface in its packet drop process. The IP Precedence setting of a
packet can also be used by interfaces on downstream routers.
Execution of the ip rsvp precedence command causes IP Precedence values for
all preexisting reservations on the interface to be modified.
RSVP receives packets from the underlying forwarding mechanism. Therefore,
before the ip rsvp precedence command is used to set IP Precedence, one of
the following features is required:
n Weighted Fair Queuing (WFQ) must be enabled on the interface
n RSVP switched virtual circuits (SVCs) must be used in combination with
NetFlow

RSVP to SVC Mapping
Example
interface
interface ATM2/1/0
ATM2/1/0
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
255.255.255.0
ip
ip rsvp
rsvp bandwidth
bandwidth 10000
10000 10000
10000
ip
ip rsvp
rsvp svc-required
svc-required
ip route-cache
ip route-cache flowflow
ip
ip rsvp
rsvp precedence
precedence conform
conform 5
5 exceed 0
exceed 0
atm
atm pvc
pvc 11 00 55 qsaal
qsaal
atm
atm pvc
pvc 22 0 16
16 ilmi
ilmi
atm
atm esi-address
esi-address 111111111151.00
111111111151.00
pvc
pvc pvc12
pvc12 0/51
0/51
inarp
inarp 55
broadcast
broadcast
!!
The sample configuration shows that up to 10Mbps can be reserved by RSVP

sessions. RSVP sessions trigger establishment of SVCs and marks conforming
packets with IP precedence 5.

RSVP to SVC Mapping
Router#
show ip rsvp interface [intf]
• Displays RSVP-related interface information

Router#show
Router#show ip
ip rsvp
rsvp interface
interface
interface
interface allocated
allocated i/f
i/f max
max flow
flow max
max pct
pct UDP
UDP IP
IP UDP_IP
UDP_IP UDP
UDP M/C
M/C
Et4/0
Et4/0 0M
0M 7M
7M 5M
5M 00 00 00 00 00
AT5/0/0
AT5/0/0 0M
0M 10M
10M 1M
1M 00 00 00 00 00
Se5/1/0
Se5/1/0 0M
0M 192K
192K 192K
192K 00 00 00 00 00
Use the show ip rsvp interface command to display RSVP parameters and
statistics for all RSVP-enabled interfaces.
Field Description
interface Interface name.
allocate Current allocation budget.
i/f max Maximum allocatable bandwidth.
flow max Largest single flow allocatable on this
interface.
pct Percent of bandwidth utilized.
UDP Number of neighbors sending User Datagram
Protocol (UDP)-encapsulated RSVP.
IP Number of neighbors sending IP-encapsulated
RSVP.
UDP_IP Number of neighbors sending both UDP- and
IP-encapsulated RSVP.

Summary
RSVP flows can be provided guarantees either by using a queuing mechanism that
supports per-flow queuing (for example, WFQ of CB-WFQ) or it can use
dedicated per-flow Switched Virtual Circuits (SVCs) when entering an ATM
backbone.
Each RSVP flow triggers a generation of a SVC. The SVC inherits service
parameters from the RSVP service parameters (modified to account for Layer-2
overhead).
Review Questions
1. How does RSVP benefit from using SVCs?
2. What are the necessary configuration steps to enable RSVP-to-SVC?

Summary
n List the requirements of IP QoS in combination with ATM QoS
n Describe and configure per-VC WRED
n Describe and configure VC bundling
n Describe and configure per-VC CB-WFQ
n Monitor and troubleshoot IP QoS on ATM interfaces

Introduction to IP over ATM
Question: What are the main differences between IP and ATM?
IP is connectionless, ATM is connection oriented
IP applies QoS per packet, ATM per virtual circuit
IP supports a smaller number of traffic classes (IP precedence, DSCP) and does
not include any services by default
ATM supports a larger number of traffic classes but has a fixed number of
services (xBR)
Answer: Which QoS services does ATM support?
CBR, VBR, ABR and UBR
Question: How should congestion be handled when an ATM backbone is used?
Congestion should be pushed back to the ingress into the ATM network to allow
IP-based congestion management.
Answer: Why is per-VC queuing so important?
Per-VC queuing prevents head-of-line blocking and allows per-VC congestion
management.
Per-VC WRED
Question: What are the benefits of per-VC WRED?
Answer: Per-VC WRED allows differentiated congestion avoidance on per-VC
basis.
Question: What are the configuration steps needed to enable per-VC WRED?
Answer: Per-VC WRED requires the configuration of WRED profiles (random
detect groups) which are then attached to individual VCs.
VC Bundling
Question: How does VC Bundling classify IP packets?
Answer: VC Bundling classifies IP packets based on the IP precedence value.
Question: Which QoS mechanisms are used when using VC Bundling?
Answer: A QoS design can rely on the ATM QoS or supplement it by using
per-VC WRED or CB-WFQ.
Question: How many parallel VCs can be used for one IP adjacency?

Answer: Up to 8 parallel VCs can be used for one point-to-point IP adjacency.
Question: How many IP precedence values can map into one VC?
Answer: Up to 8 consecutive IP precedence values can map into one VC.
Per-VC CB-WFQ
Question: Where can CB-WFQ be attached on ATM interfaces?
Answer: CB-WFQ can be used on per-interface, per-subinterface or per-VC
basis.
RSVP to SVC Mapping

Question: How does RSVP benefit from using SVCs?
Answer: RSVP-based flows can get their QoS resources by using dedicated
SVCs with the appropriate ATM QoS parameters derived from the RSVP
requests.
Question: What are the necessary configuration steps to enable RSVP-to-SVC?
Answer: Enable RSVP throughout the network and then enable SVC creation
for RSVP flows on ATM interfaces
n

IP over MPLS
Overview
This module focuses on the IP QoS mechanisms available in combination with
Multiprotocol Label Switching (MPLS).
Objectives
n Describe and configure QoS Mechanisms in Frame-mode MPLS networks
n Describe and configure QoS Mechanisms in Cell-mode MPLS networks
MPLS Introduction
Objectives
n Describe basic features of MPLS
n Describe Frame-mode MPLS
n Describe Cell-mode MPLS
23-2 World Wide Training Word Templates v1 Copyright  1999, Cisco Systems, Inc.
Basic MPLS Concepts
• Multi-protocol Label Switching (MPLS) is a

new forwarding mechanism in which packets
are forwarded based on labels
• Labels may correspond to IP destination
networks (equal to traditional IP forwarding)
• Labels can also correspond to other
parameters (QoS, source address, ...)
• MPLS was designed to support forwarding of
other protocols as well
© 2001, Cisco Systems, Inc. IP QoS IP over MPLS
Multi-protocol Label Switching (MPLS) is a switching mechanism that uses labels

(numbers) to forward packets.
Labels usually correspond to layer-3 destination addresses (equal to destination-
based routing). Labels can also correspond to other parameters (QoS, source
address, etc.).
MPLS was designed to support other protocols as well. Label switching is
performed regardless of the layer-3 protocol.
Copyright  1999, Cisco Systems, Inc. Release Date: 2/1/99 23-3

MPLS Example
10.1.1.1 10.1.1.1
L=3
5
L=
Routing lookup
Label removal and
and label assignment
routing lookup 10.0.0.0/8 à L=5
L=3
Label
swapping
L=5 à L=3
• Only edge routers must perform a routing

lookup.
• Core routers switch packets based on simple
label lookups and swap labels.
The example in the figure illustrates a situation where the intermediary router does
not have to perform a time-consuming routing lookup. Instead this router simply
swaps a label with another label (5 is replaced by 3) and forwards the packet
based on the received label (5).
In larger networks, the result of MPLS labeling is that only the edge routers
perform a routing lookup. All the core routers forward packets based on the labels.
MPLS vs. IP-over-ATM
10.1.1.1 L=17 L=5 10.1.1.1

L=3
Layer-2 devices run a

layer-3 routing protocol
and establish virtual
circuits dynamically based
on layer-3 information
• Layer-2 devices are IP-aware and run a

routing protocol
• There is no need to manually establish
virtual circuits
• MPLS provides a virtual full-mesh topology
The example in the figure shows how MPLS is used in ATM networks to provide
optimal routing across layer-2 ATM switches. In order for MPLS to work with
ATM switches, the switches must be layer-3 aware (ATM switches must run a
layer-3 routing protocol).
Another benefit of this setup is that there is no longer a need to manually establish
virtual circuits. ATM switches automatically create a full mesh of virtual circuits
based on layer-3 routing information.

Traffic Engineering with MPLS
Primary
OC-192 link
Large site A
Large site B
Secondary
OC-48 link
Small site C
• Traffic can be forwarded based on other

parameters (QoS, source, ...)
• Load sharing across unequal paths can be
achieved
MPLS also supports traffic engineering. Traffic engineered tunnels can be created
based on a traffic analysis to provide load balancing across unequal paths.
Multiple traffic engineering tunnels can lead to the same destination but can use
different paths. Traditional IP forwarding would force all traffic to use the same
path based on the destination-based forwarding decision. Traffic engineering
determines the path at the source based on additional parameters (available
resources and constraints in the network).
MPLS Architecture
• MPLS has two major components:

• Control plane – exchanges layer-3 routing information and
labels
• Data plane – forwards packets based on labels
• Control plane contains complex mechanisms to
exchange routing information (OSPF, EIGRP, IS-IS,
BGP,...) and labels (TDP, LDP, BGP, RSVP, ...)
• Control plane maintains the contents of the label
switching table (label forwarding information base or
LFIB)
• Data plane has a simple forwarding engine
To better understand the inner workings of MPLS, its two major components
should be clarified:
n Control plane, which takes care of the routing information exchange and the
label exchange between adjacent devices
n Data plane, which takes care of forwarding either based on destination
addresses or labels.
There is a large number of different routing protocols such as OSPF, IGRP,
EIGRP, IS-IS, RIP, BGP, etc. that can be used in the control plane.
The control plane also requires protocols such as TDP (MPLS), LDP (MPLS),
BGP (MPLS/VPNs), RSVP (Traffic Engineering), CR-LDP (Traffic
Engineering), etc. to exchange labels.
The data plane however, is a simple label-based forwarding engine that is
independent of the type of routing protocol or label exchange protocol. A Label
Forwarding Information Base (LFIB) is used to forward packets based on labels.
The LFIB table is populated by the control plane.

MPLS Architecture
Control plane
OSPF
OSPF: 10.0.0.0/8 OSPF: 10.0.0.0/8
LDP: 10.0.0.0/8 LDP LDP: 10.0.0.0/8

Label 17 Label 4
Data plane
Labeled packet LFIB Labeled packet
Label 17 4à17 Label 4
• Router’s functionality is divided into two

major parts: control plane and data plane
A simple MPLS-enabled network implements destination-based forwarding that

uses labels to make forwarding decisions.
A layer-3 routing protocol is still needed to propagate layer-3 routing information.
A label exchange mechanism is simply an add-on to propagate labels that are used
for layer-3 destinations.
The example in the figure illustrates the two components of the control plane:
n OSPF that receives and forwards IP network 10.0.0.0/8, and places that prefix
into the routing table.
n LDP that receives label 17 to be used for packets with a destination address
10.x.x.x. A local label 4 is generated and sent to upstream neighbors so these
neighbors can label packets with the appropriate label. LDP inserts an entry
into the Data Plane’s LFIB table where label 4 is mapped to label 17.
The data plane then forwards all packets with label 4 through the appropriate
interfaces and replaces the label with label 17.
MPLS Modes of Operation
• MPLS technology is designed to be Layer-1

and Layer-2 independent
• MPLS uses a 32-bit label field which is
inserted between Layer-2 and Layer-3
headers (frame mode)
• MPLS over ATM uses the ATM header as the
label (cell mode)
MPLS is designed for use on virtually any media and layer-2 encapsulation. Most
layer-2 encapsulations are frame-based and MPLS simply inserts a 32-bit label
between the layer-2 and layer-3 headers (“frame-mode” MPLS).
ATM is a special case where fixed-length cells are used and a label cannot be
inserted on every cell. MPLS uses the VPI/VCI fields in the ATM header as a
label (“cell-mode” MPLS).

Label Format
LABEL EXP S TTL

0 19 20 22 23 24 31
MPLS uses a 32-bit label field that

contains the following information:
• 20-bit label
• 3-bit experimental field
• 1-bit bottom-of-stack indicator
• 8-bit time-to-live field (TTL)
A 32-bit label contains the following fields:

n 20-bit label: the actual label
n 3-bit experimental field: used to define a class of service (i.e. IP precedence)
n Bottom-of-stack bit: MPLS allows multiple labels to be inserted; this bit is used
to determine if this is the last label in the packet
n 8-bit time-to-live (TTL) field: has the same purpose as the TTL field in the IP
header
Frame Mode MPLS
Frame
IP header Payload
header
Layer 2 Layer 3
Routing
lookup and
label
assignment
Frame
Label IP header Payload
header
Layer 2 Layer 2½ Layer 3
The example in the figure shows an edge router that receives a normal IP packet.
The router then performs the following actions:
n A routing lookup to determine the outgoing interface
n A label is assigned and inserted between layer-2 frame header and layer-3
packet header if the outgoing interface is enabled for MPLS and a next-hop
label for the destination exists
n The labeled packet is sent
Other routers in the core simply forward the packet based on the label.

Cell mode MPLS
Frame
IP header Payload
header
Layer 2 Layer 3
Frame
Label IP header Payload
header
VPI/VCI fields are

used for label
switching
ATM AAL5
Cell 1 Label IP header Payload
header header
ATM
Cell 2 Payload
header
Cell-mode MPLS uses the ATM header’s VPI/VCI fields to make forwarding
decisions while the 32-bit label is still preserved in the frame but not used in the
ATM network. The original label is only present in the first cell of a packet.
Label Switch Router
MPLS Domain
10.1.1.1 L=3 L=5 10.1.1.1
20.1.1.1 L=31 L=43 20.1.1.1
Edge
LSR
LSR
• Label Switch Router (LSR) primarily forwards labeled

packets (label swapping)
• Edge LSR primarily labels IP packets and forwards
them into the MPLS domain, or removes labels and
forwards IP packets out of the MPLS domain
Before proceeding with a detailed description of MPLS, some of the terminology

that is used in this course is presented:
n Label Switch Router (LSR): a device that primarily forwards packets based on
labels.
n Edge LSR: a device that primarily labels packets or removes labels.
LSRs and Edge LSRs are usually devices that are capable of doing both label
switching and IP routing. Their names are based on their position in an MPLS
domain. Routers that have all interfaces enabled for MPLS are called LSRs
because they mostly forward labeled packets. Routers that have some interfaces
that are not enabled for MPLS are usually at the edge of an MPLS domain
(autonomous system). These routers also forward packets based on IP destination
addresses and label them if the outgoing interface is enabled for MPLS.

ATM Label Switch Router
MPLS Domain
10.1.1.1 L=1/3 L=1/3 L=1/3 L=1/5 L=1/5 L=1/5 10.1.1.1
20.1.1.1 L=1/6 L=1/6 L=1/6 20.1.1.1

L=1/9 L=1/9 L=1/9
ATM ATM
Edge LSR
LSR
• ATM LSR can only forward cells
• ATM Edge LSR segments packets into cells and
forwards them into an MPLS ATM domain, or
reassembles cells into packets and forwards them
out of an MPLS ATM domain
Label Switch Routers that perform cell-mode MPLS are called:

n ATM LSR if they are ATM switches. All interfaces are enabled for MPLS
and forwarding is done based only on labels.
n ATM Edge LSR if they are routers connected to an MPLS-enabled ATM
network.
Architecture of LSRs
LSRs, regardless of the type, perform the

following three functions:
• Exchange routing information
• Exchange labels
• Forward packets (LSRs and edge LSRs) or
cells (ATM LSRs and ATM edge LSRs)
The first two functions are part of the
control plane
The last function is part of the data plane
LSRs of all types must perform the following functions:

n Exchange layer-3 routing information (ATM LSRs must also exchange layer-3
routing information)
n Exchange labels
n Forward packets or cells
Frame-mode and cell-mode MPLS use a different data plane:
n Frame-mode MPLS forwards packets based on the 32-bit label
n Cell-mode MPLS forwards packets based on labels encoded into the VPI/VCI
fields in the ATM header
The control plane performs the following functions:
n Exchange routing information regardless of the type of LSR;
n Exchange labels according to the type of MPLS (frame-mode or cell-mode);

Architecture of LSRs
LSR
Exchange of Control plane

routing information
Routing protocol
IP routing table
Exchange of
labels
Label distribution protocol
Incoming Data plane Outgoing

labeled packets labeled packets
Label forwarding table
LSRs primarily forward labeled packets

or cells (ATM LSRs)
The primary function of an LSR is to forward labeled packets. Therefore, every

LSR needs a layer-3 routing protocol (OSPF, EIGRP, IS-IS, etc.) and a label
exchange protocol (LDP, TDP, etc.).
The label exchange protocol populates the LFIB table in the data plane that is used
to forward labeled packets.
Note LSRs may not be able to forward unlabeled packets either because they are ATM
LSRs, or they do not have all the routing information.
Architecture of Edge LSRs
Edge LSR
Exchange of Control plane

routing information
Routing protocol
IP routing table
Exchange of
labels
Label distribution protocol
Incoming
Data plane Outgoing
IP packets IP packets
IP forwarding table
Incoming Outgoing
labeled packets labeled packets
Label forwarding table
Note: ATM edge LSRs can only forward cells

Edge LSRs also forward IP packets based on their IP destination addresses and
optionally label them if a label exists.
The following combinations are possible:
n A received IP packet is forwarded based on the IP destination address and
sent as an IP packet.
n A received IP packet is forwarded based on the IP destination address and
sent as a labeled packet.
n A received labele d packet is forwarded based on the label; the label is changed
and the packet is sent.
The following scenarios are possible if the network is misconfigured:
n A received labeled packet is dropped if the label is not found in the LFIB table
even if the IP destination exists in the FIB table.
n A received IP packet is dropped if the destination is not found in the FIB table
even if there is a label-switched path available for the destination.

Summary
MPLS architecture is divided into two parts:
n Control plane that takes care of routing information and label propagation.
n Data plane that takes care of the forwarding of packets.
MPLS has two modes:
n Frame-mode MPLS that is used on all frame-based media.
n Cell-mode MPLS that is used in MPLS-enabled ATM networks.
MPLS networks use the following devices:
n Label Switch Router (LSR) to forward packets based on a 32-bit label
n Edge LSR to forward labeled packets or label IP packets or remove labels.
n ATM LSRs to forward cells based on labels encoded into the VPI/VCI fields
in the ATM header.
n ATM Edge LSRs that segment labeled or unlabeled packets into ATM cells
where a label is encoded into VPI/VCI fields in the ATM header.
Review Questions
1. What are the main benefits of MPLS?
2. How is an MPLS label encoded into IP packets?
3. How are labels propagated?
Frame-mode MPLS
Objectives
n Describe the QoS possibilities in networks using Frame-mode MPLS
n Use MQC to implement QoS with Frame-mode MPLS

MPLS QoS
• MPLS uses labels to make a forwarding

decision
• The MPLS label is inserted between Layer-2
(frame) and Layer-3 (IP packet) headers
• All Layer-3 information becomes invisible to
routers in an MPLS domain
• Classification in MPLS-enabled networks can
be performed on:
• MPLS experimental bits
• MPLS labels (future enhancement)
Frame-mode MPLS uses 32-bit labels primarily to make a forwarding decision.

Three bits in the label are used for experimental purposes.
When an IP packet enters an MPLS domain a label is inserted between the frame
and the IP header.
The MPLS experimental bits can be used for classification and marking purposes
when implementing QoS in an MPLS domain.
Future enhancements will allow multiple labels to be used to describe the quality of
service.
MPLS Label Assignment
Frame
IP Payload
Header
IP precedece
MPLS exp
Frame
LABEL IP Payload
Header
• An MPLS label has a three-bit experimental field

• Cisco routers automatically copy IP precedence bits
into the MPLS experimental bits
• The Modular QoS CLI can be used to classify labeled
packets based on their MPLS experimental bits
The figure illustrates the default behavior of Cisco routers. IP precedence is

automatically copied from the IP header into MPLS label’s experimental bits.
The modular QoS CLI can be used to classify labeled packets based on MPLS
experimental bits as well as mark labeled packets with MPLS experimental-bit
values.

MPLS-aware QoS Mechanisms
• The following QoS mechanisms are MPLS aware:

- Weighted Random Early Detection (WRED): MPLS
experimental bits are used as weight in the same manner as
IP precedence
- Committed Access Rate (CAR): marking of MPLS
experimental bits
- Class-Based Policing: marking of MPLS experimental bits
- Class-based Marking: marking of MPLS experimental bits
• If classification is performed based on MPLS
experimental bits, other MQC QoS mechanisms can
also be used
The figure lists the QoS mechanisms that can interact with MPLS-specific
information:
n WRED performs random drops based on MPLS experimental values.
n CAR can mark labeled packets with MPLS experimental values. Conforming
and exceeding packets can be marked with different MPLS experimental
values.
n Class-based Policing can mark labeled packets with MPLS experimental
values. Conforming, exceeding and violating packets can be marked with
different MPLS experimental values.
n Class-based Marking can statically mark labele d packets with an MPLS
experimental value.
Other QoS mechanisms (for example: CB-WFQ, CB-LLQ) can be used in
combination with classification that is based on the value of the MPLS
experimental bits.
Configuring CB-WFQ for MPLS
Router(config-cmap)#
match mpls experimental exp
• Classifies packets based on MPLS experimental bits

class-map
class-map match-any
match-any Gold
Gold
match
match ip
ip precedence
precedence 33 44
match
match mpls
mpls experimental
experimental 33 44
!!
class-map
class-map match-any
match-any Silver
Silver
match
match ip
ip precedence
precedence 11 22
match
match mpls
mpls experimental
experimental 11 22
!!
policy-map
policy -map IP+MPLS
class
class Gold
bandwidth
bandwidth 3000
class
class Silver
Silver
bandwidth
bandwidth 1000
1000
!!
Interface
Interface Ethernet0/0
Ethernet0/0
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.0
255.255.255.0
mpls
mpls ip
ip
service-policy
service-policy output IP+MPLS
output IP+MPLS
!!
Classification based on MPLS experimental bits is performed by using the match

mpls experimental command in the class-map configuration mode. Up to eight
values can be used within one class map.
The sample configuration shows a generic class map using the match-any
classification strategy to classify IP packets and labeled packets with the same IP
precedence or MPLS experimental value.

CAR Diagram
Meter
Meter
Yes Forward
Conform or exceed
Conforms?
Conforms? Transmit?
Transmit? or
marking value
Enqueue
No
Go to
Mark?
Mark? Yes
Continue?
Continue? Next
CAR command
Yes No
Set
Set IP
IP prec?
prec? Set
Set IP
IP Precedence
Precedence
Yes Drop
Drop
Set
Set DSCP?
DSCP? Set
Set DSCP
DSCP
Yes
Set
Set MPLS
MPLS exp?
exp? Set
SetMPLS
MPLSExperimental
Experimental
Yes
Set
Set QoS
QoS grp?
grp? Set
Set QoS
QoS Group
Group
• Marking depends on whether the packet conforms to

or exceeds the policy
Committed Access Rate (CAR) can be used to differentially mark packets based
on the arrival rate of packets within the selected class. If a packet conforms (is
within contract) it is marked with one value, if it exceeds it is marked with a
different value.
CAR also supports recursive processing of packets. One packet can be processed
by multiple rate-limit commands.
Configuring
Configuring CAR for MPLS
Router(config-if)#
rate-limit {input | output} {access-group rate-limit
rate-limit acl}
acl} rate B CC BBEE
conform-act {set-mpls-exp-transmit exp
exp | set-mpls-exp-continue
set-mpls-exp-continue exp}
exp}
exceed-act
exceed-act {set-mpls-exp-transmit
{set-mpls-exp-transmit exp | set-mpls-exp-continue exp}
• CAR can mark MPLS packets based on their arrival rate
• CAR supports recursive processing of rate-limit commands
• CAR supports classification based on MPLS experimental bit values by
using rate-limit access list
• Both conform and exceed actions support other actions: transmit,
continue, drop, set-prec-transmit, set-prec-continue, …
interface
interface Serial0/0
Serial0/0
ip
ip address
address 10.1.1.1
10.1.1.1 255.255.255.252
255.255.255.252
rate-limit
2000 conform
conform set
set-mpls-exp-tr
-mpls-exp-tr 55 exceed
exceed set-
set-
mpls -exp-tr 0
mpls-exp-tr 0
rate-limit
rate-limit output
output 64000
64000 2000
2000 2000
2000 conform
conform set-mpls-exp-tr
set-mpls-exp-tr 55 exceed
exceed set -
set-
mpls -exp-tr 00
mpls-exp-tr
!!
CAR also supports a special rate-limit access list that can match labeled packets
based on their MPLS experimental values.
The action options include the two that can set MPLS experimental values:
n set-mpls-exp-continue: sets the MPLS experimental bits (0 to 7) and
evaluates the next rate-limit command.
n set-mpls-exp-transmit: set the MPLS experimental bits (0 to 7) and
transmits the packet.

Configuring CAR for MPLS
Router(config)#
access-list
rate-limit acl {exp | mask
mask mask}
mask}
• The acl index must be between 200 and 299 to select the rate
limit access list for MPLS experimental bits
• Rate limit access lists can be used to match on one or more
MPLS experimental values
• Set one value (exp) to be matched or use the mask option to
match on more values
• Each access list can have only one line
interface
interface Serial0/0
Serial0/0
rate-limit
rate-limit output access-group
access-group rate-limit 200 64000
64000 2000 2000
2000 conform
conform
transmit
transmit exceed
exceed drop
drop
rate-limit
rate-limit input
input access-group
access-group rate-limit
rate-limit 201
201 64000
64000 2000
2000 2000
2000 conform
conform set-
set-
mpls-exp-tr
mpls-exp-tr 00 exceed
exceed set-mpls-exp-tr
set-mpls-exp-tr 00
!!
access-list
rate-limit 200
200 22
access-list
rate-limit 201
201 mask
mask FE
!!
Special rate-limit access lists allow high-performance classification based on the

n IP precedence value if the number of the access list is in the range from 1 to
99
n MAC address if the number of the access list is in the range from 100 to 199
n MPLS experimental bits if the number of the access list is in the range from
200 to 299
A rate limit access list can have only one line. A single MPLS experimental value
can be matched by setting the exp value. Multiple values can be matched by using
the mask keyword and applying a mask in hex. This mask is an 8 bit value where
each bit corresponds to one experimental value 0 through 7. The low order bit
corresponds to value 0 and the high-order bit corresponds to value 7. Setting the bit
value to 1 indicates that the corresponding experimental value is a match; setting
the value to 0 indicates that the corresponding value is not a match. A combination
of bits in the mask can be used to match on any number of MPLS experimental
values.
For example, to match an experimental value of 0, the mask would be 01 (0000
0001 binary). To match a value of 5, the mask would be 20 (0010 0000 binary).
The second rate-limit command in the sample configuration above uses the mask
FE (1111 1110 binary) to match all MPLS experimental values except value 0.
CB-Policing
• CB-Policing is similar to CAR except:

- It uses the Modular QoS CLI for classification
- It supports three different actions (conform,
exceed and violate)
- It does not support recursive processing of
packets
Class-based Policing is used for the same purpose as CAR. CB-Policing differs
from CAR in the following ways:
n The Modular QoS CLI is used to classify packets.
n It can use two token buckets to determine whether a packet conforms to,
exceeds or violates the policy.
n It does not support recursive processing of packets (the continue option is not
available).

Configuring
Configuring CB-Policing for MPLS
police avg-rate [BCC [BE]] [conform-action
[conform-action [action]
[exceed-action [action]
[action] [violate-action [action]]]]
[action]]]]
• avg-rate – traffic rate in bps (8.000 to 200.000.000)
• BC – normal burst size dimensions the first token bucket in
bytes (default is 1500 or avg-rate/32; whatever is higher)
• BE – excess burst size dimensions the second token bucket in
bytes (equals BC if not configured)
• action – can be:
- transmit (default conform action)
- drop (default exceed and violate action)
- set-prec-transmit ip-precedence
- set-dscp-transmit dscp
- set-qos-transmit qos-group
- set-mpls-exp-transmit mple-exp
- set frde-transmit
- set-clp-transmit
The figure shows that one of several actions can be used to mark labeled packets
with an MPLS experimental value. Three different values can be used within a
single class depending on whether a packet conforms to, exceeds or violates the
policy.
CB Marking
• Class-based Marking can be used to mark

labeled packets by setting the MPLS
experimental bits
• MPLS experimental bits can currently only be
set on input
• DSCP should be translated to IP precedence
prior to entry into an MPLS domain
Class-based Marking can use the classification options available in the Modular
QoS CLI and statically mark classes with the MPLS experimental values.
Implementation limitations should be considered when translating between any pair
of parameters on MPLS domain borders (DSCP to MPLS, IP precedence to
MPLS). MPLS marking is currently only supported on input. Inbound IP packets
can be directly marked with MPLS experimental values. Using the QoS group
parameter is necessary when translating MPLS experimental values back to IP
precedence or DSCP (for example: MPLS to QoS group translation on input and
QoS group to DSCP translation on output). This functionality and these limitations
may change with new IOS versions.

Configuring MPLS Marking
set mpls experimental exp-bits
• Mark labeled packets with the specified value (0 to 7)

• MPLS marking can only be used on input
policy-map
policy-map SetMPLS
SetMPLS
class
class Class1
Class1 qos-group
qos-group 11
set mpls
mpls experimental
experimental 11
class
class Class2
Class2 qos-group
qos-group 22
set mpls
mpls experimental
experimental 22
class
class Class3
Class3 qos-group
qos-group 22
set mpls
mpls experimental
experimental 33
!!
Use the set mpls experimental command in the policy-map class configuration
mode to mark inbound packets with MPLS experimental values.
The sample configuration shows how a QoS group parameter can be translated
into MPLS experimental bits.
MPLS Translation
Case Study
IP Domain
MPLS Domain
• IP domain is using the DiffServ model:

- EF – Class Premium
- AF1 – Class Gold
- AF2 – Class Silver
- Default – Best effort class
• Translate IP DSCP values to and from MPLS
experimental bits to achieve a similar result in the
MPLS domain
The QoS design in the case study uses DSCP to mark packets. Four classes must
also be managed in the MPLS domain. A translation between DSCP and MPLS is
needed to implement a similar QoS solution in the MPLS domain.
Although standard DSCP values for AF classes seamlessly map to IP precedence
values for backward compatibility it is sometimes necessary to manually translate
markers between DSCP an IP precedence or DSCP and MPLS. For example:
n A QoS design based on IP precedence is using two IP precedence values to
mark packets belonging to one class:
- Class Premium is marked with IP precedence 5 and is guaranteed
low latency
- Class Gold is using IP precedence 4 for conforming (low-drop)
packets and IP precedence 3 for exceeding (high-drop) packets
- Class Silver is using IP precedence 2 for conforming (low-drop)
packets and IP precedence 1 for exceeding (high-drop) packets
- Best effort traffic is marked with IP precedence 0
n When migrating to DSCP-based implementation it is necessary to still support
the old QoS design until the entire network is migrated to support DSCP.
The case study shows how this translation can be done manually.
If the original IP-precedence-based design did not use multiple IP precedence
values per class there should be no need to configure the translation manually. All
class-maps, however, should include class selectors in their match options to
support backward compatibility with IP precedence:
n Matching packets for AF1 requires af11, af12, af13 and cs1 to be matched

n Matching packets for EF requires ef and cs5 to be matched
The solution shown on the following pages illustrates how default behavior can be
changed by manually configuring the translation between IP precedence (MPLS
experimental bits) and the DSCP.
MPLS Translation
Case Study Design
IP precedence
DSCP QoS group MPLS exp
IP Domain MPLS Domain
IP DSCP MPLE
experimental
EF 5
AF1 low-drop 4
AF1 medium-drop 4
AF1 high-drop 3
AF2 low-drop 2
AF2 medium-drop 2
AF2 high-drop 1
Default 0
The figure illustrates how DSCP values should be mapped to IP precedence or

MPLS experimental values. Some information is lost because low-drop and
medium-drop packets of AF1 and AF2 are marked as one low-drop class in the
MPLS domain.
The case study shows how some information about the conforming and exceeding
packets within one class can be retained when entering a non-DSCP part of the
network (either because routers do not support DSCP or because MPLS
experimental bits are used to select Class of Service).
The figure illustrates the translation from three drop probability levels on the DSCP
layer into two drop probability level in the IP precedence (MPLS experimental)
layer. Using this design further limits the network to only use two classes for AF
PHB.

MPLS Translation
Case Study Implementation
IP precedence
DSCP MPLS exp
class-map
class-map EFEF
match
match ip
ip dscp
dscp ef
ef
class-map
class-map AF1LD
AF1LD interface
Serial5/1/0
match
match ip
ip dscp
dscp af11
af11 af12
af12 service-policy
service-policy input DSCP2prec
class-map
class-map AF1HD
AF1HD !!
match
match ip
ip dscp
dscp af13
af13
!!
policy-map
policy-map DSCP2prec
DSCP2prec
class
class EF
EF
set
set ip
ip precedence
precedence 55
class
class AF1LD
AF1LD
set
set ip
ip precedence
precedence 44
class
class AF1HD
AF1HD
set
set ip
ip precedence
precedence 33
!!
The first part of the configuration shows how DSCP is translated to IP precedence
on ingress into the MPLS network. IP precedence is then automatically copied into
MPLS experimental bits.
The default DSCP value equals the default IP precedence value and does not need
to be translated. The EF class does not need to be translated either because the EF
value (101110) is copied as IP precedence into the MPLS experimental field (101),
which equals 5. The configuration for AF2 is not shown in the figure.
MPLS Translation
Case Study Implementation
QoS group
DSCP MPLS exp

class-map
class-map match-any
match-any MPLS5
MPLS5 class-map
class-map QoS5
QoS5
match
match mpls exp 5 match
match qos-group
qos-group 55
match
match ip
ip precedence
precedence 55 class-map
class-map QoS4
QoS4 interface
Serial5/1/1
class-map
class-map match-any
match-any MPLS4
MPLS4 match
match qos-group
qos-group 44 service-policy
service-policy input
input MPLS2QoS
MPLS2QoS
match !!
match mpls
mpls exp
exp 4 class-map
class-map QoS3
QoS3
interface
Serial5/1/0
match
match ip precedence 4 match
match qos-group
qos-group 33 service-policy
output QoS2DSCP
QoS2DSCP
class-map
class-map match-any
match-any MPLS3
MPLS3 !!
match
match mpls
mpls exp
exp 3 policy-map
policy-map QoS2DSCP
match
match ip
ip precedence
precedence 33 class
class QoS5
QoS5
!! set
set ip
ip dscp
dscp ef
ef
policy-map
policy-map MPLS2QoS class QoS4
class QoS4
class
class MPLS5 set
set ip dscp
dscp af12
af12
set
set qos-group
qos-group 5 class
class QoS3
QoS3
class
class MPLS4 set
set ip dscp
dscp af13
af13
set
set qos-group
qos-group 44 !!
class
class MPLS3
MPLS3
set
set qos-group
qos-group 3
The remainder of the configuration is used to translate MPLS experimental values

back into DSCP. The class-maps are configured to process IP packets (very likely
due to penultimate hop popping) or labeled packets. Low-drop packets are
translated into medium-drop packets in the DiffServ domain.

Summary
Frame-mode MPLS allows most IP QoS mechanisms to be used. The three MPLS
experimental bits are used in the same way as IP precedence. IP precedence is
actually copied into MPLS experimental bits.
Review Questions
1. Which MPLS parameter is used for classification and marking?
2. What is the default value of the MPLS experimental bits?
3. Which QoS mechanisms can be used to set MPLS experimental bits?
Cell-mode MPLS
Objectives
n Describe QoS features available with Cell-mode MPLS
n Implement QoS on interfaces using Cell-mode MPLS

Cell-mode MPLS QoS
• Classes are encoded with MPLS

experimental bits
• Cell-mode MPLS uses the VPI/VCI fields as
labels for forwarding
• ATM switches are not capable of looking into
the frame-mode label where the experimental
bits are
• QoS is implemented using up to four parallel
virtual circuits (label-switched paths)
ATM is a Layer-2 technology that does not use frames to transmit Layer-3
packets. Packets are fragmented into fixed-length cells. Cell-mode MPLS makes
use of the ATM header to encode labels into VPI/VCI fields. These fields are only
used to make a forwarding decision. QoS cannot be achieved using MPLS
experimental bits because:
n They are only propagated in the first cell of a packet.
n ATM switches do not look into the payload of cells.
QoS is therefore achieved using multiple labels (up to four).
Cell-mode MPLS
Cell-mode MPLS
Frame-mode MPLS
Native IP
• IP precedence used in IP domain is automatically

translated into MPLS experimental bits
• MPLS experimental bits are optionally translated into
up to four parallel virtual circuits (label-switched
paths)
The figure illustrates how IP packets can be propagated over a native IP network
(no MPLS and no ATM or with ATM PVCs), a frame-based MPLS network and
a cell-based MPLS network.
QoS is retained when IP packets enter a frame-based MPLS network by copying
the IP precedence bits into MPLS experimental bits.
When labeled packets enter a cell-based MPLS network, QoS is retained by
forwarding the packet through one of four VCs, which are based on the value of
MPLS experimental bits.

Configuring Multi-VC
Router(config-if)#
mpls atm multi-vc
• The command enables Multi-VC

MPLS exp VC
operation of cell-mode MPLS
• Eight MPLS experimental values are 0 Available
mapped to four virtual circuits 1 Standard
2 Premium
• The class is determined by the two least
3 Control
significant MPLS experimental bits
4 Available
• Default mapping is similar to 5 Standard
classification of distributed ToS-based 6 Premium
WFQ 7 Control
• Default mapping can be replaced using
the cos-map command
Cell-mode MPLS uses one single VC for each IP destination. Use the mpls atm
multi-vc interface command to enable routers to request up to four VCs for each
IP destination. Classification is based on the low-order two bits of the MPLS
experimental field (like ToS-based dWFQ).
The table in the figure shows the default mapping of MPLS values into four VCs:
available, standard, premium and control.
Default mapping can be changed using the mpls cos-map and mpls prefix-map
commands.
Configuring CoS Mapping
Router(config)#
mpls
mpls cos-map number
• Create a CoS map

Router(config-mpls-cos-map)#
class class {available | control | premium | standard}
• Assigns a class to one of four virtual circuits

• Class values can be in the range from 0 to 3
Router(config)#
mpls
mpls prefix-map pfmap access-list acl cos-map cos-map
• Uses CoS map cos-map for all destinations permitted

by access list acl
A CoS map must be configured to change the default behavior of the translation of
MPLS experimental values into one of four virtual circuits (available, standard,
premium and control).
Classes are identified by the two low-order bits of the MPLS experimental field.
Use the mpls prefix-map command to bind a cos-map to all destinations
permitted by the acl access list.
Note Most MPLS-related commands are available with the starting keyword mpls or
the older tag-switching version. Furthermore, using the mpls keyword results in
the command being automatically translated into the tag-switching version for
compatibility with older IOS versions.

tag-switching prefix-map 10 access-list 100 cos-map

cos-map 10
tag-switching prefix-map 11 access-list 101 cos-map
cos-map 10
tag-switching prefix-map 21 access-list
access-list 32 cos-map 34
34
!
tag-switching cos-map
cos-map 10
10
class
class 00 available
class
class 1 standard
class
class 22 premium
premium
class
class 33 control
control
!
interface
interface ATM1/0.1
ATM1/0.1 mpls
ip
ip unnumbered
unnumbered Loopback0
Loopback0
no
no ip
ip mroute-cache
mroute-cache
mpls
mpls atm
atm multi-vc
multi-vc
mpls
mpls ip
!
access-list 100 permit ip 10.0.0.0 0.255.255.255 10.0.0.0
0.255.255.255
The sample configuration shows that all traffic to network 10.0.0.0/8 uses four
parallel VCs. MPLS experimental bits are mapped using cos-map 10.
Note that only prefix map 10 is properly configured. Prefix map 11 does not have
the corresponding access list and prefix map 21 is missing the CoS map as well.
Cell-mode MPLS
Router#
show mpls cos-map [cos-map]
• Lists all configured CoS maps

Router#show
Router#show mpls
mpls cos-map 10
cos-map
cos-map 10 class tag-VC
tag-VC
33 control
control
22 premium
premium
11 standard
standard
00 available
available
Router#
Router#
Use the show mpls cos-map command to verify the parameters assigned to a
cos-map.

Cell-mode MPLS
Router#
show mpls prefix-map [prefix-map]
• Lists all configured prefix maps

Router#show
Router#show mpls
mpls prefix-map
prefix-map
prefix-map
prefix-map 10
10 access-list
access-list 100
100 cos-map
cos-map 10
10
prefix-map
prefix-map 11
11 access-list
access-list 101
101 cos-map
cos-map 10
10
Warning:
Warning: In prefix-map
prefix -map 11,
11, acl
acl 101
101 is
is not
not configured
configured
prefix-map
prefix-map 21
21 access-list
access-list 32
32 cos-map
cos-map 34
Warning:
Warning: In prefix-map
prefix -map 21,
21, acl
acl 32
32 and
and cos-map
cos-map 34
34 are
are not
not configured
configured
Router#
Router#
Use the show mpls prefix-map command to display one or all configured prefix
maps with their corresponding access lists and cos-maps.
Using this command helps determine if there is a component missing:
n Access list 101 is not configured for prefix map 11
n Prefix map 21 is missing both the access list and the CoS map
Summary
Cell-mode MPLS uses up to four virtual circuits to achieve differentiated quality of
service. Packets are classified based on the two low-order bits of the MPLS
experimental field.
Review Questions
1. How is differentia ted QoS implemented on MPLS-enabled ATM
interfaces?
2. What information is used for classification in cell-mode MPLS?

Summary
n Describe and configure QoS Mechanisms in Frame-mode MPLS networks
n Describe and configure QoS Mechanisms in Cell-mode MPLS networks
MPLS Introduction
Question: What are the main benefits of MPLS?
Answer: Simplified BGP designs, support for MPLS-based VPNs.
Question: How is an MPLS label encoded into IP packets?
Answer: A 32-bit label header is inserted in front of the IP header.
Question: How are labels propagated?
Answer: Labels are propagated between adjacent routers using TDP or LDP.
Frame-mode MPLS
Question: Which MPLS parameter is used for classification and marking?
Answer: The MPLS experimental bits are used to classify and mark labeled
packets.
Question: What is the default value of the MPLS experimental bits?
Answer: Cisco routers copy the IP precedence bits into MPLS experimental
bits.
Question: Which QoS mechanisms can be used to set MPLS experimental bits?
Answer: CAR, Class-based Policing and Class-based Marking.
Cell-mode MPLS
Question: How is differentiated QoS implemented on MPLS-enabled ATM
interfaces?
Answers: By using up to 4 VCs (labels) for each destination.
Question: What information is used for classification in cell-mode MPLS?
Answers: Classification is performed based on the two low-order IP precedence
bits.

Cisco Introduction IP QoS (Course)

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco Introduction IP QoS (Course)

Uploaded by

Copyright:

Available Formats

Introduction

2 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

• Phone calls over IP are no better than over satellite!

• Phone calls have really bad voice quality!

• ATM (the money-dispensing-type) are non-

© 2001, Cisco Systems, Inc. IP QoS Introduction-5

The purpose of this module is to determine the following:

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 3

• Application X is slow! (not enough BANDWIDTH)

© 2001, Cisco Systems, Inc. IP QoS Introduction-6

Quality of Service is usually identified by the following parameters:

4 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

• Lack of bandwidth – multiple flows are

© 2001, Cisco Systems, Inc. IP QoS Introduction-7

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 5

256 kbps 512 kbps

10 Mbps 100 Mbps

BW max = min(10M, 256k, 512k, 100M)=256kbps

© 2001, Cisco Systems, Inc. IP QoS Introduction-8

6 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Propagation Propagation Propagation

© 2001, Cisco Systems, Inc. IP QoS Introduction-9

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 7

Processing Delay Queuing Delay

© 2001, Cisco Systems, Inc. IP QoS Introduction-10

8 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

© 2001, Cisco Systems, Inc. IP QoS Introduction-11

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 9

IP TCP data Fancy

© 2001, Cisco Systems, Inc. IP QoS Introduction-12

There are several approaches to solving a problem of insufficient bandwidth:

10 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 11

TCP Header Compression

IP UDP RTP data Fancy

© 2001, Cisco Systems, Inc. IP QoS Introduction-13

Assuming that a router is powerful enough to make a forwarding decision in a

12 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 13

Weighted Random Early Detection (WRED)

IP data Dropper Fancy

Custom Queuing (CQ)

© 2001, Cisco Systems, Inc. IP QoS Introduction-14

Packet loss is usually a result of congestion on an interface. Most applications that

14 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 15

Throughput Delay Loss

Voice Low Low and Low Low

• Enterprise networks are typically focused on

When QoS is considered in a network implementation, important applications and

16 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Throughput Delay Loss

Gold Guaranteed Low Low Low

• Service provider networks typically offer services

Service providers, on the other hand, are there to provide connectivity to

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 17

• Best effort – no QoS is applied to packets

© 2001, Cisco Systems, Inc. IP QoS Introduction-17

18 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 19

20 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

• The Internet was initially based on a best-

© 2001, Cisco Systems, Inc. IP QoS Introduction-22