Chapitre 3 Mécanismes de Qos Internes Aux Équipements: Présenté Par DR BOUYAKOUB

CHAPITRE 3
MÉCANISMES DE QOS INTERNES AUX

ÉQUIPEMENTS
Présenté par Dr BOUYAKOUB
bouyakoub.f.m@gmail.com
La QoS, d'une vision locale à une vision globale
Efficacité
Planification
Techniques
Vision globale d'ingénierie des
macroscopique trafics
Outils
Signalisation d'administration
QoS stratégique
Contrôle de
MPLS
congestion TCP
(MultiProtocol
Gestion de la Label Switching )
QoS sur les Modèle de QoS
équipements IntServ et
Vision locale DiffServ
Réseau IP
microscopique
routeur Temps
Quelques ms Quelques Quelques Quelques Quelques
dizaines de ms centaines de ms secondes à semaines à
quelques quelques mois
minutes
L3-GTR: Vue générale des mécanismes de QoS 2
Principes de fonctionnement d'un routeur
standard
Fonctionnement d'un routeur standard (1)
▪ Un routeur standard comporte les 3 composants suivants:

1. Des interfaces d'E/S: permettent de recevoir les paquets en
provenance d'autres routeurs et de les envoyer vers d'autres
routeurs.
2. Un mécanisme d'acheminement: en fonction de l'@ de destination
contenue dans le paquet, le mécanisme d'acheminement consulte
la table de routage pour trouver le chemin à suivre.
 Si une correspondance est trouvée, l'entrée de la table précise au
mécanisme d'acheminement l'interface de sortie qui doit être utilisée.
 Si aucune correspondance n'est trouvée, le paquet est détruit.
La table de routage est mise à jour par un protocole de routage qui
fait partie du mécanisme de gestion du routeur
3. Un mécanisme de gestion: il prend en charge le protocole de
routage mais également les fonctions d'administration du routeur
(collecte de données…).
L3-GTR: Mécanismes de QoS internes aux équipements 4
▪ Initialement les routeurs ne comportaient qu'un seul

processeur dédié à:
 l'acheminement des paquets;
 l'exécution du protocole de routage;
 l'administration de l'équipement.
▪ Les routeurs d'entrée de gamme sont toujours

monoprocesseur mais la plupart des routeurs ont
évolué vers des architectures multiprocesseur
permettant de distribuer les fonctions
▪ Les routeurs des réseaux à haut débit disposent de processeurs
d'acheminement distribués sur les cartes d'interface
▪ Le processus d'acheminement (forwarding) qui consiste à trouver dans la
table de routage une entrée correspondant à l'@ de destination du paquet
IP a longtemps constitué un facteur différenciateur important entre
routeurs.
▪ A ce jour de nombreux algorithmes ont été développés et mis en œuvre
dans des composants matériels afin d'accélérer ce processus ➔ la vitesse
de traitement des paquets ne représente donc plus aujourd'hui un
problème
▪ La comparaison sur les routeurs se fait sur les solutions de QoS intégrées.
 Les routeurs standard disposent d'une simple file d'attente en sortie de type FIFO par
