Pfe Mansour Hana

RAPPORT DE PROJET DE FIN D’ETUDES
Filière
Ingénieurs en Télécommunications
Option
Ingénierie des Réseaux
Etude des mécanismes de différenciation

de services
Elaboré par :
Hana MANSOUR
Encadré par :
M. Fakhreddine KHELIFA
M. Mounir FRIKHA
Année universitaire : 2004/2005

Dédicace
A mes parents,
A mes grands-parents,
A mes soeurs,
A mes amis, particulièrement, faker, Najet, Souheil, Rim,
Qu’ils trouvent dans ce travail le fruit de leur patience
et du soutien permanent
qu’ils m’ont prodigué pour affronter
tous les moments difficiles.
Hana "
i
Avant Propos
Le travail présenté dans ce projet de fin d’études a été effectué dans le cadre de la
préparation du diplôme d’ingénieur en télécommunications, option Ingénierie des Réseaux
(IRES) à l’Ecole Supérieure des Communications de Tunis (SUP’COM).
Ce projet s’inscrit dans le cadre d’étude des mécanismes de différenciation de services et
la possibilité d’intégration de l’approche de régulation dynamique aux priorités des classes de
DiffServ.
Au terme de ce travail, nous tenons à remercier tout particulièrement :
M. Fakhreddine KHELIFA, mon encadrant, ingénieur au sein du CERT et M. Mounir

FRIKHA, mon encadrant, maître assistant à SUP’COM, directeur du département réseaux à
l’école supérieure des communications de Tunis pour leur encadrement, leur disponibilité et
sympathie, pour les conseils qu’ils m’ont prodigués et pour leur soutien moral.
Tous mes enseignants qui ont contribué à ma formation ainsi qu’aux responsables de
SUP’COM et de CERT pour les moyens qu’ils m’ont offert afin de mener à terme ce travail.
Mes vifs remerciements s’adressent aussi à tous ceux qui m’ont encouragé de près ou de
loin tout au long de ce travail.
ii
Résumé
Le modèle à Différenciation de Services (DiffServ) ajoute des nouvelles fonctionnalités

aux routeurs afin d’améliorer la Qualité de Service. Des contraintes telles que la réduction du
délai d’acheminement ou le contrôle dans la distribution de ressources peuvent être satisfaites
grâce aux mécanismes proposés par ce modèle. A travers le comportement assuré, le modèle
DiffServ introduit le mécanisme d’ordonnancement à partage de bande passante basé sur les
niveaux de priorité. D’une part, cette notion peut être exploitée pour distribuer équitablement les
ressources réseau indépendamment du comportement des sources. D’autre part, la notion des
coefficients de pondération attribués aux files d’attentes peut réduire considérablement l’effet de
pertes sur la transmission de flux multimédia.
Les travaux de ce projet se concentrent sur la définition, simulation et mise en oeuvre de
mécanismes d’attribution de priorités et de gestion des ressources pour le modèle DiffServ. Nous
proposons, ensuite, un modèle analytique permettant l’introduction du régulateur PID assurant
l’ajustement dynamique des priorités des files d’attentes de DiffServ. Enfin, nous validons les
résultats de l’implémentation de l’approche de régulation avec Network Simulator.
Mots-clés : Qualité de Service, DiffServ, WFQ, régulateur PID, modélisation, simulation.
iii
Sommaire
DEDICACE......................................................................................................................................i
AVANT PROPOS ......................................................................................................................... ii
RESUME....................................................................................................................................... iii
LISTE DES FIGURES................................................................................................................ L4
LISTE DES TABLEAUX ........................................................................................................... L6
LISTE DES ABREVIATIONS .................................................................................................. L7
INTRODUCTION GENERALE ..................................................................................................1
CHAPITRE I : LA DIFFERENCIATION DE SERVICES DANS LES RESEAUX ..............3

I- Introduction.................................................................................................................... 3
II- La qualité de service dans la conception des réseaux ............................................... 3
II-1- Les paramètres de la qualité de service...................................................................4
II-1-1- Disponibilité .........................................................................................................4
II-1-2- Bande passante .....................................................................................................5
II-1-3- Latence (Delay) ....................................................................................................5
II-1-4- Variation des délais de traversée (gigue ou jitter) ................................................6
II-1-5- Taux de pertes.......................................................................................................7
III- La réservation de ressources...................................................................................... 9
III-1- Le modèle IntServ ....................................................................................................9
III-2- La solution MPLS ..................................................................................................10
IV- Le modèle DiffServ.................................................................................................... 10
IV-1- Caractéristiques du modèle...................................................................................11
IV-2- Architecture de DiffServ........................................................................................12
IV-2-1- Agrégation de flux ............................................................................................14
M. Hana - PFE - IRES L1

IV-2-2-Traitement par noeud ( Per Hop Behavior ).......................................................15
IV-3- Le Traitement différencié de paquet dans le routeur DiffServ..........................15
IV-3-1- La classification de trafic ..................................................................................17
IV-3-2- Le conditionnement de trafic ............................................................................19
IV-3-3- L’ordonnancement de trafic ..............................................................................23
V- Intégration avec d’autres services............................................................................. 24
V-1- Intégration IntServ/DiffServ...................................................................................24
V-2- Intégration MPLS/DiffServ ....................................................................................25
VI- Conclusion.................................................................................................................. 26
CHAPITRE II : EVALUATION DES PERFORMANCES DE DIFFSERV .........................27

I- Introduction.................................................................................................................. 27
II- Présentation................................................................................................................. 27
II-1- Implémentation de Diffserv dans NS.....................................................................27
III- L’apport de l’ordonnanceur WFQ pour DiffServ ................................................. 30
III-1- La discipline Fair Queuing....................................................................................30
III-2- La discipline Weighted Fair Queuing ..................................................................31
III-2-1- La discipline de service fluide GPS ..................................................................31
III-2-2- La discipline de service PGPS ou WFQ............................................................33
III-2-3- WFQ et la garantie de délai pour un trafic (σ, ρ) borné ....................................33
IV- Résultats et Interprétations...................................................................................... 35
IV-1- L’équité de la bande passante ...............................................................................35
IV-2- Le taux de perte......................................................................................................38
IV-3- La borne sur le délai ..............................................................................................40
V- La régulation ............................................................................................................... 41
V-1- Besoin de la régulation ............................................................................................41
V-2- La loi de commande.................................................................................................42
V-2-1- La loi de commande proportionnelle..................................................................42
V-2-2- La loi de commande intégrale ............................................................................43
V-2-3- La loi de commande dérivée ..............................................................................44
V-3- Le régulateur PID ....................................................................................................44

VI- Conclusion.................................................................................................................. 45
CHAPITRE III : MODELISATION ET IMPLEMENTATION DE L’APPROCHE DE

REGULATION DANS LE MODELE DIFFSERV...................................................................46
I- Introduction.................................................................................................................. 46
II- Aperçu de l’approche de régulation dans le modèle DiffServ................................ 46
III- Intégration de régulateur PID dans le modèle DiffServ........................................ 47
III-1-Modélisation de la bande passante ........................................................................48
III-2- Modélisation du délai.............................................................................................49
IV- Evaluation des performances de la régulation ....................................................... 50
IV-1- Description du scénario choisi...............................................................................51
IV-2- Module de régulation de la bande passante.........................................................52
IV-2-1-Principe de fonctionnement de régulateur de la bande passante........................52
IV-2-2- Interprétation des résultats ................................................................................53
IV-3- La régulation du délai............................................................................................57
IV-3-1- Principe de fonctionnement de régulateur du délai...........................................57
IV-3-2-Interprétation des résultats .................................................................................58
IV-4- Compromis entre le délai et la bande passante réservée ....................................61
IV-4-1- Principe et Algorithme ......................................................................................62
IV-4-2- Interprétation des résultats ................................................................................63
V- Conclusion ................................................................................................................... 66
CONCLUSION GENERALE .....................................................................................................67

BIBLIOGRAPHIE .......................................................................................................................69

Liste des figures
Fig I-1 : Délai dans un réseau à commutation des paquets ..............................................................5

Fig I-2 : Distribution de délai et illustration de la gigue ..................................................................6
Fig I-3 : Architecture du modèle DiffServ......................................................................................13
Fig I-4 : Le champ DSCP ...............................................................................................................14
Fig I-5 : Les Composants QoS d'un routeur IP DiffServ ...............................................................16
Fig I-6: La fonction de classification .............................................................................................19
Fig I-7 : Le principe de la vérification ...........................................................................................20
Fig I-8 : Les mécanismes de régulation de trafic : le seau percé et le seau à jetons ......................22
Fig I-9 : La fonction de marquage..................................................................................................22
Fig I-10 : Classification de l’ordonnancement ...............................................................................23
Fig II-1 : Configuration des files RED dans DiffServ ...................................................................28
Fig II-2 : Topologie de la simulation .............................................................................................29
Fig II-3 : La discipline de service Round Robin ............................................................................31
Fig II-4 : La discipline de service GPS ..........................................................................................32
Fig II-5 : Délai maximal garanti par WFQ.....................................................................................34
Fig II-6 : Extrait de « Policy Table » et « Policer Table » .............................................................35
Fig II-7 : Les statiques de traitement des paquets .........................................................................35
Fig II-8 : Partage de la bande passante (1) .....................................................................................36
Fig II-9 : Partage de la bande passante ( Trafic On/Off)................................................................37
Fig II-10 : L’effet de l’ordonnanceur WFQ ...................................................................................38
Fig II-11 : Variation de taux de pertes ...........................................................................................39
Fig II-12 : Variation de délai de bout en bout ................................................................................40
Fig II-13 : Le principe de régulation en boucle fermé ...................................................................41
Fig II-14 : Présentation de l’erreur.................................................................................................42
Fig II-15 : Effet de la commande proportionnelle..........................................................................43

Fig III-1 Principe d’ajustement des coefficients ...........................................................................46
Fig III-2 : Scénario de simulation ..................................................................................................51
Fig III-3 : Organigramme du module de régulation de la bande passante .....................................53
Fig III-4 : Résultat de régulation de la bande passante ..................................................................54
Fig III-5 : Présentation des résultats de l’approche de régulation de la bande passante ................54
Fig III-6 : Résultat de la simulation concernant l’ajustement des poids ........................................56
Fig III-7 : Résultat de la simulation avec NS .................................................................................56
Fig III-8 : Organigramme du module de régulation de la borne sur le délai..................................58
Fig III-9 : Résultat de l’approche de régulation du délai ...............................................................59
Fig III-10 : Variation de la valeur consigne et mesurée.................................................................59
Fig III-11 : Variation des priorités pour les flux vidéo et de données ...........................................60
Fig III-12 : Résultat de la simulation avec NS (1) .........................................................................60
Fig III-13 : Résultat de la simulation avec NS (2) ......................................................................61
Fig III-14 : Organigramme du module de régulation du délai et de la bande passante..................63
Fig III-15 : Résultat de l’approche de régulation (délai et bande passante)...................................64
Fig III-16 : Régulation du délai maximal et de la bande passante .................................................64
Fig III-17 : Résultat de la simulation avec NS (Bande passante)..................................................65
Fig III-18 : Résultat de la simulation avec NS (le délai maximal )...............................................66

Liste des tableaux
Tableau I-1 : Les besoins en qualité de service de certaines applications .......................................7

Tableau I-2 : Tableau comparatif des approches de QoS...............................................................12
Tableau I-3: La valeur du champ DSCP pour les différentes classes AF ......................................18
Tableau I-4: Tableau comparatif entre MPLS et DiffServ.............................................................25
Tableau II-1: Caractéristiques des flux ..........................................................................................30
Tableau II-2: Taux de pertes pour le flux vidéo et de données ......................................................39
Tableau III-1 : Paramètres de simulation .......................................................................................51
Tableau III-2 : Ajustement des pondérations des files...................................................................55
Tableau III-3 : Paramètres de la simulation ...................................................................................57
Tableau III-4 : Résultats générés par le module de régulation.......................................................65

Liste des abréviations
AF Assured Forwarding
BA Behavior Aggregate
BE Best Effort
CBR Constant Bit Rate
CBS Committed Burst Size
CIR Committed Information Rate
CP Code Point
CS Class Selector
DiffServ Differentiated Services
DSCP DiffServ Code Point
EDF Earliest Deadline First
EF Expedited Forwarding
FTP File Transfer Protocol
IETF Internet Engineering Task Force
IntServ Integrated Service
IP Internet Protocol
MF Multi Field
MPLS Multi Protocol Label Switching
NS Network Simulator
PID Proportionnel Intégral Dérivé
PHB Per Hob Behavior
RSVP Ressource Reservation Protocol
QoS Quality of Service
RED Random Early Discard

SLA Service Level Agreement
TCA Traffic Condition Agreement
TOS Type of Service
UDP User Datagram Protocol
WFQ Weight Fair Queuing

Introduction Générale
La qualité de service ou QoS (Quality of service) est un nouveau concept incontournable

dans le monde des réseaux des télécommunications. Bien que complexe, il n’a rien de
révolutionnaire, puisqu’il se fonde sur des technologies préexistantes, qu’il vise à rationaliser, et
souvent à simplifier, afin d’en faciliter la mise en œuvre. Néanmoins, la normalisation n’est pas
encore achevée et de nombreuses philosophies s’affrontent, avec un principal enjeu le
« leadership » de tel ou tel constructeur. Ce concept revêt de multiples aspects technologiques, et
qui doit être précisé selon ses objectifs et son contexte d’utilisation.
En fait, la plupart des réseaux informatiques et télécommunications reposent aujourd’hui
sur le protocole IP, conçu à l’origine pour véhiculer des données informatiques. Cependant, avec
la prolifération du réseau Internet marquée par la croissance exponentielle du trafic et la
naissance de nouvelles applications, ce réseau se trouve face à des problèmes sévères. Le best
effort n’est plus suffisant pour suivre l’évolution des technologies. Donc, il ne s'avère pas un
support de communication qui permet de satisfaire pleinement les contraintes variées de ces
nouvelles applications.
Face à cette impasse, un effort de recherche important a été mené, ces dernières années,
pour qu’Internet offre un support d'interconnexion où de nombreux types d'applications puissent
cohabiter et fonctionner raisonnablement. Des solutions ont émergé : celles requérant une
nouvelle architecture appelée « avec état » tels que l’architecture IntServ et celles maintenant la
propriété « sans état » comme DiffServ.
Le traitement différencié de paquets est un concept relativement ancien dans l’Internet. Il
est présent dès l’origine du protocole IPv4 avec le champ ToS, mais une définition trop vague a
limité son déploiement. Ce concept a été redéfini pour offrir un traitement adapté aux besoins très
M. Hana - PFE - IRES 1

Introduction générale
hétérogènes des applications. En effet, le modèle de différenciation de service (DiffServ) fournit

un cadre générique aux applications réseaux pour garantir un traitement par classe de service.
C’est dans ce cadre que nous situons notre projet de fin d’étude intitulé « Etude des
mécanismes de différenciation de service ». Il a pour vocation d’expliquer les mécanismes de
gestion de la qualité de service associés aux protocoles IP, particulièrement le « Differentiated
Services » (DiffServ) et la possibilité d’intégration de l’approche de régulation dynamique aux
priorités des services de ce modèle.
Ce rapport se compose de trois chapitres. Dans le premier, nous nous intéressons à la
présentation générale des concepts de la qualité de service, l’étude des principales
caractéristiques de DiffServ et l’explication des mécanismes permettant à cette architecture
d’assurer un traitement différencié des services tout en garantissant la qualité de service (Qos) de
bout en bout.
Dans le deuxième chapitre, nous évaluons les performances d’un tel modèle par
simulation avec Network Simulator et nous étudions une solution permettant d’améliorer encore
plus le niveau de QoS. Nous définissons, en première partie, la topologie mise en œuvre lors de
l’évaluation de DiffServ ainsi que des mesures pour certaines métriques de QoS. La deuxième
partie est consacrée à la définition du concept de la régulation PID ainsi que ses caractéristiques
qui peuvent être intégrées pour l’ajustement dynamique des priorités pour les différents agrégats
de DiffServ.
L’implémentation et le test de l’approche de régulation dans DiffServ sont présentés dans
le troisième chapitre. Nous commençons, d’abord, par introduire les spécifications de notre
application, ensuite nous présentons notre modèle de régulation pour certains paramètres de QoS
et enfin, nous décrivons le prototype de test et les paramètres à réguler.

