You are on page 1of 6

The DiffServ Model, Differentiated Services Code Point

(DSCP), and Per-Hop Behavior (PHB) (Classification,

Marking, and NBAR)
Within the DiffServ architecture, traffic is preferred to be
classified and marked as soon (as close to the source) as possible.
Marking of the IP packet was traditionally done on the three IP
precedence bits, but now, marking (setting) the six DSCP bits on the
IP header is considered the standard method of IP packet marking.
NOTE Some network devices cannot check or set Layer 3 header QoS
fields (such as IP precedence or DSCP). For example, simple Layer 2
wiring closet LAN switches can only check and set the CoS (PRI) bits
on the 802.1Q header.
Each of the different DSCP valuesin other words, each of the
different combinations of DSCP bitsis expected to stimulate every
network device along the traffic path to behave in a certain way and
to provide a particular QoS treatment to the traffic. Therefore, within
the DiffServ framework, you set the DSCP value on the IP packet
header to select a per-hop behavior (PHB). PHB is formally defined as
an externally observable forwarding behavior of a network node
toward a group of IP packets that have the same DSCP value. The
group of packets with a common DSCP value (belonging to the same
or different sources and applications), which receive similar PHB from
a DiffServ node, is called a behavior aggregate (BA). The PHB toward
a packet, including how it is scheduled, queued, policed, and so on, is
based on the BA that the packet belongs to and the implemented
service level agreement (SLA) or policy.
Scalability is a main goal of the DiffServ model. Complex traffic
classification is performed as close to the source as possible. Traffic
marking is performed subsequent to classification. If marking is done
by a device under control of the network administration, the marking
is said to be trusted. It is best if the complex classification task is not
repeated, and the PHB of the transit network devices will solely
depend on the trusted traffic marking. This way, the DiffServ model
has a coarse level of classification, and the marking-based PHB is
applied to traffic aggregates or behavior aggregates (BAs), with no
per-flow state in the core.
Application-generated signaling (IntServ style) is not part of the
DiffServ framework, and this boosts the scalability of the DiffServ
model. Most applications do not have signaling and Resource
Reservation Protocol (RSVP) capabilities. The DiffServ model provides
specific services and QoS treatments to groups of packets with
common DSCP values (BAs). These packets can, and in large scale do,
belong to multiple flows. The services and QoS treatments that are
provided to traffic aggregates based on their common DSCP values

are a set of actions and guarantees such as queue insertion policy,

drop preference, and bandwidth guarantee. The DiffServ model
provides particular service classes to traffic aggregates by classifying
and marking the traffic first, followed by PHB toward the marked
traffic within the network core.

IP Precedence and DSCP

The initial efforts on IP QoS were based on the specifications
provided by RFC 791 (1981), which had called the 3 most significant
bits of the ToS byte on the IP header the IP precedence bits. The 3 IP
precedence bits can have one of eight settings. The larger the IP
precedence value, the more important the packet and the higher the
probability of timely forwarding. Figure 3-4 displays an IP packet and
focuses on the IP ToS byte, particularly on the IP precedence bits. The
eight IP precedence combinations and their corresponding decimal
values, along with the name given to each IP precedence value, are
also displayed in Figure 3-4. The IP precedence values 6 and 7, called
Internetwork Control and Network Control, are reserved for control
protocols and are not allowed to be set by user applications;
therefore, user applications have six IP precedence values available.
Figure 3-4 IP Header ToS Byte and IP Precedence Values

Redefining the ToS byte as the Differentiated Services (DiffServ)

field, with the 6 most significant bits called the DSCP, has provided
much more flexibility and capability to the new IP QoS efforts. The 2
least significant bits of the DiffServ field are used for flow control and
are called explicit congestion notification (ECN) bits. DSCP is

backward compatible with IP Precedence (IPP), providing the

opportunity for gradual deployment of DSCP-based QoS in IP
networks. The current DSCP value definitions include four PHBs:
Class selector PHBWith the least significant 3 bits of the DSCP
set to 000, the class selector PHB provides backward compatibility
with ToS-based IP Precedence. When DSCP-compliant network devices
receive IP packets from non-DSCP compliant network devices, they
can be configured only to process and interpret the IP precedence
bits. When IP packets are sent from DSCP-compliant devices to the
non-DSCP-compliant devices, only the 3 most significant bits of the
DiffServ field (equivalent to IP precedence bits) are set; the rest of the
bits are set to 0.
Default PHBWith the 3 most significant bits of the DiffServ/DSCP
field set to 000, the Default PHB is used for best effort (BE) service. If
the DSCP value of a packet is not mapped to a PHB, it is consequently
assigned to the default PHB.
Assured forwarding (AF) PHBWith the most significant 3 bits
of the DSCP field set to 001, 010, 011, or 100 (these are also called
AF1, AF2, AF3, and AF4), the AF PHB is used for guaranteed
bandwidth service.
Expedited forwarding (EF) PHBWith the most significant 3
bits of the DSCP field set to 101 (the whole DSCP field is set to
101110, decimal value of 46), the EF PHB provides low delay service.
Figure 3-5 displays the DiffServ field and the DSCP settings for the
class selector, default, AF, and EF PHBs.
Figure 3-5 IP Header DS Field and DSCP PHBs

