MOOC Routage et Qualité de Service

Automne 2015

Semaine 3 :

Au cours de cette semaine nous abordons la notion

de Qualité de Service (QoS) par réservation de
ressources. Nous allons d’abord examiner les
besoins des applications puis nous aborderons les
méthodes pour offrir de la qualité de service dans
les réseaux. Nous verrons deux architectures :
IntServ et DiffServ. Nous verrons que le
dimensionnement est une des notions essentielles
de ces architectures. Nous étudierons aussi les
mécanismes du réseau permettant de mettre
DiffServ en œuvre.
Pour aller plus loin, je vous invite à consulter
l’interview de Pascal Thubert qui aborde les
besoins des réseaux industriels. Ces réseaux ont
des besoins forts en QoS mais cherchent
maintenant à utiliser IP plutôt que des réseaux
dédiés. Il introduira les problèmes à résoudre pour
cela.
2
 Sommaire

SOMMAIRE
Sommaire ................................................................................................................................. 3  
1.   Leçon 1 : Applications et contraintes de QoS ................................................................... 4  
1.1.   Introduction ................................................................................................................. 4  
1.2.   En résumé .................................................................................................................. 9  
2.   Leçon 2 : Réservation de ressources vs dimensionnement ............................................ 11  
2.1.   Introduction ............................................................................................................... 11  
3.   Leçon 3 : Architecture DiffServ........................................................................................ 17  
3.1.   Introduction ............................................................................................................... 17  
3.1.   Pourquoi marquer les paquets ?............................................................................... 18  
3.2.   Le comportement EF ................................................................................................ 19  
3.3.   Qu’y a-t-il dans un routeur ? ..................................................................................... 21  
3.4.   Conséquences pour EF ............................................................................................ 21  
3.5.   En résumé ................................................................................................................ 22  
4.   Leçon 4 : Le comportement AF ....................................................................................... 23  
4.1.   Introduction ............................................................................................................... 23  
4.2.   Le comportement AF ................................................................................................ 23  
4.3.   Les mecanismes pour AF ......................................................................................... 25  
4.4.   En résume ................................................................................................................ 29  
5.   Leçon 5 : Compromis pour la mise en œuvre DiffServ ................................................... 30  
5.1.   Introduction ............................................................................................................... 30  
5.2.   Adaptation aux mécanismes offerts par les réseaux ................................................ 30  
5.3.   deploiement de politique DiffServ ............................................................................. 37  
5.4.   En resume ................................................................................................................ 40  
6.   Conclusion de la semaine 3 ............................................................................................ 42  
 

3
1. LEÇON 1 : APPLICATIONS ET CONTRAINTES DE QOS
1.1. INTRODUCTION

Pourquoi cela ne marche pas ?

Il peut y avoir de nombreuses raisons mais la principale est que : l’Internet n’offre
aucune garantie sur la façon dont il achemine nos données. Il fait au mieux, on
appelle cela le mode Best Effort

Nous utilisons de nombreuses applications pour échanger des messages, des

fichiers, regarder des films en direct ou à la demande, faire des recherches sur
Internet, garder un lien avec ses amis, faire des visioconférences, jouer, etc.…
Elles ont souvent des besoins différents

4
Prenons l’exemple des jeux ou de la visio-conférence. L’utilisation de ces
applications requiert une bonne fluidité dans les échanges de données et donc un
temps de réponse faible tout en tolérant un faible nombre de pertes.
Cela suppose donc un service réseau avec des bandes passantes et des délais
constants, des pertes limitées, des temps de parcours variant faiblement dans le
réseau.
Ces applications génèrent du trafic « temps réel »

Le mail, les transferts de fichiers n’ont pas les mêmes besoins, ils savent s’adapter à
un délai un peu plus important. L’indicateur de bon déroulement du transfert serait ici
le fait qu'il soit terminé correctement et que toutes les données aient été acheminées

5
et soient exploitables. Aucune perte n’est tolérée mais on peut en revanche attendre
le fichier un peu plus longtemps.
On dit que ce trafic est « élastique » car il est capable de s’adapter aux fluctuations
importantes du réseau. Sa seule contrainte étant de ne pas supporter de perte.

Les applications de streaming permettent de jouer une vidéo ou un fichier audio à la

