2002 - 2003

Etude du service
DiffServ

Sylvain FRANCOIS
Anne-Lise RENARD
Jérémy ROVARIS
 SOMMAIRE

INTRODUCTION................................................................................................................3
1 QUALITE DE SERVICE..................................................................................................4
2 DIFFERENCIATION DE SERVICES : ..........................................................................6
2.1 PRESENTATION ..............................................................................................................6
2.2 LES CLASSES DE SERVICES .............................................................................................7
2.2.1 Le Best Effort.........................................................................................................7
2.2.2 Expedited Forwarding ...........................................................................................7
2.2.3 Assured Forwarding ..............................................................................................8
3 ARCHITECTURE DIFFSERV ...................................................................................... 12
3.1 PRESENTATION ............................................................................................................ 12
3.2 CLASSIFICATION ET CONDITIONNEMENT DU TRAFIC ...................................................... 13
4 INTEGRATION AVEC D’AUTRES SERVICES ......................................................... 15
4.1 INTEGRATION INTSERV/DIFFSERV ............................................................................... 15
4.2 INTEGRATION MPLS/DIFFSERV ................................................................................... 15
5 MISE EN ŒUVRE DE DIFFSERV ............................................................................... 16
5.1 PRINCIPE ..................................................................................................................... 16
5.2 EXEMPLES DE SCENARII POSSIBLES :............................................................................. 17
Scénario 1 .................................................................................................................... 17
Scénario 2 .................................................................................................................... 17
Scenario 3 .................................................................................................................... 17
Scénario 4 .................................................................................................................... 17
Scénario 5 .................................................................................................................... 17
Scénario 6 : trafic audio et FTP ................................................................................... 18

2
 Introduction

À ses débuts, Internet avait pour seul objectif de transmettre les paquets à leur
destination. Conçu pour le transport asynchrone des données, IP (Internet Protocol) n'a
pas été prévu pour les applications en temps réel comme la téléphonie ou la vidéo, très
contraignantes. Le besoin en équipements de plus en plus fiables, d'un bout à l'autre du
réseau, est donc devenu incontournable.
Cependant, les défauts rencontrés sur les réseaux (perte de paquets, congestion)
ne peuvent pas être surmontés sans une rénovation profonde de l'architecture.

La qualité de service est la méthode permettant de garantir à un trafic de données,

quelle que soit sa nature, les meilleures conditions d'acheminement répondant à des
exigences prédéfinies. Elles fixent notamment des règles de priorité entre les différents
flux.
La maîtrise de la qualité de service est un enjeu essentiel. La qualité de service
doit être visualisée et mesurée de bout en bout. Le contexte joue un rôle crucial dans
l’appréciation des paramètres de la qualité de service qu’il faut adapter au besoin de
l’entreprise.

3
1 Qualité de service
L’Internet, comme la majorité des réseaux en mode paquets, n’a pas été
initialement prévu pour prendre en compte les paramètres de qualité de service. Les
réseaux en mode paquets ont été développés à une époque où la bande passante était rare,
la stratégie étant d’occuper le maximum de liens quitte à introduire des délais
supplémentaires dans la transmission des données.
Les opérateurs et équipementiers se sont donc attelés à une double tâche : mettre
en place de nouveaux mécanismes pour s'assurer de la disponibilité des applications -
c'est-à-dire contrôler le nombre de paquets perdus - tout en ne reniant pas les principes
fondamentaux d'Internet, à savoir sa simplicité, sa fiabilité et son universalité. Voilà donc
tout l'enjeu de la qualité de service, ou QoS.
Il y a quatre paramètres techniques à prendre en compte dans la qualité de service
qui sont :
- la disponibilité du réseau
- le temps de réponse
- le débit garanti par flux
- la stabilité des paramètres précédents

Les paramètres de services ou de prestations sont quant à eux nombreux, on peut

citer les plus importants :
- la disponibilité de service (SVP, guichet unique)
- le point central de prise en compte des problèmes (guichet unique)
- le temps de traitement d’un incident ou d’une demande
- le support technique du prestataire
- …

Afin de garantir cette qualité de service, trois protocoles se sont imposés :

- Intserv (Integrated Service, protocole inclus dans RSVP, Ressource Reservation
Protocol)
- Diffserv (Differentiated Services)
- MPLS (MultiProtocol Label Switching)

