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 values—in other words, each of the different combinations of DSCP bits—is 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 PHB—With 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 PHB—With 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) PHB—With 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) PHB—With 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
|
Drop Probability |
|||
|
Class |
Low Drop |
Medium Drop |
High Drop |
|
Class 1 |
AF11 |
AF12 |
AF13 |
|
DSCP 10: (001010) |
DSCP 12: (001100) |
DSCP 14: (001110) |
|
|
Class 2 |
AF21 |
AF22 |
AF23 |
|
DSCP 18: (010010) |
DSCP 20: (010100) |
DSCP 22: (010110) |
|
|
Class 3 |
AF31 |
AF32 |
AF33 |
|
DSCP 26: (011010) |
DSCP 28: (011100) |
DSCP 30: (011110) |
|
|
Class 4 |
AF41 |
AF42 |
AF43 |
|
DSCP 34: (100010) |
DSCP 36: (100100) |
DSCP 38: (100110) |
|
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 compromises.