Chapitre I
La différenciation de services dans les réseaux
I- Introduction
Internet a fonctionné sans que les usagers ressentent la nécessité d'introduire de traitement
différencié au niveau de la couche réseau. Le type de communication dominant le réseau, depuis,
est le transfert de fichiers et le web. Cependant, aujourd’hui, on constate le développement
d'applications s'appuyant sur des modes de communication à la sémantique radicalement
différente du transfert de fichier, comme la voix sur IP ou des applications interactives. D’où le
service best-effort devient, alors, un support de communication peu satisfaisant pour ces types de
flux. En effet, il est peu difficile de supporter ces applications au niveau des protocoles de
transport seulement. Mais il est pertinent d'aller vers l'enrichissement de la couche réseau avec de
nouveaux mécanismes d’ordonnancement et de gestion de file d’attente assurant une bonne
qualité de service.
Dans ce Chapitre, nous nous intéressons à une des mécanismes supportant ces
communications à la sémantique nouvelle, qui est le modèle DiffServ. Tout d’abord, nous
présentons les indicateurs de service et les mécanismes retenus pour caractériser les performances
d’un réseau et assurer une bonne qualité. Puis, nous décrivons l’apport du modèle DiffServ.
Ensuite, nous étudions les différents blocs fonctionnels dans le routeur de ce modèle. Enfin nous
traitons la possibilité d’intégration de DiffServ avec d’autres modèles.
II- La qualité de service dans la conception des réseaux

À ses débuts, Internet avait pour seul objectif de transmettre les paquets à leurs
destinations. Conçu pour le transport des données, IP (Internet Protocol) n'a pas été prévu

pour les applications en temps réel. Le besoin en équipements de plus en plus fiables, d'un bout à
l'autre du réseau, est donc devenu incontournable. Cependant, les inconvénients rencontrés dans
les réseaux (perte de paquets, congestion…) ne peuvent pas être surmontés sans une rénovation
profonde de l'architecture.
La QoS d’une application est définie comme étant l’ensemble des exigences requises par
cette application en terme de bande passante, délai, gigue et taux de perte. Ces exigences sont
intrinsèques à la nature des applications. Ces dernières peuvent être classées en deux catégories :
¾ Les applications temps-réel : Ce type d’applications dites temps-réel ont un besoin
ferme en terme de délai et de faible variation de délai (gigue). Cependant, elles peuvent
tolérer quelques pertes de paquets.
¾ Les applications non-temps-réel : Les applications dites non-temps-réel (ou Best-Effort)
sont plus sensibles aux pertes de paquets (par rejet) qu’à des délais élevés. Dans ce cas, la
fiabilité de la communication est plus importante que la garantie d’un délai borné
Ainsi, on définit la qualité de service comme étant la méthode qui permet de garantir à un
trafic de données, quelle que soit sa nature, les meilleures conditions d'acheminement répondant à
des exigences prédéfinies. Elle fixe notamment des règles de priorité entre les différents flux.
Dans la suite, nous nous focalisons sur les exigences requises par les applications en termes de
disponibilité, la bande passante, le délai, la gigue et le taux de perte [1].
II-1- Les paramètres de la qualité de service
La maîtrise de la qualité de service est un enjeu essentiel. Elle 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 aux besoins de l’entreprise.
II-1-1- Disponibilité
La disponibilité d’un réseau se définit comme le rapport entre le temps de bon

fonctionnement du service et le temps total d’ouverture du service. C’est la forme la plus
évidente de QoS, puisqu’elle réprésente la possibilité d’utiliser le réseau [2].

II-1-2- Bande passante
La bande passante (ou le débit maximum) est considérée comme étant le taux de transfert
maximum pouvant être maintenu entre deux points terminaux. La QoS ne génère pas la bande
passante. En revanche, ses mécanismes permettent de gérer de façon optimale la bande passante
du réseau en fonction des demandes des applications. Dans les réseaux à commutation de
paquets, la garantie de bande passante est un paramètre de performance très important pour
garantir la QoS aux flux temps-réel. Ces derniers, ont une exigence minimale en terme de bande
passante égale à leur débit moyen.
II-1-3- Latence (Delay)
La latence correspond au temps que requière un paquet pour traverser le réseau d’un point
d’entrée à un point de sortie. Elle est généralement appelée le délai de bout-en-bout. Ce
paramètre est introduit par les dispositifs intermédiaires du réseau tels que les routeurs ou les
commutateurs dans les réseaux à commutation de paquets. La figure I-1 montre les différentes
composantes susceptibles d’introduire un délai dans la transmission des paquets traversant le
réseau.
Délai introduit par un dispositif
intermédiaire du réseau
Délai de commutation Délai d’attente

Délai d’attente Délai de
ou de routage en sortie
en entrée propagation
Fonction de
routage ou
de
commutation
Fig I-1 : Délai dans un réseau à commutation des paquets
En général, la majeure partie du délai est celle introduite par les files d’attente en sortie.
En effet, plusieurs flux en entrée se trouvent en concurrence pour accéder au médium de
transmission. Les algorithmes d’ordonnancement ont été mis en oeuvre pour assurer un partage
adéquat des ressources en fonction des exigences des applications afin d’améliorer leurs
performances. L’exigence d’une application en terme de délai pourrait être stricte, auquel cas le

réseau doit garantir une borne maximale sur le délai instantané de bout-en-bout, ou moyen auquel
cas le réseau offre une valeur moyenne du délai à long terme avec la possibilité de fluctuations en
cas de surcharge du réseau.
II-1-4- Variation des délais de traversée (gigue ou jitter)
La gigue se définit comme la variation des délais d’acheminement (latence) des paquets
sur le réseau. Ce paramètre est particulièrement sensible pour les applications multimédias qui
requièrent un délai inter paquet relativement stable. Il dépend principalement du type et du
volume de trafic sur le réseau et du type et du nombre d’équipements réseau. La figure I-2 montre
une distribution typique du délai et illustre le concept de la gigue.
D is tr ib u tio n
d u d é la i
d é la i
G ig u e
D é la i D é la i D é la i
m in m oyen m ax
Fig I-2 : Distribution de délai et illustration de la gigue
Les flux temps-réel tels que les flux vidéo, audio et voix sur IP sont très sensibles à la
gigue. En effet, la non considération de cette métrique implique une discontinuité au niveau de la
restitution des données à la destination. Par exemple, la variation de délai dans une transmission
vidéo pourrait entraîner des images saccadées aléatoirement ce qui dégrade considérablement la
qualité de service de l’application. Pour réduire l’effet de la gigue, les paquets temps-réel sont
bufférisés à la destination avant leur lecture. Pour cela, la gigue doit être bornée pour prévoir la
taille du tampon qui dépend principalement de la valeur de la gigue et du débit de réception des
données [2].

II-1-5- Taux de pertes
Ce paramètre représente le pourcentage des unités de données qui ne peuvent pas atteindre
leur destination dans un intervalle de temps spécifique. Cette perte peut être le résultat d’un rejet
de paquets lorsque les ressources sont saturées ou d’un dépassement d’échéance. Dans une
application temps-réel, un paquet arrivant au-delà de son échéance ne fournira aucune
information utile à l’application. Le taux de perte est communément représenté par la «
probabilité » de perte. La retransmission d’un paquet perdu ne change pas la valeur de la
probabilité de perte mais fournit un moyen de recouvrement de perte [1].
La Qualité de Service peut être résumée, donc, comme étant un traitement préférentiel
pour certains types de trafic moyennant autant des paramètres qui la décrit. Par exemple, la
variation de délai est un facteur important pour les applications temps-réel (comme la Voix sur
IP). En effet, le trafic VoIP (voix sur IP) n’a pas besoin de beaucoup de bande passante mais il
nécessite un délai et une gigue faible. Au contraire, le trafic FTP (File Transfert Protocol)
nécessite une largeur de bande importante mais le délai n’est pas un critère primordial. Le tableau
ci-dessous résume les besoins en qualité de service de certaines applications susceptibles d'être
transportés sur les réseaux haut débit [3].
Débit moyen Délai Gigue maximum Taux d’erreur Taux d’erreur par
Service
(Mbit/s) maximum (s) (ms) par bit message
Voix non
0.064 0.25 10 < 10 -1 < 10 -1
compressée
Vidéo
1 à 30 0.25 1 < 10 -6 10 -9
compressée
Image 1 à 10 1 - 0 à 10 -4 0 à 10 -9
Transfert de
1 à 100 1 - 0 0
fichiers
Tableau I-1 : Les besoins en qualité de service de certaines applications
Le problème à l’heure actuelle est que la plupart des réseaux ont un ou plusieurs liaisons
critiques qui dégradent les performances des applications. Ceci vient du fait qu’il n’y a pas de
distinction entre le trafic prioritaire et le trafic non prioritaire. La solution proposée par la
différenciation des services est de séparer les deux types de trafic sur les liens critiques. Donc,

dans le cas où le réseau serait saturé, une alternative à l’augmentation de la bande passante est la
différenciation du trafic. Actuellement, il y a deux modèles, proposés par l’IETF, permettant la
différenciation du trafic tels que IntServ et DiffServ.
II-2- Les principaux mécanismes de gestion de QoS
Pour satisfaire les besoins des applications dans les réseaux à commutation de paquets,
une première solution suggère d’allouer plus de bande passante aux flux, afin de résoudre les
problèmes de congestion, perte de paquets et de délai puisque la bande passante devient
disponible à faible coût. Cependant, plusieurs applications temps-réel ont besoin de garanties
particulièrement en terme de délai, gigue et taux de perte et non seulement en terme de bande
passante. La proposition d’allouer des ressources supplémentaires n’est pas un choix judicieux
pour assurer la QoS. D’une part, ce choix conduit à un surdimensionnement du réseau réduisant
ainsi son taux d’utilisation en temps normal. D’autre part, avec l’émergence des applications
multimédia et l’utilisation croissante des réseaux à commutation de paquets tels que l’Internet, la
saturation rapide de la totalité des ressources du réseau est prévue. Ceci ramène de nouveau à la
situation de ressources limitées. La deuxième solution consiste à fournir les mécanismes
nécessaires pour assurer la QoS qui se résument principalement en trois fonctionnalités
supplémentaires aux services fournis par le réseau. C’est un ensemble de traitements différenciés
réalisés soit au niveau de la source de trafic (terminal émetteur) soit dans les organes du réseau.
On peut distinguer les mécanismes suivants [2]:
¾ Le « traffic shaping » ou mise en forme du trafic consiste principalement à introduire
du délai entre les émissions de paquets de manière à éviter ou limiter les rafales de
trafic.
¾ Le « traffic policing » est une opération qui consiste à vérifier que le trafic émis est
bien conforme à la description qui a été faite par la source.
¾ Le mécanisme de « buffer management » ou gestion de buffer consiste à éliminer des
paquets en cas de congestion du buffer d’une interface de sortie de manière sélective,
en fonction des paramètres de QoS associés aux flux.
¾ L’opération de traffic scheduling consiste à ordonnancer la transmission des paquets
présents dans les buffers de l’interface de sortie en fonction des paramètres de QoS
associés aux flux. Cette opération peut être effectuée par différents algorithmes.

Le domaine de la qualité de service est très vaste et complexe puisque les applications ne
cessent de se développer et les exigences varient et se ramifient. C’est un thème dynamique qui
accroît avec le progrès technique. Nous avons présenté dans ce qui précède la notion de QoS, ses
paramètres ainsi que les mécanismes permettant son contrôle. Ces derniers réalisent des actions
nécessaires au support de la QoS dans le réseau. Le placement et la configuration de ces
mécanismes dans le réseau, ainsi que leurs interactions, définissent un "modèle" de qualité de
service. Nous nous intéressons dans la suite à étudier le modèle Diffserv permettant de définir
une configuration statique des mécanismes suite à l’identification des besoins de QoS les plus
généraux.
III- La réservation de ressources

Une solution idéale du contrôle de la performance de transmission des paquets est
d'ajouter au réseau un système de réservation de ressources. Ainsi, l'émetteur d'un flux est assuré
d'obtenir la performance qu'il souhaite, que ce soit en terme de débit, de délai ou de taux de perte.
III-1- Le modèle IntServ
Un système puissant de réservation de ressources sur Internet est l'architecture Intserv

(Integrated Service), standardisée par L’IETF et destinés à définir une architecture à Intégration
de Services. Dans un tel modèle, il est possible de garantir le taux de perte et le délai
d’acheminement observés par un flux individuel, tout en contrôlant la distribution de ressources
entre les flux. Le modèle IntServ présente les caractéristiques suivantes [4]:
¾ Il est orienté récepteur, ce qui permet la réservation de ressources pour les flux
multicast. En échange, il a été nécessaire de déterminer un mécanisme pour
assurer des routes symétriques entre les émetteurs et les récepteurs.
¾ Pour que la qualité de service puisse être garantie, des ressources doivent être
réservées dans chaque routeur. En conséquences des fonctions de contrôle d’accès,
de classification et de gestion de ressources sont implantées dans chaque noeud du
réseau. Cette architecture introduit l'établissement de circuits virtuels à l'aide d'un
protocole de signalisation (RSVP) [5].
¾ La granularité spécifiée par le modèle permet de réserver des ressources jusqu’au
niveau des microflux, en augmentant le nombre de réservations qui doit être géré
par chaque routeur.

Cependant, le principe de simplicité au niveau réseau, est remis en cause puisque les
routeurs ont des tâches désormais complexes de gestion des flux, contrôle de l'utilisation…etc.
De plus, au niveau technique, la faiblesse principale de l’architecture IntServ est sa non-
résistance au facteur d’échelle [1]. Le nombre de flux qui peuvent bénéficier d’une réservation est
assez limité, en particulier dans les routeurs du coeur du réseau. Ces équipements doivent traiter
des milliers des flux simultanément, et le coût introduit par la gestion d’états et l’ordonnancement
par flux peut entraîner une réduction considérable de leurs performances.
La standardisation du modèle IntServ s’est pratiquement achevée en 1996. Pourtant, le
modèle n’a jamais été implanté à grande échelle dans le réseau. Les faiblesses énumérées
précédemment empêchent son déploiement. De nouvelles propositions cherchant à offrir des
garanties strictes dans le réseau sont actuellement à l’étude. Elles se basent sur une architecture
hybride IntServ-DiffServ.
III-2- La solution MPLS
Une solution qui connaît un certain succès auprès des opérateurs, aujourd'hui, est le
protocole MPLS. C’est un standard de réservation de circuits virtuels que devrait fonctionner sur
la plupart des équipements de niveau liaison (sans passer par IP et les tables de routage) [1]. Bien
que la réservation de circuits soit performante, elle n'est pour l'instant possible qu'à l'échelle d'un
domaine administratif et pour un nombre relativement faible de circuits. La généralisation de
MPLS et l'interconnexion de domaines MPLS sont des thèmes actifs aujourd'hui, qui offriront
certainement à terme, des solutions d'ingénierie de trafic.
L'impasse de la réservation de ressource à grande échelle a conduit l'IETF à travailler sur

une seconde architecture appelée DiffServ. Elle s'appuie sur la notion de priorité entre les paquets
et non sur la réservation de ressources dans les routeurs.
IV- Le modèle DiffServ

Les créateurs de l’IntServ observent plus attentivement les défauts de cette architecture et
cherchent à faire des modifications pour assurer sa pérennité. Pendant la même période, des
nouvelles propositions décrivent des mécanismes plus simples capables de satisfaire les besoins
de QoS d’un grand nombre d’applications. Ces propositions ont servi de base à la définition du
modèle DiffServ. Le groupe de travail de Diffserv s’est centré sur la définition d’un modèle