Leur standardisation est effectuée par l'IETF (Internet Engineering Task Force).
Intserv repose sur un mécanisme de réservation des ressources. Dans la pratique, il dédie
une partie de la bande passante pour assurer l'acheminement des messages prioritaires.
Très complexe à mettre en oeuvre, Intserv convient plutôt aux réseaux de petite
taille, mais n'est pas vraiment adapté à Internet dans son ensemble. De ce fait, il a été peu
déployé.
Pour pallier à ces carences, l'IETF a adopté un second modèle, Diffserv, qui
assure une distinction des paquets par classes de flux. Les données sont identifiées grâce
à un marquage dans le champ ToS (Type of Service, champ spécifique réservé dans l'en-
tête IP de 8 bits), qui fixe les priorités. Chaque nœud du réseau apporte un traitement
différencié en fonction de la classe de service du paquet.
Mais l'arrivée de MPLS a changé la donne. Cette nouvelle architecture permet de
véhiculer davantage de trafic IP à des vitesses de transmission très élevées. Dans ce cas,
les paquets transférés sont directement étiquetés (label de 32 bits) à l'entrée du réseau,
spécifiant leur chemin, ce qui évite au routeur de chercher l'adresse à laquelle le paquet
doit être envoyé. MPLS s'appuie sur les classes de service Diffserv et fonctionne avec

4
tout protocole existant - IP, bien sûr, mais aussi ATM et Frame Relay -, ce qui en fait un
protocole de choix, car les réseaux transportent de plus en plus de paquets issus de
diverses plates-formes.

Une bonne qualité de service sur les réseaux actuels suppose une implantation
correcte de deux fonctions : performance garantie et politiques de routage.
Les politiques de routage sont utilisées pour affecter des ressources en priorité
aux applications, aux groupes de travail ou aux serveurs. Avec l'augmentation constante
du volume de trafic sur les réseaux, les garanties de performance sont obtenues en
contrôlant la bande passante en fonction des politiques de routage.
L’évolution d’Internet pour prendre en compte les nouveaux flux se fait en
modifiant les mécanismes de files d’attente dans les routeurs.
Une solution : introduction d’un contrôle d’accès pour limiter le trafic dans le
réseau. Si la capacité de celui-ci en terme de bande passante est inférieure à la demande
de transmission, le taux de perte augmente rapidement dans un réseau. Une solution pour
limiter ce taux de perte est de limiter la demande de transmission en mettant en place un
contrôle d’admission en entrée du réseau. Cette solution est utilisée dans le réseau
téléphonique et ATM. Il est difficile à mettre en œuvre dans l’Internet car l’échange
d’information entre systèmes ne porte que sur des informations de routage.
Une deuxième solution : séparer les flux ayant des contraintes du trafic Best-
Effort et de protéger ces flux dans les routeurs pour obtenir des garanties de débit, de
délai et de taux de perte. Cette approche nécessite de réserver des ressources dans le
réseau pour ces flux.
Une troisième solution : ne donner aux flux plus sensibles qu’une priorité plus
importante, ce qui ne permet pas de garanties strictes des performances.
Une quatrième solution : sur-dimensionnement du réseau pour éviter la pénurie de
bande passante, mais cela pose des problèmes de communication malgré l’utilisation de
la fibre optique.

5
2 Différenciation de services
2.1 Présentation

La différenciation de services consiste dans une situation de congestion à reporter

