Learn QoS Using the DiffServ Model
What’s the Idea Behind the DiffServ Model?
Differentiated Services, also known as DiffServ, eliminates the need for per-flow state and signaling at every hop. The DiffServ architecture pushes all the complexity to the edge of the network and hence eliminates the overhead associated with per flow traffic handling in the core of the network.
This is exactly the reason why DiffServ has been proposed: to overcome the scalability problem imposed by integrated services, requiring per-flow state and signaling. The aim of DiffServ is to divide traffic into several classes and treat each class in a specific different manner; each class uses different classification, policing, shaping and scheduling rules.
How Does the DiffServ Model Operate?
Differentiated Services are realized by mapping the code point contained in the TOS field in the IP packet header to a particular per-hop behavior (PHB), at each network node along its path. DiffServ defines the layout of the TOS byte (called the DS field), which intends to replace in a way the existing definition of the TOS byte.
Six out of eight bits of the DS field (2 bits are currently unused) are used as a codepoint (DSCP) to select the per-hop behavior (PHB) that a packet is to experience at each node. PHBs are typically queuing disciplines implemented on egress interfaces of network devices (routers). Although standard DSCPs are expected to invoke the corresponding standard PHBs, the mapping of DSCP to PHB is implemented in each network device and it is configured by the network provider. At least within a given provider’s network or domain the DSCP-to-PHB mapping should be configured consistently.
One important thing to note is that depending on the agreement between the provider and its customer, the DSCP may be marked by the customer before the packets are submitted to the network. If the customer does not mark the packets, the network provider may classify packets at the network ingress based on the particular agreement with the customer.
How is Traffic Conditioning and Classification Achieved?
The concepts of DSCPs, Traffic Conditioning and PHBs are illustrated below:
Figure 1: DSCPs, Traffic Conditioning and PHBs
Admission control, classification and conditioning of packets are implemented at the ingress edge node, otherwise known as edge of the provider’s network. These functionalities are provided by traffic conditioning (TC) components, which mark or discard packets. The main traffic-conditioning components are the following:
Classifiers, as their name implies, classify traffic. The purpose of the classifier is to separate arriving packets at the ingress node into different traffic classes according to the classification criteria. Two types of classifiers exist: behavior aggregate (BA) classifiers and multifield (MF) classifiers.
BA classifiers classify incoming traffic according to the DSCP in the packet headers. These classifiers are used in the case where arriving packets have already been marked with a DSCP, i.e. in the core of the network where a particular DSCP is mapped to a corresponding PHB at a device’s egress interface.
MF classifiers classify traffic according to some of the IP datagram fields (IP source address, IP destination address, source port and destination port). These classifiers are typically used in the ingress nodes of the DiffServ network. From there on, BA classifiers are used to handle the traffic.
Meters are traffic-conditioning components that measure the rate of the submitted traffic and compare it against a temporal profile, which describes the temporal characteristics of conforming traffic streams. Meters separate incoming traffic into several output streams according to the level of conformance with the metering profile. Simple meters separate incoming traffic into conforming and nonconforming traffic.
Markers are used to mark a specific DSCP in a packet header. In cases where incoming traffic arrives at the ingress router unmarked, then an MF classifier classifies the traffic and then a number of markers are used to mark the appropriate DSCP in the header fields of the corresponding traffic.
In the case that arriving traffic is already marked, then a marker is used only if submitted traffic is nonconforming and needs to be remarked to a lower service level.
Shapers delay some or all of the packets in a traffic stream in order to force these packets to conform to the traffic profile. Shaping is achieved by queuing the packets in a finite-sized buffer.
Droppers simply drop packets that are submitted to the provider’s network and are found to be nonconforming (by a meter).
• Realizing Per-Hop Behaviors
Per-Hop Behaviors (PHBs) define the traffic categories supported by the network. Three PHB groups have been standardized. These are: expedited forwarding (EF), assured forwarding (AF) and the default (Best-Effort) PHB with no QoS guarantees as in today’s Internet.
• Expedited Forwarding PHB
The EF PHB is designed to provide reliable low-delay, low-jitter, low-delay, low-loss and assured bandwidth service for customers that generate fixed peak bit-rate traffic (suitable for inelastic traffic). Because this service appears as a leased line, it is often referred to as the virtual leased line (VLL) service.
Expedited Forwarding PHB guarantees a minimum departure rate for the traffic that has been marked as EF. Forwarding delayed packets is meaningless in these situations, so in EF when congestion happens packets are dropped.
• Assured Forwarding PHB Group
Unlike the EF PHB, the AF PHB group is not intended to provide a service that has a bound on delay. It is used for applications that require better reliability than what the best-effort service can provide. Furthermore, AF specifies four different traffic classes each of which is allocated a certain amount of resources. Within each class, packets may be marked for one of three-drop probability levels. AF PHB group is intended to produce a reliable service, even during network congestion, through classification and policing on the core routers. The specification of the AF PHB group is quite flexible and can be used to build a variety of service offerings.
Nevertheless, AF PHB recommends that a mechanism such as random early detection (RED) should be used to drop packet when necessary. RED is a buffer management scheme. It drops packets randomly based on their DSCPs and the average queue length. The purpose of RED is to avoid queue overflow and tail-drop (when a queue overflows, all arriving packets are dropped) at each router. By dropping packets randomly, packets of different TCP connections are likely to be dropped at different time. Therefore, the TCP flow control mechanism for these connections will reduce their send rate at different time. This helps to prevent the router’s queues from overflowing, and thus avoid the tail-drop and increase performance.
A Simpler Approach to QoS
DiffServ implementation needs no advance setup. There is no need of reserving QoS resources per traffic flow. Traffic is classified into various classes; therefore QoS is applied per traffic class and not per traffic flow. Complexity is removed from the core of the network and is transferred to the edge. This means that core routers simply follow PHBs and don’t care about the complexity of traffic policing, shaping and marking of traffic.