interface pour faire face à la congestion temporaire d'un lien ➔ si la congestion dure
(file d'attente pleine) les paquets sont détruits.
 Les routeurs supposent que les couches supérieures (TCP) au sein des terminaux des
extrémités réagiront en conséquence.
 Cette solution est acceptable pour certains types de trafic mais pas pour des trafics
avec des contraintes de délai ou de gigue.
➔ intégrer des solutions de QoS permettant aux routeurs de traiter certains trafics
de manière spécifique

Principes de fonctionnement d'un routeur
avec QoS
Architecture des réseaux avec QoS (1/2)
Dans les réseaux à QoS, on distingue deux types de
routeurs avec des fonctions différentes:
1. Les routeurs de cœur, qui font du routage et
appliquent la stratégie de gestion de la QoS décidée
par l'opérateur.
2. Les routeurs de bord, qui effectuent l'admission, les
opérations de filtrage et de marquage pour la QoS,
le lissage de trafic ou la mise en conformité de flux.

Architecture des réseaux avec QoS (2/2)
Routeurs d'accès
(Edge router)
Routeurs de Cœur
(Core router)
Réseau d'accès
Réseau d'accès
Réseau Cœur

Fonctions d'un routeur supportant la QoS
Les routeurs mettant en œuvre des fonctionnalités de

QoS requièrent quelques spécificités:
1. Ils doivent posséder toute une logique de traitement des
trafics faisant appel à un certain nombre d'algorithmes de
traitement ;
2. La disponibilité de plusieurs files d'attente par interface
de sortie

Traitements réalisés par un routeur QoS
▪ Un routeur implémentant des fonctionnalités de QoS
doit alors proposer quatre étapes de traitement:
 La classification des paquets: Etablir les caractéristiques et
effectuer la recherche d'une entrée dans la table de routage
pour déterminer son interface de sortie et sa file d'attente
(parmi toutes les files d'une interface donnée).
 Le contrôle (policing) et marquage (marking): cette étape sert
à déterminer si le trafic entrant est conforme au profil de trafic
prévu. Dans la négative, le paquet peut être éliminé ou marqué.
 La gestion des files d'attente (queuing): cette étape permet
d'influencer les émetteurs pour les inviter à réduire le trafic en
cas de congestion.
 L'ordonnancement (scheduling): cette dernière étape
achemine les paquets en fonction de la classification réalisée et
du contrôle de trafic en sortie.

Routeur QoS
Routeur QoS
II Paquets
III
Table de sortants
routage IV
Paquets
entrants Int Sortie 1
I
Acheminement
Paquets (sélection de
entrants l'interface de Paquets
sortie) III
I sortants
IV
Int Sortie N
1 2 3 4
Classification Contrôle Gestion des Ordonnancement
des paquets files d'attente des paquets
Détail des fonctionnalités et des
mécanismes associés

1. La classification des paquets

2. Contrôle, marquage et lissage du trafic
3. La gestion des files d'attente (queuing)
4. L'ordonnancement (scheduling)

La classification
▪ La classification des paquets dans un but de QoS fait
appel à des informations contenues dans le paquet
lui-même.
▪ La classification peut s'établir à partir d'un champ

simple ou de la combinaison de plusieurs champs
(Multifield ou MF Classification).
▪ La classification simple se fonde sur le champ TOS du

paquet IP ou son équivalent DSCP (Differentiated
Service Code-Point) dans un réseau DiffServ.

Classification simple à partir du champ TOS
▪ La structure du champ TOS est la suivante:
7
0 1 2
Precedence D T R C 0
▪ Les champs "precedence" sur 3 bits permet d'indiquer 8

niveaux de priorité (de 000 la plus faible priorité, à 111 la plus
forte)
▪ Les bits DTRC servent à déterminer le mode de transport du
datagramme
 D = délai court
 T = débit élevé
 R = transport fiable
 C = Coût minimal

Classification simple à partir du champ DSCP
▪ Dans le modèle DiffServ, le champ TOS a été redéfini.
Il comprend deux sous champs:
 La partie DSCP (Differentiated Services Code-Point) sur 6
bits qui permet d'obtenir 64 valeurs différentes applicable
à un paquet.
 Un partie ECN (Explicit Congestion Notification) ou
notification explicite de congestion, codée sur 2 bits.
0 1 2 3 4 5
6 7
DSCP ECN

Classification multichamps
▪ Ce type de classification permet d'effectuer une
classification sur plusieurs champs du paquet IP;
▪ La classification multichamps s'opère généralement
sur les champs suivants:
 @ IP source
 @ IP destination
 TOS
 Port source et destination de l'en-tête TCP
 ….

Classificateur d'un routeur d'accès et cœur
▪ La charge du classificateur est fonction:
 De la complexité de ses traitements;
 Du nombre de flots qui le traverse (si une classification
opère par flot et non par classes de services);
 Des règles de gestion de QoS à appliquer.
➔Il faut un compromis entre l'efficacité et la mise en œuvre
de la gestion de QoS.
▪ Le classificateur d'un routeur de cœur peut être plus

simple que le classificateur d'un routeur d'accès.
➔ les classificateurs du cœur s'appuient sur le travail
fait par les classificateurs d'accès.


Contrôle et marquage du trafic (1/3)
▪ La seconde phase de traitement dans un routeur QoS est
la phase de contrôle (policing) et de marquage (marking)
du trafic
But:
Déterminer si le flux reçu est conforme à un profil de
trafic convenu à l'avance (contrat de service convenu
avec l'opérateur) et à marquer le trafic non conforme.
Que faire du trafic non conforme?

▪ Destruction des paquets non conformes
▪ Transmission en mode best-effort
▪ Marquage pour candidat à la destruction
Trafic non conforme marqué mais transmis
Trafic non
Contrôle
conforme
Trafic reçu
Niveau de
Trafic reçu
marquage
Trafic
conforme
temps temps

Trafic supprimé (> PIR)
MBS
Trafic marqué et
Trafic reçu
transmis (>CIR et
< PIR) sans
CBS garantis
Trafic conforme
(< CIR)
temps
CIR: Committed Information Rate
CBS: Committed Burst Size
EIR : Excess Information Rate
PIR: Peak Information Rate
MBS: Maximum Burst Size
Lissage du trafic
▪ Le flot de données peut devenir aléatoire,
rafales/saccades avec des données de tailles variables
➔ idéalement, il faudrait émettre et transférer des
données de taille identique, à un rythme uniforme
(particulièrement dans le contexte du multimédia)
▪ Le lissage du trafic (traffic shaping) consiste à réguler la

vitesse et le cadencement des données passant à travers
un routeur.
▪ Le lissage de trafic est utilisé habituellement pour le
contrôle de débit afin d'éviter la congestion d'un réseau.

Contrôle du trafic versus lissage du trafic
Contrôle
seuil
Trafic
Trafic
temps temps
Lissage
seuil
Trafic
Trafic
temps temps

Les techniques de contrôle et lissage du
trafic
▪ Il existe deux techniques pour le contrôle et le lissage

du trafic:
 Le Leaky Bucket (seau percé)
 Le Token Bucket (seau à jetons)

Le mécanisme du Leaky Bucket (1)
▪ Ce mécanisme permet de contrôler le

trafic au travers d'un nœud ➔
contrôler le débit des paquets reçus
ou émis
▪ Il permet de contrôler le nombre de

paquets par seconde passant par un
nœud. Il est utilisé en particulier
pour fluidifier des échanges
irréguliers (lissage) ou pour limiter un
débit (contrôle).

▪ Soit un seau percé en son fond
▪ Si le seau n'est pas vide alors le contenu coule avec un
débit constant.
▪ La taille du seau représente la quantité d'informations
qui peut y être stockée, mesurée en nombre de
paquets.
▪ Lorsqu'un paquet arrive, et s'il reste suffisamment
d'espace dans le seau, il y est stocké. Sinon, le seau
déborde (paquet en excès).
▪ Les paquets en excès sont en général jetés. Ils peuvent

aussi être mis en attente, ou marqués comme non-
conformes avant d'être envoyés.
paquet
paquet paquet paquet
paquet
Flux entrant de
paquet
caractéristiques
paquet variables
paquet paquet
paquet paquet
Suppression des paquets en cas

de remplissage du seau
paquet paquet
paquet
Le seau permet de réguler des

débits d'eau variables en des Flux sortant contrôlé
débits d'eau réguliers en sortie paquet

Inconvénient du Leaky bucket
▪ L'inconvénient de ce mécanisme est le fait que le

débit de référence (débit en sortie) n'est pas réglable
➔ il peut donc en résulter une utilisation inefficace
du réseau quand ce dernier n'est pas chargé

Exercice
▪ Soit un ordinateur désirant envoyer un fichier d'une
taille de 19,5 MØ avec un debit de sortie de 6Mb/s.
Le débit de référence (débit de sortie) d'un routeur
utilisant la technique du seau percé est de 4Mb/s.
▪ Calculer la capacité du seau afin d'éviter toute perte

de données.
▪ But de la solution: déterminer la quantité de

données en E et en S du routeur afin de déterminer
un éventuel surplus

Solution
a) Calculer le temps nécessaire pour l'envoi du fichier:
L'ordinateur a un débit de sortie de 6Mb/s et la taille du
fichier est 19.5 MØ:
6Mb -------------> 1 s x = (19.5 * 8 *1)/6 = 26 s
19.5 MØ -------------> x s
b) Calculer la quantité de données envoyées par le routeur
en 26 s sachant que le débit de référence est 4Mb/s
4Mb -------------> 1 s
x = (26 *4)/1 = 104 Mb = 13 MØ
y Mb -------------> 26 s
c) Surplus de données ?
➔ 19.5 – 13 = 6.5 MØ

Le mécanisme de Token Bucket (1)
▪ Le mécanisme du seau à jetons est un mécanisme qui
indique à quel moment le trafic peut être émis en
fonction des jetons présents dans le seau
▪ Les jetons sont en relation avec le profil du trafic
▪ A la différence du mécanisme précédent, il autorise la
transmission des pics de trafic tant que le seau contient
des jetons
▪ On peut utiliser plusieurs Token Bucket ➔ utilisation
d'un classificateur de trafic pour la gestion des seaux
▪ Chaque seau dispose d'un seuil de débit max différent
(selon le nombre de jetons) permettant ainsi différentes
classes de trafic d'être contrôlées de manière
indépendante