les pertes de paquets sur certaines classes de trafic, pour en protéger d’autres. Il n’y a
donc pas de garantie sur les flux car il n’y a pas de contrôle d’admission dynamique
permettant d’éviter une congestion. Le contrôle d’admission est fait a priori par la
définition d’un contrat pour chaque classe de trafic et par le dimensionnement des
ressources pour pouvoir garantir ce contrat.
Les paquets DiffServ sont marqués à l'entrée du réseau et les routeurs décident en
fonction de cette étiquette de la file d'attente dans laquelle les paquets vont être placés.
Cette architecture convient à des réseaux pour lesquels il n'est pas raisonnable
d'envisager une signalisation flux par flux. Elle ne considère donc que des agrégats de
flux pour lesquels une signalisation avec réservation de ressources peut-être envisagée.
En fait un routeur de cœur ne conserve pas d'état pour un flux ou un agrégat donné, mais
traite tous les paquets d'une classe donnée de la même manière. Les données sont
identifiées grâce à un marquage dans le champ ToS (Type of Service, champ spécifique
réservé dans l'en-tête IP de 8 bits), qui fixe les priorités.
Cette zone se décompose en un premier champ de trois bits baptisé " IP
Precedence ", qui précise le niveau de priorité appliqué au paquet. Vient ensuite un
champ de 4 bits, dont la valeur détermine un critère de routage. Le dernier bit du champ
reste inutilisé. Cette classification s'opère à l'entrée du réseau étendu, déchargeant ainsi
les routeurs de la tâche. La différenciation de services présente les avantages suivants :

• La signalisation est faite dans chaque paquet en attribuant une signification

différente aux bits du champ type de service. Il n’est plus besoin de garder dans le
routeur un contexte liant le flux de signalisation au flux de données. Cela permet
aussi une agrégation naturelle des flux, ainsi pour un opérateur, les paquets qu’il
reçoit marqués pour une certaine classe peuvent appartenir à plusieurs sources.
• La complexité du traitement est concentrée dans les routeurs aux frontières du
réseau. Ils effectuent les opérations « complexes » de contrôle de la validité du
contrat pour les différentes classes de trafic. Dans le cœur du réseau, le traitement
est plus simple, ce qui autorise un relayage rapide des données.
• La tarification du service est plus simple, il suffit de définir les paramètres de
contrôles de classes de service.

Au contraire du modèle Intserv qui traite indépendamment chaque flot, le modèle

Diffserv sépare le trafic par classes. Nous avons donc affaire à une granularité moins fine
mais qui devient en revanche plus « scalable ». En effet, la granularité du flot implique la
réaction en chaîne suivante : plus il y a d'utilisateurs dans le réseau, plus il y a de flots,
plus il y a de variables de classification et d'ordonnancement dans les routeurs à
maintenir, ce qui a pour conséquence une charge importante au niveau des routeurs qui
deviennent alors de moins en moins performants.

Les routeurs DiffServ traitent les paquets en fonction de la classe codée dans l'en-
tête IP (champ DS) selon un comportement spécifique : le PHB (Per Hop Behaviour).
Chaque ensemble de paquets défini par une classe reçoit alors un même traitement et

6
chaque classe est codée par un DSCP (DiffServ Code Point). Un PHB est défini par les
priorités qu’il a sur les ressources par rapport à d’autres PHB.
En aucun cas, les routeurs ne traiteront différemment des paquets de même PHB
et de sources différentes. L'avantage de Diffserv est qu'il n'y a plus nécessité de maintenir
un état des sources et des destinations dans les routeurs, d'où une meilleure scalability.

Diffserv définit quatre PHB ou classes de service :

- Best Effort (priorité basse) : PHB par défaut et dont le DSCP vaut 000000 ;
- Assured Forwarding (AF) (RFC 2597) : regroupant plusieurs PHB garantissant un
acheminement de paquets IP avec une haute probabilité sans tenir compte des
délais, cette famille de PHB est scindée en 4 classes garantissant de fournir une
bande passante et un délai minimum, chaque classe comprenant 3 niveaux de
priorité (Drop Precedence) ;
- Expedited Forwarding (EF) ou Premium Service (RFC 2598) : correspondant à la
priorité maximale et a pour but de garantir une bande passante avec des taux de
perte, de délai et de gigue faible en réalisant le transfert de flux à fortes
contraintes temporelles comme la téléphonie sur IP par exemple ;
- Default Forwarding (DF), utilisé uniquement pour les flux Internet qui ne
nécessitent pas un trafic en temps réel.

Cette notion de PHB permet de construire une variété de services différenciés.

Les PHB sont mis en oeuvre par les constructeurs dans les routeurs en utilisant des
mécanismes de gestion de files d'attente (Custom Queuing, Weighted Fair Queuing, ...) et
de régulation de flux.

2.2 Les Classes de service

2.2.1 Best Effort

Le principe du Best Effort se traduit par une simplification à l’extrême des

équipements d’interconnexion. Quand la mémoire d’un routeur est saturée, les paquets
sont rejetés. Le principe de bout en bout de l’Internet est aussi adopté pour le contrôle de
flux grâce à différents algorithmes comme le Congestion Avoidance introduit dans TCP.
Les principaux inconvénients de cette politique de contrôle de flux sont un trafic
en dents de scie composé de phases où le débit augmente puis est réduit brutalement et
une absence de garantie à long terme.

2.2.2 Expedited Forwarding

La classe Expedited Forwarding correspond à la valeur 101110 pour le DSCP et

l'objectif est de fournir un service de transfert équivalent à une ligne virtuelle dédiée à
travers le réseau d’un opérateur.
Le contrat porte sur un débit constant. Les paquets excédentaires sont lissés ou
rejetés à l’entrée pour toujours rester conforme au contrat. L’opérateur s’engage à traiter
ce trafic prioritairement. Pour que le service soit performant, il faut qu’il ne présente
qu’une faible partie du trafic total pour qu’aucun paquet marqué EF ne soit rejeté dans le
cœur du réseau.

7
 Pour atteindre ces performances, les paquets d’un service EF ne devraient pas
subir de file d’attente ou passer par des files de très petite taille et strictement prioritaires.
De plus, les flux ne doivent avoir que très peu de perte, la gigue doit être minimale et la
bande passante garantie.
D’une part, cela nécessite la mise en place d’un contrôle d’accès et, d’autre part,
cela impose qu’à chaque nœud traversé, le taux maximal de trafic d’arrivée doit être
inférieur au taux minimal de trafic de départ. Cette dernière assertion implique que, dans
les nœuds internes, une bande passante minimale est disponible au service EF et que,
dans les nœuds d’extrémité, un traffic conditioning est effectué.
Ce mécanisme de conditionnement est utilisé pour vérifier la conformité des flux
utilisateurs. La conformité du trafic EF et AF par rapport à leurs profils est déterminée
pour chacun par un token bucket (cf. page 11). Dans ce cas, la taille et le débit du bucket
sont à spécifier. Les paquets EF non conformes sont détruits tandis que les paquets AF
non conformes sont marqués pour être jetés en cas de congestion.

Ainsi, il faut choisir parmi toutes les possibilités que DiffServ offre, c’est-à-dire
celles qui répondent le mieux aux besoins du service. On s'intéresse d'abord au choix du
PHB, le paramètre qui définit le comportement des routeurs de cœur du réseau. Par
exemple pour les streams multimédia, étant données leurs caractéristiques, le
comportement de EF n'est pas adapté. EF est un comportement coûteux, en particulier à
cause des garanties de délai qu'il peut offrir.
Pour le streaming, les variations de délai sont normalement absorbées par un
buffer chez le récepteur, les assurances de délai ne sont donc plus indispensables. Plus
important encore, dans EF la notion de priorité dans les paquets n'existe pas alors que
c'est un élément clé du service que l'on cherche à proposer. AF quant à lui, répond au
besoin d'attribuer des priorités aux paquets en offrant trois niveaux de priorité. De plus,
l'existence de 4 classes différentes permet de résoudre facilement le problème de partage
de ressources entre les flux UDP et TCP. En réservant une classe AF au trafic UDP et
une autre au trafic TCP, les deux types de flux seront isolés par l'algorithme
d'ordonnancement dans les routeurs (WFQ, CBQ, etc.) ce qui permet d'éviter la
concurrence directe entre eux. Nous proposons donc, l'utilisation de la classe AF réservée
pour les flux Audio/Vidéo.

2.2.3 Assured Forwarding

La classe Assured Forwarding définit 3 priorités définissant l’ordre de rejet dans

un routeur en cas de congestion. Les priorités sont représentées par 3 couleurs qui
dépendent de la conformité de la source avec son contrat. Le marqueur utilisé
actuellement est basé sur deux token buckets : si le trafic est conforme au deux, les
paquets sont marqués en vert, s’il n’est conforme qu’à un des deux les paquets seront
marqués en orange et s’ils ne sont conformes à aucun, ils seront marqués en rouge. Les
paquets marqués en rouge, ont une probabilité de rejet plus importante que les oranges.
Dans le cœur du réseau, les mécanismes de rejet sont basés sur RIO (cf. page 11).
Chaque couleur dispose d’un seuil et d’une probabilité de rejet différent. Quatre classes
AF sont disponibles. Il n’y a pas de priorité parmi ces classes.

8
 Figure 1 : arrivée des paquets dans un edge router puis dans un core router

Les travaux du groupe Diffserv sont surtout basés sur une approche d’ingénierie
portant sur la définition de l’architecture et sur la gestion de l’octet DS.
Les résultats de simulation montrent que RIO est très sensible aux conditions initiales du
trafic, en particulier, la proportion de trafic UDP influe énormément sur les résultats.

Les objectifs de la différenciation par l’Assured Forwarding sont l’attribution

différentiée des ressources et la protection des flux TCP des flux UDP.

Pour l’Assured Forwarding, il est défini quatre classes de service et trois priorités
(appelées niveaux de post précédence) suivant que l'utilisateur respecte son contrat, le
dépasse légèrement ou est largement en dehors. Les classes sont donc choisies par
l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. Tous les paquets
d’un même flux appartiennent à la même classe.
A l’intérieur de chaque classe, un algorithme de rejet sélectif différencie entre 3 niveaux
de priorité. En cas de congestion dans une des classes AF, les paquets de basse priorité
sont rejetés en premier. La priorité peut être modifiée dans le réseau par les opérateurs en
fonction du respect ou non des contrats.

AF offre différents niveaux de services :

• AF1 (AF11, AF12, AF13)
• AF2 (AF21, AF22, AF23)
• AF3 (AF31, AF32, AF33)
• AF4 (AF41, AF42, AF43)

9
 Avantages de l’Assured Forwarding :
• peut offrir une meilleure différenciation (classe et priorité)
• le marquage à l’entrée du réseau est une opération moins coûteuse que le shaping
• ne demande pas une coordination entre domaines
• une facturation simple peut être utilisée.

Inconvénients de l’Assured Forwarding :

• la qualité offerte dépend énormément du niveau d’agrégation et de la présence de
flux concurrents
• il n’existe aucune assurance de délai
• il y a beaucoup de paramètres à régler
• 3 niveaux de priorité ne suffissent pas pour assurer une bonne différentiation sur
des liens non-chargés
• un mauvais dimensionnement rend inutile la présence de priorités sur des liens en
congestion
• le marquage ne suffit pas pour protéger TCP de UDP.

Pour obtenir une bonne différenciation avec l’Assured Forwarding, il faut :

• un regroupement des flux similaires dans une même classe
• des mécanismes de marquage adaptés
• des variations du débit, rafales, etc.
• un marquage en fonction du résultat que l’on veut obtenir.

Une classe AF Class 1: 30% Bande passante

PHB
AF Class 2: 20% Bande passante

AF Class 3: 10% Bande passante

AF Class 4: 5% Bande passante

Exemple : dd= drop
AF12 = (Classe AF 1, Drop = 2) => DSCP = precedence
Class AF1 Class AF2 Class AF3 Class AF4
Low Drop Prec 001010 010010 011010 100010
Medium Drop Prec 001100 010100 011100 100100
High Drop Prec 001110 010110 011110 100110

10
 Rappel sur le principe du Token Bucket : l’algorithme Token Bucket est un
algorithme de lissage de trafic. Des jetons sont accumulés dans un seau, de taille finie, à
débit constant. Lorsque les paquets passent, ils décrémentent le nombre de jetons du
seau. Les paquets passent donc à vitesse élevée tant qu’il reste des jetons. Ensuite, ils
passent au débit de remplissage du seau.

Rappel sur le RED : Random Early Detection (RED) est un mécanisme qui prend
les avantages des mécanismes de contrôle de congestion de TCP. En période de
congestion, on attribue des priorités aux paquets. RED dit à la source des paquets de
diminuer le taux de transmission. La source diminuera alors son débit jusqu’à ce que
tous les paquets atteignent à nouveau leur destination, ce qui indique qu’il n’y a plus de
congestion. RED peut aussi rejeter certains paquets avant que le buffer ne soit
complètement plein, cela évite ainsi de détruire un trop grand nombre de paquets.

Rappel sur le WRED : Weighted RED (WRED) généralement base sur la

précédence IP. Les paquets avec une précédence IP élevée ont moins de chance d’être
jetés que ceux avec un taux faible. Ainsi, le trafic de plus haute priorité sera délivré avec
une probabilité plus grande que le trafic de faible priorité. Il est très utile sur les
interfaces de sortie où il peut y avoir de la congestion. Il est généralement utilisé dans
les routeurs de cœur de réseau plutôt que ceux de bordure. En effet se sont les routeurs
de bordure qui affectent la précédence IP aux paquets alors que WRED s’en sert pour
déterminer le comportement à avoir.

Rappel sur RIO : RIO permet d'implanter une classe « Assured Forwarding »
(AF) qui a été définie par l'IETF. Plus précisément, les paquets sont marqués In ou Out
à l'entrée du réseau (on utilise pour cela un token bucket) selon leur degré de priorité ;
en cas de congestion les paquets Out sont rejetés en premier, puis les paquets In le sont
à leur tour dès lors que la congestion s'amplifie.

11
3 Architecture Diffserv
3.1 Présentation

Le groupe Diffserv propose donc d'abandonner le traitement du trafic sous forme

de flots pour le caractériser sous forme de classes. Le [RFC2475] préfère d’ailleurs le
terme de behaviour aggregate (BA) plutôt que de classe de trafic.
Le service différencié de l’architecture Diffserv permet de diminuer les
informations d’état que chaque nœud du réseau doit mémoriser. Il n’est plus nécessaire
de maintenir des états dans les routeurs pour chacun des flux. Ceci permet son utilisation
à grande échelle.
L’idée consiste à diviser le réseau en domaines. On distingue ainsi les routeurs à
l’intérieur d’un domaine (Core router) des routeurs d’accès et de bordure (Edge router).
Les routeurs d’accès sont connectés aux clients, tandis qu’un routeur de bordure est
connecté à un autre routeur de bordure appartenant à un domaine différent. Les routeurs
de bordure jouent un rôle différent de ceux qui sont au cœur du domaine. Ils sont chargés
de conditionner le trafic entrant en indiquant explicitement sur le paquet le service qu’il
doit subir. Ainsi, la complexité des routeurs ne dépend plus du nombre de flux qui
passent mais du nombre de classes de service. Chaque classe est identifiée par une valeur
codée dans l'en-tête IP.
Le trafic conditionné est identifié par un champ DS ou un marquage du champ
Type of Service (ToS) de l'en-tête de paquet IPv4 ou l’octet Class Of Service (COS)
d’IPv6. Ce champ d’entête IP porte l’indice de la Classe de Service DSCP (Differentiated
service Code Point). Sachant que ce travail de marquage est assez complexe et coûteux
en temps de calcul, il vaut mieux limiter au maximum les répétitions.
Les opérations de classification, contrôle et marquage sont effectuées par les
routeurs périphériques (Edge Router) tandis que les routeurs centraux (Core Router)
traitent les paquets en fonction de la classe codée dans l'en-tête d'IP (champ DS) selon un
comportement spécifique : le PHB (Per Hop Behavior) codé par le DSCP.

Rappel sur le principe du DSCP : c’est le champ qui identifie le traitement que le
paquet doit recevoir. Ce champ est codé sur 6 bits et fait parti des 8 bits codant le champ
TOS d’IPv4 ou le champ classe de trafic d’IPv6.

DSCP : Differentiated Service Code Point (6bits)

CU : Currently Unused ( 2bits)
Pour la classe EF DSCP = 101110
Pour la classe AF DSCP = 12 codes (cf. précédemment)

12
 L'architecture des services différenciés proposée dans le [RFC2475] contient deux
types d'éléments fonctionnels :

• Les éléments de bordures (edge functions) : ils sont responsables de la

classification des paquets et du conditionnement du trafic. En bordure du réseau,
c'est à dire à l'arrivée du premier élément actif capable de traiter le champs DS
(DS-capable), les paquets arrivant ont dans leur champ TOS (pour IPv4) ou
Traffic Class Octet (pour IPv6), une certaine valeur DS. La marque qu'un paquet
reçoit identifie la classe de trafic auquel il appartient. Après son marquage, le
paquet est envoyé dans le réseau ou jeté.

• Les éléments du cœur du réseau (core functions) : ils sont responsables de

l'envoi uniquement. Quand un paquet, marqué de son champ DS, arrive sur un
routeur DS-capable, celui-ci est envoyé au prochain nœud selon ce que l'on
appelle son Per Hop Behaviour (PHB) associé à la classe du paquet. Le PHB
influence la façon dont les buffers du routeur et le lien sont partagés parmi les
différentes classes de trafic. Une chose importante dans l'architecture DS est que
les PHB routeurs se basent uniquement sur le marquage de paquet, c'est à dire la
classe de trafic auquel le paquet appartient ; en aucun cas ils ne traiteront
différemment des paquets de sources différentes.

Dans l’architecture Diffserv, le traitement différencié des paquets s’appuie sur 3

opérations fondamentales :
- la classification des flux en classes de services
- l’introduction de priorités au sein des classes (Scheduling)
- et la gestion du trafic dans une classe donnée (Queue management).

La deuxième opération est assurée par les algorithmes d’ordonnancement servant

à contrôler la distribution de ressources entre les classes de service. On peut donner en
exemple 2 types d’ordonnanceurs : PQ (Priority Queueing) et WRR (Weighted Round
Robin).
Le modèle PQ utilise plusieurs files d’attente logiques. Les paquets classifiés sont
mis dans une file d’attente correspondant à la valeur du DSCP. Les files sont ensuite
servies suivant un algorithme spécifique. Celle qui contient les paquets avec la plus haute
priorité sera favorisée par rapport aux autres files.
Le modèle WRR utilise aussi plusieurs files d’attentes mais qui sont servies à tour
de rôle. A chaque tour, on transmet un nombre de bits (ou de paquets) correspondant au
poids de la file.

3.2 Classification et conditionnement du trafic

La classification s'effectue suivant une ou plusieurs valeurs contenues dans l'en-

tête IP (exemple : adresse source - destination, port source - destination, protocol ID, ...).
Celle-ci faite, elle dirige le paquet vers la fonction de marquage appropriée comme le
montre la figure :

13
 Figure 2 : arrivée des paquets dans un edge router

Une fois les paquets marqués, ils sont envoyés à leur destination puis à chaque
routeur DS-capable, ils reçoivent le service associé à leur classe.
Il n'est pas précisé par le groupe de travail Diffserv comment le classificateur est
paramétré pour effectuer cette classification ou plus exactement, qui le paramètre. Cela
doit être fait manuellement, aux bons soins de l'administrateur (qui paramètre les tables
de marquage des paquets en fonction d'une table d'adresse source, par exemple, donnée
au edge router) ou par le biais d'un protocole de signalisation ; RSVP pourrait d'ailleurs
très bien faire l'affaire, en effet, celui-ci n'étant pas un protocole de signalisation propre à
Intserv uniquement, on pourrait l'utiliser afin de signaler les classes que les routeurs
auront à traiter.
En plus de cette classification (ou marquage), un mécanisme de profilage du trafic
est défini par le groupe de travail Diffserv. Ce traffic profile a pour objet la prise en
compte du taux d'arrivée des paquets, afin de ne pas dépasser le seuil maximum de
paquets pouvant être envoyés sur le réseau. Ainsi, un mécanisme de mesure du trafic
permet de savoir si le flot de paquets entrants correspond au profil de trafic négocié. Si ce
flot dépasse un certain seuil, certains paquets seront marqués comme moins prioritaires et
seront automatiquement jetés en cas de congestion dans le réseau comme le montre la
figure :