simple, modulaire, dont la mise en oeuvre peut s’effectuer d’une manière graduelle dans
l’Internet existant.
IV-1- Caractéristiques du modèle
Les modèles DiffServ et IntServ cherchent à résoudre les mêmes problèmes tels que le
traitement correct des flux multimédia et un meilleur contrôle dans la distribution de la bande
passante. Néanmoins, le modèle DiffServ s’attaque à ces contraintes d'une manière moins
ambitieuse mais plus résistante. Dans ce modèle, il est impossible d’offrir des garanties strictes
ou de réserver des ressources. Par contre, la simplicité d'implantation permet à cette nouvelle
architecture de se voir déployée progressivement dans certaines régions de l'Internet [8].
Une des faiblesses du modèle IntServ est sa non-résistance au facteur d’échelle
(évolutivité). Dans ce dernier, tous les équipements du réseau doivent garder un état par flux
réservé. Il suffit qu’un nœud dans la route n’implémente pas les fonctionnalités IntServ pour que
la QoS ne puisse plus être strictement garantie. Cependant, dans l’architecture DiffServ, la
priorité est donnée au regroupement des flux dont les besoins sont similaires (agrégation) et à la
définition des traitements nécessaires dans les routeurs pour que l'agrégat de ces flux soit traité
correctement.
Pour assurer la robustesse du modèle, la création d'états et la classification par flux sont
deux fonctionnalités réservées aux routeurs d’entrée au réseau. Dans ces équipements, le nombre
de flux à traiter est considérablement réduit. Dans le reste des routeurs, des opérations très
simples, ne demandant pas la création d’états, assurent le traitement différencié.
Une autre reproche faite au modèle IntServ est la complexité du protocole de signalisation
RSVP [1]. Une grande partie de la lourdeur du protocole est due à la gestion des flux multicast et
des routes symétriques. La réservation de ressources pour des flux exige la définition de règles
d’agrégation et désagrégation dans les noeuds intermédiaires. Dans DiffServ, ce problème n’a pas
été spécifiquement abordé car les connexions multi-point n’interfèrent pas avec les mécanismes
propres à l’architecture. Dans ce modèle, la seule signalisation requise est une étiquette contenue
dans l’en-tête de chaque paquet. Nous résumons dans le tableau ci dessous, les différences entre
ces deux approches :

IntServ DiffServ
Type de différenciation garantie absolue garantie statistique

Granularité de
micro - flux Agrégats
différenciation
Etats Par flux Par agrégat
Base de classification Plusieurs champs d’entête Un champ : DS
Signalisation Explicite Implicite dans le coeur
Réservation requise (RSVP) Non requise dans le coeur
Types routeurs Un type Deux types : bordure/cœur

Limitée par nombre de
Extensibilité Limitée par nombre de flux
classes
Tableau I-2 : Tableau comparatif des approches de QoS
IV-2- Architecture de DiffServ
L’idée consiste à diviser le réseau en domaines. Ainsi, on distingue à l’intérieur d’un

domaine des routeurs d’accès (Core router) et d’autres 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. Le modèle DiffServ est basé sur une
architecture qui permet des prises de décision complexe aux bords et donc moins de charge sur
les routeurs du backbone. En effet, les routeurs d’extrémités sont chargés de conditionner le trafic
entrant en indiquant explicitement sur le paquet le service qu’il doit subir. Ils examinent les
paquets, les classifient selon une politique spécifiée par l’administrateur de réseau, les marquent
et exécutent des fonctions de profilage. Ainsi, la complexité des routeurs ne dépend plus du
nombre de flux qui passent mais du nombre de classes de service. Ces dernières sont identifiées
par une valeur codée dans l'en-tête IP [8].
La figure ci dessous montre un exemple de configuration de réseau. Un site émetteur,
souhaite que ses flux bénéficient d’un traitement différencié dans le réseau. Il établit un contrat
de service avec son fournisseur. Ce contrat, appelé SLA (Service Level Agreement), contient la
nature du trafic que l’émetteur peut produire pour chaque service demandé. D’un coté, le

fournisseur s’engage à fournir la qualité demandée par l’émetteur. De son coté, l’émetteur est
conscient des limitations imposées par le contrat.
émetteur
ISP ISP
routeur de
frontière
Backbone (routeurs du coeur)
Fig I-3 : Architecture du modèle DiffServ
Le client peut effectuer un pré-marquage de ses flux avant de les transmettre au

fournisseur. Signaler une préférence en termes de classe de service ou indiquer l’importance
relative des paquets sont deux raisons qui justifient cette action. La priorité des paquets peut
varier au sein d’un flux. Par contre, les principes de DiffServ exigent que tous les paquets d’un
même flux appartiennent à une même classe de service afin d’éviter le déséquencement.
Le fournisseur connaît les spécifications techniques du contrat établi avec chacun de ses
clients. Quand le trafic produit par l’utilisateur arrive au routeur d’entrée du fournisseur, les flux
sont identifiés et leur comportement est vérifié en fonction du contrat respectif. En cas de non-
conformité, une action corrective est prise. Pour certains services, seuls les paquets conformes au
contrat peuvent entrer dans le réseau. Pour d’autres services, tous les paquets sont acceptés, mais
le routeur d’entrée modifie la priorité du paquet en fonction du niveau de conformité. En quittant
le routeur d’entrée, les paquets du site émetteur contiennent tous une étiquette reflétant la classe
de service souhaitée et le niveau de conformité du flux par rapport au contrat.
Les routeurs du coeur du réseau ne modifient pas les étiquettes. Ils se contentent de les
utiliser pour choisir la file d’attente où le paquet est inséré. Pour cet exemple, la file d’attente
représente la classe de service. Les ressources des routeurs sont distribuées entre les files en
fonction des services qu’ils supportent. Dans chaque file d’attente, un algorithme de rejet sélectif
est utilisé pour éliminer, en premier, les paquets de basse priorité en cas de congestion [9].

Cet exemple entre un site et un fournisseur d’accès peut s’appliquer également à deux
opérateurs. En général, les paquets doivent traverser plusieurs domaines administratifs avant
d’atteindre leur destination. Un accord est, donc, nécessaire entre domaines. Le fournisseur
d’accès a aussi des contraintes à respecter vis-à-vis de son opérateur. Le routeur d’entrée est
placé entre le réseau du fournisseur et celui de l’opérateur, réalisant des opérations similaires à
celles du routeur décrit précédemment. Par contre, les fonctions de contrôle de conformité ne
portent pas sur le trafic de chaque utilisateur, mais sur le trafic injecté par le fournisseur dans son
ensemble. Cette capacité d’agrégation assure la résistance du modèle au facteur d’échelle.
Les capacités des routeurs de sortie constituent une autre particularité de l’interconnexion
entre deux domaines. Un routeur de sortie est le dernier routeur traversé par un paquet avant de
quitter un domaine. Ces routeurs peuvent être chargés de traiter l’agrégat des flux quittant le
domaine afin de rendre le trafic conforme au contrat existant avec le prochain domaine. Pour
ceci, les flux appartenant à une classe de service peuvent être retardés, tandis que des paquets
d’une autre classe peuvent subir une modification dans leur niveau de priorité.
IV-2-1- Agrégation de flux
Une caractéristique de l'architecture DiffServ, qui lui permet d'être étendue à des réseaux,
est le fait que les routeurs de coeur ne considèrent pas les flux individuels. Les paquets IP ne sont
pas distingués au niveau fin du flux mais à un niveau plus grossier d'agrégats de flux. L'agrégat
d'appartenance d'un paquet est reconnu par un identifiant de classe enregistré dans le champ
DSCP (DiffServ Code Point). Cette étiquette est le champ qui identifie le traitement que le paquet
doit recevoir. Elle est codée sur 6 bits et fait parti des 8 bits codant le champ TOS d’IPv4 ou le
champ classe de trafic d’IPv6.
Version Longueur TO S: Type O f Service Longueur totale Suite de l’entête IP

(4bits) (4bits) (8bits) (16 bits)
D SC P CU
Fig I-4 : Le champ DSCP

En effet, les trois premiers bits de DSCP sont appelés Class Selector. Les codes DSCP de
type xxx000 (ou x est une variable binaire) correspondent aux classes de services principales.
Ceux-ci seront associés aux PHB (Per Hop Behviour) qui permettront le traitement différencié
des flux dans les routeurs intermédiaires. Plus la valeur de code point est élevée, plus le flux
correspondant sera prioritaire. Les deux derniers bits sont inutilisés [7].
Les agrégats sont en nombre réduit, fixé, bien inférieur au nombre de flux distincts qui
peuvent traverser un routeur. C'est le petit nombre de classes qui permet aux routeurs de coeur de
mettre en oeuvre un traitement différencié moins coûteux que celui des routeurs IntServ. Le
modèle DiffServ sépare le trafic par classes. Nous avons donc affaire à une granularité moins fine
mais qui devient en revanche plus évolutive. 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 ainsi que des
variables de classification et d'ordonnancement dans les routeurs à maintenir. Ceci a pour
conséquence une charge importante au niveau des routeurs qui deviennent alors de moins en
moins performants.
IV-2-2-Traitement par noeud ( Per Hop Behavior )
L'architecture consiste aussi en un ensemble de mécanismes simples au niveau de coeur

de réseau, agissant sur un nombre réduit de classes de service, dont la sémantique est définie non
pas de bout en bout mais par routeur (per-hop behavior). Les PHBs sont les mécanismes mis en
oeuvre dans le coeur de réseau, ceux qui pratiquent le traitement différencié entre les classes. Ils
sont définis par les constructeurs dans les routeurs en utilisant des mécanismes de gestion de files
d'attente (Round Robin, Weighted Fair Queuing,...) et de régulation de flux. En effet, deux
modèles ont été standardisés par l’IETF tels que PHB Expedited Forwarding (EF) et PHB
Assured Forwarding (AF).
IV-3- Le Traitement différencié de paquet dans le routeur DiffServ
Le routeur DiffServ agrège le flux en un ensemble de « Behaviour Aggregate » qui seront

acheminés de la même manière, ce qui assure une simplification des traitements et de stockage
dans le routeur. Ainsi, l’architecture DiffServ définit quatre types d’éléments qui constituent le
chemin emprunté par les flux lorsqu’ils passent par le routeur. Ces composants sont le
classificateur de trafic, les éléments d’actions, de mesures et les gestionnaires de file d’attente. La
tâche du classificateur de trafic est de sélectionner les flux correspondants à des critères comme

l’adresse IP et le numéro de port. Le marqueur, représentant un des éléments d’action, marque

ces flux par un code DSCP pour recevoir un traitement particulier de la part des routeurs DiffServ
à l’intérieur du réseau. La figure ci-dessous illustre les différents blocs fonctionnels du routeur
DiffServ qui seront détaillés dans la suite.
Composants du routeur de
frontière
Verificateur
Classificateur Shape - Composants du

Marqueur Ordonnanceur
selon l’entête IP Drop routeur de coeur
rejeté
Mise en profil Classificateur Ordonnanceur
EF
selon l’entête IP
Les jetons arrivent
à un taux constant
EF
Taille max AF1

du seau
AF2
Trafic entrant Trafic mis en profil

Taux Max = Taux des jetons
Rejet et Mise en profil a l’aide Rejeté si aucun jetons
du seau à jetons
dans le seau
Fig I-5 : Les Composants QoS d'un routeur IP DiffServ
Les différents éléments présentés dans la figure (I-5) peuvent être facilement contrôlés par
un modèle à base de politiques. La configuration des ces éléments DiffServ reflète le SLA
(Service Level Agreement) entre le fournisseur de service et l’utilisateur. Il pouvait exister une
entité de gestion du domaine DiffServ qui représente un outil d’administration capable de fournir
la configuration adéquate aux routeurs.
Chaque équipement frontière met en oeuvre les mécanismes de classification, de
conditionnement et d’ordonnancement des trafics. L’ampleur de conditionnement de trafic exigée

est indépendante des détails des offres de service et peut s’étendre du simple marquage aux
opérations complexes de lissage et « policing ». Les routeurs à l'intérieur d'un domaine, quant à
eux, se consacrent exclusivement au traitement des paquets en utilisant le marquage spécifié par
les nœuds de bord.
IV-3-1- La classification de trafic
Le classificateur au niveau de routeur DiffServ traite un flux en entrée et génère N flux en

sortie séparés logiquement. La séparation en des classes de flux est réalisée par des filtres. En
effet, il s’agit de choisir des paquets dans un flot de trafic basé sur le contenu d’une certaine
partie de l’entête du paquet. Généralement, on distingue deux types de classificateur. Le premier,
appelé BA (Agrégat de comportement), utilise comme clé de classification le « code point » et le
deuxième, appelé MF (Multi Field), sélectionne les paquets en se basant sur la valeur d’une
combinaison d’une ou plusieurs zones d’entête, telles que l’adresse source, l’adresse destination,
le champ DS, l’identification du protocole, les numéros de port source et destination…etc. Ainsi,
le filtre consiste à un ensemble de conditions sur les valeurs composantes les clés de la
classification du paquet [12].
Dans l’architecture DiffServ, lors d’une arrivée de flot non classifié au niveau de « Edge
Router », les filtres sont utilisés pour sélectionner les paquets IP en fonction des informations
contenues dans l’entête IP. Une fois les paquets sont filtrés, ils sont mis dans des classes
indépendantes et peuvent être contrôlés d’une manière indépendante. Chaque agrégat possède son
propre gestionnaire de file d’attente. Ainsi, le routeur arrive à faire du traitement différencié. Le
modèle DiffServ introduit trois PHB ou classes de services définies comme suit :
1. Expedited Forwarding (EF) ou Premium Service (RFC 2598) : cette classe correspond
à la valeur « 101110 » de DSCP. Son objectif est de fournir un service de transfert
équivalent à une ligne virtuelle dédiée à travers le réseau d’un opérateur. Les paquets
excédentaires sont lissés ou rejetés à l’entrée pour toujours rester conforme au contrat
SLA. De plus, les flux ne doivent avoir que très peu de perte, la gigue doit être
minimale et la bande passante garantie. On utilise couramment cette classe pour le
transport de données temps réel tel que la voix ou la visioconférence [11].
2. Assured Forwarding (AF) (RFC 2597) : Il s'agit du second modèle de service
standardisé par l'IETF qui représente N classes de services et M niveaux de taux de
perte dans chaque classe. Il regroupe plusieurs PHB garantissant un acheminement de

paquets IP avec une haute probabilité sans tenir compte des délais. Cette famille de
PHB, scindée en quatre classes, soutient un partage plus flexible et plus dynamique des
ressources de réseau en maintenant des garanties fines de bande passante, un délai
minimum et de pertes appropriées pour le trafic à flot. Chaque classe AF supporte un
mécanisme permet de gérer les flux qui dépassent la capacité souscrite. Ceci est réalisé
grâce à trois niveaux de priorités (Drop Precedence) définis dans une classe AF et
différenciés par un algorithme de rejet sélectif. 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
SLA. Ainsi le service peut offrir une meilleure différenciation (classe et priorité), il ne
demande pas une coordination entre domaines. Cependant la qualité offerte dépend
énormément du niveau d’agrégation et de la présence de flux concurrents [10].
Classe AF1 Classe AF2 Classe AF3 Classe AF4

Low Drop Prec 001010 010010 011010 100010
Medium Drop Prec 001100 010100 011100 100100
High Drop Prec 001110 010110 011110 100110
Tableau I-3: La valeur du champ DSCP pour les différentes classes AF
3. Best Effort (priorité basse) : représente le PHB par défaut et dont le DSCP vaut
« 000000 ». 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 [1].
La figure ci dessous (I-6) illustre la procédure de classification. On distingue une
topologie de réseau qui se compose de trois sources : la première envoie un trafic CBR (Constant
Bit Rate) à 64 Kbit/S modélisant la voix, la deuxième génère un flux continu modélisant le trafic
AF1 et la dernière représente un trafic web. Le rôle de classificateur consiste, alors, à lier un flux
particulier et ses paramètres et l’assigner à une classe de service tout en traitant le champ
« Differentiated Service » DS. Ainsi, trois comportements sont distingués dans le routeur. Le
trafic voix est placé dans la file de haute priorité (EF), le flux web est classé dans une file AF et
le trafic provenant d’un serveur de base de donnée, par exemple, aura la priorité la plus faible.