demande alors qu’il se trouve stocké dans le réseau. Pour ces applications,
l’utilisateur accepte d’attendre avant que la diffusion commence mais ensuite, le flux
doit être joué de façon fluide. Pour cela, l’application qui va jouer la vidéo commence
par une phase de stockage des données au fil de leur arrivée, puis, quand elle en a
reçu suffisamment, la vidéo commence à être lue. Cela permet d’atténuer les
variations de performances du réseau. Cependant une fois que le flux commence à
être joué, les exigences de l’utilisateur sont proches du temps réel. Nous retrouvons
ici le comportement des deux types de flux précédent : au début c’est élastique mais
ensuite plutôt temps réel. On dit que ce trafic est partiellement élastique.

6
Parmi les applications que nous venons de citer, quelles sont celles que nous
utilisons le plus ?
Une étude du constructeur d’équipements réseaux CISCO datant de 2014 montre
comment se répartissent les flux dans l’Internet et l’évolution dans le temps de cette
répartition :
Tout d’abord on peut voir que le volume de données échangées a considérablement
augmenté et que cette progression continue, le trafic double tous les deux ans. Si on
regarde plus en détail, on peut voir ce sont les applications de vidéo sur Internet qui
représentent la plus grande partie du trafic, ceci dit les volumes de transfert de fichier
et de mail, et les consultations web ne sont pas négligeables.

7
Pour rendre la tâche encore plus difficile, la notion de qualité est fortement
dépendante du type d’application considéré. Nous avons déjà évoqué le fait que
selon le type de trafic, nos exigences seront différentes, nous avons cité quelques
indicateurs sur la qualité du transfert. Ceci se complique encore car selon le contexte
de cette application, les critères peuvent changer. Par exemple, un utilisateur pourra
tolérer une perte de qualité lorsqu'il regarde son film en streaming, en revanche si le
streaming vidéo est mis en œuvre dans le cadre d’une opération médicale, il n’est
pas possible que la qualité ne soit pas parfaite.

Nous avons parlé des critères qui peuvent être utilisés pour dire si la communication
s’est bien passée ou non. Mais comment peut on évaluer ces critères ?
Une façon intuitive mais complexe est de mesurer la satisfaction des usagers après
les transferts réseaux. On qualifie ainsi la Qualité d’Expérience (QoE) des utilisateurs
du réseau. Cette mesure est subjective et n’est pas facile à évaluer, on peut par
exemple utiliser des indicateurs au niveau des applications ou faire des campagnes
de notation …

8
L’alternative est de ne plus considérer de paramètre subjectifs mais d’évaluer des
paramètres mesurables dans le réseau, par exemple le nombre de paquets envoyés
ou le nombre de paquets perdus. On parle de qualité de service (en anglais Quality
of Service : QoS) : il s’agit à la fois de l’évaluation de propriétés liées aux
performances du réseau et à la différentiation des garanties offertes en fonction du
type de flux.
De façon intuitive : la qualité de service c’est pouvoir offrir des garanties de
performances aux applications en différentiant leurs besoins.

1.2. EN RESUME

9
Dans cette leçon nous avons évoqué la diversité des applications qui utilisent
l’Internet et le fait qu’elles ont des besoins très différents en terme de performance
du réseau. Nous avons également vu que le réseau n’offre actuellement aucune
garantie et fonctionne sur le mode Best Effort. Cependant plus de la moitié des flux
circulant sur le réseau ont des besoins forts de QoS. Le réseau a donc besoin d’un
mécanisme de QoS répondant à leurs besoins, les volumes de trafic étant
importants, ce mécanisme doit pouvoir passer à l’échelle.
Dans les autres leçons, nous allons voir comment un tel mécanisme peut être mis en
œuvre. Nous verrons le fonctionnement des équipements relayant les données dans
l’Internet, et comment on peut paramétrer ces équipements pour mettre en place de
la qualité de service.

10
2. LEÇON 2 : RESERVATION DE RESSOURCES VS
DIMENSIONNEMENT
2.1. INTRODUCTION
Pour bien comprendre l'enjeu de passage à l'échelle lié à la mise en place de la QoS
dans les réseaux, nous allons étudier deux modes de réservation de ressources
dans cette leçon : la réservation flux par flux ou par dimensionnement du réseau.