Figure 3 : classification, marquage et conditionnement du trafic au niveau du edge

router

14
4 Intégration avec d’autres services
4.1 Intégration IntServ/DiffServ

L’intégration de ces deux mécanismes est à l’étude. Plusieurs propositions ont été
soumises. La première solution consiste à ne mettre l’intégration de service que dans les
sites terminaux. Le cœur du réseau ne traite pas les messages de signalisation mais les
transmet comme des paquets normaux qui sont à nouveau interprétés dans le site
destinataire. Un contrôle d’admission en bordure du réseau Diffserv permet de
déterminer si le flux peut entrer dans la classe de service. L’autre possibilité est de
considérer le réseau DiffServ avec la classe EF comme élément de réseau et le
caractériser pour permettre de construire un service garanti.

4.2 Intégration MPLS/DiffServ

MPLS permet de simplifier l’administration d’un cœur de réseau en ajoutant de

nouvelles fonctionnalités particulièrement intéressantes pour la gestion de la qualité de
service. Dans le même esprit que l’architecture DiffServ, MPLS permet de réduire le
coût des traitements associés au relayage des paquets en les reportant à la périphérie du
réseau et en réduisant la fréquence. Il apporte aussi un mécanisme de routage
hiérarchique efficace, c’est-à-dire des tunnels permettant de gérer les réseaux privés
virtuels. Le principe de MPLS est d’attribuer un label à chaque paquet lorsqu’il entre
dans le réseau. Ce label est attribué en fonction de la classe de relayage à laquelle
appartient le paquet. La définition de ces classes dépend de l’opérateur du réseau mais
elle peut prendre aussi en compte la classe de service DiffServ.
Le label décide donc dans chaque routeur du prochain routeur, du comportement
DiffServ et de l’utilisation éventuelle des ressources réservées.

