In order to understand these QoS implementation, it is important to have an understanding of the three different QoS models and how they are applicable when designing and implementing a QoS solution. The three Quality of Service models are:
- Best Effort Delivery (Default)
- Integrated Services
- Differentiated Services
Best Effort Delivery (Default)
As the name implies, the Best-Effort (BE) model does not guarantee any level of service and instead internetwork devices simply make their ‘best effort’ to deliver packets as quickly as possible. The best-effort delivery model scales well, but provides no difference in service for different traffic classes. In other words, when this model is used (which is the default) voice, video, and data traffic are all treated as one and the same. This model requires no Quality of Service implementation within the internetwork.
Integrated Services
Integrated Services (IntServ) performs admission control for each flow request. The IntServ architecture model, defined in RFC 1633, was motivated by the needs of real-time applications such as voice and video. IntServ provides a way to deliver end-to-end QoS for real-time applications by explicitly managing network resources to provide QoS to specific user packet streams (flows). RFC 1633 defines two components to provide guarantees per flow: resource reservation and admission control.
IntServ uses Resource Reservation Protocol (RSVP) to signal the internetworking devices about how much bandwidth and delay a particular flow requires. Admission control is used to decide when a reservation request should be rejected. The primary issue with IntServ is that is scales very poorly, especially when many sources are attempting to reserve end-to-end bandwidth for each of their particular flows. An alternative approach would be to use Differentiated Services Going into detail on IntServ QoS mechanisms is beyond the scope of the SWITCH requirements. These concepts will not be described in any further detail in this chapter.
Differentiated Services
Unlike IntServ, the DiffServ model requires no advance reservations and therefore scales very well. DiffServ defines the concept of service classes. DiffServ also allows each internetwork device to handle these packets on an individual (per hop) basis. This is referred to as per-hop behavior (PHB). Differentiated Services are applicable to Layer 3. Layer 2 frames use Class of Service (CoS) bits that are contained within the 802.1Q or ISL-encapsulated frame. Class of Service will be described in detail later in this chapter. The IPv4 header contains an 8-bit Type of Service (ToS) field. The ToS field specifies the parameters for the type of service requested.
Networks may use these settings to define the handling of the datagram during transport. This is typically performed using the IP Precedence. The IP Precedence is contained in the first three bits of the ToS field. The IPv4 header ToS field IP Precedence bits are illustrated in Figure 10-2 below.
Figure 10-2: Type of Service IP Precedence Bits

Figure 10-1 illustrates the IPv4 packet header and highlights the 8-bit ToS field. The first three bits, bits 0 to 2, of this field are used for IP Precedence, which allows for up to eight (23) IP Precedence values. The next four bits, bits 3 to 6, comprise the ToS field inside the ToS byte and are used to as flags for throughput, delay, reliability, and cost. These bits, however, are beyond the scope of the SWITCH exam requirements. The last bit, bit 7, is unused.
The IP Precedence field values are used to imply a particular class of service. In essence, the higher the IP Prec value (numerically), the more important the traffic. Table 10-3 below lists and describes the different IP Precedence values.
Table 10-3: Type of Service IP Precedence Bit
|
IP Precedence Value |
Bits |
Description / Name |
|---|---|---|
|
0 |
000 000 |
Routine |
|
1 |
001 000 |
Priority |
|
2 |
010 000 |
Immediate |
|
3 |
011 000 |
Flash |
|
4 |
100 000 |
Flash Override |
|
5 |
101 000 |
Critical |
|
6 |
110 000 |
Internetwork Control |
|
7 |
111 000 |
Network Control |
NOTE: The highest IP Precedence value that should be assigned to data traffic (e.g., voice packets) should always be 5. IP Precedence 6 and 7 should never be assigned to user traffic, as these are used by network control traffic, such as routing protocol updates.
DiffServ defines a new Differentiated Services Code Point (DSCP) field in the IP packet header by redefining the ToS byte and creating a replacement for the IP Precedence field with a new 6-bit field called the Differentiated Services (DS) field. In addition to this, the last 2 bits of the ToS byte can now be used to perform flow control, and are referred to as the Explicit Congestion Notification (ECN) bits. This is illustrated in Figure 10-3 below.
Figure 10-3: Type of Service Differentiated Services Code Point Bits

