diffserv.tex

\chapter{Differentiated Services}

The IETF has proposed two main solutions for the Internet QoS architecture: Integrated Services and Differentiated Services \cite{rfc2475}.
The first one implies per flow signaling and reservation, and therefore it does not scale well in large networks.
The focus of this chapter is on the second alternative.
In differentiated services, traffic is classified in a reduced number of classes, typically less than eight.
The routers implement different PHBs for the different classes, which provide the desired QoS.

Note that since in Diffserv there is not a per flow signaling and admission control, in principle it does not guarantee that the QoS requirements are actually satisfied.
In reality, this is achieved with a combination of traffic conditioning at the edge of the network and capacity planning.
This is not an exact science.

\section{Key aspects of DiffServ}
DiffServ is an scalable solution for QoS provisioning in IP networks.
DiffServ offers the tools for network administrators to implement QoS in an IP domain.
This can be used to offer VPNs that satisfy SLAs and to support services with tight QoS requirements such as VoIP.

The interconnection of different DiffServ domains is somewhat more complicated, as needs the collaboration of the different organizations that manage the different networks.
DiffServ is not commonly used for generic Internet access, as the Internet involves a humongous collection of networks which makes the provision of QoS guarantees an enormous challenge.

Three key aspects of DiffServ are border traffic conditioning, DiffServ markings, and PHBs.

\subsection{Traffic Conditioning}

Together with the SLA, a traffic conditioning agreement (TCA) is also established.
The TCA is often defined as a packet marking combined with token bucket, of a given rate and depth.
For example, it may specify that packets with VoIP traffic will conform to a token bucket of rate 1Mbps and depth 1Kb.

At the edge of the network, the routers will perform classifying, metering and policing to ensure that the offered load complies with the specified TCA.
The traffic exceeding the TCA may be either dropped or marked as non-conformant.

As the tasks of classifying, metering and policing require computational resources, they are done only at the edge.
At the edge of the network line speeds are lower than in the core of the network, and therefore it is possible for the router to process all the packets.
In the core of the network, the switching speeds are much higher and the time required to process each packet should be minimized, and therefore there is no time for classification, metering and policing.
As the edge of the network grows when the network grows, this solution is scalable and therefore appropriate for large networks with large volume of traffic.

According to the initial classification, the edge router will mark the packets using a field in the IP header which is the DiffServ Code Point (DSCP).

\subsection{DiffServ Code Point}

The DiffServ is a 6 bits field in the IP header that is assigned to each packet in the edge of the network.
The DSCP assigns a packet to one of the possible traffic classes supported by the network.
There are some standardized values for this field, such as Expedited Forwarding (EF), that we will review later.
But its value is of significance only within the DiffServ domain and therefore the network administrator have the decision of which DSCP values are used and what is the meaning of each of them.
This marking can be used later by the other routers of the network to quickly classify the packet, and treat the packet in accordance of the traffic class to which it belongs.
This treatment is the per-hop-behaviour (PHB).

\subsection{Per Hop Behaviour}

For each of the traffic classes (DSCP values) supported by the network there has to be an associated PHB.
This can be a many-to-one mapping, as different DSCP values can be offered the same PHB.
The PHB is a high level description of the service that a packet will receive when it arrives to a router.
It does not detail the QoS tools that will be used to implement that behaviour.

\section{IETF defined per-hop-behaviour}
The IETF has provided recommendations for four PHB.
A recommendation combines a description of the PHB with a suggested DSCP.

\subsection{Default PHB}

It is a required behaviour and it is assigned the DSCP 000000BIN.
RFC 4594 \cite{rfc4594} specifies that there is typically some bandwidth guarantee for this kind of traffic, but the packets can be lost, reordered, duplicated or delayed at random.

\subsection{Expedited Forwarding (EF)}
Expedited Forwarding (EF) is defined in \cite{rfc3246} and uses the code point 101110BIN (46DEC).
The purpose of this PHB is to serve real-time traffic such as VoIP or videoconferencing.
It should provide guaranteed bandwidth with low delay, jitter, and packet loss.