Le mécanisme de Token Bucket (2)
paquet
Jeton
paquet
Ajout de paquet
jeton Jeton
chaque t sec paquet paquet
Jeton
Jeton
Jeton
paquet
paquet
paquet

Principe de fonctionnement
▪ Un jeton est ajouté au seau chaque T secondes
▪ Le seau peu contenir au maximum b jetons
▪ Si un jeton est généré pendant le remplissage du seau, il
sera éliminé
▪ Lors de la réception d’un paquet de n octets, n jetons
seront supprimés du seau, et le paquet sera envoyé
▪ S’il existe moins de n jetons, les jetons ne seront pas
supprimés, et le paquet sera considéré comme non
conforme:
 Le paquet peut être supprimé
 Mis en file d’attente pour une éventuelle transmission lors de la
disponibilité de jetons
 Transmis, en étant marqué non conforme, avec possibilité de
suppression en cas de surcharge du réseau

Exercice
▪ Soit un seau à jetons dont la capacité de la file
d'attente est de 4 paquets.
▪ Le seau, initialement plein, génère des jetons avec
une fréquence de 1 jeton/ms et le nombre maximum
de jetons dans le seau est 3.
▪ Nous supposons que la génération des jetons
s'effectue avant toute opération et que le temps
d'envoi d'un paquet est négligeable.
▪ Soit le tableau suivant donnant l'instant d'arrivée des
paquets.
▪ Compléter le tableau en remplissant les colonnes
vides
Solution
Paquet Instant d'arrivée (ms) Instant d'envoi (ms) Nombre de jetons File d'attente
0 3 vide
1 1 1 2 vide
2 1.1 1.1 1 vide
3 1.5 1.5 0 vide
4 2 2 0 vide
5 2.7 3 0 5
6 2.9 4 0 5,6
7 3 5 0 6,7
8 3.1 6 0 6,7,8
9 3.2 7 0 6,7,8,9
10 3.5 supprimé 0 6,7,8,9



Gestion des files d'attente
▪ Afin d'obtenir un traitement optimal des trafics, il est

nécessaire de maintenir une occupation minimale
des files.
▪ Les files présentent deux inconvénients majeurs:

 Elles limitent les possibilités de prise en compte des pics de
trafics
 Elles augmentent le délai de traitement d'un paquet au
sein d'un routeur et sont responsables d'un mauvais délai
de transfert sur le réseau

Objectifs
▪ Pour réduire la taille des files d'attente, il est

nécessaire de faire appel à des mécanismes de
gestion actifs sur les trafics qui font pression sur
l'émetteur pour réduire son débit d'émission
▪ Ces mécanismes ne peuvent éviter la congestion qu'à

moyen terme. Le court terme doit être traité par les
mécanismes de files d'attente propres aux
équipements

Prévention explicite de la congestion
▪ Les informations de congestion sont incorporées dans les
paquets à destination de l'émetteur pour lui signaler la
congestion et l'inviter à baisser son débit d'émission.
▪ Solution possible:
pour éviter l'encombrement, les trames utilisent un bit
de notification de congestion explicite retardé BECN
(Backward Explicit Congestion Notification) et un bit de
notification de congestion avancé FECN (Forward Explicit
Congestion Notification)
▪ Le bit BECN avertit la station émettrice d'un
encombrement potentiel lorsque les files d'attente sont
longue et invite l'utilisateur à limiter les flux de trames.
▪ Le bit FECN avertit la station réceptrice d'éventuels
retards futurs
Les bits BECN et FECN
congestion Bit FECN
Emetteur Récepteur
Bit BECN

Politiques d'évitement de congestion dans
les routeurs
▪ Plusieurs politiques proposées pour éviter les états

de congestion des files d'attente
▪ RED, WRED, RIO, ARED, FRED…
▪ Toutes ces politiques sont basées sur RED

RED: Random Early Detection (1/2)
▪ C'est le mécanisme le plus utilisé sur les routeurs pour contrôler le
trafic TCP/IP
▪ Il consiste à observer le taux d'occupation d'une file d'attente et à
éliminer progressivement et aléatoirement les paquets au-delà d'un
certain seuil (seuil min)
▪ Plus le taux d'occupation de la file d'attente augmente, plus la
probabilité d'élimination des paquets augmente
▪ Afin d'éviter une congestion totale, la probabilité d'élimination est de
100% avant d'atteindre une saturation de la file d'attente.
▪ L'élimination aléatoire des paquets est efficace à condition que d'une
part la plupart des flux qui provoquent la congestion utilisent le
protocole TCP et non UDP et d'autre part que les paquets éliminés
appartiennent au flux TCP
▪ Ces conditions sont vérifiées dans la mesure où une grande partie
des trafics IP actuels se base sur TCP (transfert de fichiers)

RED: Random Early Detection (2/2)
1
Probabilité d'élimination
0
0% Seuil min Seuil max 100%
Taux d'occupation de la file d'attente

RED versus Drop Tail(1/2)
Probabilité de Probabilité de
suppression suppression
1 1
0 0
Seuil Min Seuil Max Taille Max

RED versus Drop Tail(2/2)
▪ Fonctions de suppression pour RED et Drop Tail
 RED
0 𝑠𝑖 𝑇𝑀𝑜𝑦 < 𝑠𝑒𝑢𝑖𝑙 𝑀𝑖𝑛
𝑆𝑢𝑝 𝑇𝑀𝑜𝑦 = ቐ1 𝑠𝑖 𝑇𝑀𝑜𝑦 > 𝑠𝑒𝑢𝑖𝑙 𝑀𝑎𝑥
𝑃 𝑠𝑖 𝑠𝑒𝑢𝑖𝑙 𝑀𝑖𝑛 ≤ 𝑇𝑀𝑜𝑦 ≤ 𝑠𝑒𝑢𝑖𝑙 𝑀𝑎𝑥
 Drop Tail
0 𝑠𝑖 𝑇𝐹𝑖𝑙𝑒 < 𝑇𝑎𝑖𝑙𝑙𝑒 𝑀𝑎𝑥

𝑆𝑢𝑝 𝑇𝐹𝑖𝑙𝑒 = ቐ
1 𝑠𝑖 𝑇𝐹𝑖𝑙𝑒 > 𝑇𝑎𝑖𝑙𝑙𝑒 𝑀𝑎𝑥

Algorithme de RED
RED()
{
pour chaque paquet arrivé faire
Calculer la taille moyenne de la file();
Si ((TMoy >= SeuilMin) et (TMoy =< SeuilMax))
alors CalculerProbabilitéSuppression();
sinon si (SeuilMax ≤ TMoy)
alors SupprimerPaquet()
fsi
fsi
fait
}