La classification
EF
1 2 3
4 5 6
7 8 9
* 8 # DSCP Class1
IP Phone BA AF
/
DSCP class2
WWW Server
MF
BE
Data DSCP class3
Fig I-6: La fonction de classification
IV-3-2- Le conditionnement de trafic
Le conditionneur de trafic peut contenir un ensemble d’ éléments tels que le vérificateur,

le marqueur, le « shaper » et le « dropper ». En effet, une fois un flot de trafic est choisi par un
classificateur, il le dirige vers un module de conditionnement spécifié pour continuer le processus
de traitement. Un conditionneur de trafic peut ne pas contenir nécessairement chacun des quatre
éléments tels que le cas où aucun profil de traitement n’est présent (les paquets peuvent
seulement passer par un classificateur et un marqueur).
A- Le vérificateur
Les vérificateurs du trafic mesurent les propriétés temporelles de flux de paquet
sélectionné par le classificateur contre un profil spécifié dans le TCA (Traffic Condition
Agreement). Il passe l’information d’état à d’autres fonctions de traitement pour déclencher une
action particulière pour chaque paquet qui est hors profil ou non. 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é. Le « meter » est
paramétré par un profil temporel et des niveaux de conformité. Chaque niveau est associé à une
sortie. En DiffServ, par exemple dans la classe AF, trois niveaux de conformités sont discutés en
terme de couleurs. Ces niveaux seront utilisés pour déclencher différents traitements dans la file,
de même pour le module de marquage et de rejet. Pour un service EF, un trafic jugé non-
conforme par le « meter » est dirigé vers le module de rejet [12].

SLA C la s s 1
T r a ff ic D e s c r ip t o r (
C la s s 2
V o lu m e + tr a it e m e n t)
C la s s 3
F lu x A F
M e te r F lu x E F c o n fo r m e M a rk e r
F lu x E F n o n
c o n fo rm e
D ro p p e r
Fig I-7 : Le principe de la vérification
B- le « Shaper » et le « Dropper »
Suite à la vérification de la conformité vis-à-vis d’un profil, le lissage peut s’effectuer
lorsque les flux d’une classe dépassent le contrat SLA prédéfini. Cette fonctionnalité n’est pas
systématique et correspond à une règle de « policing » explicite dans le SLA. Les paquets sont
alors mis en file d’attente afin d’être transmis un peu plus tard lorsque le débit de la classe sera
considéré comme étant dans le profil du contrat. Le rejet des paquets intervient pour garantir le
débit fixé pour chaque classe de service. Dans le cadre d’un lissage, pour les files d’attente ayant
une taille finie, des dépassements de profil trop importants peuvent aussi provoquer un rejet des
paquets. Ainsi le régulateur de trafic assure principalement deux fonctions :
¾ Mise en forme du trafic (Traffic Shaping) : implantée généralement auprès des sources de
trafic. Cette fonction permet de lisser le flux généré à l’entrée du réseau pour être
conforme à une spécification particulière. Elle permet de contraindre le trafic pour le
rendre conforme à sa spécification connue par le réseau.
¾ La surveillance du trafic (Traffic Policing) : Implantée dans les dispositifs du réseau, cette
fonction permet de vérifier la conformité du trafic à son contrat, c'est-à-dire à sa
caractérisation déclarée lors de sa négociation avec le réseau en phase du contrôle
d’admission [12].
La différence entre ces deux fonctions réside dans leurs actions vis-à-vis d’un paquet non
conforme. Dans ce cas, la fonction de mise en forme du trafic retarde le paquet jusqu’à ce qu’il
soit conforme. Cependant, le traitement d’un tel paquet dans la fonction de surveillance du trafic
dépend de la politique adoptée. En effet, lors de l’arrivée d’un paquet non conforme, l’algorithme

de surveillance de trafic peut décider de retarder le paquet jusqu’à ce qu’il soit conforme, de
l’éliminer entièrement ou de décrémenter sa priorité avant de le transmettre. Les mécanismes de
régulation de trafic permettent d’imposer une forme spécifique au flux régulé. Théoriquement,
cette forme est exprimée par une fonction quelconque qui limite le nombre cumulatif d’arrivées
de paquets, appelée courbe d’arrivée, dans n’importe quel intervalle de temps. En pratique, cette
fonction est typiquement linéaire pour des raisons de simplicité d’implémentation. Il existe deux
modèles de courbes d’arrivée linéaires [2]:
¾ Le modèle de débit crête permet de limiter le débit maximal d’une source de trafic à un
débit crête. Il est caractérisé par la taille de paquet maximal noté M et le temps d’inter-
arrivée minimal entre deux paquets consécutifs notés Tmin. Ainsi, le débit crête
qu’autorise le régulateur de trafic est P = M / Tmin.
¾ Le modèle à débit moyen permet de limiter le débit moyen d’une source de trafic. Ce
régulateur est caractérisé par deux paramètres : la taille de la rafale permise notée b et le
débit moyen noté r.
Ces formes de trafic linéaires sont généralement obtenues par des régulateurs appelés seau
à jetons (Token Bucket) et seau percé (Leaky Bucket). Le régulateur du seau à jetons [13] dispose
d’un seau de jetons de taille b qui sont générés au rythme constant de r jetons par seconde.
Chaque paquet qui arrive consomme un nombre de jetons proportionnel à sa taille. S’il n’y a pas
assez de jetons dans le seau, le paquet sera mis en attente dans la file jusqu’à avoir le nombre
nécessaire de jetons, sinon il sera transmis. Le régulateur du seau percé dispose d’un seau de
taille b initialement vide. A chaque arrivée d’un paquet le seau est rempli avec une quantité de
fluide égale à la taille du paquet. Le seau percé est vidé du fluide au rythme constant r. Si la
quantité de fluide ajoutée lors de l’arrivée fait déborder le seau, alors le paquet est rejeté par le
régulateur. Dans le cas contraire, le paquet est transmis vers le réseau. La figure suivante illustre
les deux mécanismes du seau à jetons et du seau percé.

Paquets
arrivés r Paquets
Jetons arrivés
b b
r Vers le réseau r
Régulateur du seau percé Régulateur du seau à jetons
Fig I-8 : Les mécanismes de régulation de trafic : le seau percé et le seau à jetons
C- Le marqueur
Le marquage fait référence à la mise à jour de la valeur du champ DS dans l’en-tête IP. En
effet, les informations fournies en entrée par le vérificateur et le classificateur permettront de
faire un choix sur la priorité à appliquer à chaque flux. Le bloc de marquage par exemple peut
décider qu’en cas de dépassement du contrat, les flux excédentaires seront marqués avec une
priorité moindre. Les marqueurs placent dans la zone DS d’un paquet un code point particulier de
comportement DS. Donc, c’est dans ce module que sera affecté le champ DSCP. Ce traitement
est basé actuellement sur deux token buckets. Le principe se résume comme suit [12] :
¾ Si le trafic est conforme aux deux, les paquets sont marqués en vert,
¾ Si le trafic n’est conforme qu’un des deux, les paquets seront marqués en orangé.
¾ Si le trafic n’est conforme à aucun alors les paquets seront marqués en rouge et ils auront
une probabilité de rejet plus importante que les autres.
DSCP Class1 DSCP class2
Marker DSCP class2
DSCP class2
Fig I-9 : La fonction de marquage

IV-3-3- L’ordonnancement de trafic
Une fois les paquets sont marqués et placés dans différentes files d’attente selon la valeur
de la classe de service identifiée dans l’en-tête IP, ils seront servis par un ordonnanceur. Ce
dernier utilise des algorithmes et des disciplines d’ordonnancement qui permettent de contrôler la
distribution de ressources. Plusieurs types de comportements d’ordonnancement et de politiques
de rejets peuvent être employés pour fournir le PHB adéquat.
Les mécanismes d’ordonnancement permettent d’assurer le partage des ressources selon
une politique de service spécifique à la nature de garantie à fournir aux applications en
concurrence d’accès aux ressources. Plusieurs algorithmes d’ordonnancement ont été proposés
pour satisfaire les exigences des applications temps-réel et fournir un service plus sophistiqué que
l’ordonnancement FIFO. Ce dernier ne présente aucune garantie particulière à une application
vis-à-vis d’une autre. Diverses classifications, présentées, dans la figure ci- dessous, peuvent être
appliquées à ces algorithmes pour caractériser leurs comportements [2]:
Algorithme
d’ordonnancement
Statique Dynamique
Priorité fixe
Guidé par Ordre Guidé par le contrôle de
l’echéance d’arrivée la bande passante
EDF DBP FiFo WFQ RR
Fig I-10 : Classification de l’ordonnancement
Dans un algorithme d’ordonnancement statique, les priorités des applications sont fixes et
invariantes au cours du temps. Un message moins prioritaire n’est servi que si tous les messages
plus prioritaires en attente sont tous servis. Dans un algorithme d’ordonnancement dynamique, la
priorité des messages est recalculée, chaque fois qu’un nouveau paquet arrive, suivant une règle
spécifique à l’ordonnancement. Par exemple, l’algorithme Earliest Deadline First (EDF) cherche
à chaque tour de sélection le client ayant l’échéance la plus proche parmi tous les clients en
attente. En ce qui concerne la catégorie d’ordonnancement guidé par le contrôle de bande

passante, elle permet de partager dynamiquement des ressources en respectant le critère de la

bande passante. L’algorithme EDF est l’algorithme le plus connu dans les réseaux industriels.
Dans les réseaux à commutation de paquets, l’ordonnancement guidé par le contrôle de bande
passante est le plus utilisé pour assurer un partage équitable des ressources. Nous retrouvons
principalement les algorithmes Round Robin, WFQ et toutes leurs variantes.
Le choix d’un algorithme d’ordonnancement adéquat a un impact très important pour la
fourniture de la QoS des applications temps-réel. Dans les réseaux à commutation de paquets, la
technique classique pour privilégier le service d’une application sous contraintes temporelles, par
rapport à une autre application moins contraignante, est de lui affecter une priorité plus élevée et
d’ordonnancer les flux en concurrence d’accès au médium de transmission selon leurs priorités.
C’est l’ordonnancement à priorité fixe. Bien que cette technique reste efficace pour améliorer la
QoS temporelle des flux prioritaires, elle pourrait être coûteuse pour les flux moins prioritaires.
En effet, dans le cas où il n’existerait pas de mécanismes de contrôle d’admission pour contrôler
l’accès de nouveau flux de priorités élevées, le problème de famine serait inévitable pour les flux
moins prioritaires dans le cas où les flux de priorité consommeraient la quasi-totalité des
ressources. En plus, un flux plus prioritaire malveillant pourrait affecter sérieusement le délai et
la gigue exercée par les autres flux moins prioritaires partageant les mêmes ressources d’accès au
médium de transmission.
Pour éviter ces problèmes, la tendance actuelle de l’ordonnancement des applications
temps-réel dans les réseaux à commutation de paquets consiste à réserver les ressources
nécessaires en terme de bande passante par le biais des algorithmes à partage de bande passante
Round Robin, WFQ. Ce dernier est détaillé dans le chapitre suivant.
V- Intégration avec d’autres services

V-1- Intégration IntServ/DiffServ
Des travaux sont menés au sein de l’IETF pour faire coexister les architectures IntServ et
DiffServ dans l’Internet. Il semble assez naturel que l’approche IntServ soit utilisée dans les
réseaux d’entreprise ou les réseaux de petite taille, alors que DiffServ sera utilisé pour les réseaux
de transit ou les coeurs de réseaux importants. Nous aboutissons, donc, vers un scénario où la
visibilité de l’utilisateur est IntServ, alors que le système de communication utilise DiffServ,
rendant ainsi IntServ client de DiffServ. L’intégration de ces deux mécanismes est en cours d’étude.

Plusieurs propositions ont été soumises. La première solution consiste à réaliser l’intégration de
service que dans les sites terminaux. Le coeur 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 un élément de réseau et le caractériser pour permettre de construire un service garanti [1].
V-2- Intégration MPLS/DiffServ
MPLS permet de simplifier l’administration d’un coeur 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. 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 mécanisme permet d’éviter le calcul complexe de routage classique et doter le monde
IP d’un mode connecté. Cette étiquette est attribuée en fonction de la classe de service à 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. L’étiquette décide donc dans chaque
prochain routeur, du comportement DiffServ et de l’utilisation éventuelle des ressources
réservées. Ainsi la mise en correspondance va consister à associer à chaque classe Diffserv un
LSP-MPLS distinct doté de QoS équivalente. Ceci peut être possible en utilisant le champ
expérimental de l’entête MPLS pour stocker la valeur de Drop Precedence [6].
La solution MPLS Le modèle Diffserv
Type de services Une connexion virtuelle (LSP) Service sans connexion
Routage Basé sur les labels. Routage classique (entête IP)
Réservation des
Protocoles RSVP et CR-LDP Au niveau de DSCP
ressources
Plusieurs contrats (plusieurs
QoS SLA établi avec l’émetteur
labels)
Tableau I-4: Tableau comparatif entre MPLS et DiffServ

VI- Conclusion
Ce chapitre avait pour objectif de présenter les différents mécanismes utilisés par DiffServ
permettant l’amélioration des performances des applications. En effet, ce modèle se base sur la
séparation du trafic en différentes classes assurant ainsi un traitement préférentiel à un ensemble
de flux regroupant des caractéristiques communes. De telles notions seront utiles dans la suite qui
s’intéressera à l’évaluation des performances du modèle DiffServ et la présentation du principe
de la régulation dans les systèmes asservis.

Chapitre II
Evaluation des performances de DiffServ
I- Introduction
L’architecture DiffServ, comme la présente le chapitre précédant, est une solution
avantageuse, classifie les paquets dans un nombre restreint de classes agrégées de service.
L’objectif principal de ce chapitre est de valider l’apport d’un tel modèle garantissant la
QoS. Ainsi il sera question d’un ensemble de scénarios simulés avec le simulateur NS (Network
Simulator). Ceci permet de dresser les différentes fonctionnalités et mécanismes utilisés pour
offrir une QoS de bout en bout. Une première étape des travaux aura pour objet d’illustrer les
processus essentiels d’une mise en place d’un algorithme de gestion de QoS. La deuxième étape
s’intéressera à l’apport de la discipline WFQ (weight Fair queuing ) dans DiffServ et la gestion
des priorités entre les différentes classes de services. Dans une dernière étape, nous introduisons
la régulation dans les systèmes asservis.
II- Présentation
II-1- Implémentation de Diffserv dans NS
Le module DiffServ de NS permet la simulation d’une architecture de QoS basée sur le

marquage des paquets selon des priorités définies par les besoins de l’utilisateur. Ainsi, lors d’une
congestion, les paquets les moins prioritaires seront rejetés. Cette répartition du trafic est réalisée
en quatre catégories associées à chacune un identificateur «un code point» et trois sous priorités
appelées « precedence » correspondantes à trois files virtuelles. Les paquets d’une seule classe de
trafic sont servis par une file d’attente «RED» physique qui contient trois files virtuelles. La
figure ci-dessous illustre cette configuration.

Quatre files physiques
Trois files virtuelles

dans une file physique
Fig II-1 : Configuration des files RED dans DiffServ
Ce module implémente aussi trois composants principaux répondant aux besoins de

modèle DiffServ tels que :
¾ « Policy » : permet le traitement des flux selon les agrégations des trafics entre la source
et la destination pour le maintient d’un niveau de service.
¾ « Edge Router »: marque les paquets selon la politique spécifiée.
¾ « Core Router » : examine les «code point» à travers la table PHB et traite les paquets en
question en les dirigent vers la file d’attente physique et virtuelle correspondante.
Dans, ce module la complexité réside aux nœuds d’extrémités. Le composant « policy »
n’est défini que lors de la spécification du type de « policier », « le meter » et le « code point ».
Pour nos simulations, nous avons opté pour un modèle de policier « TokenBucket » qui emploie
deux paramètres qui sont le CIR (Committed Information Rate) et le CBS (Comitted Burst Size).
Donc un paquet sera marqué avec la priorité minimale s’il est plus large que le sot « Bucket ».
Une fois, les files d’attentes « dsRED/Core » et « dsRED/Edge » sont définies, il faut distinguer
les flux et les relier avec leurs sources et destinations selon un « Policier Table » et un « PHB
Table » [15].
II-2- Description de scénario choisi
Compte tenu des particularités de l’architecture de DiffServ, notre topologie choisie, met
en œuvre 9 nœuds. On distingue trois sources (S1, S2, S3), trois destinations (D1, D2, D3), deux
routeurs d’extrémités (E1, E2) et un routeur intermédiaire (Core). Les liens entre les sources et le
nœud d’extrémité (E1) sont de types fullduplex et de capacités égales à 6Mbit/s, de même pour