15
5 Mise en œuvre de DiffServ
5.1 Principe

Le trafic entrant dans le réseau est classifié et se voit attribué des ressources, en
fonction des critères de gestion du modèle de service. Aucune réservation n'est faite,
mais un dimensionnement adéquat assure qu'il aura assez de ressources dans le réseau
pour les demandes de toutes les applications. Les garanties données par le modèle vont
dans le sens du partage des ressources disponibles. Pour offrir un certain niveau de QoS,
les classifications donnent un traitement différentiel à des applications sensées d'avoir
des besoins plus exigeants c’est-à-dire des priorités.
Une fois le mécanisme de priorité disponible, la mise en place d'une qualité de
service suppose la définition des règles pour utiliser ce mécanisme. Pour garantir le
respect de ces règles, on emploie une politique qui les impose aux limites d'un périmètre.
On parle de routing policies.

Figure 4 : classification, marquage et conditionnement du trafic

Dans le cadre de la QoS, nous pourrions tenir compte de différents paramètres qui
sont : le délai, le débit et le taux de perte de paquets. Cependant, ces paramètres sont
difficiles à mesurer du fait du caractère aléatoire des pertes de paquets et du temps
variable passé dans les files d’attente sur tous les routeurs qui constituent le chemin entre
une source et une destination. Il faut donc se limiter, dans le cas d’une mise en œuvre,
aux paramètres tels que : le délai, le taux de perte de paquets et la variation du délai de
bout en bout.
Le délai de bout en bout détermine le temps que mettent les données pour être
acheminée d’une source à une destination, il est composé d’une partie constante : le
temps de propagation et une partie variable qui tient compte du temps d’attente dans les
différentes mémoires tampons des routeurs traversés.
La variation du délai de bout en bout est due aux délais dans les files d’attente des
routeurs.
Le taux de perte de paquets est un facteur important car dans le cas d’un taux trop
élevé, pour certain type d’application, il est impossible de réémettre le paquet perdu.