WRED: Weighted Random Early Detection (1)
▪ Cette solution est une amélioration de l'approche
précédente
▪ Le principe est d'éliminer en premier lieu dans une file
d'attente les paquets appartenant à certains types de
trafic
▪ Il est aussi possible de disposer pour une même file
d'attente de seuils de déclenchement de l'élimination de
trafics différents en fonction des types de trafic.
▪ Dans les routeurs Cisco, les trafics faiblement prioritaires
auront un seuil de déclenchement beaucoup plus faible
que des trafics dotés d'un niveau de priorité supérieur
▪ Utilisation du bit IP Precedence pour mettre en place 8
niveaux de déclenchement

WRED: Weighted Random Early Detection (2)
1
Probabilité d'élimination
0
0% Seuil Seuil Seuil Seuil Seuil Seuil 100%
min max min max min max
Taux d'occupation de la file d'attente
RIO: Random Early Detection with In/Out
▪ C'est une amélioration de WRED
▪ Cette approche suppose deux seuils différents de

mise en œuvre de l'élimination de paquets: un pour
les paquets In (paquets qui respectent le contrat de
trafic: In Profile) et l'autre pour les paquets Out
(paquets qui ne respectent pas le contrat de trafic:
Out Profile)

ARED: Adaptive Random Early Detection
▪ C'est une amélioration de l'approche RED
▪ Au fur et à mesure que le nombre de flux TCP

augmente, il est nécessaire que l'élimination
progressive de trafic soit de plus en plus agressive et
non linéaire comme dans le cas de RED

FRED: Flow Random Early Detection
▪ Dans cette approche, l'élimination de paquets tient

compte de la façon dont les applications vont réagir à
la perte de paquets.
➔En fonction du délai aller-retour entre émetteur
et récepteur, certaines applications réagiront plus
lentement que d'autres à la perte de paquets



L'ordonnancement
▪ L'ordonnancement consiste à vider les files d'attente

vers l'interface de sortie du routeur.
▪ Plusieurs politiques d'ordonnancement sont

implémentées au niveau des routeurs
 FIFO
 Priority Queuing
 Class-Based Queuing ou Custom Queuing
 Weighted Fair Queuing
 …

FIFO: First In First Out
▪ Mode de gestion par défaut le plus couramment
utilisé dans les routeurs de base
▪ Consiste à stocker les paquets quand le réseau est

saturé et à les transmettre lorsque ce dernier n'est
plus congestionné dans l'ordre de leur arrivée
▪ Il n'y a pas de priorité entre les paquets et les sources

de trafic importantes en volume peuvent lourdement
pénaliser les applications sensibles en délai
d'acheminement

FIFO+ (1)
▪ FIFO+ a les mêmes caractéristiques que la politique FIFO:
simplicité d'implémentation et utilisation d'une file
unique.
▪ Dans FIFO+ nous rajoutons un élément de QoS ➔ le
délai
▪ Le principe de l'ordonnanceur FIFO+ est le suivant:
 Au niveau de chaque nœud, on mesure pour chaque classe, le
délai moyen des paquets ;
 Puis pour chaque paquet, on calcule la différence entre le délai
mesuré et la moyenne mesurée par classe;
 On rajoute à l'en-tête du paquet, un champ contenant la valeur
de cette différence ➔ Déterminer si le paquet est en retard ou
non;
 Le nœud insère le paquet dans la file en fonction de son temps
effectif et son temps estimé ➔ Ainsi, les paquets qui arrivent
plus tôt que la moyenne sont placés en queue de file, et ceux
qui arrivent avec du retard sont placés en tête de la file.
FIFO+ (2)
Arrivée des
paquets T < Tmoy Tmoy < T
Calcul du délai et du
délai moyen + insertion FIFO+
du champ

Priority Queuing (1)
▪ Mécanisme permettant d'allouer de façon stricte une
priorité à des trafics importants
▪ Utilisation des critères de classification des paquets

(champ TOS/DSCP et multichamps) et les méthodes
de prévention des états de congestion (RED,WRED…)
▪ La file d'attente de haute priorité est

systématiquement privilégiée par le mécanisme de
transmission

▪ Dans un routeur Cisco, chaque interface de sortie a 4
files pour ordonnancer les paquets.
▪ Les 4 files sont ordonnancées statiquement avec

priorités absolues
▪ Les priorités sont dites "absolues" car la file 1 est

moins prioritaire que la file 2, qui elle-même est
moins prioritaire que la file 3…

Algorithme PQ
Ordonnanceur-PQ ()
{
tq (vrai) faire
{
tq (file PrioritéHaute !vide) faire EnvoyerPaquetPH ( ) fait
si ((file PrioritéMoyenne !vide) et (file PrioritéHaute vide))
alors EnvoyerPaquetPM()
sinon si ((file PrioritéNormale !vide) et (file PrioritéHaute vide) et
(file PrioritéMoyenne vide))
alors EnvoyerPaquetPN()
sinon si ((file PrioritéBasse !vide) et (file PrioritéHaute vide) et
(file PrioritéMoyenne vide) et (file PrioritéNormale vide))
alors EnvoyerPaquetPB()
fsi
fsi
fsi
fait
}
}
Files d'attente (buffers)
Classification
Priorité haute
Priorité moyenne File

Transmission d'attente
de sortie
Priorité normale
Priorité basse

▪ Avantages:
 Simplicité, rapidité et faible coût au niveau du système
d’exploitation routeur;
 Les priorités absolues permettent de privilégier de manière
absolue un trafic par rapport à un autre.
▪ Inconvénients :
 L'ordonnancement statique (classifier les paquets en
entrée) n'est pas toujours facile à faire;
 Les priorités absolues et l'algorithme PQ peuvent causer
des congestions artificielles dues à des problèmes de
"famine";
 Il y a seulement 4 niveaux de priorité, comment faire alors
pour classifier plus de 4 classes de trafic ?
Round Robin (1)
▪ Les paquets sont classés par flux par le système et
insérés dans une file d'attente dédiée à chaque flux.
▪ Les flux sont servis en tourniquet paquet par paquet.
En d'autres termes:
 Les files sont scrutées les unes à la suite des autres.
 Si la file contient un paquet, ce dernier sera servi.
 Par contre, si la file est vide à ce moment, l'ordonnanceur
passe directement à la file suivante.
➔Donc, les files d'attente vides sont sautées par
l'ordonnanceur et revisitées au tour suivant.

Round Robin (2)
Arrivée
classificateur Sortie

Algorithme RR
Ordonnanceur-RR ()
{
tq (vrai) faire
Pour i= 1 à N faire
si (file i !vide) alors EnvoyerUnPaquetFile i ( ) fsi
fait
fait
}

Avantages et inconvénients de RR
▪ Pas de famine;
▪ Pas de discrimination entre les files ➔ partage équitable de la bande