Prenons un exemple : Samer et Claude veulent faire une réunion à distance dans
des conditions garanties. Ils aimeraient bénéficier de qualité de service. La solution
la plus évidente serait de réserver les ressources adéquates dans le réseau le temps
de leur communication.
Pour cela il faut que l’un d’entre eux, disons Claude, fasse cette réservation en
décrivant ce dont il a besoin : « Je veux faire une visioconférence de qualité, il faut
donc réserver une bande passante de 1 Mégabit par seconde entre mon @ IP et
celle de Samer de 10h à 11h demain matin».

11
Le réseau va traiter cette demande, soit de façon distribuée, soit grâce à un
coordinateur central. La première tache sera de trouver un chemin capable de
garantir la contrainte exprimée.

Nous ne verrons pas ici comment le réseau se débrouille pour trouver ce chemin
mais une fois qu’il l’a trouvé, il faut faire la réservation.

12
Dans chaque routeur on va réserver la bande passante et indiquer que c'est une
communication entre Claude et Samer qui doit l’utiliser.
Chaque routeur fait cette réservation et stocke dans sa table de routage qui sont ses
voisins sur le chemin emprunté pour la communication. Ainsi chaque réservation se
traduit par l’ajout d’un contexte dans les routeurs.

Cela a pour conséquence d’augmenter la taille de la table de routage, ce qui a un

impact sur l'occupation de la mémoire du routeur.
Pour chaque paquet arrivant dans le routeur il faudra parcourir plus d’entrées afin de
savoir si le paquet correspond à une réservation de ressources ou s’il doit prendre le
chemin proposé par le routage classique.

13
Cela augmente le temps de traitement et a un impact non négligeable sur le délai de
traversée des paquets
Cette solution est elle réaliste ?

Des protocoles ont été définis pour rendre ces réservations possibles, ils ont été
définis à l’IETF (Internet Engineering Task Force) qui standardise tous les protocoles
de l'Internet. Ils sont utilisés dans l’architecture IntServ qui fait de la réservation flux
par flux : le réseau va devoir gérer et maintenir de nombreuses demandes
hétérogènes. Son principal avantage est d'utiliser les ressources au plus proche des
besoins, l'inconvénient est la complexité liée à la diversité des demandes à traiter, ce
qui ne facilite pas l'exploitation du réseau ou la facturation. Vu sa complexité, cette
architecture est peu utilisée et restreintes à de petits réseaux.

N’y a-t-il pas une alternative ?

14
Une seconde idée serait de préparer des offres de QoS, de les mettre en place et de
laisser les applications les utiliser ou non selon leur besoin. C'est le
dimensionnement. Cela suppose un travail au préalable de l’administrateur du
réseau pour préparer des offres de QoS qu’il proposera à ses clients. Les offres
définissent des garanties de QoS différentes entre une source et une destination.
L'administrateur va ensuite traduire ces offres en classes de service et paramétrer
les chemins correspondant dans le réseau. Il faudra aussi que les applications
connaissent les offres pour pouvoir choisir et que les paquets qu'elles envoient
puissent indiquer au réseau quelle offre ils utilisent.

15
Les applications utilisant l’Internet ont des profils de trafic et des besoins variables.
La notion de classe de service permet grouper sous une même dénomination des
applications ayant des besoins similaires en terme de garanties de services. Par
exemple, les flux de données temps réels peuvent être caractérisés par un besoin de
délais bas tout en ne subissant pas de perte, on peut ainsi regrouper les applications
de jeux en ligne, de télémédecine ou encore de visioconférences. Cette classe de
service peut être utilisée par les flux ne sachant pas s’adapter aux variations du
réseau. La classe « Best Effort » correspond au fonctionnement actuel de l’Internet
qui fait ce qu’il peut sans garantir de QoS.

L'avantage du dimensionnement est de simplifier les traitements dans le réseau lors

de l'exploitation, les inconvénients sont qu'il nécessite une bonne estimation des
demandes à venir et un surdimensionnement des ressources.
Il faut ensuite paramétrer les équipements du réseau pour mettre en œuvre les
garanties liées aux classes de services. La complexité du dimensionnement vient de
la difficulté de traduire des propriétés de QoS de bout en bout en paramétrage
d’équipements individuels. La configuration de chaque équipement sur un chemin
entre une source et une destination doit être cohérente avec les classes mises en
œuvres sur ce chemin. Cela devient encore plus difficile si les équipements n’offrent
pas tous les mêmes caractéristiques ou les mêmes possibilités matérielles.

