Differentiated Services | Quality of Service on Wired Networks

So how do wireline networks get quality of service? They do so through the use of prioritization. Instead of asking for, and accounting for, resources and reservations and policing, the network becomes very simple. Traffic is divided up into classes. Some classes are better than others, and will get special treatment. Most likely, this treatment is just to cut to the head of the line. Each packet, not flow, is independently marked with the priority or class it belongs to. Every router and switch along the way that understands the tags will provide that differentiation, and the ones that do not simply ignore the tags and treat the packet as best effort.

This is the concept of differentiated services. For IP networks, the TOS/DSCP field in IPv4 and Traffic Class field in IPv6 is expected to hold the specific class or priority that the packet belongs to. The sender self-marks the packet, and the network takes it from there.

Here, the two conflicting concepts of the IPv4 Type of Service (TOS) come in contact with the Differentiated Services Code Point (DSCP) definition, for the same byte in the header. Each is a mechanism that was created to try to classify packets on a per-packet basis. TOS is the older mechanism, and is now considered to have fallen out of use. However, for the purposes of voice mobility, a lot is similar about TOS and DSCP. TOS defined, among other things, eight priority levels.

The format of the now formally deprecated TOS field is shown in Table 1.

Table 1: The TOS Field in IPv4 

	Precedence	Delay	Throughput	Reliability	Reserved
Bit:	0-2	3	4	5	6-7

The precedence value is a prioritization that is used within the network to determine its handling. The values run from 0 to 7, with 0 being the lower end of the range. The definitions originally conceived for this value is given in Table 2.

Table 2: The TOS Precedence 

Value	Old Meaning	802.1 p Meaning	WMM Meaning
7	Network Control	Network Management	Voice
6	Internetwork Control	Voice	Voice
5	CRITIC/ECP	Video	Video
4	Flash Override	Controlled Load	Video
3	Flash	Excellent Effort	Best Effort
2	Immediate	Undefined	Background
1	Priority	Background	Background
0	Routine	Best Effort	Best Effort

The table suggests a gradual rise in priority from 0 to 7. The problem with this definition is that different technologies use the 0-7 range for priorities. Most equipment endeavors tomaintain a consistent mapping for the number to a priority level, no matter how the priority got to the packet. The three different meanings are shown in the columns. The second column is from IEEE 802. 1p, which is a per-frame prioritization extension to Ethernet, and uses a special header to advertise the priority. The third column contains the meaning of the same eight values in WMM, the Wi-Fi prioritization standard. In general, it is best to assume the meaning of the final two columns. Note that the priority for values 1 and 2 are actually less than best effort in that case. When in doubt, do not use those priorities.

The remaining three flags in Table 3 represent extra information that may have been useful for the packet. Setting the delay bit meant to ask for low delays, whereas setting the throughput or reliability bit was meant to signal that throughput or reliability was a greater concern to the application.

TOS is considered to be replaced, and yet many modern devices in the world of IP telephones use the TOS meanings, and not the later DSCP meanings, in order to support older network configurations that may still be in use.

DSCP requires that the TOS meanings for the top three bits still be preserved, as long as the remaining bits are zero. However, DSCP looks at the one byte a different way. Table 3 shows the new meaning.

