Differentiated services
Differentiated services (DiffServ) is a computer networking architecture that enables scalable quality of service (QoS) differentiation in IP networks by classifying and managing network traffic into aggregated classes, rather than treating each flow individually.[1] It achieves this through packet marking using a 6-bit Differentiated Services Codepoint (DSCP) in the IP header's DS field, which signals per-hop behaviors (PHBs) at routers to provide varying levels of service, such as prioritized forwarding or assured bandwidth, without requiring per-flow state or signaling across the network.[2] Developed by the Internet Engineering Task Force (IETF) in the late 1990s, DiffServ contrasts with more resource-intensive approaches like Integrated Services (IntServ) by focusing on simplicity and scalability for large-scale Internet environments.[1] At its core, DiffServ operates within defined domains—contiguous sets of network nodes that share common service policies and PHBs—where boundary nodes perform traffic classification and conditioning (e.g., metering, marking, shaping, or policing) to enforce service level agreements (SLAs), while interior nodes simply apply PHBs based on the DSCP value.[1] The DS field replaces the legacy IPv4 Type of Service (TOS) octet and IPv6 Traffic Class octet, consisting of the DSCP for service selection and two currently unused (CU) bits, supporting up to 64 codepoints with specific allocations for standards, experimental use, and backward compatibility via class selector codepoints.[2] Common PHBs include the default best-effort forwarding (DSCP 000000), expedited forwarding (EF) for low-latency traffic like voice, and assured forwarding (AF) classes with varying drop probabilities to protect against congestion.[1] This architecture facilitates diverse applications, from real-time media streaming to business-critical data transport, by allowing service providers to offer tiered QoS and pricing models while minimizing overhead in core networks.[1] Although not a full standard itself (published as an informational RFC in December 1998), DiffServ has been foundational for subsequent IETF work, including interactions with tunnels, real-time protocols like RTP, and policy-based management.[1] Implementations in modern routers and switches continue to evolve, emphasizing its role in enabling efficient, end-to-end QoS in IP-based infrastructures.[1]Background and Principles
Historical Development
The development of Differentiated Services (DiffServ) emerged in the late 1990s as a response to the scalability limitations of earlier Quality of Service (QoS) approaches in IP networks. Initial concepts for simple packet marking to enable differentiated router behavior were proposed by David Clark and Van Jacobson in the IRTF's End-to-End Research Group, building on the need for service differentiation beyond the best-effort model of the Internet.[3] A pivotal "birds of a feather" (BOF) session titled "Future Directions for Differential Services" at the IETF meeting in April 1997 highlighted demands from major network users for scalable QoS mechanisms, leading to the formation of the IETF DiffServ Working Group shortly thereafter, co-chaired by Brian Carpenter and Kathleen Nichols.[3] Key milestones in DiffServ's evolution included early proposals in 1997, such as a two-bit architecture framework submitted as an Internet-Draft in November of that year, which outlined basic service differentiation using aggregate traffic classes.[4] This laid the groundwork for the core architecture, formalized in RFC 2475 ("An Architecture for Differentiated Services") published in December 1998, which defined the framework for scalable service differentiation without per-flow state.[5] Accompanying RFC 2474 specified the use of the six-bit Differentiated Services (DS) field in the IP header to replace the older Type of Service octet, enabling packet marking for behavior aggregation. The primary motivations for DiffServ stemmed from the scalability challenges of the Integrated Services (IntServ) model, outlined in RFC 1633, which relied on resource reservation protocols like RSVP to maintain per-flow state across networks, rendering it impractical for large-scale Internet deployment. In contrast, DiffServ emphasized simplicity and scalability by treating traffic in aggregates and applying per-hop behaviors (PHBs) at routers, avoiding the state explosion of RSVP while providing relative service differentiation compatible with the existing best-effort infrastructure.[3] Early adoption of DiffServ faced challenges in integrating with the predominantly best-effort Internet, including the need for bilateral agreements between domains for consistent service levels and limited router support for PHB implementations in the initial years following standardization.[3] Deployment began incrementally in enterprise and service provider backbones around the early 2000s, often as an edge-to-edge enhancement rather than end-to-end, to mitigate disruptions to legacy traffic.[5]Core Concepts and Objectives
Differentiated Services (DiffServ) is a class-based quality of service (QoS) architecture designed to provide scalable differentiation of network traffic in IP-based systems. It achieves this by utilizing the Differentiated Services Code Point (DSCP), a 6-bit field in the IP header, to mark packets and indicate the desired per-hop forwarding treatment at network nodes.[1] This marking replaces the previous Type of Service (TOS) octet, enabling a more structured approach to service classification without requiring modifications to the core IP protocol.[2] The core objectives of DiffServ emphasize scalability in large networks, where maintaining state for millions of flows would be impractical. By aggregating traffic into classes rather than managing individual flows, DiffServ avoids complex signaling mechanisms, reducing overhead and enhancing simplicity in deployment.[1] It supports a range of service levels, such as low-latency paths for real-time applications or assured bandwidth for critical data, allowing network operators to allocate resources based on business priorities while accommodating the Internet's explosive growth.[1] Central to DiffServ is its aggregation model, in which packets with the same DSCP value form a Behavior Aggregate (BA) at the network boundary. These aggregates are then forwarded through the core using uniform Per-Hop Behaviors (PHBs), which define consistent treatment like queuing or dropping priorities across routers, without the need for flow-specific state in the interior network.[1] This edge-to-core separation ensures efficient processing, as boundary nodes handle classification and conditioning, while core nodes apply simple, stateless rules. In comparison to alternatives, DiffServ addresses the limitations of Integrated Services (IntServ), which depends on per-flow reservations and protocols like RSVP, leading to scalability issues in expansive networks due to extensive state maintenance.[1][6] Unlike the Best Effort model of traditional IP, which offers no prioritization and equal treatment for all packets regardless of needs, DiffServ introduces coarse-grained differentiation to better support diverse traffic demands without per-flow overhead.[1] The architecture emerged from IETF efforts in the late 1990s to meet the demands of an expanding Internet requiring simple, effective QoS enhancements.[1]DiffServ Architecture
Packet Classification and Marking
Packet classification in Differentiated Services (DiffServ) involves categorizing incoming packets into behavior aggregates based on predefined rules to enable differentiated treatment across the network.[1] Classifiers, typically deployed at the boundaries of a DiffServ domain, select packets using either multi-field (MF) classifiers, which examine multiple header fields such as source and destination IP addresses, protocol identifiers, and TCP/UDP port numbers, or behavior aggregate (BA) classifiers, which rely solely on the Differentiated Services codepoint (DSCP) value in the IP header.[7] This process allows for the identification of traffic from specific applications or users, ensuring scalability by aggregating flows into a limited number of classes rather than handling individual flows.[1] Marking follows classification and entails setting the 6-bit DSCP field within the 8-bit Differentiated Services (DS) field of the IPv4 Type of Service (TOS) octet or IPv6 Traffic Class octet, replacing the earlier 3-bit IP Precedence bits while maintaining partial backward compatibility through specific codepoint patterns.[8] The DSCP value serves as an index to select the per-hop behavior (PHB) that the packet will receive at each node, with the remaining 2 bits of the DS field reserved for potential future use or currently unused (CU) by DiffServ-compliant nodes.[9] Marking is primarily performed by traffic conditioners at network boundaries to enforce service level agreements (SLAs), using rules derived from policies that map classified traffic to appropriate DSCP values.[10] In the DiffServ architecture, boundary routers—such as ingress and egress nodes at domain edges—handle the bulk of classification and marking responsibilities to simplify operations within the core.[11] These edge devices classify unmarked or externally marked packets, apply meters to check compliance with traffic profiles (e.g., using token bucket parameters for rate and burst limits), and then mark or re-mark the DSCP accordingly before forwarding into the domain.[12] In contrast, interior (core) routers within the domain do not perform complex classification; they directly use the DSCP value to determine forwarding treatment without altering the marking, thereby promoting efficiency and scalability.[13] This division ensures that resource-intensive policy decisions are confined to the edges, while core nodes focus on high-speed forwarding based on the established marks.[14] Practical examples of classification and marking include mapping real-time voice over IP (VoIP) traffic to a high-priority DSCP value using MF classifiers that identify UDP ports typically associated with VoIP protocols, such as those in the range 16384–32767, followed by marking to ensure low-latency treatment.[7] Similarly, bulk data transfer applications like FTP might be classified based on TCP port 21 and marked with a lower-priority DSCP to deprioritize non-urgent traffic, enforcing user or application-specific policies at the ingress point.[1] These mappings are configurable via administrative policies and help achieve the DiffServ goal of providing scalable quality of service without per-flow state in the network core.[15]Per-Hop Behaviors (PHBs)
Per-hop behaviors (PHBs) in Differentiated Services (DiffServ) architecture define the packet forwarding treatment that a DiffServ-compliant node applies to a behavior aggregate, based on the Differentiated Services Code Point (DSCP) value in the IP header.[1] A PHB specifies the externally observable forwarding characteristics, such as the allocation of buffer space, bandwidth, and processing resources to packets sharing the same DSCP, resulting in differentiated performance metrics like throughput, delay, and loss probability.[1] PHBs classify packets into distinct forwarding behaviors and outline the mechanisms for their treatment, including queueing, scheduling, and dropping strategies. For queueing and scheduling, PHBs may employ priority-based methods, where higher-priority traffic is serviced first, or weighted scheduling algorithms, such as weighted fair queuing (WFQ), to allocate bandwidth proportionally among aggregates.[16] Dropping mechanisms within PHBs, such as Random Early Detection (RED), probabilistically discard packets before queues overflow to prevent congestion and provide controlled loss differentiation.[16] These elements enable routers to handle traffic aggregates without requiring per-flow state, focusing instead on aggregate-level resource management.[1] The operation of PHBs is inherently hop-by-hop, meaning each router along the path independently examines the DSCP of incoming packets and applies the corresponding PHB treatment, without any end-to-end signaling or reservation protocols.[1] This decentralized approach relies on prior packet classification and marking at network edges or boundaries, which assign DSCPs to direct the PHB selection at core nodes.[1] PHBs serve as the foundational building blocks for service differentiation in DiffServ networks, grouping into sets that map to specific DSCP values to achieve varying levels of assurance and priority. For instance, the DSCP value of 46 (binary 101110) is standardized for the Expedited Forwarding (EF) PHB, providing low-latency treatment for delay-sensitive traffic.[17] Through such mappings, PHBs enable scalable QoS by allowing networks to offer multiple service classes without complex state maintenance.[1]Traffic Conditioning
Traffic conditioning refers to the set of mechanisms used at the boundaries of a Differentiated Services (DiffServ) domain to enforce the terms of a service agreement by ensuring that incoming traffic conforms to specified profiles before entering the network interior. This process is essential for preventing congestion and maintaining the quality of service assurances across the domain. The primary goal is to shape or police traffic streams so that they align with the agreed-upon parameters, thereby protecting the core network from overload while allowing differentiated treatment based on packet markings.[18] Central to traffic conditioning is the Traffic Conditioning Agreement (TCA), which constitutes a contract between a customer and the service provider outlining the expected traffic characteristics and the actions to be taken if they are violated. A TCA typically specifies classifier rules to identify traffic streams, traffic profiles defining allowable rates and bursts, and associated actions such as metering, marking, discarding, or shaping. These agreements are often derived from broader Service Level Agreements (SLAs) and are enforced by boundary nodes to ensure compliance without impacting the interior of the DiffServ domain. For instance, a TCA might stipulate that voice traffic must not exceed a certain burst size to guarantee low latency.[18] The core components of traffic conditioning include metering, marking, shaping, and policing, each serving a distinct role in managing traffic conformance. Metering measures the rate and volume of incoming packets against a predefined traffic profile, determining whether they are conforming or non-conforming; common metering algorithms use token bucket regulators, where tokens accumulate at a specified rate to allow packet transmission up to a burst limit. Marking involves setting or re-marking the Differentiated Services (DS) codepoint in the IP header based on the meter's output, assigning packets to appropriate Per-Hop Behaviors (PHBs) for differentiated forwarding. Shaping delays excess packets to smooth traffic and bring it into compliance with the profile, typically using a finite buffer to hold packets temporarily, while policing discards non-conforming packets outright to enforce strict limits, acting as a zero-buffer form of shaping. These components are often combined in a traffic conditioner at ingress or egress points.[18] A widely used metering tool in DiffServ is the token bucket algorithm, which models traffic with parameters such as the Committed Information Rate (CIR) and Peak Information Rate (PIR). In the Two Rate Three Color Marker (trTCM) scheme, two token buckets are employed: one for the CIR (with a Committed Burst Size, CBS) that marks packets green if they conform to this lower rate, and another for the PIR (with a Peak Burst Size, PBS) that allows yellow marking for packets exceeding CIR but within PIR, while red marking is applied to those exceeding PIR. This enables three levels of treatment—green for highest assurance, yellow for moderate, and red for discard-eligible—facilitating fine-grained control over traffic admission. The trTCM operates in color-blind or color-aware modes, making it suitable for boundary enforcement.[19] Traffic conditioners are predominantly deployed at the edges of the DiffServ domain, such as ingress nodes where customer traffic enters and egress nodes where it leaves, to isolate internal resources from external variability and avoid widespread congestion. This boundary placement ensures that only conditioned traffic propagates inward, where it can then receive the PHBs as per its marking. By concentrating conditioning here, the architecture scales efficiently for large networks without requiring per-flow state in the core.[18]PHB Categories
Expedited Forwarding (EF)
Expedited Forwarding (EF) is a per-hop behavior (PHB) in the Differentiated Services (DiffServ) architecture, defined to provide low delay, low loss, and low jitter for selected traffic aggregates by ensuring that the aggregate is forwarded at a configured rate exceeding its arrival rate.[20] This PHB serves as a foundational building block for premium services, where the EF-marked packets are treated with higher priority to minimize queuing delays and variations.[20] The EF PHB is typically associated with the Differentiated Services Code Point (DSCP) value of 46, represented in binary as 101110, which signals routers to apply the expedited treatment.[20] Implementation involves a dedicated, single queue per output interface, serviced in strict priority over other PHBs, with minimal buffering to reduce latency and jitter.[20] To prevent resource starvation for lower-priority traffic, EF aggregates must be policed at the network edge or ingress, limiting their rate to a provisioned value that avoids overwhelming the link.[20] In well-provisioned networks, the EF PHB provides low end-to-end delay, making it suitable for latency-sensitive applications such as Voice over IP (VoIP) and interactive video conferencing.[20] Unlike assured forwarding PHBs, which emphasize throughput guarantees across multiple classes, EF prioritizes delay bounds for a single, high-priority class.[20] Bandwidth allocation for EF traffic is constrained to ensure non-blocking service, typically following the guideline that the EF rate r_{EF} \leq C - o, where C is the link capacity and o represents overhead for non-EF traffic and protocol headers.[20] This policing and scheduling combination enables EF to deliver assured bandwidth while maintaining the desired performance characteristics across DiffServ domains.[20]Assured Forwarding (AF)
The Assured Forwarding (AF) Per-Hop Behavior (PHB) group defines a mechanism within Differentiated Services (DiffServ) to offer varying levels of forwarding assurance for IP packets across multiple classes, ensuring that packets receive treatment based on their assigned class and drop precedence without reordering within the same class or microflow.[21] This PHB group supports four independently forwarded classes (AF1 through AF4), each allocated specific forwarding resources such as buffer space and bandwidth, with the level of assurance depending on the resources provided, the traffic load in the class, and the drop precedence.[21] Within each class, packets are marked with one of three drop precedences—low (1), medium (2), or high (3)—allowing for differentiated discarding during congestion, where higher-precedence packets are protected from drops at the expense of lower-precedence ones.[21] The AF PHB group utilizes 12 Differentiated Services Code Point (DSCP) values to encode the classes and drop precedences, as specified in RFC 2597. These values are binary-encoded in the six-bit DSCP field of the IP header, with the notation AFxy where x denotes the class (1-4) and y the drop precedence (1-3). The following table lists the DSCP values:| Class | Low Drop (1) | Medium Drop (2) | High Drop (3) |
|---|---|---|---|
| AF1 | 001010 (10) | 001100 (12) | 001110 (14) |
| AF2 | 010010 (18) | 010100 (20) | 010110 (22) |
| AF3 | 011010 (26) | 011100 (28) | 011110 (30) |
| AF4 | 100010 (34) | 100100 (36) | 100110 (38) |