Professional Documents
Culture Documents
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.
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
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
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.
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.
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.
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.
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.
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 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
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.
12
L'architecture des services différenciés proposée dans le [RFC2475] contient deux
types d'éléments fonctionnels :
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 :
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.
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.
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
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.
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.
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