This can be attained by using strict priority queueing in combination with a buffer that is large enough to accommodate the traffic bursts.
The traffic is policed to control its rate and burstiness.
The rate needs to be controlled to ensure that this priority traffic does not starve other classes of traffic.
The bucket depth needs to be smaller than the allocated queue space, to guarantee that no packet loss will occur due to full queues.
The depth is also important as it determines the maximum delay that a packet may suffer, which is the token depth divided by the transmission rate.
The maximum delay obviously also influences the maximum jitter that the packets will suffer.

\subsection{Voice Admit (VA)}

Similar to EF, with the difference that Voice Admit (VA, \cite{rfc5865}) is subject to a call admission control procedure.

\subsection{Assured Forwarding (AF)}

Assured Forwarding is actually a group defined in RFC 2597 \cite{rfc2597} that comprises 12 DSCPs.
The packets belonging to this group will be forwarded if the offered rate is kept below the committed rate.
It differentiates four different classes: AF1x, AF2x, AF3x and AF4x.
AF1x is the lowest priority and AF4x is the higher priority.
A typical implementation is to assign each of the classes to a queue and use DWRR to distribute the bandwidth among the classes.

Within each of the classes, there are three possible drop precedences.
As an example, we have AF11, AF12 and AF13.
This means that, if congestion occurs, AF12 packets will be dropped with higher probability than AF11 packets.
And AF13 packet will be dropped with higher probability than AF11 and AF12 packets.

A typical scenario is to use a two-rate meter within a class.
If we take AF1x as an example, in-contract traffic is assigned to AF11, out-of-contract traffic is assigned to AF12, and traffic exceeding the PIR is simply dropped.

AF11 and AF12 will be mapped to the same queue.
This is an important aspect as otherwise packet re-ordering may occur.
Then, different RED profiles will be applied to AF11 and AF12.
AF12 will suffer a more aggressive RED profile to ensure that out-of-contract packets are the first to be dropped.

RFC 2597 \cite{rfc2597} recommends the following DSCP values for AF.

{\scriptsize 
\begin{verbatim}
                        Class 1    Class 2    Class 3    Class 4
                      +----------+----------+----------+----------+
     Low Drop Prec    |  001010  |  010010  |  011010  |  100010  |
     Medium Drop Prec |  001100  |  010100  |  011100  |  100100  |
     High Drop Prec   |  001110  |  010110  |  011110  |  100110  |
                      +----------+----------+----------+----------+
\end{verbatim}
}

\subsection{Class Selector (CS)}
This was included to provide some kind of backward compatibility with pre-DiffServ approaches.
The first three bits (0-2) are used to indicate precedence: higher value means higher precedence.
A practical use is to ease mapping from IP QoS markings to EXP QoS markings.
The recommended DSCPs take the form XXX000BIN.

\subsection{DSCP recommendations}

RFC 4594 \cite{rfc4594} offers recommendations about which DSCP to use for different kinds of traffic.
Normally, a network administrator will choose only a subset of those DSCP, according to the traffic that needs to be supported in a particular network.

{\scriptsize
\begin{verbatim}
    ------------------------------------------------------------------
   |   Service     |  DSCP   |    DSCP     |       Application        |
   |  Class Name   |  Name   |    Value    |        Examples          |
   |===============+=========+=============+==========================|
   |Network Control|  CS6    |   110000    | Network routing          |
   |---------------+---------+-------------+--------------------------|
   | Telephony     |   EF    |   101110    | IP Telephony bearer      |
   |---------------+---------+-------------+--------------------------|
   |  Signaling    |  CS5    |   101000    | IP Telephony signaling   |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF41,AF42|100010,100100|   H.323/V2 video         |
   | Conferencing  |  AF43   |   100110    |  conferencing (adaptive) |
   |---------------+---------+-------------+--------------------------|
   |  Real-Time    |  CS4    |   100000    | Video conferencing and   |
   |  Interactive  |         |             | Interactive gaming       |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF31,AF32|011010,011100| Streaming video and      |
   | Streaming     |  AF33   |   011110    |   audio on demand        |
   |---------------+---------+-------------+--------------------------|
   |Broadcast Video|  CS3    |   011000    |Broadcast TV & live events|
   |---------------+---------+-------------+--------------------------|
   | Low-Latency   |AF21,AF22|010010,010100|Client/server transactions|
   |   Data        |  AF23   |   010110    | Web-based ordering       |
   |---------------+---------+-------------+--------------------------|
   |     OAM       |  CS2    |   010000    |         OAM&P            |
   |---------------+---------+-------------+--------------------------|
   |High-Throughput|AF11,AF12|001010,001100|  Store and forward       |
   |    Data       |  AF13   |   001110    |     applications         |
   |---------------+---------+-------------+--------------------------|
   |    Standard   | DF (CS0)|   000000    | Undifferentiated         |
   |               |         |             | applications             |
   |---------------+---------+-------------+--------------------------|
   | Low-Priority  |  CS1    |   001000    | Any flow that has no BW  |
   |     Data      |         |             | assurance                |
    ------------------------------------------------------------------
\end{verbatim}
}