16
5.2 Exemples de scénarii possibles

Figure 5 : un exemple de réseau de test

Scénario 1
Mettre en évidence la différence entre l’utilisation de Differv et la non-utilisation de ce
service.
Pour cela on peut envoyer dans le réseau différents types de données, les unes après les
autres puis toutes ensembles sur un même chemin pour voir les problèmes que cela peut
entraîner et comparer les résultats obtenus en réitérant les transmissions mais avec le
service Diffserv.

Scénario 2
On peut considérer que l’on a deux sources. Une qui envoie des fichiers de tests, par
exemple des extraits vidéo, et l’autre qui envoie un trafic continu pour simuler un vrai
réseau utilisé.
L’envoie de fichiers vidéo permet de voir la perte de paquets lors de la réception car dans
le cas de problèmes, l’image sera brouillée.
On prend trois fichiers de même type que l’on envoie dans des conditions normales. Les
résultats serviront de témoins.
On envoie les trois mêmes fichiers mais en appliquant Diffserv.
On recommence mais on envoyant précédemment un flux UDP pour créer une
congestion sur un routeur de cœur.
Et enfin on envoie une dernière fois les trois fichiers on leur attribuant des priorités
différentes puis des priorités identiques et fortes.

Scenario 3
On pourrait faire la comparaison entre WRED et RIO.

