Differentiated Services Code Points

The original IP protocol specification (RFC 791) included three bits for marking within the IP Type-of-Service (ToS) field, referred to as IP Precedence (IPP) bits. A general problem that all three-bit marking schemes have is that they simply do not have enough granularity to support the many classes of traffic traversing today’s networks: For instance, with two values (6 and 7) reserved for network/internetwork control protocols, 5 generally used for voice, 4 for (all forms of) video, 3 for call-signaling, and 0 for best-effort, only 2 marking values (2 and 1) are available for all other classes of traffic.

The coarseness and insufficiency of 3-bit marking granularity led to the definition of a newer set of IP marking standards: the Differentiated Services Architecture (RFC 2474 and 2475). DiffServ standards supersede and replace IP Precedence. The Differentiated Services (or DiffServ, for short) Architecture uses 6 bits for IP marking (whether IPv4 or IPv6), allowing for 64 levels of marking granularity (values 0 through 63); however, note that these 64 levels do not in themselves represent or reflect application priority; they serve only to distinguish flows one from another. Each discrete marking value is a Differentiated Services Code Point (DSCP). Figure 1 shows the IP ToS Byte (for an IPv4 packet), including the (former) IP Precedence bits and the current DSCP bits.

 
Figure 1: IPv4 type of service byte (IP precedence bits and DSCP)

The Class-Based Marking command to mark DSCP is to set dscp, which marks DSCP values for both IPv4 and IPv6 packets (whereas the command set ip dscp marks only IPv4 DSCP values). To set IPv4 and IPv6 DSCP values to 16 using DSCP marking, enter the following:

Router(config)# policy-map L3-DSCP-MARKER
Router(config-pmap)# class MARK-DSCP-16
Router(config-pmap-c)# set dscp 16

You might encounter scenarios when 6-bit Layer 3 (DSCP) markings are attempted to be reflected by 3-bit Layer 2 (CoS or MPLS EXP) markings. Remember, however, that when such L3-to-L2 marking conversions are done, information is almost inevitably lost in translation (as abstracting 6 bits to 3 bits represents an 8:1 mapping; in other words, up to 8 DSCP values can be represented by a single CoS/MPLS EXP value). Even if such scenarios might be required throughout the network, marking at Layer 3 with DSCP should be preserved end-to-end to maintain granularity.

Generally speaking, the best place to mark packets is within the IP header’s ToS byte, using DSCP values. This is for three main reasons:

• IP is end-to-end, whereas Layer 2 marking fields (CoS or MPLS EXP) might be lost when the media changes.
• As has been shown, DSCP has greater marking granularity and flexibility than 3-bit L2 marking schemes.
• When marking with DSCP, administrators can follow industry Per-Hop Behaviors (PHB), which are marking values, combined with standard-defined QoS treatments.

Per-Hop Behaviors (PHB) enable a network administrator to extend the reach of his QoS strategy, even across networks over which he does not have administrative control. As mentioned, with DSCP, there are 64 possible marking combinations (0 to 63). Some of these combinations have specific standardized QoS treatments assigned to them. The following section considers a well-known example to illustrate the PHB concept: Expedited Forwarding.

Expedited Forwarding PHB (RFC 3246)

The Expedited Forwarding PHB, defined in RFC 3246, is a strict-priority treatment for packets that have been marked to a DSCP value of 46 (101110), which is also termedExpedited Forwarding (EF). Any packet marked 46/EF that encounters congestion at a given network node is to be moved to the front of the line and serviced in a strict priority manner. It doesn’t matter how such behavior is implemented—whether in hardware or software—if the behavior is met for the given platform at the network node.

Incidentally, RFC 3246 does not specify which application is to receive such treatment; this is open to the network administrator to decide, although the industry norm over the last decade has been to use the EF PHB for VoIP.

The EF PHB provides an excellent case-point of the value of standardized PHBs. For example, if a network administrator decides to mark his VoIP traffic to EF and service it with strict priority over his networks, he can extend his policies to protect his voice traffic even over networks of which he does not have direct administrative control. He can do this by partnering with service providers and extranet partners who follow the same standard PHB (RFC 3246) and who will thus continue to service his (EF marked) voice traffic with strict priority over their networks.

Assured Forwarding PHB Group (RFC 2597)

RFC 2597 defines four Assured Forwarding groups, denoted by the letters “AF” followed by two digits.

The first digit denotes the AF class number and can range from 1 through 4. (Incidentally, these values correspond to the three most-significant bits of the codepoint, or the IPP value that the codepoint falls under.) Incidentally, the AF class number does not in itself represent priority. (That is, AF class 4 does not necessarily get any preferential treatment over AF class 1.)