passante.
➔ L'équité ne peut cependant être parfaite que si la taille des paquets est
identique pour tous les flux se présentant au niveau des files (hypothèse
pas toujours vérifiées) ➔ les files contenant des paquets deux fois plus
volumineux que ses concurrentes se verront attribuer deux fois plus de
bande passante ➔ WRR, DRR, SRR, CBQ.
▪ L'ordonnanceur parcourant séquentiellement les files une à une, peut

rencontrer une file vide et devra donc passer à la file suivante.
➔Par conséquent, si le check-up de la file i a été effectué quelques
microsecondes avant qu'un paquet de cette même file arrive, le paquet devra
attendre le check-up des (n-i) files précédentes (contrainte de délai).
▪ La discipline de service RR 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.
Weighted Round Robin
▪ WRR est utilisé pour faciliter le partage de la BP entre les
différents flux
▪ Dans WRR, un poids est affecté à chaque file d'attente
➔ le poids indique la quantité de BP affectée à chaque
file
▪ La gestion des files est faite suivant une politique basée
sur RR
▪ Exemple:
 Poids File 1 = 3
➔ File 1 aura ≈ 50% de la BP, File 2 ≈ 16% et File 3 ≈ 33%

Class-Based Queuing ou Custom Queuing (1)
▪ Permet à plusieurs applications de partager la Bp du
réseau avec des spécifications minimales;
▪ Il convient de doter chaque classe de trafic d'une file
d'attente en servant chaque file d'attente à son tour;
▪ Chaque file d'attente est définie par une taille en octet
(byte count). La taille correspond au nombre maximum
d'octets que le système devra sortir de la file d'attente
pour les transmettre avant de servir la file suivante;
▪ Modifier la taille du byte count revient donc à attribuer
plus ou moins de Bp au trafic utilisant cette file;
▪ Si une file est vide, le système traite la file suivante ce qui
signifie que la bande passante n'est pas réservée à une
file de manière définitive.
▪ Un bon positionnement du paramètre byte count est
primordial pour la gestion des priorités
➔ il est important de considérer les contraintes suivantes:
 Il est nécessaire de définir le trafic que l'on veut favoriser ou au
contraire défavoriser. A cette fin, la taille moyenne des paquets
transmis par l'application doit être connue;
 Chaque file étant servie à tour de rôle, des valeurs trop élevées
du byte count génèrent une distribution par décharge des
paquets de chaque file;
 Si le byte count est atteint, la trame en cours de transmission est
envoyée dans sa totalité. Une mauvaise adéquation entre le byte
count et la taille de paquet peut fausser notablement la valeur de
Bp attribuée à cette file.
▪ Pour établir les valeurs du byte count à attribuer à
chaque file d'attente il faut procéder comme suit:
 Pour chaque flux relever la taille des trames;
 Calculer le ratio R en divisant la taille de trame la plus grande
par la taille de chaque trame;
 Choisir le pourcentage de Bp à attribuer à chaque protocole et
le multiplier par le ratio calculé;
 Normaliser le résultat en le divisant par la plus petite valeur. On
obtient un ratio exprimant le nombre de trames qui garantira la
répartition souhaitée de la Bp;
 Pour obtenir le byte count il faut multiplier ce ratio par la taille
de la trame. Il est aussi possible d'utiliser des multiples de ces
résultats sans toutefois créer de byte count trop grand.
Exemple:
Flux Taille des Ratio (R) % de R*Bp Normaliser Byte count

trames Bp
A 1086 bytes 1086/1086=1 20 1*0,2=0,2 0,2/0,2=1 1086*1= 1086
B 291 bytes 1086/291=3,73 60 3,73*0,6=2,239 2,239/0,2=11,3 291*12= 3492
C 831 bytes 1086/831=1,3 20 1,3*0,2=0,261 0,261/0,2=1,3 831*2 = 1662

▪ Avantages:
 L’avantage de cette méthode est d’utiliser au maximum la
bande passante;
 Chez Cisco, cette politique utilise 16 files d'attente pour
une interface de sortie.
▪ Inconvénients:
 CBQ souffre du même handicap que FIFO et PQ, à savoir
des priorités statiques;
 Certaines données ne sont évidentes à avoir dans certains
contextes, comme la taille moyenne des paquets;
 Le mode de fonctionnement est couteux au niveau du
système d’exploitation du routeur.

Deficit Round Robin (1)
▪ DRR essaye de résoudre le problème de l'équité (dans le cas de
paquets avec différentes tailles).
▪ Il introduit un compteur de déficit lié à chaque file.
▪ A chaque tour, ce compteur est incrémenté d'un quantum "Qi" pour
la classe i.
➔Si la valeur du compteur devient plus grande que la taille du
premier paquet dans la file, alors ce paquet sera envoyé et le
compteur de la file sera réduit de la valeur de la taille du paquet.
Cette valeur sera sauvegardée pour le prochain tour.
➔Dans le cas où la somme du déficit et du quantum est inférieure à
la taille du paquet, le déficit est incrémenté du quantum et
sauvegardé, mais le paquet ne sera pas émis. L'ordonnanceur passera
ensuite à la prochaine file.
▪ Quand l'ordonnanceur se présente devant une file vide, le déficit de
cette dernière est initialisé à zéro afin de garder l'équité.

Qi=1000 bytes 1500 bytes
DC: Deficit Counter
800
bytes
classificateur Sortie
1200 bytes

▪ Taille paquets: (file 1, 1500 Ø), (file 2, 800 Ø), (file 3, 1200 Ø)
▪ Qi = 1000 Ø et DCi = 0 Ɐ i
▪ Premier passage:
 DC1= 1000 ➔ Paquet non envoyé
 DC2= 1000 ➔ Paquet envoyé ➔ Nouveau DC2=200
 DC3= 1000 ➔ Paquet non envoyé
▪ Deuxième passage
 DC1=2000 ➔ Paquet envoyé ➔ Nouveau DC1=500
 DC2=1200 ➔ File vide ➔ Nouveau DC2 = 0
 DC3=2000 ➔ Paquet envoyé ➔ DC3 = 800

Algorithme DRR
Ordonnanceur-DRR ()
{
tq (vrai) faire
pour i= 1 à N faire
Deficit[i]=Deficit[i]+Quantum[i];
si (file i vide) alors Deficit[i]=0
sinon si (Deficit[i] >= TaillePaquetFile(i))
alors tq (Deficit[i] >= TaillePaquetFile(i)) faire
EnvoyerUnPaquetFile i ( );
Deficit[i]=Deficit[i]-TaillePaquetEnvoyé;
fait
fsi
fsi
fait
fait
}

Shared/Shaped Round Robin (SRR)
▪ Gestion des files en tourniquet avec pondération
▪ SRR diffère de WRR dans l'application de la pondération