les destinations et le nœud E2. Nous avons choisi une liaison de type simplex entre le routeur
intermédiaire et le nœud E1 de capacité égale à 3Mbit/s alors que celle entre le core et E2, sa
capacité vaut 2Mbits/s. Ceci est dans le but de créer la concurrence entre les flux pour le paratge
de la bande passante. La topologie de la simulation est présentée par la figure ci dessous :
S0 D6
Edge Router Edge Router
E1 E2
S1 3 4 5 D7
Core Router
S2 D8
Fig II-2 : Topologie de la simulation
Comme scénario de simulation, nous générons trois types de trafic des nœuds sources (S1,
S2, S3) respectivement vers les trois destinations (D1, D2, D3). Ces sources de trafic sont
respectivement de type audio, vidéo et données. Chaque flux sera marqué par un code point
(DSCP) particulier conformément aux mécanismes de DiffServ. En effet, un flux ayant un code
point à la valeur initiale « 10 » peut être remarqué par la valeur « 11 » s’il est hors profil et qui
doit lui aussi être traité en l’insérant dans la deuxième file d’attente virtuelle. Chaque file admet
comme paramètres le nombre minimal et maximal de paquets à traiter et une probabilité de rejet
(dans notre simulation nous avons opté pour un traitement de 20 à 40 paquets avec une
probabilité de rejet 0.02). Pour le deuxième bout de la liaison, nous avons refait les mêmes
définitions et configurations pour s’assurer que le traitement des paquets est presque identique au
niveau de deux routeurs d’extrémité.
Les flux générés par les nœuds de la topologie sont de type CBR/UDP. Nous avons choisi
comme « puit » un agent attaché à la destination. Nous résumons nos choix dans le tableau
suivant :

Taille de
Débit CBS Initial OP-
Trafic Type paquet CIR Priorité Source Destination
(Kbit/s) (octets) CP CP
(octets)
Audio CBR 1000 1000 400k 80000 10 11 Haute 0 6
Vidéo CBR 1000 800 400k 80000 20 21 Moyenne 1 7
Données CBR 1000 500 400k 80000 30 31 Faible 2 8
Tableau II-1: Caractéristiques des flux
III- L’apport de l’ordonnanceur WFQ pour DiffServ

Avec l’émergence des applications temps-réel, le modèle Best-Effort s’est montré
incapable d’offrir un service répondant aux différents besoins des flux en compétition. En effet,
un mauvais comportement d’une source de trafic aura un effet négatif sur tous les autres flux. De
plus, les fluctuations du réseau en cas de surcharge pourraient dégrader sévèrement le niveau de
service offert aux différents flux. D’où l’intérêt des disciplines de service à partage de bande
passante qui sont généralement utilisées pour :
¾ Le contrôle de congestion par partage équitable des ressources entre tous les flux.
¾ Fournir des garanties en terme de bande passante et par conséquent en terme de délai.
III-1- La discipline Fair Queuing
La discipline de service « à partage équitable » (Fair Queueing) représente le travail

initiateur pour le développement des techniques d’ordonnancement à partage équitable de bande
passante. L’objectif est de fournir équitablement le même taux de service aux différents flux
partageant les ressources.
Dans la discipline FQ, les paquets sont classés par flux par le système et insérés dans une
file d’attente particulièrement dédiée à chaque flux. Les flux sont servis en tourniquet (Round
Robin) paquet par paquet comme est présenté dans la figure II-3. Les files d’attente vides sont
sautées par l’ordonnanceur et revisitées au tour suivant.

Classificateur Round
Robin
Fig II-3 : La discipline de service Round Robin
La discipline de service FQ n’est pas destinée à servir des flux ayant des besoins
différents en terme de bande passante. Son objectif se limite à fournir la même portion de la
bande passante à tous les flux. Aussi, la garantie équitable du même taux de bande passante à
tous les flux n’est possible que lorsque tous les paquets aient la même taille. En effet, les flux de
paquets de large taille auront plus de bande passante que les flux de taille de paquets plus petite.
De plus, cette discipline est sensible à l’ordre d’arrivée des paquets. En effet, si un paquet arrive à
une file d’attente vide immédiatement après avoir été visitée par l’ordonnanceur, alors ce paquet
doit attendre la fin de service de tous les paquets des autres files d’attente avant d’être transmis
[19].
III-2- La discipline Weighted Fair Queuing
Pour résoudre les problèmes du FQ, un service en tourniquet bit-à-bit a été proposé. C’est
un modèle théorique, pour le partage équitable de la bande passante. De plus, la notion du poids a
été introduite pour pondérer le service proportionnellement à la bande passante exigée par le flux.
Cette proposition est appelée Weighted Fair Queueing (WFQ). Cette discipline de service est
connue aussi sous le nom de GPS (Generalized Processor Sharing) et PGPS qui est la version
«paquet» de GPS et qui correspond exactement à WFQ définie par Parekh [16].
III-2-1- La discipline de service fluide GPS
La discipline de service GPS (Generalized Processor Sharing) est un modèle théorique de

multiplexage de flux qui se charge de transmettre les paquets bit par bit en fonction de leurs
poids. La figure II-4 montre le déroulement de la discipline de service GPS.

P11 P12 P13 P14

P1= 0.5
Flux1
P21 P22
P2= 0.25
Flux2 GPS
P31 P32
Flux3
P3= 0.25
Pij : j ème paquet de i ème flux

Pi = Taux de service du i ème flux
Fig II-4 : La discipline de service GPS
Plus formellement, un serveur GPS est caractérisé par les taux de service affectés,
{ φ1.....φN }, à chacun des N flux actifs. Un flux est dit actif dans l’intervalle de temps [t1, t2], si la
file d’attente de ce flux est toujours pleine durant cet intervalle. Le serveur opère à capacité fixée
C.
Notons par Wi (t1, t2) la quantité de service reçue par le flux «i» dans l’intervalle de
temps [t1, t2]. Le serveur GPS est défini tel que :
Wi (t 1 ,t 2 ) φ i
≥ , j =1,2,...,N
W j (t 1 ,t 2 ) φ j (1)
pour tous les flux actifs «i» ayant des paquets en attente et sur tout intervalle [t1, t2]. Ainsi, en
faisant une somme sur j = 1…N pour une valeur de « i » fixée, on obtient:
φi (2)
Wi (t1,t 2) ≥ ∗C(t1,t 2)
∑ φj
j=1...N
Par conséquent, la bande passante garantie au ieme flux est :
φi
ri = ∗C (3)
∑ φj
j =1...N
Avec ∑ φ j =1 . Ainsi, le flux actif reçoit un service minimum égal à ri tant qu’il a des paquets
j =1...N
en attente de service.
GPS est une discipline fluide non implantable en réalité qui suppose que le serveur peut
servir simultanément plusieurs flux. Dans un système réaliste qui considère des paquets, un seul

flux peut être servi à un instant donné et un paquet doit être servi entièrement avant qu’un autre
paquet puisse l’être. Il existe plusieurs techniques qui permettent d’émuler la discipline GPS.
L’algorithme WFQ (ou PGPS) est la version « paquet » la plus répandue.
III-2-2- La discipline de service PGPS ou WFQ
Le système WFQ est une émulation du système GPS proposé par Parekh et Gallager [16].
Ce serveur consiste à servir les paquets dans l’ordre croissant de leurs instants de fin de service
dans le système GPS correspondant. Ces instants sont appelés date virtuelle de fin de service.
Le processus d’ordonnancement de WFQ consiste à calculer la date virtuelle de fin de
service de chaque paquet pour émuler le système GPS. La date virtuelle de fin de service
correspond à l’instant de fin d’émission dans le modèle fluide. L’instant de départ du serveur
GPS est défini par [19] :
Fi k = max { Fi k −1 ,V (t ik ) }+ Li
k
(4)
φi
Avec :
- Fik : La date virtuelle de fin de service du keme paquet du ieme flux,
- V (t ik ) : La date virtuelle d’arrivée du keme paquet du ieme flux,
- t ik : La date réelle d’arrivée du keme paquet du ieme flux,
- max{ Fik −1 , V (t ik ) } : représente la date virtuelle du début de service keme paquet.

Cette opération assure que le paquet ne commence pas son service avant que le paquet
précédent du même flux n’ait terminé son service. La date virtuelle de fin de service Fik est
marquée dans le paquet. Ensuite, le serveur WFQ ordonnance les paquets dans l’ordre croissant
de ces estampilles temporelles.
III-2-3- WFQ et la garantie de délai pour un trafic (σ, ρ) borné
Un flux temps-réel est généralement représenté par sa contrainte de rafale (σ, ρ) où σ

représente la taille maximale de rafale du flux et ρ représente son débit moyen. Un tel flux est dit
(σ, ρ)-borné et par conséquent le nombre des paquets arrivés (ou bits) pendant la durée ∆t est
bornée par la fonction linéaire σ+ρ*∆t. Formellement, un flux ayant la fonction d’arrivée
cumulative est dite (σ, ρ)-borné si et seulement si :

R (t )− R (s ) ≤ σ + ρ (t − s ) (5)
La fonction d’arrivée cumulative du flux R (t ) est alors limitée par la courbe d’arrivée
supérieure σ + ρ (t − s ) . Dans le formalisme du Network Calculus, la garantie de la bande passante
assurée par WFQ se traduit par une courbe de service de la forme βR ,T (t ) = R (t −T ) où R est la
bande passante réservée et T représente la latence maximale du service. Cette courbe, présentée
dans la figure ci dessous, est appelée courbe de service débit-latence (Rate-Latency Service
Curve). Généralement, Lmax dénote la latence introduite pour transmettre le paquet de plus grande
C
taille, où Lmax représente la taille maximale du paquet parmi tous les paquets servis par WFQ et C
étant la capacité du serveur.
A r r iv é e s ( b its )
D W FQ
T e m p (s e c )
T = L m ax/C
Fig II-5 : Délai maximal garanti par WFQ
Par conséquent, le délai garanti par WFQ à un flux ayant une courbe d’arrivée
α (t ) = σ + ρ t est la distance horizontale maximale entre la courbe d’arrivée et la courbe de service.
Formellement, la borne maximale sur le délai garanti par WFQ est [20] :
D max = σ + L max (6)
R C
Notons que le délai augmente linéairement avec la taille de la rafale du flux et diminue en
augmentant le taux de bande passante réservée. Par conséquent, lors de l’arrivée d’une rafale de
taille importante, les paquets du flux peuvent rater leurs échéances requises et la qualité de
service peut être sévèrement dégradée. Nous remarquons que l’équation (6) ne tient compte
d’aucune contrainte temporelle. Elle dépend uniquement du taux de partage de bande passante et
de la taille de rafale.

IV- Résultats et Interprétations

La simulation de la topologie, décrit précédemment, met en évidence le bon
fonctionnement du composant policy et l’attribution adéquate aux codes point (CP) initiaux
relatifs et aux nœuds sources et destinations. Nous illustrons dans la figure II-6 l’état du « Policy
Table » et « policier Table » pour notre simulation :
Fig II-6 : Extrait de « Policy Table » et « Policer Table »
Les statistiques relatives à la file d’attente située entre le « core router » sortant et le
deuxième « edge router » menant à la destination sont définies selon différents paramètres
présentés dans la figure II-7. Cette dernière représente le total des paquets envoyés ainsi que ceux
rejetés suite à une saturation dans la file RED ou une congestion dans le réseau.
Fig II-7 : Les statiques de traitement des paquets
IV-1- L’équité de la bande passante
Après l’étude de l’ordonnanceur WFQ et ses avantages, nous optons au choix de ce

serveur lors de la configuration de notre topologie. En effet, ce mécanisme d’ordonnancement
n’est pas implémenté dans NS. Pour cela, il fallait faire des modifications au niveau de ce
simulateur. En conséquence, pour assurer le bon fonctionnement de WFQ, nous avons

implémenté des nouvelles bibliothèques et modules qui prennent en compte le principe de

fonctionnement de WFQ décrit dans le paragraphe précédent [17].
L’introduction de WFQ au niveau de notre script se réalise avec la commande «$set
SchedulerMode WFQ » en spécifiant les poids pour chaque file physique. Pour notre scénario, la
file modélisant le flux audio est la plus prioritaire, nous l’affectons un taux de service, P1, égal à
52%, le flux vidéo aura un coefficient de pondération, P2, égal à 38% et la file la moins prioritaire
représentant les données a un coefficient, P3, égal à 10%. Ainsi pour notre évaluation de
DiffServ, nous nous intéressons dans cette section à un paramètre de qualité de service si
important qui est la bande passante. Pour cela, dans un premier temps, nous avons activé nos trois
sources générant leurs trafics selon les caractéristiques définis dans le tableau II-1. Ils
commencent la transmission à l’instant t= 0 (s) et finissent à t= 50 (s). Pendant ce temps de
simulation, nous avons mesuré la bande passante réservée pour chaque flux en présence de
l’ordonnanceur WFQ. La figure ci-dessous illustre la répartition de cette ressource.
Fig II-8 : Partage de la bande passante (1)
En effet, d’après la figure II-8, nous remarquons bien que le partage de la capacité de lien
entre les différents flux est proportionnel aux poids attribués à la file. En fait, en appliquant les
coefficients de pondération et suivant l’équation (3), nous vérifions la conformité des résultats.
En conséquence, le flux le plus prioritaire, le trafic audio, normalement aura besoin d’une bande

de l’ordre de 1 Mbit/s notée BPaudio. L’excès de réservation, associé à ce flux, sera partagé entre
les autres flux. En conséquence, la bande réservée au flux vidéo, égale à (C- BPaudio )*P2 /( P2+
P3)) est proche de 790kbit/s alors que celle de données a pour valeur 210kbit/s.
Ainsi, nous remarquons, que grâce ces taux de service, nous avons favorisé le flux audio
en lui assignant la bande passante dont il a besoin. Aussi, les mêmes résultats sont obtenus
lorsque la source de données génère un flux selon le modèle de trafic On/Off. Les périodes
d’activité On et de silence Off sont exponentiellement distribuées avec les moyennes
1/µOn =500 ms et 1/ µOff =500 ms . La figure-ci dessous illustre le partage de 2Mbit/s entre les trois
flux.
Fig II-9 : Partage de la bande passante ( Trafic On/Off)
Une autre simulation a été établie pour mettre en évidence la gestion efficace de la bande
passante par l’ordonnanceur WFQ. En effet, Nous avons arrêté la transmission de flux audio à
t=30 (s) puis nous l’avons réactivé à t= 50 (s) afin d’observer comment le surplus de la bande
passante est réparti entre les flux actifs. Le résultat est présenté dans la courbe ci-dessous.

Fig II-10 : L’effet de l’ordonnanceur WFQ
En conséquence de l’arrêt à t=(30s), nous observons une augmentation équitable de

l’utilisation de la bande passante de lien selon les coefficients de pondération. De plus, le débit
utile pour les deux flux (vidéo et données) atteint la valeur maximale suite à cette interruption.
IV-2- Le taux de perte
Le scénario de simulation compare le taux de perte des paquets de flux vidéo et de

données pour le cas d’ordonnancement WFQ. En effet, plusieurs applications temps-réel telles
que la vidéo ont besoin de garanties particulièrement de taux de perte et non seulement en terme
de bande passante. Ainsi, si le taux de perte est élevé pour le flux vidéo, le processus de décodage
peut rencontrer des problèmes sérieux pour maintenir une bonne qualité d’image qui peut être
perturbée suite à la perte des plusieurs informations significatives. Nous présentons, dans la suite,
le taux de perte résultant de notre simulation dans le tableau II-2. Nous rappelons que le taux de
perte est le rapport entre le nombre de paquets perdus et le total des paquets envoyé.
Temps de simulation Taux (%)- Flux Taux (%)- Flux de