Cette approche a été standardisée à l'IETF avec l’architecture DiffServ que nous
allons étudier avec plus d’attention par la suite.
 
 

16
3. LEÇON 3 : ARCHITECTURE DIFFSERV
3.1. INTRODUCTION
 
Dans cette leçon nous abordons l’architecture DiffServ pour Différentiation de
Service, qui permet d’offrir de la qualité de service dans les réseaux. Cette
architecture effectue de la réservation de ressources grâce à une phase préliminaire
de dimensionnement puis de configuration des équipements par l’administrateur du
réseau. L’idée de DiffServ est de concentrer la complexité dans les phases amont du
déploiement et d’avoir un fonctionnement simple à l’exécution. Au cours de cette
leçon nous verrons comment DiffServ définit les comportements des routeurs et les
outils à la disposition des applications ou des utilisateurs pour choisir une classe de
service.

L’architecture DiffServ n’est pas nouvelle, elle a été standardisée à la fin des années
90 à l’IETF. L’objectif est de pouvoir offrir de meilleures garanties que le Best Effort à
certaines applications.

17
La QoS est garantie de bout en bout, c’est à dire de la source à la destination, ce qui
veut dire que le paramétrage des réseaux traversés doit être cohérent. La complexité
est concentrée dans le dimensionnement des offres et le paramétrage, surtout dans
les équipements de bordure des réseaux.
Le principe est qu’une application va choisir une classe de service parmi celles
définies par l’administrateur pour envoyer son trafic. Cela peut être la classe Best
Effort. Les paquets de l’application porteront une marque. Cette marque permet à
chaque routeur de connaître le traitement à appliquer aux paquets. Cela permet la
différentiation des services offerts aux paquets. DiffServ définit plusieurs traitements
appelés PhB Per Hop Behavior. Nous allons en voir trois : Best Effort, EF, et AF.
Le comportement Best Effort correspond au fonctionnement de l’Internet actuel sans
aucune garantie. Il permet de traiter tous les paquets qui ne nécessitent pas de
garantie de performance particulière.

3.1. POURQUOI MARQUER LES PAQUETS ?

18
L’intérêt du marquage est de placer un code indiquant le traitement à fournir au
paquet directement dans son en-tête, ce qui n’augmente pas le temps de traitement
d’un paquet dans le routeur. C’est donc le paquet qui transporte l’information.
Suivant le protocole Réseau utilisé, l’endroit où l’on peut placer la marque diffère. En
IPv4, la marque est indiquée dans le champ DSCP (DiffServ Code Point). En IPv6, la
maque sera transportée dans le champ Traffic Class.

Qui pose la marque ?

Si c’est possible, l’application est bien placée pour marquer les paquets? Si
l’application n’est pas capable de poser la marque, alors c’est un routeur de bordure
qui le fera. Afin de poser la marque il faut déjà identifier le paquet. On pourra utiliser
les 5 tuples de l’entête IPv4 : les champs Protocole, adresse source, adresse
destination, port source et port destination. En IPv6, on dispose en plus du champs
flow label qui peu servir à identifier des paquets.

3.2. LE COMPORTEMENT EF

19
Le comportement EF pour Expedited Forwarding correspond à un traitement très
privilégié des paquets afin qu’ils ne soient pas retardés en traversant le routeur et ne
soient pas perdus.

Le routeur comporte des files d’attentes dans lesquelles les paquets attendent leur
tour pour être traités.
Ces files d’attentes sont servies dans un ordre donné par l’ordonnanceur. Par
exemple à tour de rôle, ou bien l’ordonnanceur peut être paramétré pour envoyer les
paquets d’une file tant qu’elle n’est pas vide.

20
 3.3. QU’Y A-T-IL DANS UN ROUTEUR ?

Pour mieux comprendre la mise en œuvre de DiffServ, intéressons nous au

fonctionnement du routeur. De façon schématique, la première fonction du routeur
est l’acheminement des paquets vers leur destination en les transmettant à un
prochain routeur connu grâce à la table de routage. Le routeur comporte des files
d’attentes dans lesquelles les paquets sont rangés en attendant leur tour pour être
traités. Les files d’attente fonctionnent en général en mode FIFO : « First In, First
out » : le premier paquet entré dans la file sera le premier à sortir
L’ordre et la façon de servir ces files d’attentes est donnée par l’ordonnanceur. Il peut
par exemple servir les files à tour de rôle, de façon équitable. Il peut mettre en œuvre
d’autres politiques que nous aborderons plus tard. Lorsque c’est son tour, le paquet
est transmis à la file de sortie correspondant à l’interface réseau vers le routeur
suivant sur le chemin.