(envoie des paquets sur l'interface de sortie)
▪ Exemple:
 File 1 ➔ poids 2
Ordonnancement des paquets:
WRR: P1,P1,P2,P2,P2,P3,P3,P3,P3,P4
SRR: P1,P2,P3,P4,P1,P2,P3,P2,P3,P3
Avantage de SRR: Diminuer les bursts par rapport à WRR

Différence entre Shared RR et Shaped RR
▪ Deux variantes existent: avec partage de BP (shared
RR) et sans partage de BP (shaped RR)
 Exemple: Soient 4 files avec une pondération de 25%
chacune:
 Cas 1: Toutes les files sont pleines
➔ Shared RR et shaped RR fonctionnement de la même
manière
 Cas 2: Uniquement une file est non vide
➔ Dans shared RR, la file non vide aura la totalité de la BP
disponible tant que les autres files restent vides
➔ Dans shaped RR, la file non vide aura toujours 25% de la BP
même si les autres files sont vides

Fair queueing (1)
▪ On simule une politique de type Round Robin bit par
bit (RRBB)
But: Calculer le temps de fin d'envoi des paquets
(temps où un paquet aurait été envoyé
théoriquement si nous appliquons un politique
de type RR mais en bit/bit)
▪ Envoyer les paquets dans l’ordre croissant des temps

de fin d'envoi des paquets

Fair queueing (2)
▪ Le temps de fin d'un paquet est exprimé en termes
de nombre de tours (au lieu d'un temps effectif)
▪ Pendant un « tour » on « consomme » un bit par file

non vide
➔ un paquet de 100 bits sera envoyé après 100 tours
▪ Durée d’un tour est définie par le nombre de files

actives

Exemple
▪ Soient deux flux A et B dont la taille des paquets est
de 1000 bits pour le flux A et 500 bits pour le flux B
Arrivée des
paquets du flux A
Arrivée des
paquets du flux B
▪ En appliquant RRBB
Nombre
de tours
1000 2000 2500 3000 3500 4000 4500 5000

Exemple (suite)
▪ Temps d'envoi virtuel des paquets est:

 A1 = 1000, A2=2000, A3=3000, A4=4000, A5=5000
 B1=2500, B2=3000, B3=3500, B4=4000, B5=4500, B6=5000
▪ L'envoie des paquets sera basé sur ce temps d'envoi

virtuel:
➔ A1, A2, B1, A3, B2, B3, A4, B4, B5, A5, B6

Calcul du temps théorique de fin (1)
▪ Le système gère les informations suivantes:
 Le tour actuel R(t) ou le temps théorique (virtuel)
 Le temps de fin (en termes de tour) de chaque paquet
 Le dernier temps de fin (en termes de tour) du dernier
paquet de chaque file
▪ Le calcul du temps de fin varie en fonction de l'état

de la file:
 Cas d'une file vide
 Cas d'une file non vide

Cas d'une file vide
▪ On suppose que le paquet k du flux f arrive dans une
file vide
▪ Soit F(f,k) le temps de fin du paquet K du flux f
▪ Le paquet k arrive à un temps réel t(f,k) et virtuel
R(t(f,k))
▪ La taille du paquet est T(f,k) bits
▪ Le temps de fin du paquet est:
F(f,k) = R( t(f,k) ) + T(f,k) (1)

Cas d'une file non vide
▪ On suppose que le paquet k du flux f arrive dans une
file non vide
▪ Le paquet k doit attendre l'envoi de tous les paquets
qui le precedent (du même flux) ➔ le paquet k
dépendra du temps de l'envoi du paquet (k-1)
▪ Le temps de fin du paquet (k-1) est F(f, k-1).
▪ Si la taille du paquet k est T(f,k) alors le temps de fin
du paquet est:
F(f,k) = F(f,k-1) + T(f,k) (2)

Pour résumer !
▪ Cas d'une file vide:
F(f,k) = R(t(f,k)) + T(f,k) (1)
▪ Cas d'une file non vide:

F(f,k) = F(f,k-1) + T(f,k) (2)
▪ En combinant les deux formules nous obtenons:
F(f,k) = max{F(f,k-1), R( t(f,k) )} + T(f,k)

Fonctionnement de FQ
▪ Pour gérer les paquets des différentes files, une file à
priorité FP est utilisée par l’ordonnanceur.
▪ Chaque file "i" non vide a une entrée dans la file FP.
Cette entrée est insérée dans la file FP selon son
échéance exprimée en temps virtuel.
▪ Les paquets prêts sont transmis selon l’ordre donné

par la file FP (c-à-d, selon l’ordre croissant des
échéances virtuelles).

Exercice 1
▪ Considérons un ordonnanceur de type FQ avec trois
files et un débit sortant de 1U/S.
En appliquant RRBB, donnez la séquence de sortie
des paquets dans le cas suivant:
 File 1: arrivée du paquet 1 à t=0 (taille= 3) et arrivée du
paquet 2 à t=2 (taille=1).
 File 2: arrivée du paquet 1 à t=1 (taille=1) et arrivée du
paquet 2 à t=2 (taille = 4).
 File 3: arrivée du paquet 1 à t=3 (taille=3).

File 1 File 2 File 3
P1 P2 Q1 Q2 R1 Nb Tours
(3bit) (1bit) (1bit) (4bit) (3bit) R
t=0 ➔ t=1 1 R1
t=1 ➔ t=2 1/2 1/2
R2
t=2 ➔ t=3 1/2 1/2
t=3 ➔ t=4 1/3 1/3 1/3
t=4 ➔ t=5 1/3 1/3 1/3 R3
t=5 ➔ t=6 1/3 1/3 1/3
t=6 ➔ t=7 1/3 1/3 1/3
t=7 ➔ t=8 1/3 1/3 1/3 R4
t=8 ➔ t=9 1/3 1/3 1/3
t=9 ➔ t=10 1/2 1/2
R5
t=10 ➔ t=11 1/2 1/2
t=11 ➔ t=12 1 R6
Temps d'envoi virtuel: F(P1)=3 , F(P2)=4, F(Q1)= 2, F(Q2)= 6 et F(R1)=5

➔ Ordre d'envoi des paquets: Q1, P1, P2, R1 et enfin Q2
Méthode de calcul
▪ Etape 1:
 Calcul des instants virtuels R(t) avec R(t=0)=0.
 Le calcul se fait en utilisant la formule suivante:

R(x) = R(y) + (x-y)/Nb files actives
▪ Etape 2:
 Appliquer la formule de calcul pour déterminer les temps de
fin virtuels des paquets

Etape 1: Calcul des R(t)
R(x) = R(y) + (x-y)/Nb files actives
R(0)=0
R(1) = R(0) + (1-0)/1 = 1 // passage à deux files actives

R(3)= R(1) + (3-1)/2 = 2 // passage à trois files actives
R(6)=R(3) + (6-3)/3= 3 // changement des trois files actives
R(9)=R(6)+(9-6)/3 = 4 // passage à deux files actives
R(11)=R(9)+ (11-9)/2= 5 // passage à une file active

Etape 2: Calcul des temps de fin virtuels
F(f,k) = max{F(f,k-1), R( t(f,k) )} + T(f,k)
F(P1) = R(0) + 3 = 3
F(P2)= F(P1) + 1 = 4
F(Q1)=R(1) + 1 = 2
F(Q2)=F(Q1)+ 4 = 6
F(R1)=R(3)+ 3= 5
➔ Ordre d'envoi des paquets: Q1, P1, P2, R1 et enfin Q2

Exercice 2
▪ Considérons un ordonnanceur de type FQ avec trois
files et un débit de sortie effectif de 0,5U/S.
Donner la séquence de sortie des paquets et calculer
le temps de fin effectif dans le cas suivant:
 File 1: arrivée du paquet 1 à t=0 (taille= 2) et arrivée du
paquet 2 à t=4 (taille=1).
 File 2: arrivée du paquet 1 à t=1 (taille=3) et arrivée du
paquet 2 à t=2 (taille = 1).
 File 3: arrivée du paquet 1 à t=3 (taille=5).

File 1 File 2 File 3
P1 P2 Q1 Q2 R1 Nb Tours
(2bit) (1bit) (3bit) (1bit) (5bit) R
t=0 ➔ t=1 1 R1
t=1 ➔ t=2 1/2 1/2
R2
t=2 ➔ t=3 1/2 1/2
t=3 ➔ t=4 1/2 1/2
t=4 ➔ t=5 1/3 1/3 1/3 R3.5
t=5 ➔ t=5 1/3 1/3 1/3
t=6 ➔ t=7 1/3 1/3 1/3
t=7 ➔ t=8 1/2 1/2 R4
t=8 ➔ t=9 1/2 1/2
R5
t=9 ➔ t=10 1/2 1/2
t=10 ➔ t=11 1 R6
t=11 ➔ t=12 1 R7
Temps d'envoi virtuel: F(P1)=2, F(P2)=3.5, F(Q1)=4, F(Q2)=5 et F(R1)=7
➔ Ordre d'envoi des paquets: P1, P2, Q1, Q2 et enfin R1
Temps de fin effectif: 4, 6, 12, 14, 24
Méthode de calcul
▪ Calcul des R(t)
R(1) = R(0) + (1-0)/1 = 1
R(3)= R(1) + (3-1)/2 = 2
R(4)=R(3)+ (4-3)/2 = 2.5
▪ Calcul des F()
F(P1) = R(0) + 2 = 2
F(P2)= R(4) + 1 = 3.5
F(Q1)=R(1) + 3 = 4
F(Q2)=F(Q1)+ 1 = 5
F(R1)=R(3)+ 5=7

Weighted Fair Queuing (1)
▪ La gestion des priorités et le vidage des files d'attente
sont effectués par une pondération (weighted)
équitable (Fair) des flux.
▪ L'idée est de permettre un accès équitable à la BP,

fondé sur un entrelacement des flux
▪ Le poids d'une file représente le nombre de bit

envoyés à chaque tour (si Ɐi Wi =1 ➔ cas de FQ).

Weighted Fair Queuing (2)
▪ Les trafics sont classés et séparés en flux, chacun

d'eux recevant une file d'attente distincte ➔ gestion
lourde et gourmande en termes de ressources
▪ WFQ utilise n+8 files d'attente sur chaque interface

de sortie. Le paramètre n est fonction du nombre de
flux de l'interface et les 8 autres files sont réservées
pour ne pas mettre en concurrence certains flux
(critiques) avec ceux des utilisateurs.

Temps de fin d'un paquet dans WFQ
F(f,k) = max{F(f,k-1), R( t(f,k) )} + T(f,k) /Wf

Class-Based Weighted Fair Queuing
▪ La gestion des flux dans WFQ nécessite beaucoup de
ressources
▪ Le nombre de flux dans un réseau peut être très

important
▪ Regrouper les flux par classe
▪ Une file est associée à chaque classe
▪ Le poids d'un paquet est le poids de sa classe

Combinaison de plusieurs politiques (hybride)
Haute Priorité
Gestion FIFO
Flux 1 Priorité Moyenne

Flux 2 Classificateur WFQ (w1=30% BP)
Ordonnanceur
Flux 3
Flux 4
WFQ (w2=20% BP) Ordre d'envoi des paquets
Flux 5
Flux 6
WFQ (w3=10% BP)
Flux 7
Flux 8
Basse Priorité
Gestion FIFO

Algorithme de la politique hybride
Ordonnanceur-Hybride()
{
tq (vrai) faire
tq (files PrioritéHaute !vide) faire OrdonnaceurPH ( ) fait

si ((files PrioritéMoyenne !vide) et (files PrioritéHaute vide))
alors OrdonnaceurPM( )
sinon si ((files PrioritéFaible !vide) et (files PrioritéHaute vide) et
(files PrioritéMoyenne vide))
alors OrdonnaceurPF( )
fsi
fsi
fait
}

Exercice 3
▪ Soit le tableau suivant représentant l'instant d'arrivée
des paquets ainsi que leurs tailles pour les flux 1 et 2
appartenant aux files F1 et F2.
Flux 1 Flux 2
Temps d'arrivée Taille Temps d'arrivée Taille
P1 1 1 0 3
P2 2 1 5 2
P3 3 2 9 2
P4 11 2
1) Tracer le chronogramme d'envoi pour une politique

FQ et déduire le temps virtuel d'envoi, l'ordre des
paquets sur l'interface de sortie ainsi que le temps
d'envoi réel si le débit sortant est de 1U/S.
File 1 File 2
P1 P2 P3 P4 Q1 Q2 Q3 Nb
(1bit) (1bit) (2bit) (2bit) (3bit) (2bit) (2bit) Tours
R
t=0 ➔ t=1 1 R1
t=1 ➔ t=2 1/2 1/2
R2
t=2 ➔ t=3 1/2 1/2
t=3 ➔ t=4 1/2 1/2
R3
t=4 ➔ t=5 1/2 1/2
t=5 ➔ t=6 1/2 1/2
R4
t=6 ➔ t=7 1/2 1/2
t=7 ➔ t=8 1/2 1/2
R5
t=8 ➔ t=9 1/2 1/2
t=9 ➔ t=10 1 R6
t=10 ➔ t=11 1 R7
t=11 ➔ t=12 1 R8
t=12 ➔ t=13 1 R9
F(P1)=2, F(P2)=3, F(P3)=5, F(P4)=9, F(Q1)= 3, F(Q2)= 5, F(Q3)=7

▪ Temps de fin virtuels
F(P1)=2, F(P2)=3, F(P3)=5, F(P4)=9, F(Q1)= 3, F(Q2)= 5,
F(Q3)=7
▪ Ordre d'envoi
P1 , P2, Q1, P3, Q2, Q3, P4
▪ Temps d'envoi réel

P1= 1s , P2= 2s, P3=7s , P4= 13s
Q1=5s, Q2=9s, Q3= 11s
Exercice 3
2) Reprendre les mêmes données pour une politique

