This chapter is from the book
This chapter is from the book
This chapter is from the book
DiffServ and IP Packets
QoS markings in the IP packet have evolved over time. The IP header has always contained a byte known as the type of service (ToS) byte. The 8 bits within this byte have evolved and have been redefined over time. It's a little confusing to start with, because the ToS byte has contained multiple things, some of which were called ToS bits.
Figure 6-1 shows the first four bytes of the IP header as defined in the original IP header (RFC 791, circa 1981) and as redefined in RC 1349 (circa 1992), RFC 2474 (circa 1998), and RFC 3168 (circa 2001).
)
Figure 6-1 Evolution of the First 4 Bytes of the IP Header
Originally, the IP header had 3 precedence bits and 3 ToS bits, as well as 2 unused bits. The precedence bits were (and still are) used to make various decisions about packet treatment. Precedence values 0 through 5 are designated for user data; precedence values 6 and 7 are reserved to make network control traffic. RFC 1349 reassigned one of the unused bits to the ToS bits, giving the IP header a total of 3 precedence bits, 4 ToS bits, and one unused bit.
Use of ToS bits was never well-defined or well-deployed. The original intent was to be able to mark packets that preferred low delay, high throughput, or high-reliability paths, but service architectures were never designed or built around these bits.
The DiffServ set of RFCs (RFCs 2474 and 2475) redefined the entire ToS byte. The ToS byte now contains 6 bits of information that declare desired packet treatment—DSCP bits. The remaining two bits in the ToS byte are used for a TCP mechanism called Explicit Congestion Notification (ECN), which isn't addressed here but is defined in RFC 3168.
When discussing QoS and the ToS byte, some people use IP Precedence terminology, and others use DiffServ terminology. This chapter uses DiffServ terminology, but we recognize that not everyone is familiar with DiffServ and its code points. If you are familiar with IP Precedence but are new to DiffServ, two things you should know are
How to map DSCP bits to IP Precedence bits, and vice versa
What services DSCP offers above and beyond mapping to IP Precedence
The first part is easy—how to map DSCP bits to IP Precedence bits. See Table 6-3.
Table 6-3 Mapping DSCP Bits to IP Precedence Bits
|
IP Precedence (Decimal) |
IP Precedence (Bits) |
DSCP (Decimal) |
DSCP (Bits) |
|
0 |
000 |
0 |
000000 |
|
1 |
001 |
8 |
001000 |
|
2 |
010 |
16 |
010000 |
|
3 |
011 |
24 |
011000 |
|
4 |
100 |
32 |
100000 |
|
5 |
101 |
40 |
101000 |
|
6 |
110 |
48 |
110000 |
|
7 |
111 |
56 |
111000 |
If you're accustomed to dealing with IP Precedence values 0, 1, 2, and 5 (for example), you just need to refer to them as DSCP values 0, 8, 16, and 40. It's easy: To convert IP Precedence to DSCP, just multiply by 8.
The terminology is simple, too. The eight IP Precedence values are called classes, and the DSCP bits that map to them (in Table 6-3) are called Class Selector Code Points (CSCP). Sometimes you see these class selectors abbreviated as CS (CS1, CS2, CS5, and so on). These are referred to simply as class selectors; the term Class Selector Code Point isn't all that widely used.
In addition to the eight class selectors that are defined, RFCs 2597 and 2598 define 13 additional DSCP values—12 Assured Forwarding (AF) values and an Expedited Forwarding (EF) value (see Table 6-4). The decimal values are shown for reference only; almost all discussions of DSCP use the names given in the Name column.
Table 6-4 Additional DSCP Values in RFCs 2597 and 2598
|
Name |
DSCP (Decimal) |
DSCP (Bits) |
|
Default |
0 |
000000 |
|
AF11 |
10 |
001010 |
|
AF12 |
12 |
001100 |
|
AF13 |
14 |
001110 |
|
AF21 |
18 |
010010 |
|
AF22 |
20 |
010100 |
|
AF23 |
22 |
010110 |
|
AF31 |
26 |
011010 |
|
AF32 |
28 |
011100 |
|
AF33 |
30 |
011110 |
|
AF41 |
34 |
100010 |
|
AF42 |
36 |
100100 |
|
AF43 |
38 |
100110 |
|
EF |
46 |
101110 |
There are 12 AF values, all in the format Afxy, where x is the class number and y is the drop precedence. There are four classes (AF1y through AF4y), each of which has three drop precedences (AFx1 through AFx3). AF is a method of providing low packet loss within a given traffic rate, but it makes minimal guarantees about latency.
EF is a defined behavior that asks for low-delay, low-jitter, low-loss service. EF is typically implemented using some form of LLQ. Only one EF class is defined, because it doesn't make sense to have more than one class whose goals are minimal delay and jitter. These two classes would compete with each other for the same resources.
DiffServ would be extremely simple if it weren't for all the confusing terminology, not all of which is covered here. If you want to learn more about the full set of DiffServ terminology and the DiffServ architecture, see the references in Appendix B.