3.4. CONSEQUENCES POUR EF

21
Revenons au comportement EF. Si l’on ne permet pas de retard lors de la traversée
d’un routeur, cela veut dire que le arrive sur une file d’attente vide et est servi tout de
suite. Cela est possible par exemple en mettant en œuvre une file d’attente à priorité
stricte. Si le routeur offre cette possibilité, on peut utiliser la file à priorité stricte pour
stocker les paquets EF. La propriété de cette file est d’être servie en priorité tant
qu’elle contient des paquets. Cela garantit que les paquets ne seront pas retardés
dans le routeur.

Naturellement, pour que cela fonctionne, il faut que la file d’attente prioritaire ne soit
pas remplie.

Si le routeur n’offre pas de file à priorité stricte, la solution est de sur-dimensionner

une file d’attente. L’ordonnanceur sera programmé pour servir la file du trafic EF la
plus part du temps. Cela consomme des ressources mais assure le fonctionnement
EF, même sans file à priorité stricte. Le dimensionnement est la clé du traitement EF
: s’il est mal calculé et que l’on admet trop de paquets EF dans le réseau, alors les
paquets seront plus nombreux dans les files d’attente et on augmentera le délai de
traversée des paquets. Ainsi, il faut restreindre le nombre de paquets EF dans le
réseau. Le contrôle d’admission a pour but de décider si oui ou non un paquet peut
être accepté dans le réseau sans nuire aux paquets EF déjà dans le système.

3.5. EN RESUME

Dans cette leçon nous avons vu que DiffServ définit des comportements utilisés par
les routeurs pour traiter les paquets et mettre en place la qualité de service. Nous
avons particulièrement regardé le PHB EF pour les paquets ne supportant pas d’être
retardés ou perdus. Pour cela, l’administrateur du réseau va devoir mettre en place
des mécanismes tels qu’un contrôle d’admission, pour restreindre le nombre de
paquets EF dans le réseau ou qu’un mécanisme d’ordonnancement prioritaire,

22
4. LEÇON 4 : LE COMPORTEMENT AF

4.1. INTRODUCTION

Le comportement AF de DiffServ offre des possibilités de différentiation vastes. Les

garanties sont plus faibles qu’EF mais meilleures que BE. Dans cette leçon, nous
allons étudier le comportement AF et les mécanismes qui peuvent être utilisés pour
le mettre en œuvre.

4.2. LE COMPORTEMENT AF

Nous avons vu que DiffServ définit un comportement best effort et un

comportement privilégié EF principalement pour les flux temps réels. Afin d’offrir plus
de souplesse et de s’adapter aux autres types de flux, DiffServ propose un
comportement AF pour Assured Forwarding. AF offre des garanties plus faibles,
meilleures que le Best Effort mais pouvant comporter des délais et des pertes.
DiffServ propose 4 classes de service AF sans relation d’ordre. Ces 4 classes offrent
des garanties de QoS différentes. Les paramétrages des routeurs traduisent le
contrat passé entre l’utilisateur et l’opérateur. Les garanties sur les délais et les
pertes étant faibles, l’opérateur réseau acceptera de transporter plus de paquets que
ce que le contrat spécifie, du moment que cela ne pénalise pas les autres flux. On dit
que ces paquets sont hors profile.

23
Chaque classe met en place 3 niveaux de priorité. En cas de congestion dans le
réseau le routeur va éliminer des paquets les moins prioritaires puis ceux de la
priorité moyenne, le but étant de protéger les paquets prioritaires.
A l’intérieur de chaque classe, un algorithme de rejet sélectif différencie entre 3
niveaux de priorité.
En cas de congestion dans une des classes AF, les paquets de basse priorité sont
rejetés en premier

La classe AF admet le transport de flux hors profil, il est donc important de pouvoir
classifier et marquer le trafic. Dans un premier temps, on peut se demander

24
comment faire. Afin de marquer de façon systématique, on peut utiliser une méthode
de classification des flux en fonction de leur volume.
Ici on regarde le marqueur par débit moyen, sur un intervalle de temps, il calcule le
débit moyen du flux. L’attribution des priorités est très sensible à la méthode utilisée
pour le calcul du débit moyen et à la taille de la fenêtre d’observation.

