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.

MPLS EXP | Marking Tools

MPLS is a tunneling technology that prepends labels to IP packets to enable more efficient packet switching and virtual private networking. More than one MPLS label can be prepended, or “stacked,” onto an IP packet.

Note

Typically, two labels are used in most MPLS VPN scenarios (one to identify each customer’s traffic and another to perform local switching with a service provider’s cloud); however, in some scenarios, such as MPLS Traffic Engineering, three or more labels are used.

MPLS labels contain 3 bits for CoS marking, which are referred to as the MPLS Experimental (EXP) bits. The possible values of the MPLS EXP bits for CoS are the same as those for 802.1Q/p CoS. Figure 1 shows the MPLS EXP bits within an MPLS label.

 
Figure 1: MPLS EXP bits within an MPLS label

Because MPLS labels include three bits for QoS marking, it is possible to tunnel DiffServ—that is, preserve Layer 3 DiffServ markings through a service provider’s MPLS VPN cloud while still performing re-marking (through MPLS EXP bits) within the cloud to indicate in- or out-of-contract traffic.

RFC 3270 defines three distinct modes of MPLS DiffServ tunneling:

• Uniform Mode: Generally used when the customer and service provider share the same DiffServ domain, as in the case of an enterprise deploying its own MPLS VPN core. The provider can re-mark at either Layer 2 (MPLS EXP) or at Layer 3 (IPP/DSCP). The key point is that in uniform mode, the Layer 3 marking value that a packet has when exiting the MPLS VPN might be different from the value it had when entering the VPN.
• Short-Pipe Mode: Both Pipe and Short-Pipe modes preserve DiffServ transparency; that is, under these modes, Layer 3 packet marking values never change as a packet enters, transits, and exits the MPLS VPN. The key difference between Short-Pipe and Pipe mode relates to the final egress queuing policies as the packet exits the VPN. In Short-Pipe mode, these queuing policies are based on the customer’s Layer 3 markings.
• Pipe Mode: Identical to Short-Pipe mode, but with the final egress queuing policies based on the service provider’s Layer 2 markings.

The enterprise network administrator needs to understand these basic differences between MPLS DiffServ Tunneling modes, especially as they relate to how traffic can be marked and re-marked over the MPLS VPN.

Ethernet 802.1Q/p CoS | Marking Tools

Native Ethernet does not support any fields that can be marked for QoS purposes. However, when trunked with the 802.1Q protocol, three bits of the 802.1Q tag are made available for setting User Priority, referred to as 802.1p. These bits are more commonly referred to as CoS bits. Three bits allow for eight binary combinations for marking, represented by values 0 to 7.

Figure 1 illustrates the Ethernet frame with an 802.1Q tag, which includes the following fields:

• PRI: The Priority field, which is a 3-bit field that refers to the IEEE 802.1p priority. It indicates the frame priority level from 0 (lowest) to 7 (highest), which prioritizes different classes of traffic (such as voice, video and data).
• CFI: The Canonical Format Indicator, which is a 1-bit field. CFI is used for compatibility between Ethernet and Token Ring networks. It is always set to zero for Ethernet switches (and 1 for Token Ring networks).
• VLAN ID: The VLAN Identifier, which is a 12-bit field specifying the VLAN to which the frame belongs.

 
Figure 1: Ethernet frame: 802.1Q/p CoS field

You can set CoS fields with Class-Based Marking by using the set cos command. To use Class-Based Marking to set the 802.1Q/p Class of Service field to 2, enter the following:

Router(config-cmap)# policy-map L2-MARKER
Router(config-pmap)# class MARK-COS-2
Router(config-pmap-c)# set cos 2