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 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.