4.3. LES MECANISMES POUR AF

On peut utiliser une autre méthode grâce à un outil de mesure du profile (le profile
meter) qui a pour but d’indiquer la partie du trafic qui ne respecte pas le contrat.
L’idée, si l’opérateur le permet, est de faire transiter tout de même ce trafic mais en
priorité faible. Par conséquent, si une congestion arrive, ces paquets seront éliminés
en priorité. Le traitement des paquets non-conformes dépend du service demandé: il
peut être marqué en basse priorité, détruit ou retardé.

25
Le routeur peut utiliser un mécanisme appelé « seau à jeton » pour examiner la
conformité des flux. Un seau contient les jetons disponibles qui seront consommés
par les paquets. Lorsqu’un paquet arrive sur le seau à jeton, on commence par
regarder si un jeton est disponible. Si tel est le cas, le paquet est conforme au contrat
négocié, il consomme le jeton et est traité. Si le sceau est vide, alors ce paquet est
en excédent par rapport au contrat. Le seau est rempli au rythme de r jeton qui
correspond au volume de trafic autorisé par le contrat.
Le routeur pourra alors soit marquer ce paquet avec une classe moins importante,
soit le détruire. Grace au seau à jeton nous pouvons différentier 2 niveaux de priorité
pour nos paquets. Pour avoir trois niveaux, on peut mettre deux seaux à jeton en
série.

26
Nous avons regardé comment attribuer les priorités, nous pouvons maintenant voir
comment les utiliser pour réguler l’occupation des files d’attentes dans les routeurs
en cas de congestion. Le mécanisme de gestion de files d’attente RED (Random
Early Discard) permet de freiner le remplissage d’une file d’attente en commençant à
détruire certains paquets sans attendre l’arrivée de la congestion. Lorsque le
remplissage de la file dépasse un seuil th_min, un tirage avec une probabilité Pmax
est fait lors de l’arrivée des paquets. Au dessus d’un seuil th_max, les paquets qui
arrivent sont détruits. Mais comment fait on avec trois niveaux de priorité ?

Nous pouvons prendre les trois priorités en compte en prenant le mécanisme WRED
qui correspond à trois RED s’exécutant en parallèle. Le principe du mécanisme est
assez simple, cependant on peut remarquer qu’avec trois couleurs, il faut déjà 7
paramètres !

27
Le mécanisme d’ordonnancement permet de servir les files d’attentes du routeur
selon des politiques définies. Cela a pour conséquence de partager la bande
passante entre les flux empruntant ce routeur. Si avec EF la politique était de
favoriser des files d’attente quasi vides, ici il s’agit de répartir les ressources entre
tous les flux. La politique la plus simple est FIFO (first in first out) qui sert les paquets
dans leur ordre d’arrivée. Le Round Robin va attribuer les ressources de façon
équitable entre les files d’attente, ce qui n’est pas forcément ce que l’on souhaite
quand on fait de la qualité de service. Le Weighted Round Robin garde cette notion
d’équité mais le poids associé à chaque file permet de jouer sur les métriques.

28
Le Round Robin va attribuer les ressources de façon équitable entre les files
d’attente, ce qui n’est pas forcément ce que l’on souhaite quand on fait de la qualité
de service.

4.4. EN RESUME

Dans cette leçon, nous avons abordé la classe AF qui offre une grande palette de
service avec 4 classes différentes ayant chacune 3 niveaux de priorité. L’un des
avantages de AF est que le réseau accepte de transporter des paquets
supplémentaires tant que cela ne perturbe pas le service des autres flux. Cela a des
conséquences bénéfiques sur les temps de traversée du routeur car le marquage
comme paquet hors profil est moins coûteux que de retarder le paquet pour qu’il soit
conforme au contrat. En revanche le paramétrage de tous les mécanismes est
complexe. De plus, la qualité reçue par les flux dépend beaucoup des flux
concurrents sur le réseau.
 
 
     
 
 
 
 

29
5. LEÇON 5 : COMPROMIS POUR LA MISE EN ŒUVRE
DIFFSERV
5.1. INTRODUCTION
Dans cette leçon, nous allons nous allons voir comment mettre en œuvre DiffServ,
en particulier nous allons traiter de la cohabitation des différents flux dans les
réseaux. Nous verrons comment déployer les différents mécanismes nécessaires en
entrée et en cœur de réseau. Nous discuterons des compromis à trouver quand le
matériel n’offre pas les mécanismes escomptés.