(sec) vidéo données
0 0 0
10 0 50,4

20 0,3 54,36
30 0,77 55,70
40 0,68 56,94
50 0,76 57,76
60 0,88 57,37
80 0 ,88 57,54
100 0,91 57,76
120 0,97 57,84
140 0,96 57,85
160 0,97 57,93
180 0.98 58
Tableau II-2: Taux de pertes pour le flux vidéo et de données
En effet, en favorisant le flux vidéo par rapport au flux de données qui est considéré le
moins prioritaire, nous obtenons un taux de perte pour le flux vidéo plus faible que celui de
données tout le long de nos simulations. Nous illustrons la variation de ce taux dans par la figure
II-11 respectivement pour les deux flux.
Fig II-11 : Variation de taux de pertes

IV-3- La borne sur le délai
D’après l’équation (6), la borne maximale du délai dépend de deux facteurs tels que la
taille de la rafale et la bande passante réservée. Le réseau doit garantir une borne maximale sur le
délai instantané. Nous étudions, dans cette section, ce paramètre de QoS. Les résultats de la
simulation confirment à ceux obtenus analytiquement. En effet, le délai maximal bout en bout
acquis par un paquet de flux audio, par simulation, est égal à 20 ms. Cette valeur est inférieure à
la borne calculée théoriquement avec l’équation (6). De même pour le flux vidéo, le délai
maximum obtenu est égal à 0,12 s. De plus, étant donné que le flux audio est le plus prioritaire,
alors, nous remarquons que son délai est très inférieur que celui de vidéo qui est moins
prioritaire. Ceci est conforme à notre configuration, puisque nous avons favorisé le flux audio
avec un taux de service élevé. Nous présentons la variation de délai pour ces deux flux dans la
figure ci dessous.
Fig II-12 : Variation de délai de bout en bout
Le module DiffServ permet de mettre en valeur le fonctionnement global des différentes

tâches qui tiennent part à la mise au point d’une stratégie de QoS. L’ordonnanceur WFQ dont
l’idée de base est de permettre un accès équitable à la bande passante fondée sur un
entrelacement des flux améliore encore le niveau de QoS. Cependant les coefficients affectés aux

files sont statiques. Alors la question qui se pose comment ajuster ces taux de service
dynamiquement et rendre l’allocation des ressources dynamique. Une solution assurant ce type
d’ajustement est l’utilisation de principe de fonctionnement de régulateur PID. Pour cela, dans la
suite de ce chapitre, nous introduisons l’algorithme de fonctionnement de ce correcteur ainsi que
ces différentes actions.
V- La régulation
V-1- Besoin de la régulation
Les systèmes asservis pouvaient présenter quelques défauts tels que une précision
insuffisante, une stabilité trop relative, un temps de réponse trop élevé, un dépassement trop
important, au regard des spécifications d’un cahier des charges. Il est donc souvent nécessaire
d’intégrer dans le système asservis un système, appelé correcteur ou régulateur, dont l’objectif est
d’améliorer ces paramètres sans bien sûr le faire au détriment des autres. Le correcteur doit
permettre de répondre au cahier de charges et de réaliser le meilleur compromis entre les
spécifications lorsque celles-ci ne peuvent pas être satisfaites totalement. Les éléments contenus
dans un cahier de charges peuvent être formulés de différentes manières, mais dans tous les cas,
ils traduisent les performances attendues relatives à la stabilité, à la précision et à la rapidité.
Le comportement attendu d’une régulation peut être résumé ainsi : après un changement
de consigne ou une perturbation, la mesure doit atteindre la consigne, le plus rapidement possible
et sans oscillations. Donc la régulation permet de maintenir une grandeur physique à une valeur
constante quelque soient les perturbations extérieures. Un régulateur est un mécanisme
automatique qui élabore un signal de commande appelée «U» en fonction de l’écart de réglage et
selon un algorithme bien défini. La figure ci dessous résume ce fonctionnement.
Erreur = (Yc - Y) Signal de commande «U»

Signal consigne
«Yc » + Régulateur Processus
sortie
Signal mesuré «Y »
Fig II-13 : Le principe de régulation en boucle fermé

V-2- La loi de commande
La commande est l'action délibérée sur un système en vue d'atteindre des objectifs définis.
On parle de commande en boucle fermée (BF) dont l'action sur le système commandé dépend de
la mesure de la grandeur commandée y(t). Il s'agit d'une commande avec rebouclage de
l'information ou boucle de rétroaction. En conséquence, les performances de ce type de
commande sont meilleures. On définit la commande comme suit :
U (s)
= F (s) Î U (s) = ε (s) ∗ F (s) (7)
ε (s)
Avec F(s) représente la fonction de transfert et ε (t) =Yc −Y . On représente, aussi, l’erreur par la
figure ci dessous :
Fig II-14 : Présentation de l’erreur
V-2-1- La loi de commande proportionnelle
La loi de type « Tout ou Rien » peut être améliorée. S’il est en effet pertinent d’envoyer
toute la puissance quand on est encore loin du but poursuivi, il convient de la réduire quand on
s’approche du résultat à atteindre. L’action « U » est alors dosée à proportion du résultat atteint et
donc de l’erreur. La loi de commande u (t) est proportionnelle à l’écart ε :
(8)
U = K ∗ ε
En effet, si K est grand, la correction est énergique donc rapide mais le risque de
dépassement et d’oscillations dans la boucle s’accroît. Si K est petit, la correction est lente mais il
y a moins de risque d’oscillations. Nous représentons la variation de cette correction dans la
figure ci dessous :

Y(t) K élevée
K faible
Yc
Fig II-15 : Effet de la commande proportionnelle
Le régulateur proportionnel assure une transmission instantanée du signal d’erreur; dans

ce sens, son action est relativement dynamique. Sa commande ne dépend pas du passé, ni d’une
tendance, mais simplement de ce qui se passe à l’instant présent. Une limitation de ce type de
correcteur est son incapacité à annuler notamment l’erreur statique (vis-à-vis d’une consigne
constante ou d’une perturbation constante) [19]. En effet, si la commande u(t) à appliquer au
système doit être non nulle afin que celui-ci puisse retrouver ou maintenir son état d’équilibre, il
est dans le même temps nécessaire que l’erreur soit non nulle.
V-2-2- La loi de commande intégrale
La loi de commande intégrale permet d’assurer une commande « U » plus progressive.

Cette loi est de la forme :
Τ
u(t) = 1/T i ∫ ε (x) dx (9)
0
La variable Ti est une constante de temps d’intégration qui doit être de même ordre de
grandeur que T. Si Ti est trop petit, l’action « U » monte trop vite sans laisser au système le temps
de démarrer progressivement. Par contre s’il est grand, l’action « U » monte trop lentement. La
commande intégrale réagit donc calmement aux variations brusques de l’erreur et assure un
rattrapage progressif de la consigne. En effet, lorsque l’erreur est devenue nulle, la commande ne
l’est pas nécessairement. Le signal de commande d’équilibre, nécessaire au processus, est
maintenu. L’intérêt principal de ce correcteur est d’ajouter dans la chaîne de commande une
intégration. On sait que la présence d’une intégration annule l’erreur statique pour une entrée en
échelon. De ce fait, il permet donc d’améliorer la précision.

V-2-3- La loi de commande dérivée
L’intérêt principal de la correction dérivée est son effet stabilisant. Elle s’oppose aux
grandes variations de l’erreur (donc aux oscillations) et permet donc de stabiliser le système et
d’améliorer le temps de réponse. Dans l’industrie, l’action D n’est jamais utilisée seule mais
toujours associée aux autres actions. L’action du régulateur dérivée n’intervient que sur la dérivée
de l’erreur. La loi de commande est de la forme :
  d ε (t) 
u (t) = ε (t) + Td   (10)
  dt 
L’action dérivée permet une correction rapide de l’erreur sans encourir le risque de
dépassement de consigne. Elle permet d’améliorer la stabilité et la rapidité du système régulé.
V-3- Le régulateur PID
L’intérêt du correcteur PID est d’intégrer les effets positifs des trois correcteurs
précédents. La détermination des coefficients K, Ti, Td du correcteur PID permet d’améliorer à la
fois la précision (Ti et K), la stabilité (Td) et la rapidité (Td, K) [18].
Le réglage d’un PID est en général assez complexe, des méthodes pratiques de réglages
permettent d’obtenir des bons résultats. Le correcteur PID effectue un traitement de l’erreur ε (t):
u(t) = K  ε(t) + 1/T i ∫ ε(x) dx + Td dε 

t
 dt  (11)
0
La transformée de la place de l’expression précédente (11), en supposant toujours des conditions

initiales nulles, est sous cette forme:
 
u (p) = K ∗ ε ( p ) ∗  1 + 1 + (Td ∗ P )  (12)
 Ti ∗ p 
D’où nous tirons la fonction de transfert du correcteur PID.
U (p)  (1 + Ti ∗ P + Ti ∗ Td ∗ P 2 )
C (p) = =K∗  (13)
ε (p)  Ti ∗ P 

Pour discrétiser cette loi, on pose t = k*∆, on choisit une approximation de la dérivée et
une autre cohérente pour le calcul de l’intégrale. Si on appelle I(k) la valeur approchée par la
méthode des rectangles supérieurs de l’intégrale de ε (x) pendant k*∆, on aura :
i=k
I(k) = ∑ ε (i) ∗ ∆ (14)
i =1
Si on appelle D (k) la valeur approchée de la dérivée de ε (x ) pendant k*∆, on aura :
ε (k) −ε (k −1)
D (k) = (15)
∆
Ainsi le PID aura la forme suivante :
 i =k 
u(k)= K ε (k)+ ( ∆ ) ∑ ε(i)+Td (ε(k)−ε(k−1))
 Ti i=1 ∆ 
(16)
VI- Conclusion
Le modèle DiffServ, en introduisant la notion de classes et de priorités entre les flux, offre
des garanties strictes en terme de métriques de qualité de service. Cependant, les priorités
affectées aux files sont statiques. Une alternative, permettant d’améliorer encore plus le niveau de
la qualité de service, est l’introduction de l’approche de régulation dynamique des priorités.
Ce chapitre, avait pour objectif d’évaluer les performances de DiffServ et de présenter la
notion de la régulation dans les systèmes asservis. Ces informations seront utiles dans le chapitre
suivant qui s’intéressera à l’implémentation de l’approche de la régulation dynamique des
coefficients de pondération des files de la discipline WFQ.

Chapitre III
Modélisation et implémentation de l’approche de

régulation dans le modèle DiffServ
I- Introduction
Dans les chapitres précédents, nous avons introduit les paramètres quantitatifs de la
qualité de services. Parmi les exigences de certaines applications, comme la voix, en terme de
QoS, on trouve la bande passante et le délai de transmission. Nous avons aussi étudié les
mécanismes de régulation dans les systèmes asservis. Dans ce chapitre, nous nous intéressons à
intégrer le principe du régulateur PID avec le modèle de DiffServ afin d’améliorer les
performances de différenciation des flux et le niveau de la qualité de service.
II- Aperçu de l’approche de régulation dans le modèle DiffServ

Le but de notre approche est de tirer profit d’avantages d’asservissement et de la
régulation afin de réaliser un module d’ajustement dynamique des coefficients de pondération des
files d’attentes de l’ordonnanceur WFQ. En effet, cette régulation est relative aux besoins des
applications et permet de favoriser un flux au détriment de l’autre. L’automatisation de processus
d’ajustement et d’affectation des priorités est dans le but d’atteindre certaines métriques de
qualité de service. L’approche peut être présentée comme suit :
Pi WFQ
Sortie
+ Régulateur PID U Pj
La Qos consigne«Yc »
-
La QoS Pk
mesurée
Fig III-1 Principe d’ajustement des coefficients

Modélisation et implémentation de l’approche de régulation dans le modèle DiffServ
Le régulateur génère une commande « U » qui ajustera les poids des files. Les classes
seront servies par le « scheduler » WFQ proportionnellement aux nouveaux coefficients. La
différence entre la valeur consigne (Yc) et la valeur mesurée (Ym) sera, alors, transmise vers le
régulateur PID. La valeur consigne désigne généralement un niveau de paramètre de QoS qu’on
l’asservit, comme la bande passante, le délai, la gigue. Ensuite, une commande, relative à chaque
erreur calculée, est générée par le correcteur PID. Cette commande ajustera le coefficient de
pondération propre à chaque file et sert comme déterminant de sa priorité et son niveau de service
par WFQ. Le principe de la régulation se résume, ainsi, par les étapes suivantes :
- Spécification de la valeur consigne ou la métrique qu’on veut asservir pour un flux « i ».
- Mesure de la métrique.
- Calcul de l’erreur.
- Application de la commande de régulation pour ajuster les poids des files afin d’atteindre
la valeur consigne.
- Refaire les mesures relatives à cette régulation.
III- Intégration de régulateur PID dans le modèle DiffServ

L’introduction de la notion de priorité permet de différencier les services entre les
différents flux en fonction de leur importance. A chaque file d’attente est attribuée un niveau de
priorité. Cette attribution est statique. En effet, si les flux des plus hautes priorités ne sont pas
conditionnés par le réseau, les flux de priorités plus basses peuvent subir des délais assez
importants en attendant la fin de service des flux prioritaires non bornés. C’est le problème de la
famine. Ce phénomène peut conduire au rejet de paquets des flux les moins prioritaires quand les
files d’attente correspondantes deviennent saturées. Donc la priorité statique ne permet pas de
fournir une qualité de service flexible en fonction des besoins des applications. Pour remédier à
ces problèmes, les algorithmes de partage de bande passante ont été proposés et ont suscité
beaucoup d’intérêt dans les dernières années visant à gérer plus efficacement les ressources entre
les différents flux. L’objectif de ces algorithmes consiste à assurer un accès aux ressources du
réseau d’une manière équitable et empêcher qu’un flux en rafale puisse consommer plus de
ressource que le taux qui lui est alloué. Cependant le coefficient de pondération associé aux files
reste toujours statique. D’où le but d’intégration de régulateur PID qui visera à ajuster les
priorités dynamiquement afin d’atteindre certains niveaux de qualités de service.

III-1-Modélisation de la bande passante
Dans ce paragraphe, nous proposons de calculer, en utilisant les lois de commande de

régulateur PID, l’ajustement des coefficients de pondération afin de garantir une bande passante
consigne à un flux « i » proportionnellement à un taux de partage [16]. Comme nous l’avons
indiqué dans le chapitre précédant, la bande passante réservée pour un flux « i » par un serveur à
débit garanti, notamment WFQ est :
φi
ri = n ∗C (1)
∑φj
j
De même, nous avons déjà détaillé dans le chapitre II l’action de régulateur numérique
PID [18] qui se traduit par l’équation ci dessous:
 i =k 
u(k)= K ε (k)+ ( ∆ ) ∑ ε(i)+Td (ε(k)−ε(k−1)) (2)
 Ti i=1 ∆ 
De plus, WFQ conserve la même garantie de bande passante au flux, proportionnellement

à leurs taux de service. Pour cela, afin d’atteindre une valeur consigne (bande passante souhaitée
pour un flux «i»), il est nécessaire d’attribuer une nouvelle pondération φ' i à la file «i». Ceci
sera, en fait, un ajustement de l’ancienne priorité de la file qui est déduite à partir de l’erreur
calculée entre la valeur souhaitée (consigne) et la valeur mesurée (bande passante réellement
mesurée à la sortie).
(3)
ε = Yc − Y m
Etant donné qu’on modifie la priorité de la file « i », alors tout ajustement de celle ci sera
au détriment des autres files. A cet effet, on considère que l’assignation d’un nouveau taux de
service au flux « i » est suivi d’une modification d’un autre taux pour une classe moins prioritaire
que celle-ci. L’idée est de conserver toujours la qualité de service désirée pour les trafics les plus
prioritaires. Compte tenu des modifications des priorités, on exprime Yc comme suit :
φ 'i
Yc = n ∗C (4)
∑φ
j
'j