The second digit refers to the level of drop preference within each AF class and can range from 1 (lowest drop preference) through 3 (highest drop preference). For example, during periods of congestion on an RFC 2597-compliant node, AF33 (representing the highest drop preference for AF class 3) would (statistically) be dropped more often than AF32, which in turn would (statistically) be dropped more often than AF31. Figure 2 shows the Assured Forwarding PHB encoding scheme.

 
Figure 2: DiffServ Assured Forwarding PHB encoding scheme

Figure 3 shows the full table of Assured Forwarding PHBs with their decimal and binary equivalents.

 
Figure 3: Assured Forwarding PHBs with decimal and binary equivalents

All AF traffic is initially marked to a drop preference value of 1. So for example, traffic for AF class 1 will initially be marked AF11; traffic for AF class 2 will be initially marked AF21, and so on. Only if AF traffic is policed by a DSCP-based policer (as will be discussed) can it be re-marked to a higher-drop preference, such as AF12 or AF13.

Assured Forwarding PHBs are most effective when applied to TCP-based traffic classes. This is because if such traffic exceeds the predefined rates, enforced by DSCP policers, exceeding and violating traffic might be re-marked to a higher drop preference value (either drop preference 2 or 3).

Consequentially, on congested nodes enabled with DSCP-based dropping algorithms, such re-marked traffic has a higher likelihood of being dropped. Dropped traffic, in turn, affects TCP windowing operations so that senders will adjust their transmission rates to optimize flows without dropping traffic, which is one of the objectives of the AF PHB.

Class Selector Code Points (RFC 2474)

Class Selectors, defined in RFC 2474, are not Per-Hop Behaviors, per se, but rather were defined to provide backward compatibility to IP Precedence. Each Class Selector corresponds to a given IP Precedence value, with its three least-significant bits set to 0. For example, IP Precedence 1 (001) is referred to as Class Selector 1 (001000 or DSCP 8); IP Precedence 2 (010) is referred to as Class Selector 2 (010000 or DSCP 16). Table 1 shows the IP Precedence to Class Selector mappings.

Table 1: IP Precedence to Class Selector/DSCP Mappings 

IP Precedence Value	IP Precedence Name	IPP Binary Equivalent	Class Selector	CS Binary Equivalent	DSCP Value (Decimal)
0	Normal	000	CS0[*]	000 000	0
1	Priority	001	CS1	001 000	8
2	Immediate	010	CS2	010 000	16
3	Flash	011	CS3	011 000	24
4	Flash-Override	100	CS4	100 000	32
5	Critical	101	CS5	101 000	40
6	Internetwork Control	110	CS6	110 000	48
7	Network Control	111	CS7	111 000	56
[*]Class Selector 0 is a special case, as it represents the default marking value (defined in RFC 2474-Section 4.1); it is not typically called Class Selector 0 but rather Default Forwarding or DF.

Lower Effort Per-Domain Behavior (Scavenger) (RFC 3662)

Although most of the PHBs discussed so far represent manners in which traffic can be treated preferentially, there are cases where you might want to treat traffic deferentially. For example, certain types of nonbusiness traffic, such as gaming, video-downloads, peer-to-peer media sharing, and so on might dominate network links if left unabated.

To address such needs, a Lower Effort Per-Domain Behavior is described in RFC 3662 to provide a less than Best Effort service to undesired traffic. Two things should be noted about RFC 3662 from the start:

• RFC 3662 is in the “informational” category of RFCs (not the standards track) and is not necessary to implement to be DiffServ standard-compliant.
• A Per-Domain Behavior (PDB) has a different and larger scope than a Per-Hop Behavior (PHB). A PDB does not require that undesired traffic be treated within a “less than Best Effort service” at necessarily every network node (which it would if this behavior were defined as a Per-Hop Behavior); but rather, as long as one (or more) nodes within the administrative domain provide a “less than best effort service” to this undesired traffic class, the Per-Domain Behavior requirement has been met.

The reason a PDB is sufficient to provision this behavior, as opposed to requiring a PHB, is that the level of service is deferential, not preferential. To expand: When dealing with priority or preferential QoS policies, sometimes it is said that a QoS chain of policies is only as strong as the weakest link. For example, if provisioning an EF PHB for voice throughout your network and only one node in the path does not have EF properly provisioned on it, the overall quality of voice is (potentially) ruined. On the other hand, if you’re objective is to provide a deferential level of service, all you need is one weak link in the path to lower the overall quality of service for a given class. Thus, if only a single weak link is required per administrative domain, a Per-Domain Behavior, rather than a Per-Hop Behavior, better suits the requirement.

The marking value suggested in RFC 3662 for less than best effort service is Class Selector 1 (DSCP 8). This marking value is typically assigned and constrained to a minimally provisioned queue so that it will be dropped most aggressively under network congestion scenarios.