Prenons l’exemple d’un réseau IP dans lequel l’administrateur veut mettre en place
de la qualité de service grâce au protocole DiffServ. Son premier travail va être de
recenser les flux et de déterminer dans quelles classes de services ils vont être
assignés. Ensuite il va créer les configurations des équipements de son réseau.
Dans notre exemple, l’administrateur met en œuvre trois classes de service basées
sur les comportements EF, AF et Best Effort.

5.2. ADAPTATION AUX MECANISMES OFFERTS PAR LES RESEAUX

30
Ce schéma résume l’architecture fonctionnelle de DiffServ.

La machine de l’utilisateur est un des principaux acteurs de l’architecture, elle va

émettre du trafic et est donc la mieux placée pour choisir la classe de service et
mettre le flux en conformité.

31
Le routeur en bordure du réseau d’opérateur est un autre acteur essentiel, à noter
que ce peut être le routeur d’entrée du réseau de l’opérateur ou bien le routeur de
sortie du réseau de l’utilisateur si l’opérateur lui fait confiance, voire les deux. Ce
routeur de bordure va préparer le paquet pour l’utilisation de DiffServ si l’application
n’a pas pu le faire elle même. Il peut effectuer le marquage et va probablement
effectuer la vérification de conformité du flux. L’action prise en cas de non conformité
dépendra de la politique de l’administrateur du réseau d’opérateur.

Lorsque l’application sait marquer les paquets elle le fait, sinon c’est le routeur
d’entrée du réseau qui va le faire. La vérification de la conformité des flux se fait en
bordure de réseau, dans le routeur d’entrée du réseau d’opérateur.

32
En plus de leur rôle de relais, les routeurs de cœur mettent en place des fonctions de
répartition de la bande passante et essayent d’éviter les congestions en gérant le
remplissage des files d’attente. Enfin les routeurs de cœur de réseau ont un rôle
important puisqu’ils exécutent la politique de QoS configurée par l’administrateur. Ils
gèrent les files d’attentes, mettent en œuvre l’ordonnancement afin d’envoyer le
paquet vers le prochain saut.

Rappel :

33
Le marquage est l’action d’insérer, dans l’en-tête IP, une valeur que les équipements
du réseau sauront interpréter et traduire en comportement. La qualité de service doit
être valable de bout en bout, il faut donc que tous les équipements sur le chemin
puissent comprendre cette marque, sa valeur a donc été standardisée.

Pour insérer la marque, plusieurs solutions ont possibles. La première est que
l’application est capable d’indiquer la classe de service à utiliser, les paquets IP
seront forgés avec la marque dans la machine émettrice.

Une autre solution, si l’application ne sait pas le faire est de demander à un routeur
proche de la source sur le chemin de faire ce marquage. Il utilisera pour cela des

34
access-lists. Ces access-lists sont en général utilisé par les firewall pour identifier
des trafics. Elles sont comme un filtre qui permet de repérer un ensemble de paquet
IP répondant à une même caractéristique. Par exemple une access-list peut identifier
tous les paquets IP provenant d’une source donnée, ou allant vers une certaine
destination.
Les routeurs permettent de coupler ces access-lists avec des politiques de QoS.

L’autre mécanisme important à l’entrée du réseau de l’opérateur est la vérification de

conformité.

35
Si une partie du flux est non conforme, cela veut dire qu’on ne respecte pas le SLA
avec le fournisseur. L’action à prendre pour ce trafic non conforme dépend de la
classe de service. Dans le routeur on va paramétrer une politique de QoS qui va
indiquer les volumes de données acceptées en entrée et deux niveaux d’action : que
faire quand on envoie un trafic légèrement supérieur ? Que faire quand le volume de
trafic est vraiment trop grand.

Si c’est un paquet devant recevoir le comportement AF, l’opérateur peut laisser

passer le trafic en léger excès tout en marquant ces paquets comme prioritaire à la
perte, les paquets violant vraiment le SLA pourront être détruits.

36
En revanche si c’est un paquet EF, l’opérateur fera du contrôle d’admission, c’est à
dire qu’il retardera ou détruira le paquet non conforme.