WFQ avec les pondérations suivantes: W1= 1 et W2=2

File 1 ➔ w=1 File 2 ➔ w=2
P1 P2 P3 P4 Q1 Q2 Q3 Nb
(1bit) (1bit) (2bit) (2bit) (3bit) (2bit) (2bit) Tours
R
t=0 ➔ t=1 2 R1
t=1 ➔ t=2 1/2 1 R1.5
t=2 ➔ t=3 1/2 1/2 R2.5
t=3 ➔ t=4 1/2 1/2 R3.5
t=4 ➔ t=5 1 R4.5
t=5 ➔ t=6 1/2 1 R5
t=6 ➔ t=7 1 R5.5
t=7 ➔ t=8
t=8 ➔ t=9
t=9 ➔ t=10 2 R6.5
t=10 ➔ t=11
t=11 ➔ t=12 1 R7.5
t=12 ➔ t=13 1 R8.5
F(P1)=2, F(P2)=3, F(P3)=5, F(P4)=8.5, F(Q1)= 1.5, F(Q2)= 5.5, F(Q3)=6.5

Méthode de calcul
Etape 1: Calcul des R(t)
R(0)=0
R(1)=0+1=1
R(2)= 1 + 1/2= 3/2
R(3)=3/2 + 1 = 5/2
R(4)=5/2 + 1 = 7/2
R(5) = 7/2 + 1 = 9/2
R(6)= 9/2 + 1/2 = 5
R(7)= 5 + 1/2 = 11/2
R(8)=R(9)=R(7)
R(10)=11/2 + 1 = 13/2
R(11)=R(10)
R(13)= 13/2 + 2 = 17/2
Méthode de calcul
Etape 2: Calcul des F(f,k)
F(P1)= R(1)+T(P1)/W1=1+1=2
F(P2)=F(P1)+T(P2)/W1=2+1=3
F(P3)=F(P2)+T(P3)/W1=3+2=5
F(P4)=R(11)+T(P4)/W1=13/2+2=8.5
F(Q1)=R(0)+T(Q1)/W2=0+3/2=1.5
F(Q2)=R(5)+T(Q2)/W2=9/2+2/2=5.5
F(Q3)=R(9)+T(Q3)/W2=11/2+2/2=6.5

