S01 - IP QoS Intrduction

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?
TCP Header Compression

RTP Header Compression
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

– Committed Access Rate (CAR)
– 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
MPLS experimental bits
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:
– Generic Traffic Shaping (GTS)
– Frame Relay Traffic Shaping (FRTS)
– 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
– Adaptation to Frame Relay congestion notification
– Class-based Policing
– 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?
Committed Access Rate (CAR)
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
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.

S01 - IP QoS Intrduction

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

S01 - IP QoS Intrduction

Hochgeladen von

Copyright:

Verfügbare Formate

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

The Internet Engineering Task Force (IETF) is responsible for standardization of