5.3. DEPLOIEMENT DE POLITIQUE DIFFSERV

Le travail de l’administrateur de machine en entrée de réseau est donc de

paramétrer les access lists pour filtrer les flux et de leur associer un mécanisme tel
que le seau à jeton pour savoir si les flux respectent le SLA ou non.

37
L’administrateur du réseau doit créer et maintenir les configurations des routeurs de
cœur.
Après avoir recensé le trafic circulant sur le réseau, il va identifier les classes de
service utilisées et préparer le traitement des paquets.

Le premier travail sera d’attribuer les files d’attente de ses équipements aux flux. Si
ses équipements disposent de suffisamment de files d’attente, il va attribuer une file
d’attente différente à chaque classe de trafic. Cela permettra au routeur d’isoler les
paquets d’une même classe et de leur attribuer le comportement prévu. S’il ne
dispose pas d’un nombre suffisant de file d’attente, il devra regrouper des flux en
fonction de leurs caractéristiques. Par exemple, si les équipements ne disposent que

38
de deux files utilisables, l’administrateur essaiera de regrouper les flux. Pas question
de mélanger les flux EF avec du Best Effort, les flux EF doivent être traité de façon
très prioritaire. Il est probable que dans ce cas, une file sera attribuée à EF et que la
deuxième sera utilisée par les flux Best Effort et AF.
Afin d’éviter de pénaliser les applications utilisant TCP ou nécessitant une arrivée
ordonnée des paquets, les paquets d’un même flux utiliseront la même file d’attente.

L’administrateur doit encore paramétrer la politique de gestion des files d’attente.

Rappelons ici que ces files ont une taille finie et que lorsqu’un paquet se présente en
entrée d’une file pleine, il est détruit. Dans le cadre de AF on peut paramétrer un
mécanisme tel que WRED pour gérer le remplissage de la file. Ce mécanisme
permet de rejeter en premier les paquets de basse priorité. En revanche, ce
mécanisme ne doit pas être utilisé pour le trafic EF qui ne doit pas compter de perte.

39
Le dernier mécanisme à paramétrer dans le routeur de cœur est l’ordonnanceur. Les
algorithmes disponibles peuvent varier selon le constructeur de l’équipement. Si le
routeur dispose d’une file à priorité stricte, alors elle sera réservée pour le trafic EF.
Dans le cas contraire, il faudra attribuer une file classique à EF mais sur-
dimensionner la bande passante qui lui sera attribuée par l’ordonnanceur. L’idée est
de vider le plus souvent possible la file pour que le paquet EF arrive dans une file
vide la plus part du temps. Pour les classes AF, l’administrateur va répartir la bande
passante du lien de sortie selon les performances qu’il désire attribuer aux différents
flux AF. Il programmera le mécanisme d’ordonnancement en accord avec ce
dimensionnement.

5.4. EN RESUME

40
41
6. CONCLUSION DE LA SEMAINE 3

Pendant cette semaine, nous avons vu comment mettre en place des solutions de
qualité de service grâce à la réservation de ressource. Nous avons vu que sa
particularité est de ne pas gérer les micro-flux mais de regrouper les flux en classes
de services. Cela permet de s’appuyer sur une phase de dimensionnement et de
passer à l’échelle.

Selon le type de trafic les garanties de QoS offertes à la classe seront plus ou moins
souples. DiffServ est standardisé depuis de nombreuses années et implémenté dans
les routeurs. Cependant il n’existe pas d’offre grand publique pour bénéficier de QoS.
Cela peut être du à l’absence de modèle économique associé à DiffServ.
Le fait que DiffServ offre un grand nombre de paramètres à régler dans chaque
équipement et que la politique doit être globale rend son déploiement complexe dans
un réseau.

De plus, un déploiement à l’échelle de l’Internet nécessiterait une coopération des

opérateurs, Standardiser la marque DiffServ ne suffit pas, il faut en plus garantir la
cohérence globale des configurations individuelles des équipements de chaque
opérateur.

Cependant DiffServ continue à susciter de l’intérêt et de nouveaux comportements

ont été proposé. En particulier, il peut être couplé avec des solutions d’ingénierie de
trafic, offrant une palette importante pour gérer les flux selon les besoins.
 
 

42
43
44
46, rue Barrault
75634 Paris Cedex 13
France
Tél. +33 (0)1 45 81 80 80
www.mines-telecom.fr