Questions

Chapitre 3 Mécanismes de Qos Internes Aux Équipements: Présenté Par DR BOUYAKOUB

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 3 Mécanismes de Qos Internes Aux Équipements: Présenté Par DR BOUYAKOUB

Transféré par

Droits d'auteur :

Formats disponibles

CHAPITRE 3

MÉCANISMES DE QOS INTERNES AUX

▪ Un routeur standard comporte les 3 composants suivants:

▪ Initialement les routeurs ne comportaient qu'un seul

▪ Les routeurs d'entrée de gamme sont toujours

L3-GTR: Mécanismes de QoS internes aux équipements 6

L3-GTR: Mécanismes de QoS internes aux équipements 8

L3-GTR: Mécanismes de QoS internes aux équipements 9

Les routeurs mettant en œuvre des fonctionnalités de

L3-GTR: Mécanismes de QoS internes aux équipements 10

L3-GTR: Mécanismes de QoS internes aux équipements 11

L3-GTR: Mécanismes de QoS internes aux équipements 13

1. La classification des paquets

L3-GTR: Mécanismes de QoS internes aux équipements 14

▪ La classification peut s'établir à partir d'un champ

▪ La classification simple se fonde sur le champ TOS du

L3-GTR: Mécanismes de QoS internes aux équipements 15

▪ Les champs "precedence" sur 3 bits permet d'indiquer 8

L3-GTR: Mécanismes de QoS internes aux équipements 16

L3-GTR: Mécanismes de QoS internes aux équipements 17

L3-GTR: Mécanismes de QoS internes aux équipements 18

▪ Le classificateur d'un routeur de cœur peut être plus

1. La classification des paquets

L3-GTR: Mécanismes de QoS internes aux équipements 20

Que faire du trafic non conforme?

Trafic non conforme marqué mais transmis

L3-GTR: Mécanismes de QoS internes aux équipements 22

Trafic supprimé (> PIR)

▪ Le lissage du trafic (traffic shaping) consiste à réguler la

L3-GTR: Mécanismes de QoS internes aux équipements 24

L3-GTR: Mécanismes de QoS internes aux équipements 25

▪ Il existe deux techniques pour le contrôle et le lissage

L3-GTR: Mécanismes de QoS internes aux équipements 26

▪ Ce mécanisme permet de contrôler le

▪ Il permet de contrôler le nombre de

L3-GTR: Mécanismes de QoS internes aux équipements 27

▪ Les paquets en excès sont en général jetés. Ils peuvent

Suppression des paquets en cas

Le seau permet de réguler des

L3-GTR: Mécanismes de QoS internes aux équipements 29

▪ L'inconvénient de ce mécanisme est le fait que le

L3-GTR: Mécanismes de QoS internes aux équipements 30

▪ Calculer la capacité du seau afin d'éviter toute perte

▪ But de la solution: déterminer la quantité de

L3-GTR: Mécanismes de QoS internes aux équipements 31

L3-GTR: Mécanismes de QoS internes aux équipements 32

L3-GTR: Mécanismes de QoS internes aux équipements 33

L3-GTR: Mécanismes de QoS internes aux équipements 34

L3-GTR: Mécanismes de QoS internes aux équipements 35

2 1.1 1.1 1 vide

3 1.5 1.5 0 vide

10 3.5 supprimé 0 6,7,8,9

1. La classification des paquets

L3-GTR: Mécanismes de QoS internes aux équipements 38

▪ Afin d'obtenir un traitement optimal des trafics, il est

▪ Les files présentent deux inconvénients majeurs:

L3-GTR: Mécanismes de QoS internes aux équipements 39

▪ Pour réduire la taille des files d'attente, il est

▪ Ces mécanismes ne peuvent éviter la congestion qu'à

L3-GTR: Mécanismes de QoS internes aux équipements 40

congestion Bit FECN

L3-GTR: Mécanismes de QoS internes aux équipements 42

▪ Plusieurs politiques proposées pour éviter les états