Ainsi, si nous optons de garder toujours la même bande passante pour les flux les plus
prioritaires et les mêmes coefficients, alors, une file « m » moins prioritaire que « i » aura une
nouvelle pondération φ'm ≤ φ m . Notons donc par :
n n 
∑ φ ' j =  ∑ φ j − φm − φ i  + φ 'i + φ 'm (5)
j  j 
L’expression de l’erreur peut s’écrire alors:
 
 
φ' i φi 
ε= n − n  ∗C
(6)
 ∑φ' j ∑φ j 
 j j 

Par conséquent, à partir de l’équation (6) et (2), nous déduisons le nouveau coefficient de
pondération associé à la file « i » garantissant la bande passante souhaitée. Cette nouvelle priorité
se traduit par l’équation ci-dessous :
 
 [U (k) − A + B ] φ i   n 
 C ∗ D
+ n   ∑ φ j − φ i − φ m + φ ' m 
 ∑φj   j 
φ' i =  
j
(7)
 
 [U(k) − A + B ] φi 
1 − C ∗D
+ n 
 ∑φj 
 j 
k −1
Notons par : A= K ∗ ∆/T i ∗ ∑ ε (i) ; B =K ∗Td/∆∗ ε(k −1) ; D = [ K + ∆/Ti + Td /∆ ]
i=1
III-2- Modélisation du délai
Nous avons présenté dans le chapitre II, le formalisme du Network Calculus [16] et
particulièrement la notion de la courbe d’arrivée et la courbe de service [20]. Nous déduisons le
délai garanti par un serveur WFQ pour un trafic (σ, ρ)-borné:
Dmax = σ + Lmax
(8)
R C
Formellement, la borne maximale sur le délai garanti par WFQ pour une réservation de
bande passante R augmente linéairement avec la taille de la rafale du flux et diminue en
augmentant la bande passante réservée.

Ainsi, en suivant la même démarche que celle de la régulation de bande passante, le

régulateur PID ajuste le poids de la file « i » de telle sorte à garantir une limite sur le délai qui
désigne la valeur consigne Yc.
Yc = σ + Lmax
φ' i C (9)
n *C
∑φ'
j
j
De même, à partir de la commande de régulateur (équation (2)), on peut déduire l’erreur

présentée par l’équation ci dessous:
 k −1

u (k) − K ∗  ∆/Ti ∗∑ ε (i)+ K ∗Td /∆∗ ε(k −1)
ε(k) =  i =1  (10)
[ K + ∆/Ti +Td /∆ ]
En supposant toujours que toute augmentation de la priorité de la file « i » sera au

détriment de la file la moins prioritaire, alors le poids de la classe « i » s’écrit sous la forme
suivante :
 n φ j − φi − φ m + φ ' m 
 ∑ 
φ 'i =  j 
  (11)
 [
U(k) − A + B ]
+ n
φi 
− 1
 C* σ ∗D
 ∑φj 
 j 
On remarque que le coefficient calculé représente la valeur minimale qu’on peut attribuer à la file
« i » afin de ne pas dépasser la valeur limite sur le délai.
IV- Evaluation des performances de la régulation

Après avoir modéliser la régulation du délai et de la bande passante, indépendamment
l’un de l’autre. Nous nous intéressons, maintenant, à l’intégration de cette approche et sa
validation en effectuant les tests nécessaires.
Plusieurs langages de programmation permettent l’implémentation de notre approche de
régulation. Cependant, nous avons opté pour le langage C++ pour un futur intégration de ce
module dans NS.

IV-1- Description du scénario choisi
Nous nous proposons de mettre en évidence l’ajustement dynamique des coefficients de

pondération des files à chaque instant « t » et satisfaire les besoins des utilisateurs. Dans cette
section, nous présentons une étude de cas, par simulation avec NS (Network Simulator), d’un
réseau pour le transport de l’audio, la vidéo et des données.
C lie n t 1
6
s
M
t/
A u d io
b
bi
it/
M
s
1 ,0 4 M b it/s
it /s
6
b 2 Mb
i t /s
3 M
C o re
b it/s 6 M b it/s c lie n t2
6 M
6
E1 E2
M
b
it/
s
t/s
bi
0 .8 M b it/s
M
6
C lie n t 3
D a ta
0 .5 M b it/s
Fig III-2 : Scénario de simulation
Considérons un réseau constitué de trois sources de trafic. Ces dernières partagent la

bande passante disponible (2Mbit/s) selon leurs coefficients de réservation. Dans ce scénario,
nous supposons une taille fixe de tous les paquets des trois flux égale à 1000 octets. Le tableau ci-
dessous récapitule les paramètres de simulation pour chacun des flux.
Taille de paquet
Flux Débit (Mbit/s) Priorité Poids
(Octets)
Audio 1,04 1000 Haute 52%
Vidéo 0.8 1000 Moyenne 30%
Données 0.5 1000 Faible 18%
Tableau III-1 : Paramètres de simulation
La source audio génère un trafic à débit constant (CBR) à 1,04Mbit/s. La deuxième source
génère aussi un flux vidéo à un débit constant égal à 800kbit/s. La source de données délivre ses
paquets à un débit égal à 500 kbit/s.

IV-2- Module de régulation de la bande passante
Lors de l’implémentation de ce module, nous avons pris en considération le scénario

décrit précédemment. En effet le but de ce module est de nous fournir l’ajustement nécessaire des
coefficients de pondération de flux vidéo pour atteindre la bande passante souhaitée à chaque
instant « t ». L’objectif est d’alimenter le régulateur avec les valeurs consignes que nous voulons
atteindre et de générer à la sortie les modifications des priorités qui doivent affecter les files.
Dans cette approche, nous visons toujours à assurer pour le flux audio un taux de service
qui est proportionnel à sa priorité de l’ordre de 1,04Mbit/s. Ce taux restera statique et nous
essayons de varier la bande passante que nous voulons atteindre pour le flux vidéo. Donc, on
provoque un changement de la pondération de la file la moins prioritaire.
IV-2-1-Principe de fonctionnement de régulateur de la bande passante
Au départ, nous commençons par l’initialisation des variables internes utilisées par le
programme tels que les constantes d’intégration, de dérivation, l’intervalle de temps. Ensuite,
l’application calcule la bande passante réservée au flux prioritaire, et ceci guidera le programme à
gérer le reste de la capacité afin d’assurer la valeur consigne.
Pendant l’intervalle de temps ∆, le programme effectue une routine particulière qui
consiste à calculer l’erreur entre la valeur consigne et la valeur mesurée, générer la commande de
régulation selon la modélisation décrite précédemment afin de déduire la nouvelle priorité
associée au flux vidéo et enfin se préparer au prochain cycle.

D ébut
Initialisation des
param ètres de PID
Initialisation des
variables de PID
Réception de la valeur
consigne (Bp)
Lancer l’horloge
Extraction de la bande
m esurée
Calcul de l’erreur
Routine de la génération
de la com m ande U et
des priorités
Non Fin de Oui

cycle?
Non
Arrêt de
processus?
Oui
Fin
Fig III-3 : Organigramme du module de régulation de la bande passante
IV-2-2- Interprétation des résultats
Pour tester le fonctionnement du programme développé pour la régulation de la bande

passante de flux vidéo, nous avons utilisé en entrée, un fichier texte qui contient des données
présent à l’entrée du régulateur PID. Ces dernières désignent, dans notre cas, les valeurs de la
bande passante consigne de flux vidéo. Un autre fichier représente les données obtenues à la
sortie de la régulation et désignant la valeur mesurée. Les mesures effectuées à la sortie sont

utilisées au fur et à mesure de l’exécution pour le calcul de l’erreur et l’ajustement nécessaire.

Nous illustrons les sorties de l’exécution de notre module dans la figure ci-dessous :
Fig III-4 : Résultat de régulation de la bande passante
Cette interface de sortie montre la valeur consigne ainsi que l’ajustement nécessaire affectant
la pondération de la file de flux vidéo et permettant de garantir la bande passante souhaitée. En
effet, cette dernière est obtenue avec un certain retard, ce qui explique sa présence comme valeur
mesurée à la prochaine tentative.
Fig III-5 : Présentation des résultats de l’approche de régulation de la bande passante
La figure III-5 montre bien l’apport de la régulation et de correction. Elle illustre la

poursuite du signal de sortie aux variations de la consigne. En effet, le signal de commande dans
le module permet de conduire le processus vers l’objectif souhaité. Ainsi, l’allure de la courbe de
la bande passante mesurée se rapproche vers la valeur consigne ou la bande passante souhaitée
tout en agissant dynamiquement sur les poids des files. Par exemple, pour atteindre une bande

passante de l’ordre de 0.7Mbit/s à l’instant « t », et suite à la valeur mesurée, à l’instant « t-∆ »,

qui est égale à 0.650Mbit/s, le module de correction génère la commande « U ». Cette dernière
agit sur les coefficients de pondération pour fournir la nouvelle priorité de flux vidéo. Ainsi, en
attribuant à la file un taux de service de 35%, la valeur souhaitée est obtenue avec un certain
retard. Notons aussi, suite à cette poursuite, la priorité de la file de données diminue et atteint un
taux égal à 13%. Le tableau ci-dessous montre la variation des priorités pour la file de la vidéo et
de données selon la bande passante réservée au flux vidéo.
La valeur consigne Le poids de flux vidéo Le poids de flux de données

(Mbit/s)
0.650 32,5% 15,5%
0.7 35% 13%
0.750 37,5% 10,5%
0.780 39% 9%
Tableau III-2 : Ajustement des pondérations des files
La bande passante est proportionnelle au taux de partage, ce qui explique la variation des
priorités de la file vidéo. En effet, pour atteindre une consigne particulière, le régulateur agit sur
les poids. Dans le cas d’une bande passante supérieure à la valeur initiale qui est de l’ordre de 0.6
Mbit/s et pour un taux égal à 30%, le régulateur ajuste la priorité pour la file vidéo et l’augmente
sans affecter la priorité de la file la plus prioritaire. Nous devons garantir pour la file de flux
audio, toujours, une bande réservée fixe de 1,04 Mbit/s et un taux égal à 52%. En conséquence,
l’augmentation de la priorité de flux vidéo peut être au détriment de flux de données vu qu’il est
le moins prioritaire. A titre d’exemple, pour une bande égale à 0.750 Mbit/s, la file de flux vidéo
aura un taux égal à 37,5% tandis que celle de données aura un taux de 10,5%. La figure III-6
illustre la variation des poids générés par le régulateur.

Fig III-6 : Résultat de la simulation concernant l’ajustement des poids
Nous proposons, donc, de valider les résultats de la régulation obtenus en utilisant le

simulateur NS. En fait, nous avons généré un script « tcl », conforme au scénario choisi,
implémentant le modèle DiffServ et utilisant l’ordonnanceur WFQ. En partant des conditions
initiales concernant les pondérations pour chaque file, puis en modifiant les priorités selon les
résultats de module de régulation, nous avons mesuré la bande passante obtenue pour le flux
vidéo. La figure ci-dessous montre la variation de la bande passante consigne de flux vidéo
proportionnellement aux priorités calculées par le régulateur. En effet, avec un taux égal à 35%,
le flux vidéo bénéficie de 700kbit/s comme bande passante alors qu’avec un taux de partage égal
à 39%, nous avons aboutit à une valeur consigne égale à 780 kbit/s conformément aux sorties de
module de régulation.
Fig III-7 : Résultat de la simulation avec NS

IV-3- La régulation du délai
La priorité statique offerte par le modèle DiffServ ne permet pas de fournir une qualité de
service flexible en fonction des besoins des applications. Nous proposons, alors, d’ajuster
dynamiquement le délai de transmission des paquets. L’objectif principal de cette section est de
modifier la priorité d’un flux « i » dans le but à ne pas dépasser le délai maximal Dmax. Le
principe consiste à alimenter le régulateur avec la valeur consigne, qui désigne la borne maximale
de délai que nous ne voulons pas la dépasser pour le flux vidéo, et affecter à la file vidéo le poids
nécessaire pour atteindre cet objectif.
En effet, ce délai maximal est proportionnel à la bande passante réservée à un flux «i » et
à la taille de trafic de rafale. Pour simuler notre approche, nous avons opté pour le choix de ces
paramètres décrits dans le tableau III-3 avec la même topologie décrit ci-dessus (Fig III-2).
CBS Echéance
Flux Policier Priorités
(Octets) (ms)
Audio Token Bucket 80000 52% 150
Vidéo Token Bucket 80000 40% 150
Donnée Token Bucket 80000 8% --
Tableau III-3 : Paramètres de la simulation
Comme, le montre le tableau ci dessus, nous avons choisi d’augmenter la priorité de flux
vidéo, par conséquent, la bande réservée augmente. Ce choix est dû aux exigences temporelles
contraignantes des applications temps-réel afin de ne pas excéder l’échéance requise par
l’application. Ainsi, en tenant compte des initialisations des priorités, nous avons essayé d’ajuster
dynamiquement ces paramètres sans dépasser la valeur consigne spécifiée par l’utilisateur. Lors,
de la programmation de module de régulation de la borne maximale du délai, nous avons garanti
pour le flux prioritaire une borne de l’ordre de 0.6s calculée selon la formule (8) de la section III-
2.
IV-3-1- Principe de fonctionnement de régulateur du délai
Dans la régulation de la borne sur le délai, nous commençons par initialiser les paramètres
du régulateur PID ainsi que ses variables. Puis, vient la phase de la lecture de la valeur consigne à
partir d’un fichier texte rempli par l’utilisateur et de la comparer à celle mesurée. Enfin, le
régulateur génère la commande « U » assurant l’ajustement des poids de la file de flux vidéo.

Début
Initialisation des
paramètres de PID
Initialisation des
variables de PID
Réception de la valeur
consigne (Dmax)
Lancer l’horloge
Extraction de délai max

mésurée
Calcul de l’erreur
Routine de la génération
de la commande U et
des priorités
Non Fin de Oui

cycle?
Non
Arrêt de
processus?
Oui
Fin
Fig III-8 : Organigramme du module de régulation de la borne sur le délai
IV-3-2-Interprétation des résultats
Ce module génère comme sorties des coefficients de pondération à affecter aux files de
flux vidéo et de données. Cependant la priorité calculée pour la vidéo représente la pondération
minimale à attribuer à la file de cette classe de service. Pour le flux de données, le taux représente
la valeur maximale. L’interface ci-dessous illustre les résultats de la simulation de l’approche.

Fig III-9 : Résultat de l’approche de régulation du délai
En effet, le but est de fournir l’ajustement nécessaire de coefficient de pondération afin de

ne pas dépasser le délai maximal. Ainsi, par exemple, en affectant à la file de flux vidéo un taux
minimal égal à 45,71%, nous garantissons que le délai d’un paquet de flux vidéo, pour atteindre
sa destination, est bien inférieur à 0.7s. En effet, ce coefficient est calculé à partir de la
commande de régulateur PID en utilisant l’erreur entre la valeur consigne et la valeur mesurée à
chaque instant « t ». La figure III-10 présente la variation de la valeur consigne et la valeur
mesurée dans le temps.
Fig III-10 : Variation de la valeur consigne et mesurée
La figure III-10 montre bien la poursuite de la valeur mesurée. En effet la limite du délai
mesurée tend de se rapprocher vers la valeur souhaitée avec un certain retard. Par conséquent, ce
phénomène se traduit par une variation automatique des priorités des flux vidéo et de données.

Fig III-11 : Variation des priorités pour les flux vidéo et de données
Comme le montre la figure III-11, plus on diminue la valeur du délai maximal, plus on
augmente la pondération de flux vidéo et on diminue celle de donnée. Il en résulte, alors, une
variation de la bande passante réservée à chaque flux.
Pour valider cette approche de la régulation du délai, nous avons utilisé ces résultats pour
les intégrer dans un script tcl. L’objectif est de vérifier qu’avec les nouvelles priorités, nous
mesurons toujours un délai inférieur à une valeur maximale.
Fig III-12 : Résultat de la simulation avec NS (1)

Les résultats de la simulation montrent qu’avec un coefficient de pondération minimal
égal à 32%, le délai maximal d’un paquet de flux vidéo est de l’ordre de 0.95s. Cette mesure est
bien inférieure à la valeur maximale calculée théoriquement. Cependant, si nous considérons un