Figure 10-3 illustrates the IPv4 packet header and highlights the 8-bit ToS field. The first six bits, bits 0 to 5, of this field are used for DSCP, which allows for up to 64 (26) DSCP values. The decimal DSCP range is from 0 to 63. The next two bits are the Explicit Congestion Notification (ECN) bits. ECN is beyond the scope of the SWITCH exam requirements and will not be described in this chapter. The 64 DSCP values are backward compatible with IP Precedence values. This compatibility is based on the first three bits, bits 0 through 2, which both IP Precedence and DSCP share in common. Table 10-4 below shows how the decimal DSCP values are mapped to IP Precedence.
Table 10-4: Mapping Decimal DSCP Values to IP Precedence
|
IP Precedence Value |
Decimal DSCP |
|---|---|
|
0 |
0 |
|
1 |
8 |
|
2 |
16 |
|
3 |
24 |
|
4 |
32 |
|
5 |
40 |
|
6 |
48 |
|
7 |
56 |
NOTE: You are not expected to go into detail on how these values are derived. Instead, simply ensure that you are familiar with the DSCP ranges that correspond to an IP Precedence value.
DiffServ defines three sets of PHBs, which are the Class Selector (CS), Assured Forwarding (AF) and Expedited Forwarding (EF) PHBs. The Class Selectors are DSCP values that are compatible with IP Prec values. Although referred to as DSCP values, the class selectors only use the first three bits of the DS field, which is the same three bits used by IP Prec. Table 10-5 below illustrates the DSCP class selector values and how they match the IP Precedence.
Table 10-5: DSCP Class Selector Values
|
DSCP Class Selector |
IP Precedence |
Description |
|---|---|---|
|
Default |
0 |
Routine |
|
CS 1 |
1 |
Priority |
|
CS 2 |
2 |
Immediate |
|
CS 3 |
3 |
Flash |
|
CS 4 |
4 |
Flash Override |
|
CS 5 |
5 |
Critical |
|
CS 6 |
6 |
Internetwork Control |
|
CS 7 |
7 |
Network Control |
The highest DSCP class selector value that should be assigned to user traffic, e.g. voice packets, should always be CS 5. CS 6 and CS 7 should never be assigned to user traffic.
The Assured Forwarding (AF) PHB set is used for two functions: queuing and congestion avoidance. Queuing places the packets into the different software queues based on the QoS labels. Queuing will be described in detail later in this chapter.
Congestion avoidance is used to avoid congestion by randomly discarding packets. Congestion avoidance will also be described in detail later in this chapter. Four AF classes, 1 through 4, are defined. Class 1 is the lowest class, while class 4 is the highest class. Therefore, packets with AF Class 4 will be de-queued before packets with AF Class 1, for example. Each class has three levels of drop precedence, 1 through 3. Drop precedence 1 is the lowest, while drop precedence 3 is the highest. This is used for congestion avoidance.
For example, if two packets, both in AF Class 2 are received, and one has a drop precedence of 1, while the other has a drop precedence of 2, the packet with the drop precedence of 2 will be discarded first (if congestion is experienced) because it has a higher drop precedence. Table 10-6 below lists the four AF classes and their respective drop precedence values.
Table 10-6: Assured Forwarding DSCP Values
| Class | Low Drop Probability | Medium Drop Probability | High Drop Probability |
|---|---|---|---|
| 1 | AF 11 | AF 12 | AF 13 |
| 2 | AF 21 | AF 22 | AF 23 |
| 3 | AF 31 | AF 32 | AF 33 |
| 4 | AF 41 | AF 42 | AF 43 |
To determine the decimal DSCP value for each AF class, you can use the formula 8x + 2y where x references the first number in the AF class, and y represents the second number in the AF class, i.e. AFxy. For example, to determine the decimal DSCP value of AF 42, do the following:
- If DSCP = AF42, then x = 4 and y = 2
- Therefore 8x + 2y = 8(4) + 2(2) = 32 + 4
- 32 + 4 = 36 (This is the decimal DSCP value for AF 42)
As a final example, we will use the same formula to calculate the decimal value for AF 22:
- If DSCP = AF22, then x = 2 and y = 2
- Therefore 8x + 2y = 8(2) + 2(2) = 16 + 4
- 16 + 4 = 20 (This is the decimal DSCP value for AF 22)
The last PHB set is the Expedited Forwarding (EF) set. This uses a single DSCP value (EF) to represent it. The Binary notation of the DSCP value is 101 110, which is 46 in decimal. EF packets are given premium service (above all other classes). This is the default value assigned to voice media packets in Cisco IP Telephony solutions. It is important to remember that even though the DSCP decimal range for both CS 5 and IP Prec 5 is 40 – 47, DSCP value EF is designated only as 46. CS 5 is not the same as EF. Make sure you commit that to memory.