R´
ETROACTION DE LA QUALIT´
E DE L’EXP´
ERIENCE POUR AM´
ELIORER LA
QUALIT ´
E DE SERVICE
GREGORY CHARLOT
D´
EPARTEMENT DE G´
ENIE INFORMATIQUE ET G´
ENIE LOGICIEL
´
ECOLE POLYTECHNIQUE DE MONTR´
EAL
M´
EMOIRE PR´
ESENT´
E EN VUE DE L’OBTENTION DU DIPL ˆ
OME DE
MAˆITRISE `
ES SCIENCES APPLIQU´
EES
(G ´
ENIE INFORMATIQUE)
NOVEMBRE 2012
c
´
ECOLE POLYTECHNIQUE DE MONTR´
EAL
Ce m´
emoire intitul´
e :
R´
ETROACTION DE LA QUALIT´
E DE L’EXP´
ERIENCE POUR AM´
ELIORER LA
QUALIT ´
E DE SERVICE
pr´
esent´
e par : CHARLOT Gregory
en vue de l’obtention du diplˆ
ome de : Maˆıtrise `
es Sciences Appliqu´
ees
a ´
et´
e dˆ
ument accept´
e par le jury d’examen constitu´
e de :
M. GAGNON Michel, Ph.D, pr´
esident
M. PIERRE Samuel, Ph.D., membre et directeur de recherche
M. QUINTERO Alejandro, Doct., membre
`
REMERCIEMENTS
J’´
eprouve un immense plaisir d’exprimer ma gratitude envers Dieu, Jehovah, et envers
toutes les personnes qui m’ont aid´
e `
a la r´
ealisation de ce m´
emoire.
Je veux d’abord remercier mon directeur de recherche, le Professeur Samuel Pierre, pour
son encadrement, son support financier et ses conseils n´
ecessaires `
a la r´
ealisation de ce travail.
Mes remerciements s’adressent ´
egalement `
a M´
eral Shirazipour charg´
ee de mon
encadre-ment chez Ericsson pour m’avoir guid´
e, orient´
e et soutenu dans toutes les ´
etapes de ce projet
de recherche.
Je tiens aussi `
a remercier les honorables membres du jury qui ont accept´
e d’´
evaluer ce
travail.
Enfin je veux remercier tous les coll`
egues et amis du LAboratoire de recherche en R´
eseau-tique et Informaeseau-tique mobile (LARIM) pour leur collaboration, particuli`
erement Mari`
eme
Diallo, Saida Maaroufi El Idrissi et Val´
erie Justafort.
R´
ESUM´
E
Pendant de nombreuses ann´
ees l’´
evaluation des r´
eseaux IP a ´
et´
e effectu´
ee de fa¸con
ob-jective en mesurant diff´
erents crit`
eres qui d´
eterminent la qualit´
e du r´
eseau. Ces crit`
eres font
r´
ef´
erence `
a un ensemble de param`
etres de qualit´
e de service (QdS) que doit satisfaire le r´
eseau
dans le transport des paquets. Avec l’apparition des trafics multim´
edias tels que la voix sur
IP et la vid´
eo, les param`
etres de QdS, quoique fondamentaux, se r´
ev`
elent ˆ
etre insuffisants
puisqu’ils ne tiennent pas compte de ce qui se passe en amont et en aval du r´
eseau. C’est
ce qui explique l’´
emergence du concept de la qualit´
e de l’exp´
erience (QdE) dans les r´
eseaux
IP pour les applications temps r´
eel et interactives. Ce concept, exprimant le niveau de
satis-faction de l’usager, permet de tenir compte de ce dernier dans la boucle de service. Ainsi, il
s’av`
ere n´
ecessaire de disposer de m´
ecanismes pour contrˆ
oler la QdE des usagers et qui sont
capables de r´
eagir lorsqu’une d´
egradation se produit.
Les m´
ecanismes propos´
es jusqu’ici concernent, pour la plupart, les applications de voix
sur IP ou la vid´
eo. Ils agissent le plus souvent au niveau des ´
equipements terminaux
par-ticuli`
erement sur les codeurs ou les d´
ecodeurs en modifiant leur d´
ebit ou en faisant varier
la taille du tampon de la gigue. De ce fait, ils ne sont appropri´
es que pour les applications
multim´
edias et ne peuvent pas ˆ
etre appliqu´
es aux autres applications interactives, les jeux
vid´
eo en ligne par exemple, auxquelles le concept de QdE s’est ´
elargi. De plus, tr`
es peu de
travaux proposent d’utiliser les m´
etriques de QdE pour avoir de meilleurs m´
ecanismes de
QdS.
Dans ce m´
emoire, un nouveau m´
ecanisme est propos´
e qui, via des techniques utilis´
ees pour
faire de la QdS dans les r´
eseaux IP, permet de r´
eagir lorsque la QdE, pour une application,
subit des d´
egradations. Ce m´
ecanisme comporte deux aspects. Le premier aspect consiste `
a
d´
efinir un cadre r´
ealiste pour, d’une part, avoir la r´
etroaction de la QdE (feed-back ) pour
tout type d’applications, temps r´
eel et non temps r´
eel ; et d’autre part, introduire le feed-back
de la QdE (re-feed-back ) dans le r´
eseau de sorte que les diff´
erents nœuds puissent en ˆ
etre
inform´
es. La r´
einsertion du feed-back de la QdE se fait ‘in band ’ `
a travers l’entˆ
ete IP. Le
second aspect consiste `
a proposer un nouveau m´
ecanisme de classification des paquets par les
routeurs internes `
a un domaine DiffServ. Ce m´
ecanisme permet aux routeurs de tenir compte
de la QdE lors de la mise en file d’attente des paquets d’un flot de trafic qui doit b´
en´
eficier
d’une certaine garantie de QdE. L’information de la QdE sera accessible aux routeurs par le
m´
ecanisme de feed-back propos´
e qui l’´
ecrira dans l’entˆ
ete des paquets IP.
e-montrent que l’utilisation du feed-back de la m´
etrique de la QdE dans DiffServ permet
d’ob-tenir de meilleurs r´
esultats de QdE, prouvant ainsi qu’il est possible et utile d’impliquer la
QdE dans les m´
ecanismes de QdS.
ABSTRACT
For many years the evaluation of IP networks was carried out objectively by measuring
different criteria that determine the quality of the network. Those criteria refer to a set of
parameters of quality of service (QoS) that must be satisfied by the network while carrying
packets. With the emergence of multimedia traffic such as Voice over IP (VoIP) and video,
QoS parameters, though still very important, are yet not enough because they do not take
into account what is happening at the end nodes. This has led to the emergence of the
new concept of quality of experience (QoE) which expresses the user’s satisfaction regarding
a given comunication service. Thus it is necessary to develop mechanisms in IP netwoks
allowing one to monitor and enhance the users’ QoE.
So far, proposed mechanisms concern mostly VoIP or video applications and act, most of
the time, at the terminal equipment, particularly at the codec to adapt, if possible, the data
transmission rate or to modify the jitter buffer size. So, they are only suitable for multimedia
applications and they do not take into account other interactive applications, like online
games for example, to which QoE concept has widened. In addition, very few works propose
to use QoE metrics to enhance QoS mechanisms.
In this master thesis, we propose a new QoS-based mechanism which is able to react when
the QoE value of an application goes below a threshold. This mechanism has two aspects.
The first aspect is to define a realistic framework to have the QoE information echoed to
the receiver on the one hand and secondly to insert the QoE information in the network so
that nodes on the path can use it in QoS mechanisms. That is done ‘in band’ through IP
packet header. The second aspect consist of proposing a new mechanism to classify packets by
routers inside a DiffServ domain. This latter mechanism enables routers to take into account
the QoE info. The QoE information will be accessible to the routers by the proposed feedback
mechanism.
The proposed mechanism was simulated with the NS-3 simulator. The results show that
the use of feedback of the QoE info in DiffServ achieves better QoE results, proving that it
is possible and useful to involve the QoE in QoS mechanisms.
TABLE DES MATI`
ERES
D´
EDICACE . . . .
iii
REMERCIEMENTS . . . .
iv
R´
ESUM´
E . . . .
v
ABSTRACT
. . . vii
TABLE DES MATI`
ERES . . . viii
LISTE DES TABLEAUX . . . .
xi
LISTE DES FIGURES . . . xii
LISTE DES SIGLES ET ABR´
EVIATIONS . . . xiv
CHAPITRE 1
INTRODUCTION . . . .
1
1.1
D´
efinitions et concepts de base . . . .
2
1.2
El´
´
ements de la probl´
ematique . . . .
5
1.3
Objectifs de la recherche . . . .
6
1.4
Plan du m´
emoire . . . .
6
CHAPITRE 2
D´
EFIS DE QUALIT ´
E DE SERVICE ET IMPACT SUR LA QUALIT ´
E
DE L’EXP´
ERIENCE . . . .
7
2.1
Strat´
egies et m´
ecanismes ´
el´
ementaires de qualit´
e de service . . . .
7
2.1.1
Gestion active des files d’attente - AQM . . . .
7
2.1.2
Ordonnancement de paquet . . . .
8
2.1.3
Routage . . . 11
2.1.4
Contrˆ
ole et lissage de trafic
. . . 11
2.2.1
Architecture de qualit´
e de service - IntServ . . . 13
2.2.2
Architecture de qualit´
e de service - DiffServ . . . 15
2.3
Feed-back et qualit´
e de service . . . 21
2.3.1
Notification explicite de la congestion ECN . . . 21
2.3.2
Feed-back et User Datagram Protocol (UDP) . . . 23
2.3.3
R´
eins´
ertion de la notification explicite de la congestion (Re-ECN) . . . 25
2.4
Qualit´
e de service et qualit´
e de l’exp´
erience . . . 27
2.4.1
Impact des m´
ecanismes de qualit´
e de service sur la qualit´
e de l’exp´
erience 28
2.4.2
Corr´
elation entre la qualit´
e de service et la qualit´
e de l’exp´
erience . . . 28
2.4.3
Am´
elioration de la QdE par le feed-back de celle-ci
. . . 30
2.4.4
M´
ecanismes de qualit´
e de service dans les r´
eseaux IP ax´
es sur la qualit´
e
de l’exp´
erience
. . . 30
2.5
Synth`
ese des travaux . . . 31
CHAPITRE 3
M ´
ECANISME DE QUALIT´
E DE SERVICE AX´
E SUR LA QUALIT ´
E
DE L’EXP´
ERIENCE . . . 32
3.1
M´
ecanisme de feed-back de la QdE
. . . 32
3.1.1
Feed-back de la QdE avec TCP . . . 33
3.1.2
Feed-back de la QdE avec UDP . . . 33
3.1.3
R´
e-insertion de la QdE dans le r´
eseau . . . 34
3.1.4
Format de l’information du feed-back de la QdE . . . 36
3.2
M´
ecanisme de QdS propos´
e bas´
e sur la QdE . . . 37
3.2.1
Vue d’ensemble du m´
ecanisme propos´
e . . . 38
3.2.2
M´
ecanisme de traitement des paquets . . . 39
CHAPITRE 4
EXP´
ERIMENTATIONS ET R´
ESULTATS . . . 45
4.1
Description du simulateur utilis´
e . . . 45
4.2
Environnement de simulations . . . 47
4.3
M´
ethode d’´
evaluation de la qualit´
e de l’exp´
erience . . . 47
4.4
Evaluation du MOS dans le simulateur . . . 49
´
4.6
Simulation de la voix sur IP . . . 53
4.7
Plan d’exp´
erience . . . 53
4.7.1
Sc´
enario simple . . . 53
4.7.2
Sc´
enario complexe
. . . 57
CHAPITRE 5
CONCLUSION . . . 64
5.1
Synth`
ese des travaux . . . 64
5.2
Limitations des travaux . . . 64
5.3
Travaux futurs
. . . 65
LISTE DES TABLEAUX
Tableau 1.1
Mean Opinion Score - MOS . . . .
1
Tableau 1.2
M´
ethode d’´
evaluation de la QdE . . . .
5
Tableau 2.1
Codage des bits ECN . . . 22
Tableau 3.1
Format de l’information de la QdE . . . 36
Tableau 4.1
Mise en correspondance entre les valeurs de R et l’estimation du MOS . 49
Tableau 4.2
Flots pour le sc´
enario simple . . . 54
Tableau 4.3
Sc´
enarios simul´
es . . . 58
Tableau 4.4
R´
esultats pour les diff´
erents sc´
enarios avec et sans le m´
ecanisme . . . . 58
LISTE DES FIGURES
Figure 1.1
QdS/QdE domaines d’application inspir´
e de [6] . . . .
3
Figure 1.2
QdS/QdE couches dans le mod`
ele OSI . . . .
4
Figure 2.1
Gestion des files d’attente Drop Tail et RED . . . .
9
Figure 2.2
Algorithme Seau `
a Jetons . . . 12
Figure 2.3
Architecture IntServ . . . 14
Figure 2.4
Module d’un routeur d’entr´
ee . . . 16
Figure 2.5
Algorithme Single Rate Three Color Marker (srTCM) . . . 18
Figure 2.6
algorithme Two Rate Three Color Marker (trTCM) . . . 19
Figure 2.7
Illustration du traitement des paquets `
a un routeur fronti`
ere . . . 19
Figure 2.8
Algorithme WRED . . . 20
Figure 2.9
Traitement des paquets par un routeur interne . . . 20
Figure 2.10
Format du type de paquet RTCP SR . . . 24
Figure 2.11
Format d’un paquet XR . . . 24
Figure 2.12
Format d’un bloc de rapport XR
. . . 25
Figure 2.13
Format d’un bloc de rapport VoIP
. . . 25
Figure 2.14
Entˆ
ete de destination utilis´
ee dans ConEx . . . 26
Figure 2.15
Fonctionnement de ConEx . . . 26
Figure 2.16
QdS et QdE impactent l’une l’autre . . . 27
Figure 3.1
Exemple de format d’un bloc de rapport XE pour le feed-back de la QdE 34
Figure 3.2
Entˆ
ete de destination utilis´
ee dans ConEx . . . 35
Figure 3.3
Entˆ
ete de destination pour le feed-back de la QdE sans ConEx . . . 35
Figure 3.4
M´
ecanisme de feed-back propos´
e . . . 37
Figure 3.5
Vue d’ensemble . . . 39
Figure 3.6
Classification des paquets dans un routeur interne `
a un domaine DiffServ 40
Figure 3.7
Classification des paquets dans le m´
ecanisme propos´
e . . . 42
Figure 3.8
Illustration de la classification des paquets dans le m´
ecanisme propos´
e . 43
Figure 3.9
Algorithme de traitement des paquets dans le m´
ecanisme propos´
e . . . 44
Figure 4.1
Architecture logicielle de NS-3 inspir´
e de [43] . . . 46
Figure 4.2
Statistique par flot . . . 49
Figure 4.3
Digramme des principales classes ajout´
ees au simulateur . . . 51
Figure 4.4
R´
eseau du sc´
enario simple . . . 54
Figure 4.5
Graphe de la variation du MOS pour le flot 2 avec et sans le m´
ecanisme 55
Figure 4.6
Variation des pertes pour le flot 2 avec et sans le m´
ecanisme . . . 56
Figure 4.7
Variation du d´
elai pour le flot 2 avec et sans le m´
ecanisme . . . 56
Figure 4.8
R´
eseau du sc´
enario complexe
. . . 57
Figure 4.9
Graphe du MOS pour les flots AF2 . . . 60
Figure 4.10
D´
elai moyen des flots AF2 . . . 60
Figure 4.11
Graphe de la moyenne du MOS pour tous les flots VoIP
. . . 61
Figure 4.12
Graphe du d´
elai moyen tous les flots VoIP . . . 61
Figure 4.13
Graphe des pertes moyennes tous les flots VoIP . . . 62
Figure 4.14
Graphe de la gigue moyenne des flots VoIP . . . 62
Figure 4.15
Graphe de la moyenne du MOS pour tous les flots AF1 . . . 63
LISTE DES SIGLES ET ABR´
EVIATIONS
AF
Assured Forwarding
AMR
Adaptive Multi-Rate
ARED
Adaptative Random Early Detection
AQM
Active Queue Management
AVQ
Adaptative Virtual Queue
BBRR
bit-by-bit Round-Robin
CBR
Constant Bit Rate
DF
Default Forwarding
DiffServ
Differentiated Services
DSCP
DiffServ Code Point
DWRR
Deficit Weighted Round Robin
ECN
Explicit Congestion Notification
EF
Expedited Forwarding
ETSI
European Telecommunications Standards Institute
FIFO
First In First Out
FQ
Fair Queueing
FTP
File Transfer Protocol
GSM
Global System for Mobile Communications
IEEE
Institute of Electrical and Electronics Engineers
IETF
Internet Engineering Task Force
IntServ
Integrated Services
IP
Internet Protocol
IPTV
Internet Protocol television
IPv4
IP version 4
IPv6
IP version 6
ITU
International Telecommunication Union
MOS
Mean Opinion Score
NS-2
Network Simulator version 2
NS-3
Network Simulator version 3
OSI
Open Systems Interconnection
PCAP
Packet Capture
PEAQ
Perceptual Evaluation of Audio Quality
PESQ
Perceptual Evaluation of Speech Quality
PHB
Per-Hop Behavior
PI
Proportional Integrator
PQ
Priority Queueing
POLQA
Perceptual Objective Listening Quality Assessment
PSQM
Perceptual Speech Quality Measure
QdS
Qualit´
e de Service
QdE
Qualit´
e de l’Exp´
erience
RED
Random Early Detection
REM
Random Exponential Marking
RFC
Request for Comments
RR
Round-Robin
RTCP
Real-time Transport Control Protocol
RTP
Real Time Protocol
SLA
Service Level Agreement
srTCM
single-rate, three-color marker
TCP
Transmission Control Protocol
trTCM
two-rate, three-color marker
TSpec
Trafic Specification
RSVP
Resource Reservation Protocol
RSpec
Request Specification
RTT
Round Trip Time
UDP
User Datagram Protocol
VoIP
Voice over IP
WBBRR
Weighted bit-by-bit Round-Robin
WFQ
Weighted Fair Queueing
WRED
Weighted Random Early Detection
WRR
Weighted Round-Robin
CHAPITRE 1
INTRODUCTION
Au cours des vingt derni`
eres ann´
ees, la r´
eseautique a connu une ´
evolution importante.
Nous avons assist´
e, depuis l’av`
enement du World Wide Web vers les ann´
ees 1990, `
a la
nais-sance de nouveaux types de trafic et `
a une augmentation consid´
erable des usagers de
l’inter-net. Cette ´
evolution a fait naˆıtre le besoin d’avoir une gestion efficace des ressources pour
assurer que le r´
eseau puisse acheminer correctement le trafic des usagers par la mise en place
de politiques de qualit´
e de service (QdS). De plus, les progr`
es technologiques et le besoin
d’avoir une connexion permanente ont contribu´
e `
a r´
ealiser le passage des r´
eseaux filaires aux
r´
eseaux sans fil et mobiles. L’´
emergence des technologies mobiles et l’int´
erˆ
et grandissant des
usagers pour les communications multim´
edias font que ces derniers deviennent de plus en
plus int´
eress´
es par la qualit´
e qu’ils per¸coivent et non par les param`
etres techniques relatives
`
a la transmission des trafics.
En t´
el´
ephonie classique, la qualit´
e per¸cue pas les usagers est un ´
el´
ement fondamental,
car une communication t´
el´
ephonique effectu´
ee dans les mˆ
emes conditions peut ˆ
etre per¸cue
diff´
eremment par deux couples de correspondants diff´
erents. L’un pourrait ˆ
etre tr`
es satisfait
de la qualit´
e de la communication et l’autre plus ou moins satisfait. C’est la raison pour
laquelle les op´
erateurs utilisaient le Mean Opinion Score (MOS) [1] pour ´
evaluer la qualit´
e
des appels t´
el´
ephoniques telle que per¸cue par les usagers. Il s’agissait de recueillir les opinions
de diff´
erents usagers s´
electionn´
es suivant une m´
ethodologie. Chaque opinion est exprim´
ee par
une note sur une ´
echelle de 1 `
a 5 et la moyenne des notes obtenues indiquait le niveau de
satisfaction des usagers. Ce niveau de satisfaction est d´
esign´
e par le nouveau concept de
qualit´
e d’exp´
erience (QdE) [2].
Tableau 1.1 Mean Opinion Score - MOS
MOS
Qualit´
e
D´
efaut de la communication
5
Excellent
Imperceptible
4
Bon
Perceptible, pas nuisible
3
Satisfaisant
L´
eg`
erement nuisible
2
M´
ediocre
Nuisible
1
Mauvais
Tr`
es nuisible
pour transporter tout type de trafic, un int´
erˆ
et sans cesse croissant se porte sur la QdE dans
les r´
eseaux IP si bien que son application s’est ´
etendu au-del`
a de la t´
el´
ephonie classique.
Elle concerne aujourd’hui tous les services interactifs accessibles via un r´
eseau IP tels que la
voix sur IP (VoIP), la t´
el´
evision sur IP (IPTV), le web et les jeux vid´
eo en ligne. La QdE
devient un ´
el´
ement critique pour un fournisseur de service qui veut satisfaire ses clients et
ainsi rester dans la comp´
etition [3]. D’o`
u la n´
ecessit´
e, pour les op´
erateurs, de s’assurer de
la fid´
elit´
e de leurs utilisateurs, directement li´
ee `
a leur satisfaction, pendant qu’ils cherchent
`
a maximiser leur profit en optimisant leurs ressources. A cet effet, les op´
erateurs doivent
disposer, dans leurs r´
eseaux, des m´
ecanismes pour constamment contrˆ
oler la QdE et r´
eagir
d`
es qu’une d´
egradation se produit.
Dans la suite de ce chapitre nous d´
ecrirons bri`
evement les concepts de QdS et de QdE
tout en faisant ressortir leurs diff´
erences. Ensuite certains ´
el´
ements de probl´
ematique relatifs
au concept de QdE seront expos´
es `
a la suite desquels les objectifs du m´
emoire seront ´
enonc´
es.
Enfin le plan du m´
emoire sera fourni.
1.1
D´
efinitions et concepts de base
Qualit´
e de service/Qualit´
e de l’exp´
erience
Il existe diff´
erentes d´
efinitions pour le concept de QdS. Dans [4], Crawley la d´
efinit comme
un ensemble de requis que doit satisfaire un r´
eseau en transportant un trafic donn´
e. Ces requis
sont traduits par des m´
etriques qui font r´
ef´
erence `
a la capacit´
e du r´
eseau `
a transporter les
informations en terme de disponibilit´
e, au d´
elai maximal que doit exp´
erimenter les paquets,
au taux de perte de paquets minimal que doit garantir le r´
eseau, etc. [5]. Pour assurer que
ces m´
etriques aient des valeurs permettant de satisfaire les requis, diff´
erents strat´
egies ou
m´
ecanismes sont utilis´
es par les op´
erateurs et administrateurs de r´
eseaux. Ces techniques
incluent le routage, la r´
egulation de trafic, l’ordonnancement de paquets, le contrˆ
ole du trafic,
le contrˆ
ole d’admission, etc.
La QdE d´
esigne, suivant la d´
efinition de l’European Telecommunications Standards
Ins-titute (ETSI), une mesure de performance du point de vue de l’usager d’un syst`
eme de
communication bas´
ee sur des mesures psychologiques objectives et subjectives [3]. Elle prend
en compte des param`
etres techniques tels que les param`
etres de QdS et est influenc´
ee par le
contexte dans lequel la communication se fait et les attentes de l’usager. Elle est une mesure
importante de la performance globale d’un syst`
eme de communication qui prend en compte ce
qui se passe en amont et en aval du r´
eseau jusqu’aux terminaux des utilisateurs (Figure 1.1).
Pour ´
eviter toute confusion entre les concepts de QdS et de QdE, il importe de bien saisir
leur diff´
erence. Consid´
erant le mod`
ele de r´
ef´
erence, OSI, la QdS concerne particuli`
erement les
couches inf´
erieures jusqu’`
a la couche transport et la QdE les couches sup´
erieures (Figure 1.2).
La QdE revˆ
et une importance capitale pour les fournisseurs de services et les op´
erateurs
et est utile pour optimiser les services ou produits. Un fournisseur de services dont les clients
exp´
erimentent une bonne QdE jouit d’un avantage comp´
etitif significatif tandis que d’autres
qui n’y mettent pas assez l’accent pourront connaˆıtre des pertes de revenue ils se verront
perdre des clients.
Source Codeur Transmission Décodeur Affichage
Réseau cœur Réseau d’accès QdS QdE Mesure de QdE
Figure 1.1 QdS/QdE domaines d’application inspir´
e de [6]
´
Evaluation de la QdE
En tant que mesure de performance d’un r´
eseau et syst`
eme de communication, d’apr`
es
l’ETSI, diff´
erentes m´
ethodes existent pour ´
evaluer la QdE. Ces m´
ethodes d´
ependent du type
de l’application et sont cat´
egoris´
ees en m´
ethodes subjectives, objectives et mod`
eles de
plani-fication r´
eseau. Les m´
ethodes subjectives se basent sur l’opinion des usagers sur un service
multim´
edia. Suivant ces m´
ethodes, il est demand´
e aux usagers d’indiquer par des notes
va-riant de 1 `
a 5 leur niveau de satisfaction et la moyenne donne le MOS. Quoiqu’elles soient
consid´
er´
ees comme les m´
ethodes les plus fiables pour ´
evaluer la QdE, elles comportent, n´
ean-moins, certains inconv´
enients. En effet, ces m´
ethodes sont tr`
es fastidieuses, consomment
beaucoup de temps et ne peuvent ˆ
etre utilis´
ees en temps r´
eel. Pour pallier aux limitations
des m´
ethodes subjectives, des m´
ethodes objectives ont ´
et´
e ´
elabor´
ees et standardis´
ees. Elles
permettent d’´
evaluer la QdE en se basant sur un ensemble de param`
etres li´
es `
a un service
particulier ou sur des param`
etres du signal `
a la sortie pour estimer la QdE. Ces m´
ethodes sont
session transport réseau liaison physique présentation application Domaine de la QoE Domaine de la QoS
Figure 1.2 QdS/QdE couches dans le mod`
ele OSI
subdivis´
ees en quatre classes : Full Reference (FR), No Reference (NR), Reduced Reference
(RR) et mod`
ele de planification r´
eseau.
La cat´
egorie FR regroupe les m´
ethodes qui comparent le signal `
a la source, consid´
er´
e
comme une r´
ef´
erence, au signal d´
eform´
e `
a la sortie pour donner une estimation de la QdE.
Dans certains cas, les caract´
eristiques du signal d’entr´
ee peuvent ˆ
etre inconnues. A cet effet
les m´
ethodes de la cat´
egorie NR sont utilis´
ees. Ces m´
ethodes ´
evaluent le signal `
a la sortie et
une estimation de la QdE est d´
eduite. Les m´
ethodes de la classe RR, en revanche, font un
compromis entre les deux autres cat´
egories. Elles analysent le signal `
a la sortie `
a la lumi`
ere
d’un ensemble r´
eduit d’information sur le signal de r´
ef´
erence. Les mod`
eles de planification
r´
eseau sont consid´
er´
es comme une sous-cat´
egorie des m´
ethodes objectives car ils ne se basent
pas sur les opinions des usagers. Cependant, ils ne proc`
edent pas `
a une analyse du signal
r´
eel mais ils utilisent une fonction qui fait le lien entre la QdE et des param`
etres intrins`
eques
du r´
eseau notamment ceux de la QdS. Un exemple pour cette cat´
egorie est le mod`
ele E
(E-model ) [7].
Tableau 1.2 M´
ethode d’´
evaluation de la QdE
VoIP
VIDEO
WEB
Jeux en ligne
PSQM, ITU-T Rec.
P.861 (08/1996)
ITU-T Rec. J.249
ITU-T Rec. G.1030
OPScore
(Online
Playability
Score)
propos´
e par Ubicom
PESQ,
ITU-T
Rec.
P.862 (02/2001)
ITU-T Rec. J.146
G-Model
POLQA, ITU-T Rec.
P.862 (01/2011)
TU-T Rec. J.144
PEAQ, ITU-R Rec.
BS.1387
ITU-R BT.1683
E-Model, ITU-T Rec.
G.107 (03/2005)
ITU-T Rec. J.247
1.2
El´
´
ements de la probl´
ematique
Comme mentionn´
e ci-dessus, l’objectif de tout fournisseur de services ou op´
erateur est de
satisfaire leur client ou de leur permettre d’exp´
erimenter une bonne qualit´
e d’exp´
erience tout
en optimisant les ressources du r´
eseau. ´
Etant donn´
e que la QdE peut ˆ
etre consid´
er´
ee comme
une m´
etrique de performance globale d’un syst`
eme de communication, son ´
evaluation inclut
celle de la QdS. De ce fait, diff´
erentes propositions ont ´
et´
e faites en vue de trouver une relation
math´
ematique entre la QdE et la QdS. `
A travers ces propositions certains chercheurs se sont
donn´
es pour objectif de d´
efinir des relations math´
ematiques telles que QdE = f (QdS) [8]
dans l’objectif de contrˆ
oler la QdE par les param`
etres de QdS. D’autres travaux portent sur
des m´
ecanismes qui, en utilisant la r´
etroaction de la QdE ´
evalu´
ee au r´
ecepteur, permettent
d’agir sur le d´
ebit des codeurs utilis´
es dans le cas des applications de voix ou de vid´
eo lorsque
la QdE de l’usager se d´
egrade [9]. Cette cat´
egorie de travaux vise essentiellement `
a am´
eliorer
la QdE dans le cas d’une communication de voix sur IP et ne saurait ˆ
etre utilis´
ee pour
d’autres types d’applications.
D’autres auteurs proposent de nouveaux m´
ecanismes de QdS ou des modifications `
a
ap-porter `
a des m´
ecanismes existants pour pouvoir am´
eliorer la QdE. Dans cette troisi`
eme
cat´
egorie, certains se portent sur de nouveaux m´
ecanismes de gestion des files d’attentes,
l’ordonnancement de paquets et d’autres sur le routage [10]. La plupart des m´
ecanismes
pro-pos´
es ne r´
eagissent pas lorsque la QdE de l’usager se d´
egrade, et ceux qui le font, ne mettent
l’accent que sur les applications multim´
edias o`
u il est possible de faire varier le d´
ebit des
codeurs et d´
ecodeurs ; ce qui n’est pas valable pour les autres types d’application.
1.3
Objectifs de la recherche
L’objectif de ce m´
emoire est de proposer un m´
ecanisme qui permet `
a un r´
eseau IP de r´
eagir
lorsque la QdE, pour certaines applications, subit des d´
egradations, en utilisant l’architecture
de QdS Differentiated Services (DiffServ), dans le but d’assurer que le r´
eseau garantisse un
niveau acceptable de QdE pour ces applications. Les autres types de trafic ne doivent pas ˆ
etre
p´
enalis´
es et l’usage des ressources du r´
eseau doit ˆ
etre optimis´
e. De mani`
ere plus sp´
ecifique le
m´
emoire vise `
a :
1. Analyser les solutions d´
ej`
a impl´
ement´
ees ou propos´
ees dans la litt´
erature relatives `
a
l’am´
elioration de la QdS dans les r´
eseaux IP ;
2. Examiner les propositions existantes dans la litt´
erature qui mettent en ´
evidence l’impact
de la QdS sur la QdE et vice-versa ;
3. Proposer un nouveau m´
ecanisme r´
ealiste qui permet d’ins´
erer l’information de la QdE
dans un r´
eseau pour ˆ
etre utilis´
ee dans des m´
ecanismes de QdS existants ;
4. Proposer une modification dans DiffServ pour prendre en compte l’information de la
QdE ;
5. ´
Evaluer la performance de la proposition au moyen de simulations.
1.4
Plan du m´
emoire
Les objectifs 1 et 2 seront atteints `
a travers la revue de litt´
erature qui fera l’objet du
chapitre 2 o`
u nous pr´
esenterons diff´
erentes techniques qui ont ´
et´
e propos´
ees pour fournir
la QdS dans les r´
eseaux IP et montrerons, `
a travers certains travaux, l’impact sur la QdE
de la QdS et vice versa. Apr`
es avoir fait ressortir les limites des solutions impl´
ement´
ees ou
propos´
ees relatives `
a l’am´
elioration de la QdE dans les r´
eseaux IP, la proposition sera ´
elabor´
ee
et les m´
ecanismes seront d´
ecrits dans le chapitre 2. Au chapitre 3, sera d´
ecrit le simulateur
utilis´
e pour ´
evaluer la performance des m´
ecanismes propos´
es et l’analyse des r´
esultats sera
effectu´
ee. Enfin, la conclusion fera la synth`
ese. Nous y ferons ressortir les limitations des
travaux et y ´
evoquerons ´
egalement certains pistes pour des travaux futurs.
CHAPITRE 2
D´
EFIS DE QUALIT´
E DE SERVICE ET IMPACT SUR LA QUALIT´
E DE
L’EXP´
ERIENCE
Les r´
eseaux IP sont par essence de type best-effort o`
u tous les trafics sont trait´
es de la
mˆ
eme fa¸con sans tenir compte de leurs besoins particuliers. Avec l’´
evolution de l’internet, il
a paru n´
ecessaire d’adjoindre au mod`
ele best-effort, des techniques qui permettent d’utiliser
plus efficacement les ressources r´
eseaux par une gestion pro-active de la congestion, d’assurer
une utilisation ´
equitable des ressources par les diff´
erents flots de trafic et enfin de diff´
erencier
les trafics en leur accordant des priorit´
es pour r´
epondre `
a leurs besoins sp´
ecifiques de qualit´
e
de service (QdS).
Dans ce chapitre seront pr´
esent´
es, dans un premier temps, diff´
erents strat´
egies et mod`
eles
de QdS qui ont ´
et´
e impl´
ement´
es en vue d’am´
eliorer la QdS dans les r´
eseaux IP. Dans un
second temps, seront pass´
es en revue quelques propositions et travaux qui montrent l’impact
de la QdS sur la QdE.
2.1
Strat´
egies et m´
ecanismes ´
el´
ementaires de qualit´
e de service
Les strat´
egies ´
el´
ementaires de QdS incluent : les m´
ecanismes de gestion pro-active des files
d’attente des routeurs qui aident `
a r´
eduire la congestion, les algorithmes d’ordonnancement,
les techniques de contrˆ
ole de trafic etc. Bien qu’elles soient utilis´
ees dans certains cas de fa¸con
individuelle, elles constituent les modules sur lesquels se fondent les principales architectures
de QdS.
2.1.1
Gestion active des files d’attente - AQM
Les m´
ecanismes de gestion active des files d’attente (active queue management ) sont des
m´
ecanismes de gestion pro-active des tampons des routeurs pour ´
eviter que ces derniers soient
congestionn´
es. En effet, les routeurs disposent de m´
emoires tampons qui absorbent les paquets
qui ne peuvent ˆ
etre transmis imm´
ediatement autrement dit les paquets sont mis dans une
file d’attente. Traditionnellement, ces files d’attente sont g´
er´
ees suivant le m´
ecanisme
Drop-Tail illustr´
e `
a la Figure 2.1(a) qui rejette les paquets lorsque la m´
emoire tampon du routeur
est remplie. Bien que cette m´
ethode soit la plus simple `
a mettre en œuvre, elle a n´
eanmoins
plusieurs inconv´
enients. Elle est in´
equitable en terme d’allocation de ressources aux diff´
erents
flots de trafic qui transitent `
a travers les routeurs et peut entrainer des pertes de paquets
en rafale en p´
eriode de congestion. Les sources produisant des rafales importantes risquent
d’ˆ
etre beaucoup plus p´
enalis´
ees que celles `
a d´
ebit constant et il est possible de se retrouver
dans une situation o`
u des files d’attente sont remplies en permanence, ce qui se traduira par
une augmentation du d´
elai exp´
eriment´
e par les paquets.
Les m´
ecanismes d’AQM repr´
esentent une alternative pour ´
eviter ou diminuer la
conges-tion dans le r´
eseau, r´
eduire le taux d’occupation des files d’attente en assurant une bonne
utilisation des liens et une distribution ´
equitable des ressources.
L’algorithme Red Early Drop (RED), illustr´
e `
a la Figure 2.1 (b) et propos´
e par Sally
Floyd [11] est l’algorithme d’AQM le mieux connu. Il utilise l’approche de la moyenne mobile
exponentielle pour calculer la taille moyenne de la file Q
moy. Cette moyenne est compar´
ee `
a
deux seuils d´
efinis pour la taille de la file, un seuil minimal th
minet un seuil maximal th
max.
Lorsqu’un paquet arrive, l’algorithme compare la taille moyenne de la file d’attente `
a ces
deux seuils :
– Si la taille moyenne de la file Q
moyest inf´
erieure au seuil minimal, th
min, le paquet est
ins´
er´
e dans la file d’attente.
– Si la taille moyenne de la file Q
moyest sup´
erieure au seuil minimal, th
minmais inf´
erieure
au seuil maximal, th
max, ce qui indique qu’il y a un d´
ebut de congestion et le paquet
est rejet´
e avec une probabilit´
e p variant lin´
eairement entre 0 et P
max.
– Si la taille moyenne de la file Q
moyest sup´
erieure th
max, il d´
enote une congestion
persistante et le paquet est rejet´
e pour ´
eviter que la file ne soit pas remplie de fa¸con
persistante.
2.1.2
Ordonnancement de paquet
L’ordonnancement des paquets est le m´
ecanisme par lequel le routeur d´
ecide du prochain
paquet `
a envoyer sur le lien. Quand plusieurs files d’attente existent dans le routeur,
l’or-donnancement permet de choisir la prochaine file d’attente qui doit ˆ
etre servie. L’algorithme
d’ordonnancement de base et le plus utilis´
e est l’algorithme premier arriv´
e, premier servi
(FIFO) o`
u les paquets sont servis dans l’ordre de leur arriv´
ee. Il n’´
etablit pas de distinctions
entre les paquets de classes de trafic diff´
erentes ni ne contrˆ
ole le partage des ressources. En
cons´
equence, un flot peut monopoliser toute la capacit´
e d’un routeur dans une p´
eriode o`
u
ses paquets arrivent en rafale. Pour pallier `
a certains des inconv´
enients de l’algorithme FIFO
notamment en ce qui a trait au contrˆ
ole du partage des ressources, la prise en charge de
plusieurs classes de service ou la r´
eduction du temps d’attente dans les files d’attente, deux
1 0 Taille de la file Taille moyenne de la file d’attente 0 pmax Probabilité p de rejet de paquet thmin thmax 1
(a)Drop Tail (b)RED
Probabilité p de rejet de paquet
Taille moyenne de la file d’attente
Figure 2.1 Gestion des files d’attente Drop Tail et RED
autres types d’algorithmes ont ´
et´
e propos´
es : les algorithmes avec priorit´
e (priority queuing)
et les algorithmes de partage de la bande passante.
Parmi les algorithmes avec priorit´
e, l’algorithme priority queuing (PQ) est le plus
po-pulaire. Dans ce dernier, les paquets sont d’abord classifi´
es par le syst`
eme avant d’ˆ
etre mis
dans des files d’attente auxquelles des priorit´
es sont accord´
ees. Les diff´
erentes files d’attente
sont servies dans l’ordre de leur priorit´
e. La file la plus prioritaire est servie en premier et
tant qu’elle contient des paquets aucune autre file n’est servie. `
A l’int´
erieur de chaque file
l’ordonnancement se fait suivant l’algorithme FIFO. L’avantage principal de
l’ordonnance-ment avec priorit´
e est la subdivision du trafic en diff´
erentes classes de fa¸con `
a accorder un
traitement pr´
ef´
erentiel `
a certains types de trafic. Par exemple, les priorit´
es peuvent ˆ
etre fix´
ees
de sorte que les applications temps r´
eel re¸coivent des priorit´
es sup´
erieures par rapport aux
autres applications. Cependant, ce type d’algorithme a un d´
efaut ´
evident en pr´
esentant un
risque de famine pour les files de basses priorit´
es s’il y a constamment du trafic de classes de
priorit´
es ´
elev´
ees. Pour rem´
edier `
a ce probl`
eme de famine, une variante de l’algorithme PQ,
rate-controlled priority queuing, a ´
et´
e propos´
ee afin de limiter le trafic des classes de plus
grande priorit´
e. D’autres m´
ecanismes externes peuvent aussi ˆ
etre utilis´
es pour limiter les flux
qui partagent les files les plus prioritaires.
Les algorithmes Round Robin (RR) et Fair Queuing (FQ) sont utilis´
es pour contrˆ
oler
le partage de la bande passante. Se basant sur le principe de la r´
epartition des paquets
dans diff´
erentes files d’attente, ces algorithmes servent les files d’attente `
a tour de rˆ
ole. Ils
parcourent en s´
equence les diff´
erentes files et prennent le paquet se trouvant `
a l’entˆ
ete de
chacune d’elle. Si une file est vide, ils passent `
a la suivante. Un probl`
eme d’´
equit´
e peut se
produire si les paquets dans les diff´
erentes files ne sont pas de la mˆ
eme taille. Pour pallier
`
a ce probl`
eme ´
eventuel d’´
equit´
e, diverses variantes ont ´
et´
e propos´
ees. L’algorithmeWeighted
Round Robin (WRR) associe un poids `
a chacune des files d’attente. Lorsque l’ordonnanceur
fait un tour, il sert dans chacune des files une quantit´
e de paquets ´
equivalent au poids de
la file. Le poids d’une file se r´
ef`
ere `
a la quantit´
e de bande passante allou´
ee `
a cette file.
Cet algorithme contrˆ
ole la quantit´
e de bande passante allou´
ee `
a chaque classe de trafic.
Cependant, ce contrˆ
ole ne peut ˆ
etre efficace que si tous les paquets ont la mˆ
eme taille ou
quand la taille moyenne des paquets est connue `
a l’avance.
L’algorithme Deficit Weighted Round Robin (DWRR) permet d’adresser les limitations
de l’algorithme WRR en garantissant une r´
epartition juste de la bande passante lorsqu’il sert
des files contenant des paquets de tailles in´
egales. Dans cet algorithme, outre le poids (weight )
qui indique la proportion de bande passante allou´
ee `
a une file, chaque file est configur´
ee avec
deux autres param`
etres :
– Un compteur de d´
eficit (DeficitCounter ) qui sp´
ecifie le nombre total d’octets que la
file peut transmettre `
a chaque fois qu’elle est visit´
ee par l’ordonnanceur. Le compteur
de d´
eficit permet `
a une file qui ne pouvait pouvait pas transmettre lors du passage
pr´
ec´
edent de l’ordonnanceur, parce que la taille du paquet qui occupait l’entˆ
ete de la
file ´
etait sup´
erieure `
a la valeur de DefictCounter, d’avoir des cr´
edits qu’elle peut utiliser
lors du prochain passage de l’ordonnanceur.
– Un quantum de service qui est proportionnel au poids et qui est exprim´
e en octets. Le
compteur de d´
eficit pour une file est incr´
ement´
e par le quantum chaque fois que la file
est visit´
ee par l’ordonnanceur.
Typiquement, `
a chaque tour, l’ordonnanceur visite chacune des files non vide et d´
etermine
la taille en octet du paquet se trouvant `
a l’entˆ
ete de la file. la variable DeficitCounter est
incr´
ement´
ee par la valeur du quantum. Si la taille du paquet se trouvant `
a l’entˆ
ete de la
file est sup´
erieure `
a la variable DefictCounter, alors l’ordonnanceur passe `
a une autre file. Si
elle est inf´
erieure ou ´
egale `
a la variable DefictCounter, alors le paquet est envoy´
e sur le lien.
L’ordonnanceur continue `
a servir les paquets et `
a d´
ecr´
ementer la variable DefictCounter de
la taille des paquets transmis jusqu’`
a ce que la taille du paquet qui arrive `
a l’entˆ
ete de la
file devienne inf´
erieure `
a DefictCounter, ou si la file est vide. Si la file est vide, la valeur de
DefictCounter est mise `
a z´
ero et l’ordonnanceur passe `
a une autre file non vide.
Plusieurs autres algorithmes ont ´
et´
e propos´
es, cependant nous nous gardons de les pr´
e-senter. Pour plus de d´
etails, le lecteur peut se r´
ef´
erer `
a [12].
2.1.3
Routage
De fa¸con g´
en´
erale, le routage consiste en la d´
etermination d’un chemin pour acheminer les
donn´
ees d’une application d’une source `
a une destination. En r´
ef´
erence `
a la QdS, le routage est
utilis´
e pour trouver, non pas un chemin, mais le meilleur chemin pour transporter les donn´
ees
d’une application tout en assurant une bonne utilisation et un partage juste des ressources.
En choisissant le meilleur chemin, l’algorithme de routage doit permettre de satisfaire les
contraintes de l’application en tenant compte de l’´
etat actuel des ressources disponibles dans
le r´
eseau. Par exemple, pour les applications interactives fonctionnant en mode temps r´
eel
comme la voix sur IP, sera choisi un chemin permettant d’avoir un faible d´
elai et un faible
d´
ebit tandis qu’un chemin offrant un haut d´
ebit et un long d´
elai sera plus appropri´
e pour
effectuer du t´
el´
echargement.
Diff´
erents types d’algorithmes de routage sont propos´
es dans la litt´
erature [13] pour faire
la QdS. Ces algorithmes de routage peuvent ˆ
etre cat´
egoris´
es en algorithmes dynamiques ou
statiques, en ligne ou hors ligne. Les algorithmes statiques utilisent des informations qui ne
changent pas dans le temps pour ´
etablir les chemins tandis que ceux qui sont statiques utilisent
des informations li´
ees `
a l’´
etat du r´
eseau comme la bande passante disponible, la capacit´
e des
liens, etc. D’un autre cot´
e, dans les algorithmes de routage en ligne, les chemins sont ´
etablis
sur demande. Ils consid`
erent chaque requˆ
ete de ‘chemin’ s´
epar´
ement ce qui empˆ
eche le routage
`
a nouveau des connections rout´
ees. Les algorithmes hors ligne, par contre, sont utilis´
es dans
des connexions permanentes car de nouvelles routes ne peuvent ˆ
etre calcul´
ees.
2.1.4
Contrˆ
ole et lissage de trafic
Le contrˆ
ole et le lissage de trafic permettent d’assurer la r´
egulation de trafic c’est-`
a-dire
le rythme moyen auquel les donn´
ees sont transmises ainsi que les rafales. Le lissage du trafic
assure le transport des paquets de sorte que le d´
ebit ne d´
epasse pas un seuil maximal. Les
paquets qui ne sont pas directement achemin´
es sont buff´
eris´
es pour ˆ
etre achemin´
es plus tard.
Ce m´
ecanisme n´
ecessite une allocation suffisante de ressources au niveau des routeurs pour
pouvoir mettre dans un tampon les paquets qui sont retard´
es, ce qui permet d’´
eviter des
pertes de paquets et de pr´
evenir la congestion. Le contrˆ
ole de trafic, de son cot´
e, permet de
contrˆ
oler un ou plusieurs flots de trafic agr´
eg´
es, mais `
a la diff´
erence du lissage de trafic, le
trafic exc´
edentaire n’est pas buff´
eris´
e mais rejet´
e.
Le lissage de trafic peut ˆ
etre impl´
ement´
e en utilisant l’algorithme seau `
a jeton (token
bucket ) [14], d´
ecrit `
a la Figure 2.2, avec un seau de taille B qui repr´
esente la taille de rafale
permise et un d´
ebit R de remplissage en jeton du seau. Quand un paquet arrive, la taille du
paquet est compar´
ee au nombre de jetons disponibles dans le seau. Si le nombre d’octets du
seau ´
equivalent au nombre de jetons qu’il contient est au moins ´
egal `
a la taille du paquet, le
paquet est transmis sans d´
elai et le seau est d´
ecr´
ement´
e du nombre de jetons ´
egal au nombre
d’octets du paquet. S’il y a moins de jetons que d’octets dans le paquet, le paquet est retard´
e
c’est-a-dire mis en file d’attente jusqu’`
a ce qu’il y ait assez de jetons dans le seau.
Le seau `
a jeton peut aussi ˆ
etre utilis´
e pour effectuer du contrˆ
ole de trafic. A la diff´
erence
du lissage, lorsqu’un paquet arrive et que le nombre d’octets jetons est inf´
erieur `
a la taille du
paquet, le paquet est rejet´
e.
un paquet de taille b octets arrive Reste-il b octets du seau? Le routeur ajoute des jetons au seau à un taux R
le paquet est soit bufférisé pour être transmis plus tard, soit mis dans une file d’attente mais marqué
comme un paquet
excédentaire, soit droppé
paquet mis dans la file d’attente pour être
transmis enlever b octets du saut Générateur de jetons Taux de remplissage en jetons R bps Taille du seau B bits (taille de raffale permise) Seau à jetons (token bucket) Les jetons sont
accumulés dans le sceau jusqu’a qu’il soit rempli; les jetons excédentaires sont rejetés
oui
non
Figure 2.2 Algorithme Seau `
a Jetons
2.2
Mod`
eles de QdS - Architectures de QdS dans les r´
eseaux IP
Dans un r´
eseau IP, les m´
ecanismes d´
ecrits dans la pr´
ec´
edente section peuvent ˆ
etre
com-bin´
es pour constituer des architectures de QdS. Ces architectures permettent ainsi d’assurer
une qualit´
e de service de bout en bout r´
epondant aux exigences des usagers d´
efinis dans
un contrat de service entre ces derniers et les fournisseurs de service. Deux architectures de
qualit´
e de service ont ´
et´
e standardis´
ees par l’IETF
1. L’architecture des services diff´
erenci´
es DiffServ
2. L’architecture `
a int´
egration de services IntServ
2.2.1
Architecture de qualit´
e de service - IntServ
L’architecture `
a int´
egration de services, IntServ d´
ecrit dans [15], a ´
et´
e con¸cue et adopt´
ee `
a
l’IETF pour permettre `
a internet de supporter la QdS, tout en garantissant un comportement
pr´
evisible du r´
eseau vis `
a vis des applications qui ont des besoins sp´
eciaux en bande passante
et/ou en d´
elai. Cette architecture se repose sur le principe de la r´
eservation de ressources.
L’architecture IntServ est subdivis´
ee en un plan de contrˆ
ole et un plan de donn´
ees dont
les principales composantes sont :
– Protocole de r´
eservation : Il permet d’effectuer la r´
eservation de ressources pour un
nouveau flot qui requiert un niveau de QdS donn´
e. Il met aussi `
a jour la base de
donn´
ees de contrˆ
ole de trafic utilis´
ee par l’ordonnanceur pour d´
eterminer le traitement
`
a offrir aux paquets de chaque flot.
– Contrˆ
ole d’admission : Quand un nouveau flot doit ˆ
etre admis dans le r´
eseau, le
proto-cole de r´
eservation invoque le m´
ecanisme d’admission de contrˆ
ole. Il d´
etermine s’il y a
des ressources suffisantes pour garantir la QdS requise pour le flot.
– Agent de gestion : Pour modifier la base de donn´
ees de contrˆ
ole de trafic qui
com-mande le module d’admission de contrˆ
ole pour que ce dernier applique les politiques
d’admission de contrˆ
ole.
– Protocole de routage : Responsable de la maintenance de la base de donn´
ees de routage
et permet d’indiquer le prochain saut, la prochaine route qui doit ˆ
etre prise pour chaque
adresse de destination et pour chaque flot.
– Classification et s´
election de route : Pour acheminer les paquets, contrˆ
oler le trafic et
effectuer la liaison entre les paquets qui arrivent `
a l’interface du routeur et les classes
de trafic.
– L’ordonnancement et mise en file des paquets.
Dans un r´
eseau supportant IntServ, avant qu’un client ne commence `
a envoyer des paquets
dans le r´
eseau, ce dernier envoie une requˆ
ete vers sa destination, en sp´
ecifiant les caract´
eris-tiques de son trafic (traffic specification ou Tspec). Cette requˆ
ete est ´
evalu´
ee par le r´
eseau
et une r´
eponse est donn´
ee au client pour lui indiquer si oui ou non il peut commencer `
a
transmettre.
Protocole de routage
Protocole de reservation
Protocole de
reservation Agent de gestion
Base de données de contrôle de trafic Base de données de routage Classification & choix de route Ordonnanceur de paquets File best-effort File avec QdS Plan de contrôle Plan de données Arrivée des paquets
Figure 2.3 Architecture IntServ
Du point de vue du r´
eseau, l’´
etablissement de la communication implique plusieurs ´
etapes
qui sont effectu´
ees `
a travers les principales composantes de l’architecture IntServ montr´
ees `
a
la Figure 2.3.
Dans le plan de contrˆ
ole, l’´
etablissement de la communication implique deux tˆ
aches
prin-cipales au niveau du protocole de r´
eservation. D’abord le protocole de routage doit d´
eterminer
le prochain hop vers lequel la requˆ
ete doit ˆ
etre envoy´
ee. Ensuite, se basant sur la d´
ecision
de routage, l’admission de contrˆ
ole doit d´
ecider s’il y a assez de ressources disponibles `
a
l’in-terface de sortie choisie pour accepter la nouvelle communication. Si la r´
eservation est faite,
les ressources engag´
ees sont enregistr´
ees dans la base de donn´
ees de contrˆ
ole de trafic. Les
informations relatives `
a la r´
eservation de ressources sont utilis´
ees pour configurer le module
de classification et d’ordonnancement dans le plan de donn´
ees. Quand un paquet arrive `
a un
routeur, le module de classification choisit les paquets qui appartiennent aux flots r´
eserv´
es
et les ins`
ere dans leurs files d’attente appropri´
ees. L’ordonnanceur sert ensuite les diff´
erentes
files suivant les informations de la r´
eservation.
Le contrˆ
ole d’admission et la r´
eservation de ressources sont bas´
es, entre autres, sur
l’in-formation contenue dans le TSpec. La sp´
ecification du trafic ou TSpec est une description du
trafic pour lequel la requˆ
ete de service a ´
et´
e effectu´
ee. En g´
en´
eral TSpec est une clause du
contrat entre les flots de donn´
ees et le service. Une fois la requˆ
ete de service est accept´
ee, le
module de service accepte de fournir la QdS demand´
ee tant que les flots de donn´
ees du trafic
demeurent tel qu’ils ont ´
et´
e d´
ecrits par le TSpec. Le client d´
esirant faire une r´
eservation doit
effectuer une requˆ
ete de QdS (Request Specification ou RSpec) associ´
ee au TSpec,
Deux grandes classes de service sont d´
efinies dans IntServ : Service garanti et charge
contrˆ
ol´
ee. La classe de service garanti est utilis´
ee pour des applications ayant besoin d’une
garantie pour le d´
elai et la largeur de bande. Les applications de cette classe de service
doivent fournir un TSpec qui indique, entre autres, le d´
ebit maximal, la longueur maximale
des paquets et la dur´
ee des rafales. Le RSpec doit contenir la largeur de bande requise par
l’application pour pouvoir d´
eterminer le d´
elai maximal. La classe de service charge contrˆ
ol´
ee
est utilis´
ee pour des applications n’ayant pas besoin d’une borne garantie math´
ematiquement
pour le d´
elai et la largeur de bande. Pour cette classe de service, on s’assure que l’application
recevra un niveau de QdS comparable `
a celle qu’elle aurait dans un r´
eseau non charg´
e, mais
avec la capacit´
e n´
ecessaire.
Bien que d’autres protocoles puissent ˆ
etre utilis´
es pour faire les requˆ
etes de QdS dans
IntServ, le protocole RSVP [16] qui a ´
et´
e d´
evelopp´
e pour effectuer la r´
eservation de ressources
sur internet, est fortement sugg´
er´
e [17]. Dans IntServ, RSVP permet `
a l’application de signaler
ses besoins en QdS en transmettant, entre autres, le TSpec, RSpec et le type de service. Deux
types de message sont utilis´
es par RSPV pour ´
etablir une r´
eservation : les messages PATH
et les messages RESV. Le message PATH va de l’origine `
a une ou plusieurs destinations et
transporte l’information de la classification et le TSpec. Apr`
es avoir re¸cu le message PATH,
la destination envoie le message RESV qui contient les informations de la session, le RSpec
et la QdS. Une fois le message RESV re¸cu, l’´
emetteur peut commencer `
a envoyer des paquets
via le chemin r´
eserv´
e.
Quoiqu’elle puisse permettre de garantir la QdS, l’architecture IntServ pr´
esente de
nom-breux inconv´
enients qui ont empˆ
ech´
e qu’elle soit d´
eploy´
ee `
a grande ´
echelle. D’abord, la
granu-larit´
e est trop petite ce qui peut donner lieu `
a un tr`
es grand nombre de r´
eservation. Ensuite,
la quantit´
e d’informations stock´
ees dans chaque nœud augmente avec le nombre de flots,
ce qui n´
ecessite beaucoup de capacit´
e de stockage et de traitement au niveau des routeurs.
De plus, chaque routeur doit impl´
ementer RSVP, les m´
ecanismes d’admission de contrˆ
ole, la
classification et l’ordonnancement, ce qui rend le d´
eploiement de IntServ aux routeurs tr`
es
complexe.
2.2.2
Architecture de qualit´
e de service - DiffServ
Compte tenu des inconv´
enients de l’architecture IntServ, l’IETF s’est pench´
e sur des
m´
ecanismes plus simples pour satisfaire la QdS. Dans cette perspective, l’architecture DiffServ
[18] a ´
et´
e propos´
ee.Cette architecture se base sur la plupart des m´
ecanismes ´
el´
ementaires de
QdS d´
ecrits dans la section 2.1. Elle d´
efinit un cadre qui permet de faire de la QdS dans
les r´
eseaux IP en utilisant des m´
ecanismes qui permettent de classifier les paquets `
a l’entr´
ee
du r´
eseau, les v´
erifier pour ´
eventuellement effectuer des actions de mises en conformit´
e, les
marquer et les transf´
erer `
a travers les diff´
erents nœuds du r´
eseau de fa¸con `
a garantir le niveau
de service sp´
ecifi´
e dans le contrat de service (SLA).
L’architecture DiffServ d´
efinit des zones de services diff´
erenci´
es. Une zone de service
dif-f´
erenci´
e est un domaine constitu´
e de routeurs qui supportent les fonctionnalit´
es de Diffserv.
Nous y trouvons deux types de routeurs suivant qu’ils sont situ´
es en bordure de la zone (Edge
Node) ou `
a l’int´
erieur (Core Node).
Les routeurs d’entr´
ee (Edge Node) sont responsables d’effectuer la classification et le
conditionnement du trafic (Traffic classification and conditionning).
heightheight
classification de paquets
Meter
Marquer Dropper/shapper
Conditionnement de trafic
arrivée des paquets paquets marqués