taux égal à 29% inférieur au premier taux, le paquet peut atteindre sa destination dans un délai
égal à 1.074s et donc dépasse la limite. De même, avec un coefficient égal à 40%, le délai
maximal acquis par ce même flux, présenté dans la figure III-13, est proche de 33 ms qui est
inférieur à la limite calculée théoriquement.
Fig III-13 : Résultat de la simulation avec NS (2)
Ainsi, les résultats de simulation confirment ceux obtenus analytiquement. Néanmoins,

les bornes analytiques sont toujours supérieures à celles fournies par simulation due à la
surestimation du système dans le cas analytique, du fait que la courbe d’arrivée (σ,ρ)-borné
surévalue le trafic réel.
IV-4- Compromis entre le délai et la bande passante réservée
Après avoir développé les modules de régulation de la bande passante et du délai, nous avons
voulu aboutir à un compromis entre ces deux métriques. Il s’agit d’ajuster les coefficients de
pondération des files afin de répondre aux exigences de ces deux paramètres de qualité de
service. Pour cela, nous considérons que nous avons deux valeurs consignes et nous voulons les
atteindre. Cependant, notre régulateur génère deux coefficients répondant aux deux paramètres de
qualité de service (délai et bande passante).
L’objectif consiste de trouver un compromis entre ces deux priorités pour satisfaire les besoins
en terme de qualité de service. Au début, nous considérons les flux vidéo, audio et données ont
des coefficients de pondération respectivement égales aux 30%, 52% et 18%.

IV-4-1- Principe et Algorithme
Après initialisation des variables et des paramètres, le régulateur reçoit les valeurs
consignes (la bande passante à réserver et le délai maximal). En effet, chaque consigne renvoie
vers une routine particulière comme l’indique le diagramme de la figure ci-dessous.
- La procédure de régulation de la bande passante : Une fois le régulateur reçoit la
valeur de la bande passante souhaitée, il aura besoin de la valeur mesurée afin de générer
la commande PID à partir de l’erreur calculée. Cette commande permettra de fournir
l’ajustement nécessaire pour la file de flux vidéo afin d’atteindre la bande passante
consigne.
- La procédure de régulation du délai : En recevant la valeur consigne du délai maximal,
nous faisons appel à cette routine afin de générer la commande PID permettant de nous
fournir l’ajustement adéquat de poids de la file de flux vidéo.
Dans cette approche, nous avons comme résultat deux priorités qui peuvent être
différentes. En conséquence, nous optons pour le choix de la priorité la plus élevée. En effet, en
choisissant la valeur la plus grande, ceci nous permet de satisfaire les deux besoins en terme de
qualité de service. En optons pour le coefficient déduit par la régulation de la bande passante, qui
est supérieur à celui du délai, nous garantissons la bande passante consigne et aussi un délai
maximal inférieur à la valeur consigne.

Début
Initialisation des
paramètres de PID
Initialisation des
variables de PID
Réception des valeurs

consignes
Lancer l’horloge
Extraction de délai max Extraction de la BP

mesuré mesurée
Procédure de régulation Procédure de régulation

de la borne sur le délai de la BP
Choix de la priorité
adéquate
Non
Fin de Oui
cycle?
Arrêt de Non
processus?
Oui
Fin
Fig III-14 : Organigramme du module de régulation du délai et de la bande passante
IV-4-2- Interprétation des résultats
Pour tester l’application permettant la régulation de la bande passante réservée et du délai,

nous avons alimenté l’entrée de régulateur à chaque instant (t) avec deux consignes
correspondant respectivement à ces deux métriques de qualité de service. Ensuite nous avons
mesuré les sorties et la nouvelle priorité à affecter à la file de flux vidéo. La figure ci-dessous
illustre les résultats de l’exécution du code.

Fig III-15 : Résultat de l’approche de régulation (délai et bande passante)
Dans certains cas, la valeur de la bande passante garantie ou de délai est différente de la
valeur consigne appliquée à l’entrée de régulateur. Ceci est dû au choix de taux de service. En
effet, après la déduction de la priorité adéquate, nous recalculons la bonne valeur consigne des
deux paramètres. La figure III-16 illustre la poursuite de la valeur mesurée la variation de la
valeur consigne.
Fig III-16 : Régulation du délai maximal et de la bande passante
En effet, nous remarquons bien que, plus le délai maximal est faible plus qu’on doit
réserver plus de la bande passante et donc augmenter le coefficient de pondération de flux vidéo.
Ainsi, pour valider ces travaux, nous avons intégré les résultats de l’approche de régulation dans

un script tcl afin de vérifier la conformité avec le cas pratique. Le tableau ci dessous représente
un extrait de l’exécution du programme.
Dmax Pondération BP Pondération Pondération Dmax garanti BP

souhaité Selon Dmax Souhaitée selon la BP adéquate (s) garantie
(s) (Mbit/s) (Mbit/s)
1.07 29.90 % 0.730 36.5 % 36.5% 0.876 0.730
0.95 33.68% 0.680 34% 34% 0.941 0.680
Tableau III-4 : Résultats générés par le module de régulation
Pour atteindre la bande passante égale à 680 kbit/s et un délai maximal égal à 0.95s, il est
nécessaire d’attribuer à la file de flux vidéo un coefficient égal à 34%. Nous spécifions alors ce
paramètre dans le script, puis à partir de fichier trace, nous avons obtenu la courbe ci-dessous.
Cette figure montre bien que nous atteignions la valeur consigne en terme de bande passante. De
plus, nous démontrons dans la figure III-18 que le délai subi par chaque paquet de flux vidéo est
toujours inférieur à la valeur consigne modifiée qui est 0.94s.
Fig III-17 : Résultat de la simulation avec NS (Bande passante)

De même, dans le cas où nous voudrions garantir une bande passante de l’ordre de 730
kbit/s avec un délai maximal égal à 1,07 s, le module nous a fourni un ajustement de la priorité de
flux vidéo égal à 36.5%. En utilisant NS, nous mesurons une bande passante très proche de la
consigne, présentée dans la figure ci-dessus, aussi nous obtenons un délai maximal inférieur à la
valeur consigne qui est 0.87 s.
Fig III-18 : Résultat de la simulation avec NS (le délai maximal )
V- Conclusion
L’objectif de ce chapitre est d’intégrer l’algorithme de fonctionnement de régulateur PID,
utilisé dans les systèmes asservis, dans le modèle DiffServ. Pour atteindre ce but, nous avons
commencé par une modélisation de la régulation des paramètres de la qualité de service et une
maîtrise de l’environnement de développement. Puis, nous avons passé à la phase
d’implémentation et des tests qui a montré le bon fonctionnement des programmes. Finalement,
la simulation avec NS et les résultats de tests obtenus valident l’approche de la régulation
dynamique qui peut enrichir le modèle DiffServ.

Conclusion Générale
La qualité d’une connexion réseau a un impact significatif sur les performances des
applications et des services réseaux. Le modèle de service différencié (DiffServ) représente une
solution aux applications réseaux pour garantir une QoS par classe de service.
Dans ce projet de fin d’études, nous avons fait une étude détaillée du modèle DiffServ. La
compréhension des éléments théoriques, leur simulation et leur mise en oeuvre nous ont permis
d’analyser la QoS que le modèle peut offrir aux applications. En particulier, ce projet s’est
intéressé à la Différenciation de services obtenue grâce à l’introduction des priorités dans le
réseau. La notion de classes de services et de priorités forment les deux axes qui régissent le
fonctionnement du modèle DiffServ. Nos efforts sont centrés sur le déploiement de nouvelles
techniques permettant l’ajustement des priorités d’ordonnancement de ces classes d’une manière
dynamique.
Suite à une étude des concepts du modèle DiffServ et de l’apport de l’ordonnanceur
WFQ. Nous avons présenté la notion de la régulation et ses différentes commandes.
Nous avons complété notre travail par la réalisation d’un prototype de régulation assurant
un ajustement dynamique des priorités des files d’attente de l’ordonnanceur WFQ et satisfait les
exigences de l’utilisateur en terme de métriques de qualité de service. Après une modélisation de
processus de la régulation, nous avons bien structuré notre programmation et nous avons exposé,
finalement, l’analyse du fonctionnement et les résultats obtenus.
L’apport de ce projet a été la présentation et la simulation de l’approche de régulation.

Cette dernière qui représente une solution qui peut être intégrer dans les mécanismes de DiffServ
afin d’améliorer la QoS.

Conclusion Générale
L’application traitée au cours de ce projet reste ouverte, car l’algorithme WFQ a un

certain degré d’extensibilité. On parle aujourd’hui de la discipline d’ordonnancement (m,k)-WFQ
assurant un partage équitable des ressources et respectant la contrainte (m,k)-firm de chaque
classe de trafic. De plus, les codes sources, sont toujours à optimiser, à affiner et à compléter en
vue de l’implémenter dans le simulateur NS.
Enfin, pour clore ce projet de fin d’étude, nous espérons que les résultats obtenus
trouveront un bon écho et formeront un petit noyau de recherche pour tout intéressé par les
applications sur la régulation et le domaine de QoS.

Bibliographie
[1] Eric Horlait, Nicolas Rouhana, « Qualité de service dans l’architecture

TCP/IP », DNAC, Université Pierre et Marie Curie, Laboratoire LIP6, Paris,
1999.
[2] Jean - Louis Melin, « Qualité de service sur IP », Eyrolles édition,1 juillet
1992.
[3] D. Hehmann, M. Salmony, H. Stuttgen “Transport Services for Multimedia

Applications on Broadband Networks”, Computer Communications, vol. 13 -
nº 4, Mai 1990.
[4] R. Braden, D. Clark and S. Shenker, “Integrated Services in the Internet

Architecture: an Overview”, RFC 1633, IETF, Jul. 1994.
[5] Braden, R, “Resource ReSerVation Protocol (RSVP-Version 1 Functional

Specification”, RFC 2205, IETF, 1997.
[6] Steven MARTIN, Pascale MINET, Laurent GEORGE, “A DiffServ-MPLS

solution offering real-time end-to-end guarantees”, rapport de recherché, N°
4831 Mai 2003, INRIA.
[7] K. Nichols, S. Blake, F. Baker, “Definition of the Differentiated Services Field

(DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, IETF, Dec. 1998.
[8] Anne-Lise RENARD, Jérémy ROVARIS, « Etude du service DiffServ »,

coiurs, ESIAL, 2002 - 2003
[9] S.Blake, D. Black, M. Carlson, E. Davies, “An Architecture for Differentiated

Service”, RFC 2475, IETF, Dec. 1998

Bibliographie
[10] J. Heinanen, Telia Finland, F. Baker, W. Weiss, “Assured Forwarding PHB

Group”, RFC 2597, IETF, June. 1999.
[11] V. Jacobson, K. Nichols, K. Poduri, “An Expedited Forwarding PHB”, RFC

2598, IETF, June. 1999.
[12] Y. Bernet, S. Blake, D. Grossman, A. Smith, “An Informal Management Model

for Diffserv Routers”, RFC 3290, IETF, May 2002.
[13] L. Toutain, O. Medina, « Utilisation d’un Token-Bucket pour l’implémentation

d’Internet à différentiation de services», JDIR, 98.
[14] Pascale Vicat-Blanc Primet, Benjamin Gaidioz, Mathieu Goutelle,

« Approches alternatives pour la différenciation de services IP », Laboratoire
de l’Informatique du Parallélisme, Projet INRIA, ReSO , École Normale
Supérieure de Lyon.
[15] Peter Pieda, Jeremy Ethridge, Mandeep Baines, Farhan Shallwani, “A Network
Simulator Differentiated Services Implementation”, Open IP, Nortel Networks,
July 26, 2000.
[16] K. Parekh and R. G. Gallager, “A Generalized Processor Sharing Approach to

Flow Control in Integrated Services Networks: The single-node case,”
IEEE/ACM Transactions on Networking, Vol. 1, No. 3, pp. 344-357, June
1993.
[17] Aleksandar MrKaic, “Porting a WFQ Scheduler into ns-2’s DiffServ

Environment”, thèse, Swiss Federal Institute of Technology Zurich, été 2001.
[18] Maurice Rivoire, Jean-Louis Ferrier, « Cours d’Automatique : Asservissement

Régulation », Tome 2, EYROLLES, 1992.
[19] hthttp://perso.menara.ma/~bennisnajib/index.htm
[20] Koubâa Anis, Yé-Qiong Song, « Amélioration des Délais dans les Réseaux à
Débits Garantis pour des Flux Temps-Réel Sous Contrainte « (m,k)-Firm » »,
article, LORIA – UHP Nancy 1 - INPL - INRIA Lorraine, 2004.

Bibliographie

Pfe Mansour Hana

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Pfe Mansour Hana

Încărcat de

Drepturi de autor:

Formate disponibile

RAPPORT DE PROJET DE FIN D’ETUDES

Etude des mécanismes de différenciation

Année universitaire : 2004/2005

A mes amis, particulièrement, faker, Najet, Souheil, Rim,

Qu’ils trouvent dans ce travail le fruit de leur patience

qu’ils m’ont prodigué pour affronter

tous les moments difficiles.

Au terme de ce travail, nous tenons à remercier tout particulièrement :

M. Fakhreddine KHELIFA, mon encadrant, ingénieur au sein du CERT et M. Mounir

Le modèle à Différenciation de Services (DiffServ) ajoute des nouvelles fonctionnalités

Mots-clés : Qualité de Service, DiffServ, WFQ, régulateur PID, modélisation, simulation.

CHAPITRE I : LA DIFFERENCIATION DE SERVICES DANS LES RESEAUX ..............3

M. Hana - PFE - IRES L1

CHAPITRE II : EVALUATION DES PERFORMANCES DE DIFFSERV .........................27

M. Hana - PFE - IRES L2

CHAPITRE III : MODELISATION ET IMPLEMENTATION DE L’APPROCHE DE

CONCLUSION GENERALE .....................................................................................................67

M. Hana - PFE - IRES L3

Fig I-1 : Délai dans un réseau à commutation des paquets ..............................................................5

M. Hana - PFE - IRES L4

M. Hana - PFE - IRES L5

Tableau I-1 : Les besoins en qualité de service de certaines applications .......................................7

M. Hana - PFE - IRES L6

M. Hana - PFE - IRES L7

M. Hana - PFE - IRES L8

La qualité de service ou QoS (Quality of service) est un nouveau concept incontournable

M. Hana - PFE - IRES 1

hétérogènes des applications. En effet, le modèle de différenciation de service (DiffServ) fournit

M. Hana - PFE - IRES 2

La différenciation de services dans les réseaux

II- La qualité de service dans la conception des réseaux

M. Hana - PFE - IRES 3

II-1- Les paramètres de la qualité de service

La disponibilité d’un réseau se définit comme le rapport entre le temps de bon

M. Hana - PFE - IRES 4

II-1-2- Bande passante

II-1-3- Latence (Delay)

Délai de commutation Délai d’attente

Fig I-1 : Délai dans un réseau à commutation des paquets

M. Hana - PFE - IRES 5

II-1-4- Variation des délais de traversée (gigue ou jitter)

Fig I-2 : Distribution de délai et illustration de la gigue

M. Hana - PFE - IRES 6

II-1-5- Taux de pertes

Tableau I-1 : Les besoins en qualité de service de certaines applications

M. Hana - PFE - IRES 7

II-2- Les principaux mécanismes de gestion de QoS

M. Hana - PFE - IRES 8

III- La réservation de ressources

III-1- Le modèle IntServ

Un système puissant de réservation de ressources sur Internet est l'architecture Intserv

M. Hana - PFE - IRES 9

III-2- La solution MPLS

L'impasse de la réservation de ressource à grande échelle a conduit l'IETF à travailler sur

IV- Le modèle DiffServ

M. Hana - PFE - IRES 10

IV-1- Caractéristiques du modèle

M. Hana - PFE - IRES 11

Type de différenciation garantie absolue garantie statistique

Base de classification Plusieurs champs d’entête Un champ : DS

Signalisation Explicite Implicite dans le coeur

Réservation requise (RSVP) Non requise dans le coeur

Types routeurs Un type Deux types : bordure/cœur

Tableau I-2 : Tableau comparatif des approches de QoS