Table 3: The DSCP Field in IPv4 (Same Byte as TOS; Different Meaning 

	Code Selector	ECN
Bit:	0-5	6-7

There are a couple of RFCs that define what the code selector maps to. The goal of the DSCP is to interpret the selector as a somewhat arbitrary code, mapping into a specific quality of service type.

RFC 2597 defines the concept of Assured Forwarding (AF), the purpose of which is to allow a service provider to accept markings of packets and apply a certain amount of guaranteed bandwidth, as well as allowing more bandwidth to be given. Each class is named AFxx, where the first x is a number from one to four, representing the class of traffic, and the second x is a number from one to three, representing the drop probability from low to high (see Table 4).

Table 4: Assured Forwarding DSCP Values 

Drop Probability	Class 1	Class 2	Class 3	Class 4
Low	AF11 = 10	AF21 = 18	AF31 = 26	AF41 = 34
Medium	AF12 = 12	AF22 = 20	AF 32 = 28	AF42 = 36
High	AF13 = 14	AF23 = 22	AF33 = 30	AF43 = 38

The network administrator is expected to assign meanings to the four classes, in terms of assured, set-aside bandwidth that these codes can eat into. The drop probabilities are meant to be sent by the traffic originator to make sure that, if resources are getting exhausted, some packets get more protection than others.

A different concept is defined in RFC 2598. Expedited Forwarding (EF) sets up a specific codepoint, 46, to allow packets to be marked as belonging to a "virtual lease line," a high-performing point-to-point measure of quality of service. (There is a wrinkle with this DSCP code as it applies to Wi-Fi: All EF tagged packets get transmitted in the class of service designated for video because of the way the EF tag is coded.)

In total, there are 21 commonly seen DSCPs: the twelve AFs, the EF codepoint, and the eight original precedence values, now known default and CS1 to CS7.

Nothing in DSCP or differentiated services defines just what the qualities of the differentiated services are to be. This is the advantage of differentiated services: the differentiation is up to the administrator, and can grow as the network grows.

Differentiated Services (diffserv) | QoS

The effort of the Differentiated Services (diffserv) working group (www.ietf.org/html.charters/diffserv-charter.html) is directed toward the development of the mechanisms that support aggregate QoS services. In other words, diffserv is concerned with ordering (and treating accordingly to this order) traffic aggregates. The packets that end up in a particular aggregate are classified according to a certain behavior rather than according to a particular service. With the intserv model, the admission control considers only the available capacity in order to grant or deny the resource reservation request. Yet, a new set of admission criteria (such as the identity of users, security-related information, time of day, and day of the week) are becoming increasingly important in influencing admission policy.

These criteria, once specified at the network endpoints, are mapped into differentiated services (DS) codepoints to be carried in the IP packets and thus recognized by the network elements. Informational RFC 2475 explains the relevant architecture model and sets the terminology. To this end, RFC 2475 classifies existing models of service differentiation into five categories: (1) relative priority marking (including IP version 4 precedence marking), (2) service marking, (3) label switching, (4) integrated services/RSVP, and (5) static per-hop classification. The diffserv architecture can be considered as a refinement of the relative priority marking in that it “more clearly . . . [specifies] the role and importance of boundary nodes and traffic conditioners.” As for the integrated services/RSVP model, which lacks state aggregation, the differentiated services mechanisms are expected to help by aggregating the RSVP state in the core of the network.

Among the key concepts of diffserv is that of per-hop behavior (PHB), defined as “a description of the externally observable forwarding behavior of a . . . node applied to a particular . . . behavior aggregate.” (A behavior aggregate is a set of packets, marked with the same codepoint, that are moving in the same direction over a given link.) A simple example of a PHB is specification of a guaranteed minimal allocation of bandwidth to a link for a period of time. RFC 2475 further notes that PHBs may be specified in terms of their resources (for example, buffer or bandwidth), priority relative to other PHBs, or relative observable traffic characteristics (for example, delay or loss). PHBs shaped by a common constraint so that they can be specified (and subsequently implemented) together, form a PHB group. PHB groups are essential differentiated services building blocks, and their concept is central to defining other elements of the diffserv architecture.

A differentiated services domain (DS domain) is defined as a contiguous set of nodes “that operate with a common service provisioning policy and set of PHB groups implemented on each node.” Nodes within a DS domain use the DS codepoint of an IP packet to select a relevant PHB and to deal with the packet accordingly. Typically, a DS domain encompasses one or more networks under the same administration (that is, an enterprise network or an ISP). As illustrated in Figure 1, a DS domain consists of DS boundary nodes (interconnecting the DS domain with the outside world, which, in turn, consists of other DS domains as well as non-DS-capable nodes) and DS interior nodes. As Figure 1 points out, a host “may [but does not have to] act as a DS boundary node for traffic from applications running on that host . . .” Contiguous DS domains form a DS region. Note, however, that the domains within any given region are not required to have a common set of PHB groups or identical codepoint-to-PHB mappings.

Figure 1: Classification of the DS domain nodes.

In order to support the services that span across the domains, the peering domains establish a service level agreement (SLA). The diffserv architecture defines an SLA in terms of the things it may provide, including:

§  Packet classification policy (that is, the criteria for selecting the subset of traffic that is to receive a differentiated service) and remarking rules.

§  Specification of traffic profiles and actions to traffic streams that fit (or don’t fit) these profiles. (A profile may, for example, assign to a particular codepoint the request to measure the traffic marked by it with a token bucket and provide the respective parameters.) Actually, the binary fit/don’t-fit scheme may be insufficient; according to diffserv architecture, “multiple levels of conformance with a profile may be defined and enforced.”

The ultimate product of the SLA is the traffic conditioning agreement (TCA). Here, the word conditioning means ensuring that the classified traffic complies with the profile; as the result of conditioning, certain packets may be dropped or delayed (delaying packets is one means of shaping the traffic). In addition, the packets’ codepoints can be changed in the process of conditioning. The act of measuring the arriving traffic against the profiled temporal properties is called metering. RFC 2475 defines a TCA as “an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain’s service provisioning policy.”

The traffic enters a DS domain through a DS boundary node, which, in this case, is called (in complete analogy with the PSTN terminology) a DS ingress node; the traffic leaves the domain through a DS boundary node called a DS egress node. Figure 2 illustrates the role of these nodes in traffic conditioning and their relation to TCAs. Here, the downstream traffic is leaving DS domain X through a DS egress node bound by the X-to-Y TCA. The egress node must therefore ensure that the traffic to DS domain Y corresponds to this agreement; if it finds the input traffic in violation of the TCA, it conditions it appropriately. The peering DS ingress node of domain Y is responsible for checking (again, by possibly conditioning it) by the same agreement. Typically, “the SLA between the domains should specify which domain has responsibility for mapping traffic streams to DS behavior aggregates and conditioning those aggregates in conformance with the appropriate TCA,” but the DS ingress node is ultimately responsible for enforcing the TCA within its domain. The functions of the DS egress node of DS domain X and the DS ingress node of DS domain Y are similar with respect to the Y-to-Z TCA, but note that the (only depicted) ingress node of DS domain Z is also connected to the non-DS-capable network. In this case, the ingress node is responsible for traffic conditioning in accordance with the local policy (of the DS domain Z).

Figure 2: Traffic conditioning at the edges of DS domains.

Figure 3 depicts the elements of the diffserv architecture relevant to the packet classification and traffic conditioning process. The first functional element of the architecture is the packet classifier, whose role is to sort the incoming packets based on some packet-related criteria. RFC 2475 defines two types of classifiers. The behavior aggregate (BA) classifiers look only at the DS codepoint; the multifield (MF) classifiers consider other packet header fields as well as additional information (for example, incoming interface). The packet classifier passes selected packets to the marker (which sets the DS field of each packet to a particular codepoint and adds it to a particular behavior aggregate) as well as to the meter (which measures the temporal properties of the traffic according to a particular profile and triggers specific actions for the in- and out-of-profile packets in the rest of the conditioning elements). Finally, the traffic streams end up in the shaper/dropper, whose role is to delay the traffic when it is necessary to bring it in compliance with a traffic profile. The delayed traffic is held in a buffer; when the buffer is full, certain packets (including those already in the buffer) may be dropped.

Figure 3: Packet classifiers and traffic conditioners.

Source: RFC 2475.

RFC 2475 also addresses a number of important topics (like security and tunneling considerations and PHB specification and guidelines) that are essential for complete understanding of the scope of differentiated services. The present diffserv standards-track documents have been published in RFC 2597 and RFC 2598.

RFC 2474 defines the DS field of the IP header for IP version 4 (IPv4)—where it replaces (or rather reinterprets) the type of service (TOS) octet—and version 6 (IPv6)—where it reinterprets the class of service (CoS) octet. Six bits (bits 0 through 5) of the field contain the DS codepoint; the last two bits are reserved. The document also addresses the existing (“historical”) codepoint definitions and the resulting issue of backward compatibility. To ensure the backward compatibility, a set of codepoints (called the class selector codepoints) that meet minimum requirements of compatibility with the deployed forwarding treatments is reserved. The document also makes recommendations regarding PHB standardization guidelines and assignment of codepoints.

The last two RFCs, respectively, define the assured forwarding (AF) PHB group and the expedited forwarding (EF) PHB:

1.  RFC 2597 defines the AF PHB group. The group contains four general-use AF classes; within each class there are three levels of drop precedence. Packets belonging to a specific AF class are forwarded independently from packets of any other class. The standard deals with short-term congestion by prescribing packet queuing. The long-term congestion is dealt with by dropping packets with higher drop precedence. RFC 2597 recommends specific codepoints for the 12 class–drop precedence pairs.

2.  RFC 2598 defines the EF PHB as the mechanism for building low-loss, low-latency, and low-jitter end-to-end services through a DS domain. (Note that these qualities are especially important for real-time voice-over-IP delivery.) EF PHB is defined as “a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate’s packets from any diffserv node must equal or exceed a configurable rate.” In order to eliminate (or reduce to a small size) the queues the aggregate has to go through, RFC 2598 postulates that the DS nodes that support the PHB must be configured (by network administrators), “so that the aggregate has a well-defined minimum departure rate.” Furthermore, the aggregate is to be conditioned, “so that its arrival rate at any node is always less than that node’s configured minimum departure rate.” Conversely, to protect non-EF traffic, RFC 2598 postulates that the maximum EF rate and, when appropriate, burst size must also be settable by network administrators. The document recommends a specific codepoint for the EF PHB and provides example mechanisms for implementing the EF PHB. It also reports (in its appendix) on an implementation of the Virtual Leased Line (VLL) Service.