The EF PHB provides low delay service and should minimize jitter
and loss. The bandwidth that is dedicated to EF must be limited
(capped) so that other traffic classes do not starve. The queue that is
dedicated to EF must be the highest priority queue so that the traffic

assigned to it gets through fast and does not experience significant

delay and loss. This can only be achieved if the volume of the traffic
that is assigned to this queue keeps within its bandwidth limit/cap.
Therefore, successful deployment of EF PHB is ensured by utilizing
other QoS techniques such as admission control. You must remember
three important facts about the EF PHB:
It imposes minimum delay.
It provides bandwidth guarantee.
During congestion, EF polices bandwidth.
Older applications (non-DSCP compliant) set the IP precedence
bits to 101 (decimal 5, called Critical) for delay-sensitive traffic such
as voice. The most significant bits of the EF marking (101110) are
101, making it backward compatible with the binary 101 IP
precedence (Critical) setting.
The AF PHB as per the standards specifications provides four
queues for four classes of traffic (AFxy): AF1y, AF2y, AF3y, and AF4y.
For each queue, a prespecified bandwidth is reserved. If the amount
of traffic on a particular queue exceeds the reserved bandwidth for
that queue, the queue builds up and eventually incurs packet drops.
To avoid tail drop, congestion avoidance techniques such as weighted
random early detection (WRED) are deployed on each queue. Packet
drop is performed based on the marking difference of the packets.
Within each AFxy class, y specifies the drop preference (or probability)
of the packet. Some packets are marked with minimum
probability/preference of being dropped, some with medium, and the
rest with maximum probability/preference of drop. The y part of AFxy
is one of 2-bit binary numbers 01, 10, and 11; this is embedded in the
DSCP field of these packets and specifies high, medium, and low drop
preference. Note that the bigger numbers here are not better,
because they imply higher drop preference. Therefore, two features
are embedded in the AF PHB:
Four traffic classes (BAs) are assigned to four queues, each of
which has a minimum reserved bandwidth.
Each queue has congestion avoidance deployed to avoid tail
drop and to have preferential drops.
Table 3-3 displays the four AF classes and the three drop preferences
(probabilities) within each class. Beside each AFxy within the table, its
corresponding decimal and binary DSCP values are also displayed for
your reference.
Table 3-3 The AF DSCP Values

You must remember a few important facts about AF:

The AF model has four classes: AF1, AF2, AF3, and AF4; they
have no advantage over each other. Different bandwidth reservations
can be made for each queue; any queue can have more or less
bandwidth reserved than the others.
On a DSCP-compliant node, the second digit (y) of the AF PHB
specifies a drop preference or probability. When congestion avoidance
is applied to an AF queue, packets with AFx3 marking have a higher
probability of being dropped than packets with AFx2 marking, and

AFx2 marked packets have a higher chance of being dropped than

packets with AFx1 marking, as the queue size grows.
You can find the corresponding DSCP value of each AFxy in
decimal using this formula: DSCP (Decimal) = 8x + 2y.
For example, the DSCP value for AF31 is 26 = (8 * 3) + (2 * 1).
Each AFx class is backward compatible with a single IP
precedence value x. AF1y maps to IP precedence 1, AF2y maps to IP
precedence 2, AF3y maps to IP precedence 3, and AF4y maps to IP
precedence 4.
During implementation, you must reserve enough bandwidth for
each AF queue to avoid delay and drop in each queue. You can deploy
some form of policing or admission control so that too much traffic
that maps to each AF class does not enter the network or node. The
exact congestion avoidance (and its parameters) that is applied to
each AF queue is also dependent on the configuration choices.
If there is available bandwidth and an AF queue is not policed,
it can consume more bandwidth than the amount reserved.
Most of the fields within the IP packet header in a transmission do
not change from source to destination. (However, TTL, checksum, and
sometimes the fragment-related fields do change.) The Layer 3 QoS
marking on the packet can be preserved, but the Layer 2 QoS
marking must be rewritten at every Layer 3 router because the Layer
3 router is responsible for rewriting the Layer 2 frame. The packet
marking is used as a classification mechanism on each ingress
interface of a subsequent device. The BA of the service class that the
traffic maps to must be committed. To guarantee end-to-end QoS,
every node in the transmission path must be QoS capable. QoS
differentiated service in MPLS networks is provided based on the EXP
bits on the MPLS header. As a result, it is important that at certain
points in the network, such as at edge devices, mapping is performed
between IP precedence, DSCP, CoS, MPLS, or other fields that hold
QoS markings. The mapping between 802.1Q/P CoS, MPLS EXP, and IP
precedence is straightforward because all of them are based on the
old-fashioned 3-bit specifications of the 1980s. Mapping the DSCP
PHBs to those 3-bit fields requires some administrative decisions and