Differentiated services or DiffServ is a computer networking architecture that specifies a mechanism for classifying and managing network traffic and providing quality of service (QoS) on modern IP networks. DiffServ can, for example, be used to provide Network delay to critical network traffic such as voice or streaming media while providing best-effort service to non-critical services such as web traffic or .
DiffServ uses a 6-bit differentiated services code point ( DSCP) in the 6-bit differentiated services field ( DS field) in the IP header for packet classification purposes. The DS field, together with the ECN field, replaces the outdated IPv4 TOS field.
In the DS field, a range of eight values (class selectors) is used for backward compatibility with the former IPv4 IP precedence field. Today, DiffServ has largely supplanted TOS and other layer-3 QoS mechanisms, such as integrated services (IntServ), as the primary architecture routers use to provide QoS.
Rather than differentiating network traffic based on the requirements of an individual flow, DiffServ operates on the principle of traffic classification, placing each data packet into one of a limited number of traffic classes. Each router on the network is then configured to differentiate traffic based on its class. Each traffic class can be managed differently, ensuring preferential treatment for higher-priority traffic on the network. The premise of Diffserv is that complicated functions such as packet classification and policing can be carried out at the edge of the network by edge routers. Since no classification and policing is required in the core routers, functionality there can then be kept simple. Core routers simply apply PHB treatment to packets based on their markings. PHB treatment is achieved by core routers using a combination of scheduling policy and queue management policy.
A group of routers that implement common, administratively defined DiffServ policies are referred to as a DiffServ domain.
While DiffServ does recommend a standardized set of traffic classes, the DiffServ architecture does not incorporate predetermined judgments of what types of traffic should be given priority treatment. DiffServ simply provides a framework to allow classification and differentiated treatment. The standard traffic classes (discussed below) serve to simplify interoperability between different networks and different vendors' equipment.
The per-hop behavior is determined by the DS and ECN fields in the IP header. The DS field contains the 6-bit DSCP value. Explicit Congestion Notification (ECN) occupies the least-significant 2 bits of the IPv4 TOS field and IPv6 traffic class (TC) field. Filtering DSCP
In theory, a network could have up to 64 different traffic classes using the 64 available DSCP values. The DiffServ RFCs recommend, but do not require, certain encodings. This gives a network operator great flexibility in defining traffic classes. In practice, however, most networks use the following commonly defined per-hop behaviors:
The AF behavior group defines four separate AF classes with all traffic within one class having the same priority. Within each class, packets are given a drop precedence (high, medium or low, where higher precedence means more dropping). The combination of classes and drop precedence yields twelve separate DSCP encodings from AF11 through AF43 (see table).
+ Assured Forwarding behavior group
!Drop probability ! Class 1 !! Class 2 !! Class 3 !! Class 4 |
Some measure of priority and proportional fairness is defined between traffic in different classes. Should congestion occur between classes, the traffic in the higher class is given priority. Rather than using strict priority queuing, more balanced queue servicing algorithms such as fair queuing or weighted fair queuing are likely to be used. If congestion occurs within a class, the packets with the higher drop precedence are discarded first. Re-marking a packet is sometimes used to increase its drop precedence if a stream's bandwidth exceeds a certain threshold. For example, a stream whose rate is above the Committed Information Rate (CIR) as defined in causes the stream to be marked with a higher AF drop precedence. This allows the decision as to when to shape the stream to devices further downstream if they encounter congestion. To prevent issues associated with tail drop, more sophisticated drop selection algorithms such as random early detection are often used.
+ Class Selector mapping ! Service class ! DSCP Name ! DSCP Value ! IP precedence ! Examples of application | ||||
Standard | CS0 (DF) | 0 | 0 (000) | NTP |
Low-priority data | CS1 | 8 | 1 (001) | File transfer (FTP, SMB) |
Network operations, administration and management (OAM) | CS2 | 16 | 2 (010) | SNMP, SSH, Ping, Telnet, syslog |
Broadcast video | CS3 | 24 | 3 (011) | |
Real-time interactive | CS4 | 32 | 4 (100) | Gaming, low priority video conferencing |
Signaling | CS5 | 40 | 5 (101) | Peer-to-peer (SIP, H.323), client-server IP telephony signaling (H.248, MEGACO, MGCP, SCCP) |
Network control | CS6 | 48 | 6 (110) | Routing protocols (OSPF, BGP, IS-IS, RIP) |
Reserved for future use | CS7 | 56 | 7 (111) | |
DF= Default Forwarding
Prior to DiffServ, IPv4 networks could use the IP precedence field in the TOS byte of the IPv4 header to mark priority traffic. The TOS octet and IP precedence were not widely used. The IETF agreed to reuse the TOS octet as the DS field for DiffServ networks, later splitting it into the DS field and ECN field. In order to maintain backward compatibility with network devices that still use the Precedence field, DiffServ defines the Class Selector PHB.
The Class Selector code points are of the binary form 'xxx000'. The first three bits are the former IP precedence bits. Each IP precedence value can be mapped into a DiffServ class. IP precedence 0 maps to CS0, IP precedence 1 to CS1, and so on. If a packet is received from a non-DiffServ-aware router that used IP precedence markings, the DiffServ router can still understand the encoding as a Class Selector code point.
Specific recommendations for use of Class Selector code points are given in .
offers detailed and specific recommendations for the use and configuration of code points. Other RFCs such as have updated these recommendations.
+ IETF recommendations ! Service class ! DSCP Name !DSCP Value ! Conditioning at DS edge ! PHB ! Queuing ! AQM | ||||||
Low-latency data | AF21, AF22, AF23 | 18, 20, 22 | Using single-rate, three-color marker (such as ) | Rate | Yes per DSCP | |
High-throughput data | AF11, AF12, AF13 | 10, 12, 14 | Using two-rate, three-color marker (such as ) | Rate | Yes per DSCP | |
CS6 | Yes | |||||
EF | No | |||||
CS5 | No | |||||
Multimedia conferencing | AF41, AF42, AF43 | 34, 36, 38 | Using two-rate, three-color marker (such as ) | Rate | Yes per DSCP | |
Real-time interactive | CS4 | 32 | Police using sr+bs | Rate | No | |
Multimedia streaming | AF31, AF32, AF33 | 26, 28, 30 | Using two-rate, three-color marker (such as ) | Rate | Yes per DSCP | |
CS3 | No | |||||
CS2 | Yes | |||||
DF | Yes | |||||
Lower-effort | LE | 1 | Not applicable | Priority | Yes | |
sr+bs = single rate with burst size control (such as a token bucket).
The details of how individual routers deal with the DS field are configuration specific, therefore it is difficult to predict end-to-end behavior. This is complicated further if a packet crosses two or more DiffServ domains before reaching its destination. From a commercial viewpoint, this means that it is impossible to sell different classes of end-to-end connectivity to end users, as one provider's Gold packet may be another's Bronze. DiffServ or any other IP-based QoS marking does not ensure the quality of the service or a specified service-level agreement (SLA). By marking the packets, the sender indicates that it wants the packets to be treated as a specific service, but there is no guarantee this happens. It is up to all the service providers and their routers in the path to ensure that their policies will take care of the packets in an appropriate fashion.
|
|