Scénario 4
On pourrait comparer la différence entre un flux UDP et un flux TCP en utilisant les
programmes en C fait en 2ème année, avec l’influence pour le flux TCP des Token Bucket.

Scénario 5
Voir l’influence d’une agrégation en périphérie du réseau sur la QoS.
Voir l’influence d’une agrégation dans le cœur du réseau sur la QoS.

17
Scénario 6 : trafic audio et FTP
Cet exemple est tiré d’un document écrit par Ibrahima NIANG et Dominique SERET
« Dimensionnement de DiffServ basé sur des métriques de performances » et donne un
exemple complet d’une réalisation de mise en œuvre qui aurait pu être faite.

On peut gérer 3 files d’attentes de type : BE (Best Effort), EF et AF.

Ces files d’attentes doivent être servies par des ordonnanceurs différents qui peuvent être
soit PQ (Priority Queuing) soit par WRR (Weighted Round Robin) qui ont été définis au
chapitre précédent.
On peut considérer que dans le cas PQ, la file de la classe EF a la plus haute priorité et la
file BE la plus basse. La file EF sera une simple FIFO et en cas de congestion, les
paquets EF seront rejetés.
La file BE peut être gérer par un mécanisme RED (Random Early Detection) qui permet
de prévenir les congestions avant qu’elles n’interviennent, en détectant à l avance le
remplissage des buffers, sans attendre la saturation. Les paquets sont rejetés par
anticipation ce qui amène la source à réduire son débit. Un seuil de remplissage, inférieur
au seuil de rejet par saturation, sert de déclencheur au mécanisme.
La file AF pourra utiliser une extension du mécanisme précédent appelée RIO (RED In
and Out). Ce mécanisme distingue le trafic In et Out. Dans ce cas, si un paquet est non
conforme, il est marqué et sera détruit en cas de congestion.