The same RFC offers recommendation about edge conditioning, PHB, scheduler configuration and AQM.

{\scriptsize
\begin{verbatim}
    ------------------------------------------------------------------
   |  Service      | DSCP | Conditioning at   |   PHB   | Queuing| AQM|
   |   Class       |      |    DS Edge        |  Used   |        |    |
   |===============+======+===================+=========+========+====|
   |Network Control| CS6  | See Section 3.1   | RFC2474 |  Rate  | Yes|
   |---------------+------+-------------------+---------+--------+----|
   |   Telephony   |  EF  |Police using sr+bs | RFC3246 |Priority| No |
   |---------------+------+-------------------+---------+--------+----|
   |   Signaling   | CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+------+-------------------+---------+--------+----|
   |   Multimedia  | AF41 |  Using two-rate,  |         |        | Yes|
   | Conferencing  | AF42 |three-color marker | RFC2597 |  Rate  | per|
   |               | AF43 | (such as RFC 2698)|         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |   Real-Time   | CS4  |Police using sr+bs | RFC2474 |  Rate  | No |
   |   Interactive |      |                   |         |        |    |
   |---------------+------+-------------------+---------|--------+----|
   |  Multimedia   | AF31 |  Using two-rate,  |         |        | Yes|
   |  Streaming    | AF32 |three-color marker | RFC2597 |  Rate  | per|
   |               | AF33 | (such as RFC 2698)|         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |Broadcast Video| CS3  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+------+-------------------+---------+--------+----|
   |    Low-       | AF21 | Using single-rate,|         |        | Yes|
   |    Latency    | AF22 |three-color marker | RFC2597 |  Rate  | per|
   |    Data       | AF23 | (such as RFC 2697)|         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |     OAM       | CS2  |Police using sr+bs | RFC2474 |  Rate  | Yes|
   |---------------+------+-------------------+---------+--------+----|
   |    High-      | AF11 |  Using two-rate,  |         |        | Yes|
   |  Throughput   | AF12 |three-color marker | RFC2597 |  Rate  | per|
   |    Data       | AF13 | (such as RFC 2698)|         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |   Standard    | DF   | Not applicable    | RFC2474 |  Rate  | Yes|
   |---------------+------+-------------------+---------+--------+----|
   | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
   |     Data      |      |                   |         |        |    |
    ------------------------------------------------------------------
\end{verbatim}
}

\subsection{Differentiated Services in MPLS}
An MPLS header contains: a label value (20 bits), an experimental EXP value used for QoS (3 bits), a bottom-of-stack flag (1 bit)  and a TTL field (8 bits).
There are only three EXP bits for QoS markings, compared to the six available in IP.
If the ``class selector'' PHB are used, which use only the first three bits of the six available in DSCP, it is very easy to map from DSCP to EXP and the other way around.
All is needed is to copy those three bits when an IP packet enters the MPLS domain.

If ``class selector'' is not used, but there are less than eight different classes, it is still possible to map from DSCP to EXP.
This would be the case if AF11, AF12, AF21, AF22, AF31, AF32, AF41 and AF42 are used.
The approach in which the information about the traffic class is contained in EXP bits is called EXP inferred PHB selection (E-LSP, where LSP stands for label switched path).

If the classification used has more than eight different DSCP values, a first option is to opt for a many-to-one mapping.
As an example if the eight classes mentioned above are used and in addition also EF is necessary, a possible option would be to treat AF1x packets just as AF2x packets.

An alternative to the many-to-one mapping is to use the label for QoS.
In our example, we could use five different labels.
One for each of the AF1x groups and the fifth one for EF.
When the LSP identifier carries QoS information it is called label inferred LSP (L-LSP).