Etant donné que les 2 classes les plus intéressantes sont AF et EF, le scénario suivant
sera basé sur ces 2 comportements.
Le trafic audio est envoyé dans la file de plus haute priorité EF et le trafic FTP dans la
file de plus basse priorité AF.

Figure 6 : système de file d’attente des nœuds DiffServ

On envoie des paquets audio et FTPde taille connue. On fait les mesures.

18
Figure 7 : topologie simulée

19
 BIBLIOGRAPHIE
Adresses Internet utilisées pour réaliser ce document :

http://irl.cs.ucla.edu/twotier/
http://www-rp.lip6.fr/~lochin/qos/qoshtml/node8.html
http://diffserv.sourceforge.net/
http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/mpls-arch/sld036.html
http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/mpls-arch/sld037.html
http://www-rp.lip6.fr/~lochin/qos/qoshtml/
http://www.loria.fr/~fleury/AlgoTel2000/Exposes/toutain/
http://www-
rp.lip6.fr/airs/Mise_en_oeuvre_et_etat_de_l_ar/mise_en_oeuvre_et_etat_de_l_ar.html
http://www-sop.inria.fr/planete/intradiff/
http://www-rp.lip6.fr/~pan/enseignement/internet-multimedia/4-DEA1.pdf
http://www.inria.fr/rrrt/rr-4511.html
http://irl.cs.ucla.edu/twotier/
http://www.regit.org/article.php3?id_article=13
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/diffserv/

20