La différenciation de services

par Octavio MEDINA

Ingénieur de recherche
GET/ENST Bretagne, département réseaux et services multimédias
et Géraldine TEXIER
Maître de conférences
GET/ENST Bretagne, département réseaux et services multimédias

1. Vers la différenciation de services ..................................................... TE 7 565 - 2

1.1 Modèle IntServ............................................................................................. — 2
1.2 Origines du groupe DiffServ à l’IETF.......................................................... — 3
1.3 Ancienne approche : le champ ToS............................................................. — 3
2. Mécanismes élémentaires ..................................................................... — 3
2.1 Identification d’un flux IP ............................................................................ — 3
2.2 Caractérisation d’un flux IP : le seau à jetons ........................................... — 3
2.3 Mécanismes d’ordonnancement................................................................ — 4
2.3.1 Algorithmes à file unique : Fair Queueing........................................ — 4
2.3.2 Algorithmes à files multiples : Round Robin,
Strict Priority Queueing...................................................................... — 5
2.4 Mécanismes de gestion de file d’attente ................................................... — 6
2.4.1 Random Early Discard ........................................................................ — 6
2.4.2 Weighted RED ..................................................................................... — 7
2.4.3 RED with In and Out ........................................................................... — 8
3. Modèle DiffServ ....................................................................................... — 8
3.1 Caractéristiques ........................................................................................... — 8
3.2 Fonctionnement........................................................................................... — 8
3.3 Routeur d’entrée .......................................................................................... — 9
3.3.1 Classification ....................................................................................... — 10
3.3.2 Vérification .......................................................................................... — 10
3.3.3 Actions de mise en conformité.......................................................... — 10
3.3.4 Étiquetage ........................................................................................... — 11
3.4 Routeurs de cœur du réseau ...................................................................... — 11
3.5 Comportements standardisés .................................................................... — 11
3.5.1 Sélecteurs de classe ........................................................................... — 11
3.5.2 Comportement expédié...................................................................... — 12
3.5.3 Comportement assuré........................................................................ — 12
3.6 Comportements expérimentaux ................................................................ — 13
3.6.1 Less than Best Effort........................................................................... — 13
3.6.2 Alternative Best Effort ........................................................................ — 13
3.7 Services ........................................................................................................ — 13
4. Conclusion ................................................................................................. — 14
Références bibliographiques ......................................................................... — 14

’Internet existant, fondé sur le principe du Best Effort (voir [H 2 285]), n’a pas
L été initialement conçu pour prendre en compte des informations de qualité
de service (QoS). Le modèle Best Effort maximise l’utilisation de ressources tout
en simplifiant l’opération des équipements d’interconnexion. Quand la mémoire
d’un routeur est saturée, les paquets arrivants sont rejetés. Les mécanismes de
retransmission de TCP (Transport Control Protocol) recouvrent ces pertes, garan-
tissant un transfert sans faute de bout en bout. Simultanément, les algorithmes

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 1

Dossier délivré pour

DOCUMENTATION
21/10/2008
LA DIFFÉRENCIATION DE SERVICES ________________________________________________________________________________________________________

de « slow start » et de « congestion avoidance », implantés dans TCP, assurent

une distribution de ressources relativement équitable [1] [2].
Si le comportement de TCP répond aux besoins d’applications traditionnelle-
ment majoritaires dans le réseau comme telnet ou ftp [10], il est peu adapté
pour la transmission des flux avec des contraintes temporelles. Les applica-
tions de visioconférence ou de voix sur IP (VoIP) sont pour la plupart basées
sur le protocole UDP (User Datagram Protocol) [3]. Ce protocole peut être uti-
lisé pour obtenir un débit quasi constant, mais il n’implante pas de mécanisme
de gestion de la congestion. La présence de flux non adaptatifs affecte la
performance de TCP, pénalisant les applications basées sur ce protocole. Des
mesures de contrôle sont nécessaires pour éviter la saturation du réseau par
les flux non adaptatifs, en assurant qu’un minimum de ressources est disponi-
ble pour que les applications TCP puissent communiquer.
Les mécanismes de contrôle de TCP empêchent la gestion du partage des
ressources. La quantité de ressources accordées à un flux dépend de la capacité
des liens et de la présence d’autres flux dans le réseau. Des intérêts écono-
miques poussent à la modification de ce comportement. Une distribution
contrôlée de la bande passante permettrait aux opérateurs de définir de nou-
veaux services qui pourraient être facturés en conséquence. S’il devient possible
dans l’Internet d’assurer le débit ou le délai observés, les opérateurs seront en
position d’implanter une politique tarifaire conforme aux ressources accordées.
L’évolution d’Internet pour prendre en compte les besoins des nouveaux flux
et pour contrôler la distribution de ressources se fait en modifiant, au niveau 3,
les mécanismes de file d’attente dans les routeurs ou en se basant sur les pro-
priétés offertes par le niveau 2 (priorités dans IEEE 802.1p, classes de services
ATM - Asynchronous Transfer Mode) plutôt qu’en modifiant TCP. Les mécanismes
de contrôle de flux de ce protocole sont très mal compris à grande échelle, les
modèles analytiques ne sont pas assez précis et la simulation ne peut s’appli-
quer qu’à de petits réseaux. Comme le bon fonctionnement de l’Internet repose
sur ces mécanismes, les modifications de TCP se font très lentement [4].
Afin d’avoir une vision claire sur la différenciation de services, cet article en
montre dans une première partie les motivations ainsi que le cheminement suivi
pour arriver aux solutions proposées aujourd’hui. Les mécanismes expliqués
ensuite sont les briques de base nécessaires à la mise en œuvre de la différen-
ciation dans les réseaux. L’une des tâches essentielles lors de la mise en place
de la différenciation de services est de choisir les mécanismes appropriés et de
les paramétrer de façon à ce que la composition de leurs actions accomplisse
le traitement différencié des flux dans le réseau. Une dernière partie présente
le modèle DiffServ défini à l’IETF (Internet Engineering Task Force) afin de mettre
en œuvre la différenciation de services dans le réseau.

1. Vers la différenciation tionnalités nécessaires à l’implantation de ces services ont été étu-
diées, mettant en correspondance les critères de QoS d’IntServ et
de services ceux des technologies de niveau 2 (ATM, liens à bas débit, IEEE802)
[7] [8] [9]. En même temps, un protocole de signalisation, RSVP
(Reservation Protocol - RFC 2 205 et 2 210), a été défini pour assurer
l’échange des informations de qualité de service entre les routeurs.
1.1 Modèle IntServ
Le modèle IntServ présente les caractéristiques suivantes.
En réponse aux demandes d’amélioration de la QoS dans l’Inter-
■ Le modèle est orienté récepteur, ce qui permet la réservation de
net, l’IETF a créé en 1994 plusieurs groupes de travail destinés à
ressources pour les flux multicast. En échange, il a été nécessaire de
définir une architecture à intégration de services. Dans une telle
déterminer un mécanisme pour assurer la symétrie des routes entre
architecture, il est possible de garantir le taux de perte et le délai
les émetteurs et les récepteurs.
d’acheminement observés par un flux individuel, tout en contrôlant
la distribution de ressources entre les flux [3]. ■ Pour que la qualité de service puisse être garantie, des ressources
Le modèle IntServ, issu des travaux de standardisation, définit doivent être réservées dans chaque routeur. Cela demande
deux nouveaux services : garanti [5] et contrôlé [6], mieux adaptés l’implantation de fonctions de contrôle d’accès, de classification et
aux nouveaux besoins des utilisateurs et des applications. Les fonc- de gestion de ressources dans chaque nœud du réseau.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 565 − 2 © Techniques de l’Ingénieur

Dossier délivré pour

DOCUMENTATION
21/10/2008
 _______________________________________________________________________________________________________ LA DIFFÉRENCIATION DE SERVICES

■ La granularité spécifiée par le modèle permet de réserver des

ressources jusqu’au niveau des microflux (un transfert ftp, par 2. Mécanismes élémentaires
exemple), augmentant le nombre de réservations devant être
gérées par chaque routeur. Avant d’introduire le modèle à différenciation de services Diff-
Serv, nous décrivons les briques de base qui peuvent servir à la
■ Au niveau technique, la faiblesse principale de l’architecture construction d’une telle architecture. Les fonctions nécessaires à
IntServ est sa non-résistance au facteur d’échelle. Le nombre de flux l’identification et à la caractérisation d’un flux sont analysées ainsi
qui peuvent bénéficier d’une réservation est assez limité, en particu- que les mécanismes d’ordonnancement et de gestion de la conges-
lier dans les routeurs de cœur de réseau. Ces équipements doivent tion. L’identification et la caractérisation d’un flux IP sont deux fonc-
traiter des milliers des flux simultanément [10], et le coût introduit tions qui peuvent être utilisées pour déterminer le niveau de
par la gestion d’états et l’ordonnancement par flux peut entraîner conformité du flux par rapport à son contrat de service. En revanche,
une réduction considérable de leur performance. la mise en place des mécanismes d’ordonnancement et de gestion
■ Au niveau économique, la réservation de ressources est incom- de file d’attente peuvent servir à satisfaire les besoins de qualité de
patible avec le système de tarification forfaitaire habituellement uti- service que les flux réclament.
lisé dans l’Internet. Si aucun contrôle n’est effectué, un seul
utilisateur peut réserver la totalité de la bande passante au détri-
ment des connexions établies par d’autres utilisateurs. Un nouveau 2.1 Identification d’un flux IP
système de tarification, basé sur la quantité de ressources réser-
vées, devrait être implanté dans le réseau. Avec l’introduction du Le protocole IP, orienté datagramme, ne comporte pas de notion
protocole COPS (Common Open Policy Service) [11] [12], une telle de flux dans sa définition. Ce concept est néanmoins nécessaire à
action est imaginable à l’intérieur d’un domaine. En revanche, pour la mise en œuvre d’une architecture de différenciation de services.
que le modèle puisse être implanté à grande échelle, l’échange des Les équipements intermédiaires du réseau doivent être capables
informations concernant la tarification doit être sécurisé. d’identifier les paquets IP appartenant à un même « flux », afin de
leur accorder le traitement dont ils ont besoin. Si l’un des principes
La standardisation du modèle IntServ s’est achevée en 1997. du modèle DiffServ est l’agrégation, il existe toujours une première
Pourtant, le modèle n’a jamais été implanté à grande échelle dans classification assez fine (qui peut avoir lieu directement dans la
le réseau. Les faiblesses énumérées précédemment empêchent station émettrice) qui identifie les microflux IP avant qu’ils soient
son déploiement. De nouvelles propositions cherchant à offrir des injectés dans le réseau.
garanties strictes dans le réseau sont actuellement à l’étude. Elles
se basent sur une architecture hybride IntServ-DiffServ [15]. Un microflux peut représenter une connexion TCP ou un stream
UDP individuel. Au sens IP, un microflux est identifié par cinq
champs dans l’en-tête [22]. Tous les paquets portant des valeurs
1.2 Origines du groupe DiffServ à l’IETF identiques sur ces champs appartiennent au même microflux IP.
Les champs concernés sont :
Les travaux de l’IETF en matière de différenciation de services — adresse source IP ;
débutent au moment où les documents définissant le modèle Int- — adresse destination IP ;
Serv deviennent des standards (RFC 2 205 à 2 216). Les créateurs de — protocole de transport (TCP, UDP, autres) ;
l’IntServ observent plus attentivement les défauts de cette architec- — port source (pour TCP ou UDP) ;
ture et cherchent à faire des modifications [16] [17] pour assurer sa — port destination.
pérennité. Pendant la même période, de nouvelles propositions [18]
Dans certaines situations, l’obtention du quintuple qui identifie un
[19] décrivent des mécanismes plus simples capables de satisfaire
microflux peut devenir une opération compliquée. Dans le modèle
les besoins de QoS d’un grand nombre d’applications. Ces propo-
IPsec [13] [TE 7 545], l’en-tête du protocole de transport (TCP ou
sitions ont servi de base à la définition du modèle DiffServ.
UDP) est chiffré et, par conséquent, illisible dans les routeurs inter-
Quand le groupe de travail DiffServ a été créé en 1997, les objectifs médiaires. Dans le cas où cette information est indispensable pour
à poursuivre n’étaient pas précisément définis. Il était difficile de la différenciation, une extension peut être définie, ce qui est le cas
visualiser quelles étaient les relations avec les travaux sur IntServ, pour RSVP [14].
quelle serait l’étendue du travail de standardisation et quel type
Un problème différent existe avec IPv6 [23] : dans cette version
d’architecture pourrait accélérer le déploiement du modèle. Finale-
du protocole, la présence d’extensions d’en-tête peut compliquer la
ment, la charte du groupe [20] reflète le résultat des discussions :
recherche des numéros de port. Pour résoudre ce problème, le
le groupe s’est centré sur la définition d’un modèle simple, modu-
champ « étiquette de flux » peut être utilisé. Ce champ, actuellement
laire, dont la mise en œuvre peut s’effectuer d’une manière gra-
inutilisé, peut servir à réduire le nombre de paramètres à vérifier
duelle dans l’Internet existant.
et éviter le traitement des extensions. Dans ce cas, l’étiquette de flux
et l’adresse source suffisent pour garantir l’unicité.
1.3 Ancienne approche : le champ ToS
La différenciation de services se base sur une étiquette introduite 2.2 Caractérisation d’un flux IP :
dans chaque paquet qui détermine le traitement que celui-ci obtient le seau à jetons
dans le réseau. Ce concept n’est pas nouveau dans l’Internet. Dès
la définition du protocole IPv4 [21], le champ ToS (Type of Service) La différenciation de services comporte un compromis entre les
dans l’en-tête était dédié aux informations de qualité de service. sources d’information et le réseau. Le réseau s’engage à assurer la
Trois bits de ce champ dénotaient la précédence (priorité) du paquet, QoS demandée pour les flux IP tant que les sources respectent le
pendant que quatre bits indiquaient la préférence pour l’un des profil de trafic accordé. Il existe plusieurs possibilités pour caracté-
quatre services identifiés à l’époque. La définition de services trop riser le comportement d’un flux IP. Dans les travaux de l’IETF
vagues et une absence de contrôle font que ce champ n’a été utilisé concernant la qualité de service, l’algorithme recommandé pour
que par les protocoles de gestion de réseau. réaliser cette opération est le seau à jetons.
Le modèle à différenciation de services aurait pu se baser sur l’uti- Le seau à jetons (figure 1) caractérise un flux grâce à deux para-
lisation effective du champ ToS, mais les 8 bits qui forment le ToS ne mètres r et b [22]. Le premier représente le débit moyen d’émission
sont pas utilisés de manière efficace. Les services proposés sont alors que le deuxième indique la taille maximale des rafales que la
plutôt liés à la sélection des routes et de nouveaux services ne peu- source peut générer. Avec cet outil, un flux est caractérisé par son
vent pas être ajoutés, ce qui justifie le besoin d’un nouveau modèle. débit moyen et la déviation temporaire acceptable de ce débit.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 3

Dossier délivré pour

DOCUMENTATION
21/10/2008
LA DIFFÉRENCIATION DE SERVICES ________________________________________________________________________________________________________

paquet Flux 0 ; r0 = 2
Li 10 25 10 10 25 15 15
paquet
r (octets/s) A B C D E F G
Fi 5 17,5 22 27 40 47,5 55
b (octets)
Flux 1 ; r1 = 1
Li 10 25 10 10 25 15 15
Figure 1 – Seau à jetons
L M N O P Q R
Fi 10 35 45 55 80 95 110
En tant qu’algorithme de caractérisation, r représente la vitesse
de remplissage du seau et b la taille de celui-ci. À l’instant initial, Ordonnancement
le seau est rempli de jetons. Lors de l’arrivée d’un paquet, le seau
est débité de L jetons, où L représente la taille en octets du paquet A L B C D M E N F G O P
arrivant. Entre l’arrivée de deux paquets, le niveau du seau monte 5 10 17,5 22 27 35 40 45 47,5 55 55 80
à une vitesse de r jetons /s. Le remplissage s’arrête quand le niveau
du seau atteint b. Tant qu’il y a des jetons dans le seau, le flux est
considéré conforme aux spécifications. Figure 2 – Ordonnancement par Weighted Fair Queueing

Le seau à jetons est un élément indissociable du modèle IntServ.

Le profil de trafic de tout flux demandant une réservation de res-
sources est composé par les paramètres r et b d’un seau à jetons Dans l’exemple de la figure 2, le poids attribué au flux 0 est le
[24]. Cette information est utile pour déterminer s’il existe assez de double de celui du flux 1 (r 0 = 2 , r 1 = 1). Par conséquent, malgré
ressources dans un routeur pour accepter une nouvelle réservation. l’équivalence dans la taille des paquets ( L 0 = L 1 ) , les paquets du
i i
Dans le modèle DiffServ, le seau à jetons est utilisé par les routeurs i i
de frontière afin de vérifier la conformité du trafic soumis par une flux 1 auront des estampilles deux fois plus grandes ( F 1 = 2F 0 ) .
source avant de l’accepter dans le réseau. L’état de la file, représenté en bas de la figure 2, montre que les
paquets du flux 0 sont effectivement servis en premier. À long
terme, le flux 0 doit observer un débit deux fois plus important que
2.3 Mécanismes d’ordonnancement le flux 1.
La formule précédente (1) présente deux défauts. En premier
Le traitement différencié de paquets dans le modèle DiffServ lieu, elle ne prend pas en compte le temps d’arrivée des paquets.
peut être décomposé en deux axes : le regroupement de flux en Si un flux reste inactif pendant que d’autres évoluent, la valeur des
i
classes de services et l’introduction de priorités au sein des flux. estampilles F k est désynchronisée. Lors de son réveil, le flux se
Les principaux algorithmes d’ordonnancement servant à contrôler verra attribuer des estampilles de faible valeur et obtiendra une
la distribution des ressources entre les classes de services sont quantité de ressources qui ne correspond pas à son poids rk . En
présentés ici. second lieu, la formule ne prend pas en compte la présence
Nombreux sont les ouvrages qui traitent du problème de l’ordon- d’autres flux, information indispensable pour calculer la quantité
nancement dans les routeurs [26] [27] [28] [34]. Plusieurs techniques exacte de ressources qu’un flux peut obtenir. Des techniques plus
ont été développées pour contrôler le partage de ressources, pour avancées introduisent la notion de temps virtuel pour caractériser
isoler des classes de services ou encore pour réduire le temps l’accélération du service quand certains flux ne sont pas actifs à un
d’attente des paquets dans les files. Ces algorithmes peuvent être moment donné.
classés en fonction de l’approche qu’ils mettent en œuvre : l’utili- La fonction de temps virtuel permet de définir le temps que les
sation d’une file d’attente unique ou de plusieurs files. paquets restent dans une file d’attente. Elle définit l’accélération du
service quand certaines classes de services sont absentes. Le
temps virtuel v ( t ) est calculé à partir de la formule suivante, où les
2.3.1 Algorithmes à file unique : Fair Queueing instants τ et τ ′ limitent un intervalle de temps où l’ensemble de
Des mécanismes tels que WFQ [28], SCFQ [29] ou encore SCFQ+ flux actifs reste constant :
[30] se basent sur la notion d’estampilles temporelles qui détermi- 1
nent le point d’insertion d’un paquet dans une file unique. Cette ν (τ ′ ) – ν (τ ) = ------------------------ (τ ′ – τ ) (3)
estampille est calculée à partir du poids attribué à la classe de ser- ∑ ri
r ∈ actifs
vice, de la longueur du paquet et de l’interaction avec les autres
classes actives sur le lien. Avec cette correction, une politique de distribution de ressources
La figure 2 montre un exemple d’ordonnancement par Weighted équitable peut être mise en place à l’aide de la formule :
Fair Queueing. Dans l’algorithme de base du WFQ, les estampilles i 1 i i i– 1
temporelles sont calculées à partir de la formule : F k = ------ L k + max [ ν ( a k ), F k ] (4)
rk
i 1 i i– 1 i
F k = ------L k + F k (1) où a k représente le temps que met un paquet pour arriver. Cette
rk formule est utilisée par l’algorithme de Self-Clocked Fair
i Queueing [29]. Une bonne description des méthodes de Fair
où F k désigne l’estampille du i-ème paquet du flux k , r k le poids Queueing peut être consultée dans [31].
i L’insertion ordonnée des paquets dans une file unique est une
attribué au flux et L k la longueur du paquet. Le poids d’une classe
rk détermine le pourcentage de bande passante que la classe se opération coûteuse. Plus précisément, le Fair Queueing demande
un travail de O [lg (n )] par paquet où n est le nombre de classes acti-
voit attribuer. On dit que les poids sont normalisés si : ves dans le lien [32]. De plus, si les contraintes des classes de ser-
∑ rk = 1 (2) vices telles qu’elles ont été définies par DiffServ sont prises en
compte, il est difficile d’imaginer l’application de ce type de tech-
∀k

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 565 − 4 © Techniques de l’Ingénieur

Dossier délivré pour

DOCUMENTATION
21/10/2008
 _______________________________________________________________________________________________________ LA DIFFÉRENCIATION DE SERVICES

niques dans l’architecture. L’inconvénient majeur de l’approche à file

unique est le manque d’isolement des flux. Le comportement d’un
Classificateur
flux ou d’une classe de service peut facilement perturber les per-
formances des autres classes.

2.3.2 Algorithmes à files multiples :

Round Robin, Strict Priority Queueing
Le principe de Round Robin est très adapté à l’isolement de flux
grâce à la répartition des paquets dans plusieurs files d’attente. En Ordonnanceur
même temps, les implémentations de ces techniques peuvent être
très efficaces, puisque le travail demandé par paquet n’est que de Sortie
O (1) [33]. La figure 3 montre l’architecture de base du Round
Robin. L’ordonnanceur parcourt en séquence les files et prend le
premier élément. Si une file est vide, l’ordonnanceur passe à la file Figure 3 – Modèle d’ordonnancement par files multiples
suivante. L’équité offerte par ce mécanisme dépend de la taille
moyenne des paquets dans chaque file : une file contenant des
paquets deux fois plus gros que les autres obtient deux fois plus
de bande passante. Il est donc nécessaire de modifier l’algorithme Encadré 1 – Ordonnancement
pour limiter le nombre d’octets que l’ordonnanceur peut servir par Deficit Round Robin
pour chaque file afin d’assurer l’équité.
Le Deficit Round Robin (DRR) a été proposé par Shreedhar et Initialisation :
Varghese [32]. Cette technique est une variation du bit-by-bit Round DC [i] = 0 (Deficit Counter de chaque classe)
Robin : un modèle théorique d’ordonnancement prenant en Au passage de l’ordonnanceur par la file i :
compte la taille des paquets [34]. Dans cet algorithme, la variable DC [i] = DC [i] + quantum
quantum est chargée de limiter le nombre d’octets débités dans Tant que DC [i] > L (longueur paquet en-tête)
chaque file lors du passage de l’ordonnanceur. Si la taille du le paquet est transmis
paquet en tête de la file est supérieure au quantum, le paquet n’est DC [i] = DC [i] – L
pas transmis et les jetons sont accumulés pour être utilisés lors du Quand L > DC [i]
prochain passage. L’encadré 1 détaille l’algorithme du DRR. l’ordonnanceur passe à la file suivante
La figure 4 contient un exemple d’ordonnancement avec l’algo- Les crédits restant dans DC [i] sont conservés pour le passage
rithme de DRR. Les tableaux à droite montrent l’évolution des cré- suivant.
dits pour chaque file d’attente à chaque passage de Si, après service, une file est vide, DC [i] = 0.
l’ordonnanceur.
■ Weighted Round Robin (WRR) : en introduisant la notion de poids
sur les classes de services, les techniques de WRR peuvent offrir une traire de chaque file d’attente à chaque passage de l’ordonnanceur.
distribution différenciée de la bande passante. À la différence des Par exemple, en utilisant l’algorithme de DRR décrit précédemment,
techniques de Fair Queueing où le poids d’une classe r k est utilisé une pondération des flux peut être facilement mise en œuvre si l’on
pour calculer l’estampille temporelle, dans les mécanismes de attribue des valeurs de quantum différentes pour chaque classe de
Round Robin, cette variable détermine le nombre d’octets à sous- services, c’est-à-dire que quantum k = r k .

Évolution de DCi
Jour Avant Après Service
Flux 0 ; quantum = 15 1 15 5 A
L0i 10 25 10 10 25 15 2 20 20
A B C D E F 3 35 0 B, C
4 15 5 D
5 20 20

Évolution de DCi
Jour Avant Après Service
Flux 1 ; quantum = 15 1 15 5 L

L1i 10 15 10 15 25 10 2 20 5 M
L M N O P Q 3 20 10 N
4 25 10 O
5 25 0 P

Ordonnancement
A L M B C N D O P E Figure 4 – Ordonnancement
par Deficit Round Robin

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 5

Dossier délivré pour

DOCUMENTATION
21/10/2008
LA DIFFÉRENCIATION DE SERVICES ________________________________________________________________________________________________________

mécanismes sont de toute façon nécessaires puisqu’un bas délai ne

Classe 1 Classe 2 Classe 3 peut être garanti que si l’occupation des files d’attente reste faible
à tout moment. Comme nous le verrons dans la définition du service
11 11 11
Premium (§ 3.5.2), un élément de signalisation, le Bandwidth Bro-
10 10 10
ker, est introduit pour prendre en considération cette contrainte [38].
9 9 9
8 8 8
7 7 7
6 6 6 2.4 Mécanismes de gestion
5 5 5 de file d’attente
4 4 4
Temps d’arrivée

Temps d’arrivée

Temps d’arrivée
3 3 3 Il ne faut pas confondre les mécanismes d’ordonnancement avec
2 2 2 ceux de gestion de file d’attente. L’ordonnancement est la fonction
1 1 1
qui distribue les ressources entre les différentes classes de services.
0 0 0
La gestion de file d’attente est la fonction qui, au sein d’une même
Longueur classe, détermine quels paquets éliminer en cas de congestion. Deux
du paquet mécanismes de gestion de file d’attente peuvent être utilisés pour
Ordonnanceur mettre en œuvre une politique d’élimination sélective, nécessaire
pour implanter le comportement assuré du modèle DiffServ (§ 3.5.3).
Traditionnellement, la politique FIFO (first-in, first-out ) est utilisée
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
dans les routeurs. Dans ce cas, si le débit d’arrivée est supérieur au
débit de sortie, les paquets s’accumulent dans la file jusqu’à ce
Ordre de sortie
qu’elle atteigne sa taille maximale. À partir de ce moment, tous les
paquets arrivants sont éliminés. Si cette méthode est la plus simple
Figure 5 – Ordonnancement par Priority Queueing à mettre en œuvre, elle a aussi plusieurs défauts. D’abord, elle peut
être très inéquitable : des sources produisant des rafales importan-
tes risquent d’être plus pénalisées que des sources ayant un débit
Le Class-Based Queueing (CBQ), défini par Floyd et Jacobson quasi constant. Ensuite, il se peut qu’un grand nombre de paquets
[35], est un modèle de référence pour tout ce qui concerne l’ordon- soit éliminé consécutivement, provoquant l’entrée simultanée de
nancement dans l’Internet. Le modèle propose de regrouper les plusieurs flux TCP en mode de slow start . On parle alors de syn-
flux dans un nombre limité de classes en fonction du type d’appli- chronisation des flux. Enfin, des files remplies en permanence se
cation et /ou de l’identité de l’émetteur. Il existe une relation hiérar- traduisent par une augmentation du délai observé par les paquets.
chique entre les classes qui détermine la distribution de
ressources. À partir de ces principes, les auteurs établissent les Pour résoudre les problèmes liés au mécanisme FIFO, il existe des
objectifs que toute politique de gestion de ressources doit accom- propositions [39] [40] dans lesquelles le protocole de transmission
plir. En revanche, la proposition de Floyd et Jacobson ne définit dans les extrémités contrôle la vitesse d’émission pour réduire la
aucun algorithme spécifique d’ordonnancement. Des implémenta- taille des files dans les routeurs. Ces solutions sont difficiles à mettre
tions de WRR, comme le Hierarchical Round Robin [36], peuvent en œuvre et leur efficacité est relative. Le meilleur endroit pour
très bien servir à la mise en œuvre du CBQ tout en respectant les contrôler l’évolution des files d’attente est dans le routeur même [41].
contraintes de l’architecture DiffServ. Le Random Early Discard (RED, § 2.4.1), proposé par Sally Floyd,
est un mécanisme de gestion de file d’attente très efficace qui est
■ Strict Priority Queueing (SPQ) : l’ordonnancement prioritaire, devenu très populaire. Suivant un algorithme relativement simple,
une variation du Round Robin assez simple à mettre en œuvre, a la RED a pour but de réduire le taux d’occupation d’une file d’attente
capacité de diminuer considérablement le délai observé par les tout en restant équitable sur la distribution des pertes. Cet algo-
paquets sensibles à ce paramètre. Cette technique est sans doute la rithme peut être facilement modifié pour éliminer les paquets en
meilleure alternative d’ordonnancement pour des flux tels que la fonction de leur précédence. WRED (Weighted RED, § 2.4.2) et RIO
téléphonie sur IP ou les jeux interactifs. (RED with In and Out, § 2.4.3) en sont deux exemples.
Dans une implémentation naïve, l’algorithme SPQ est le suivant :
supposons qu’il n’existe que quatre classes de services numérotées
de 1 à 4 en fonction de leur sensibilité au délai, la classe 1 étant la 2.4.1 Random Early Discard
plus sensible. À chaque passage de l’ordonnanceur, la file 1 est ser-
RED s’attaque principalement à la congestion persistante dans
vie. Tant qu’il y a des paquets sur cette file, l’ordonnanceur les retire
une file d’attente. Sa fonction d’élimination est basée sur la taille
pour les envoyer sur l’interface. Quand la file 1 est enfin vide,
moyenne de la file, ce qui autorise des fluctuations instantanées
l’ordonnanceur traite les paquets de la file 2 et ainsi de suite. Quand
nécessaires pour le traitement du trafic très variable. Dans sa défi-
un paquet arrive sur la file 1, il est servi dès que l’interface termine
nition [41], RED n’impose aucune formule pour le calcul de l’occu-
la transmission du paquet en cours quelle que soit sa priorité. La
pation moyenne. En revanche, dans les exemples, un filtre passe-
figure 5 montre un exemple d’ordonnancement par SPQ.
bas est utilisé, comme le montre l’encadré 2.
L’algorithme précédent contient un défaut évident : la surcharge
d’une classe prioritaire peut entraîner la « famine » des classes
moins prioritaires. L’ordonnanceur, étant occupé en permanence à Encadré 2 – Calcul de l’occupation moyenne de la file
servir la file 1 et peut-être la file 2, ne sert jamais les files 3 et 4, dans RED
provoquant le débordement récurrent des files de ces deux classes.
Une première solution consiste à utiliser des quantums, comme Initialisation :
dans le DRR, pour limiter le nombre d’octets consécutifs qui peu- a vg = 0
vent être enlevés d’une même classe. Des solutions plus avancées,
comme celle proposée par Zhang et Ferrari [37], peuvent aussi À l’arrivée de chaque paquet :
servir pour que le SPQ soit implanté effectivement dans les rou- si la file n’est pas vide,
teurs du réseau. avg = (1 – wq ) avg + wqq
Une autre approche, cherchant à résoudre le problème de famine sinon,
dans le SPQ, consiste à utiliser des mécanismes externes qui limi- m = temps pendant lequel la file était vide
tent le nombre de flux qui partagent les files prioritaires. De tels avg = (1 – wq )m avg

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 565 − 6 © Techniques de l’Ingénieur

Dossier délivré pour

DOCUMENTATION
21/10/2008
 _______________________________________________________________________________________________________ LA DIFFÉRENCIATION DE SERVICES

q représente l’occupation instantanée de la file et wq est le poids

attribué à chaque nouvelle mesure. Il faut remarquer que le code
prend en compte les périodes pendant lesquelles la file est inac- pa Probabilité
d’élimination
tive, supposant que m paquets de taille minimale auraient pu être des paquets
transmis pendant ce temps-là.
Toujours basé sur la moyenne (avg), RED utilise une fonction aléa- 1
toire croissante pour décider si un paquet doit être éliminé. Grâce
à cette caractéristique, les éliminations successives sont évitées. Le
rejet de plusieurs paquets appartenant à une même rafale peut
forcer un flux TCP à rentrer dans la phase de slow start . Le rejet aléa-
toire est une solution équitable puisque la probabilité pour qu’un pmax
flux subisse une perte est directement proportionnelle au pourcen-
tage d’occupation de ce flux dans la file. Dans RED, l’élimination thmin thmax avg
aléatoire se réalise uniquement quand la taille moyenne de la file
se trouve entre deux seuils th min et th max comme le montre l’enca-
dré 3. Figure 6 – Paramètres de RED

Encadré 3 – Calcul de l’occupation moyenne de la file

dans RED demande. L’ECN est un mécanisme orthogonal à DiffServ, sa des-
cription détaillée se trouve dans [42].
si th min < = avg < = th max
count = count + 1
p b = p max (avg – th min) / (th max – th min)
2.4.2 Weighted RED
pa = pb / (1 – count * p b)
avec probabilité p a : Le WRED, originellement proposé par Cisco, se base sur l’utilisa-
éliminer le paquet tion des différents paramètres RED pour divers flux. En attribuant
count = 0 un p max et des seuils th min et th max différents, il est possible d’offrir
une distribution différenciée des pertes [43]. Cette utilisation n’est
si th max < = avg pas compatible avec le modèle DiffServ. S’il est nécessaire de stoc-
éliminer le paquet ker des paramètres différents pour chaque flux traversant le routeur,
count = 0 la méthode n’est pas résistante au facteur d’échelle.

Dans le comportement assuré (§ 3.5.3), le routeur doit éliminer les

La variable count compte les paquets acceptés dans la file depuis
paquets en fonction de leur précédence. WRED peut néanmoins réa-
la dernière élimination. Avec cette variable, la possibilité d’éliminer
liser cette fonction en utilisant un jeu de paramètres pour chaque
deux paquets consécutifs est réduite. Dans le code, p a représente
niveau de priorité.
la probabilité de rejet du paquet. Elle augmente linéairement de 0
à p max pendant que la moyenne varie de th min à th max (figure 6). Dans WRED, le calcul de l’occupation moyenne reste celui de RED.
À partir de th max , tous les paquets sont éliminés. Si les sources À l’arrivée de chaque paquet, avg est actualisée quelle que soit sa
réduisent leur débit en conséquence, la moyenne revient rapide- précédence. En revanche, c’est dans le calcul de p max que la diffé-
ment à un niveau acceptable. renciation s’effectue. La figure 7 montre un choix de paramètres qui
Le mode de fonctionnement de RED a servi à la conception pourrait s’appliquer à DiffServ. Pour les paquets de haute précé-
d’autres méthodes visant à améliorer les performances de TCP, en dence (pr 2 dans l’exemple), à éliminer en priorité, l’algorithme est
particulier de l’ECN (Early Congestion Notification). Avec cette très agressif : il ne leur permet pas de traverser le routeur dès que
méthode, une source TCP est informée de la congestion grâce à un l’occupation de la file d’attente dépasse une limite relativement
drapeau dans l’en-tête IP. Dans ce cas, RED n’élimine pas les paquets courte. En revanche, pour les paquets de basse précédence (pr 0
mais se contente d’activer le drapeau pour indiquer que le débit doit dans l’exemple), le mécanisme autorise des taux d’occupation plus
être réduit. Le récepteur du paquet TCP reflète la valeur de ce dra- élevés en partant du principe que, dans des réseaux bien dimen-
peau dans les acquittements pour que la source réagisse à cette sionnés, ces paquets ne doivent jamais être éliminés.

pa

pmax 2

pmax 1
pmax 0

thmin 2 thmax 2 /thmin 1 thmax 1/thmin 0 thmax 0 avg

probabilité d’élimination des paquets de précédence 0

probabilité d’élimination des paquets de précédence 1
probabilité d’élimination des paquets de précédence 2

Figure 7 – Paramètres pour WRED

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 7

Dossier délivré pour

DOCUMENTATION
21/10/2008
LA DIFFÉRENCIATION DE SERVICES ________________________________________________________________________________________________________

2.4.3 RED with In and Out regroupement des flux dont les besoins sont similaires (agrégation)
et à la définition des traitements nécessaires dans les routeurs pour
RIO est l’un des premiers algorithmes à avoir été proposé pour que l’agrégat de ces flux soit traité correctement.
effectuer la différenciation de services. Dans sa définition [44], Pour assurer la robustesse du modèle, la création d’états et la
Clark et Fang ont décrit toute une architecture qui a servi de réfé- classification par flux sont deux fonctionnalités réservées aux rou-
rence aux travaux de l’IETF sur le sujet. À l’origine, RIO était conçu teurs d’entrée du réseau. Dans ces équipements, le nombre de flux
pour différencier entre deux niveaux de précédence (in et out ) ; à traiter est considérablement réduit et un bon dimensionnement
depuis, le modèle a été étendu pour supporter plusieurs niveaux. doit suffire pour assurer que la capacité ne soit pas dépassée. Dans
Dans RIO, la différenciation se base en partie sur le calcul de le reste des routeurs, des opérations très simples, ne demandant
l’occupation moyenne de la file d’attente. À la différence de WRED, pas la création d’états, assurent le traitement différencié.
l’algorithme calcule une moyenne par précédence. La moyenne Un autre reproche fait au modèle IntServ est la complexité du pro-
avg n est actualisée à chaque fois qu’un paquet de précédence égale tocole de signalisation RSVP [24] [45]. Une grande partie de la lour-
ou inférieure à n arrive dans la file. Dans le cas de DiffServ, avg0 deur du protocole est due à la gestion des flux multicast et des
reflète la moyenne des paquets de basse précédence présents dans routes symétriques. La réservation de ressources pour des flux n
la file, avg1 dénote la somme des paquets des précédences basse vers m exige la définition de règles d’agrégation et désagrégation
et moyenne, avg 2 , comme dans RED, prend en considération tous dans les nœuds intermédiaires. Dans DiffServ, ce problème n’a pas
les paquets qui attendent dans la file. Cela permet d’isoler la pro- été spécifiquement abordé car les connexions multipoints n’inter-
babilité de rejet pour chaque niveau : pour les paquets de basse pré- fèrent pas avec les mécanismes propres à l’architecture. Dans ce
cédence, seul un excès de paquets de la même précédence justifie modèle, la seule signalisation requise est une étiquette contenue
une élimination. Pour les paquets de haute précédence, l’excès de dans l’en-tête de chaque paquet.
paquets de précédence moins forte suffit pour qu’ils soient rejetés. Au niveau économique, l’absence de réservation de ressources
permet aux opérateurs d’offrir de nouveaux services tout en gardant
Fang et Clark proposent aussi d’utiliser des paramètres RED
un système de tarification simple. Au niveau de la mise en œuvre,
(p max , th min et th max ) différents pour chaque niveau. Des valeurs
la priorité a été donnée à l’utilisation des mécanismes d’ordonnan-
similaires à celles qui seraient utilisées dans WRED peuvent servir. cement et de gestion de file d’attente comme WFQ [34] et RED [41]
En revanche, pour le cas de RIO, des seuils moins agressifs peuvent qui ont montré leur efficacité dans des réseaux opérationnels. De
suffire, puisque la moyenne avance plus vite pour les paquets de nombreuses expériences ont déjà été menées pour déterminer leurs
haute précédence à cause de la méthode de calcul. capacités et leurs limites [46] [47]. En outre, le standard définissant
Le calcul différencié des moyennes ajouté au paramétrage de RED l’architecture est assez ouvert pour accueillir de nouveaux algo-
font de RIO un algorithme très performant pour l’élimination basée rithmes pouvant servir à la définition de nouveaux services.
sur la précédence, mais son implémentation est plus compliquée
que celle de WRED, mis en œuvre dans la plupart des routeurs
commerciaux [43]. 3.2 Fonctionnement
Dans le modèle DiffServ, il n’existe pas de signalisation dans le
cœur du réseau : seule une étiquette dans l’en-tête, le DSCP (Diff-
3. Modèle DiffServ Serv Code Point), est utilisée pour assurer le traitement différencié
[48]. Cette capacité permet aux routeurs de garder un mode de fonc-
tionnement relativement simple qui n’affecte pas considérablement
Le modèle DiffServ, standardisé à l’IETF, offre des capacités de leur capacité d’acheminement. La complexité est reportée sur les
différenciation basées sur les mécanismes, simples et résistants au routeurs de frontière, se trouvant à l’entrée ou à la sortie d’un
facteur d’échelle, décrits au paragraphe 2. Sont présentes ici les domaine [49]. Ces équipements sont chargés de déterminer la
caractéristiques du modèle DiffServ, ses composants, ainsi qu’une valeur de l’étiquette de chaque paquet en fonction d’un contrat, du
description des services qui pourraient être offerts à l’aide de ce service demandé et des mécanismes de contrôle de trafic. Le DSCP
modèle. occupe les six bits de poids fort du champ DS (DiffServ) de l’en-tête
IP. La figure 8 montre l’emplacement de ce champ. Dans IPv4, il se
substitue à l’ancien champ ToS ; dans IPv6, il se situe à la place du
3.1 Caractéristiques champ Traffic Class.
Il est plus facile de comprendre l’utilité des divers outils qui
Pour comprendre les décisions prises par le groupe de travail de forment le modèle si, avant d’entrer dans les détails de l’architec-
l’IETF, il faut se rappeler les motivations qui ont mené à la création ture, un exemple de fonctionnement est présenté. La figure 9
du modèle DiffServ, c’est-à-dire l’incapacité de l’architecture IntServ montre une configuration de réseau très simple. Un site émetteur,
à se voir déployée à grande échelle et le besoin dans l’Internet des souhaitant que ses flux bénéficient d’un traitement différencié dans
mécanismes d’amélioration de la qualité de service (QoS). Si les le réseau, établit un contrat de service avec son fournisseur. Ce
problèmes que les modèles DiffServ et IntServ cherchent à résoudre contrat, appelé SLA (Service Level Agreement), contient la nature
sont les mêmes – le traitement correct des flux multimédias et un du trafic que l’émetteur peut produire pour chaque service
meilleur contrôle dans la distribution de la bande passante –, le demandé. D’un côté, le fournisseur s’engage à fournir la qualité
modèle DiffServ s’attaque à ces contraintes d’une manière moins demandée par l’émetteur. De l’autre côté, l’émetteur est conscient
ambitieuse mais plus résistante. Dans ce modèle, il est impossible des limitations imposées par le contrat.
d’offrir des garanties strictes ou de réserver des ressources. En
revanche, la simplicité d’implantation permet à cette nouvelle archi- ■ Le client peut effectuer un prémarquage de ses flux avant de les
tecture de se voir déployée progressivement dans certaines régions transmettre au fournisseur. Signaler une préférence en termes de
de l’Internet. classe de service ou indiquer l’importance relative des paquets sont
deux raisons qui justifient cette action. La priorité des paquets peut
Une des faiblesses du modèle IntServ est sa non-résistance au varier au sein d’un flux. En revanche, les principes de DiffServ
facteur d’échelle. Dans ce modèle, tous les équipements du réseau exigent que tous les paquets d’un même flux appartiennent à une
doivent garder un contexte par flux réservé. Il suffit qu’un nœud même classe de service afin d’éviter le déséquencement.
dans le chemin emprunté ne mette pas en œuvre les fonctionnalités
IntServ pour que la qualité de service ne puisse plus être strictement ■ Le fournisseur connaît les spécifications techniques du contrat
garantie. Dans l’architecture DiffServ, la priorité est donnée au établi avec chacun de ses clients. Quand le trafic produit par l’utilisa-

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 565 − 8 © Techniques de l’Ingénieur

Dossier délivré pour

DOCUMENTATION
21/10/2008
 _______________________________________________________________________________________________________ LA DIFFÉRENCIATION DE SERVICES

paquet est inséré. Dans cet exemple, la file d’attente représente la

classe de service. Les ressources des routeurs sont distribuées entre
version IHL DS Total length les files en fonction des services qu’ils supportent. Dans chaque file
Identification Flag Fragment Offset d’attente, un algorithme de rejet sélectif est utilisé pour éliminer en
premier les paquets de basse priorité en cas de congestion.
Time to Live Protocol Header Checksum
Cet exemple entre un site et un fournisseur d’accès peut s’appli-
Source Address quer également à deux opérateurs. En général, les paquets doivent
Destination Address traverser plusieurs domaines administratifs avant d’atteindre leur
destination ; un accord est donc nécessaire entre domaines. Dans
a en-tête IPv4 le premier cas, le fournisseur d’accès a aussi des contraintes à res-
pecter vis-à-vis de son opérateur. Le routeur d’entrée est placé
entre le réseau du fournisseur et celui de l’opérateur, réalisant des
opérations similaires à celles du routeur décrit précédemment. En
version DS Flow Label
revanche, les fonctions de contrôle de conformité ne portent pas
Payload Length Next Header Hop Limit sur le trafic de chaque utilisateur, mais sur le trafic injecté par le
fournisseur dans son ensemble. Cette capacité d’agrégation assure
Source Address la résistance du modèle au facteur d’échelle.
Les capacités des routeurs de sortie constituent une autre parti-
cularité de l’interconnexion entre deux domaines. Un routeur de
sortie est le dernier routeur traversé par un paquet avant de quitter
Destination Address un domaine. Ces routeurs peuvent être chargés de traiter l’agrégat
des flux quittant le domaine pour rendre le trafic conforme au
contrat existant avec le prochain domaine. Pour cela, les flux
appartenant à une classe de service peuvent être retardés, tandis
que des paquets d’une autre classe peuvent subir une modification
b en-tête IPv6 dans leur niveau de priorité.
Le dimensionnement de ressources est un facteur clé dans le
Figure 8 – Champ DS dans les en-têtes IP maintien de la qualité de service. Les références [11] et [38] sont
deux propositions cherchant à implanter un certain type de signa-
lisation entre l’utilisateur et le fournisseur. Dans ce cas, le contrat
teur arrive au routeur d’entrée du fournisseur, les flux sont identifiés
peut être modifié dynamiquement par l’utilisateur pour accroître
et leur comportement est vérifié en fonction du contrat. En cas de
ses capacités de transmission pour une durée limitée. Ce type de
non-conformité, une action corrective est déclenchée. Pour certains
signalisation ne remet pas en cause la résistance du modèle au fac-
services, seuls les paquets conformes au contrat peuvent entrer
teur d’échelle puisque des échanges ne s’effectuent qu’entre les
dans le réseau. Pour d’autres services, tous les paquets sont
clients et les routeurs d’entrée et ils n’ont pas besoin d’être connus
acceptés, mais le routeur d’entrée modifie la priorité du paquet en
par le reste du réseau.
fonction du niveau de conformité.
En quittant le routeur d’entrée, les paquets du site émetteur
contiennent tous une étiquette, reflétant la classe de service sou-
haitée et le niveau de conformité du flux par rapport au contrat.
3.3 Routeur d’entrée
■ Les routeurs de cœur du réseau ne modifient pas les étiquettes, La structure d’un routeur d’entrée peut être décomposée en
ils se contentent de les utiliser pour choisir la file d’attente où le quatre modules (figure 10). Toute la complexité de l’architecture est

Émetteur

ISP ISP

Routeur de frontière

Backbone
(routeurs de cœur du réseau)

Figure 9 – Architecture DiffServ

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 9

Dossier délivré pour

DOCUMENTATION
21/10/2008
LA DIFFÉRENCIATION DE SERVICES ________________________________________________________________________________________________________

Le concept de conformité d’un flux est généralement associé au

débit généré par celui-ci. Un contrat de service doit contenir le débit
Classification Vérification Action Étiquetage
maximal accepté pour chaque classe de service. Pour des services
TB shape ayant besoin d’une vérification à deux niveaux, la méthode la plus
TCM simple consiste à mesurer son débit moyen. Cette mesure peut être
mark difficile à définir car la valeur obtenue dépend de la fenêtre d’obser-
LTB vation utilisée. Un autre mécanisme, simple et pourtant efficace, est
AVG drop utilisé dans l’architecture DiffServ : le seau à jetons (§ 2.2).
Afin d’obtenir trois niveaux de conformité, des mécanismes plus
complexes que le seau à jetons sont nécessaires. Pour les services
se basant sur le comportement assuré, cette opération est cruciale
pour la définition de services car elle est directement liée à la dis-
Base de données tribution de priorités au sein d’un flux. Le marqueur par seaux à
jetons parallèles [58], par fenêtre glissante [59] ou le marqueur à
trois couleurs [60] sont des mécanismes qui peuvent être utilisés
Figure 10 – Modules d’un routeur d’entrée pour cette opération.

concentrée dans ce type d’équipements [50]. Ils doivent effectuer 3.3.3 Actions de mise en conformité
une classification qui peut aller jusqu’au niveau du microflux. Une
fois le flux identifié, il est nécessaire de vérifier la conformité au L’action corrective à prendre pour les paquets non conformes
contrat en utilisant un mécanisme adapté au service demandé. d’un flux varie en fonction du service. Trois types de pénalisations
Ensuite, une action est faite pour pénaliser les paquets non confor- peuvent être identifiés : élimination, mise en forme et remarquage.
mes. Finalement, avant d’injecter les paquets dans le réseau, la ■ L’élimination est sans doute l’action la plus sévère, mais néces-
valeur du DSCP est actualisée en fonction du conditionnement subi. saire au bon fonctionnement de certains services. Pour un flux dont
les paquets non conformes sont éliminés à l’entrée, il peut être sou-
3.3.1 Classification haitable de contrôler le débit d’émission. Des flux interactifs conte-
nant des contraintes temporelles fortes pourraient tirer profit de ce
Pour que les différents flux produits par les utilisateurs puissent type d’action. Dans un service DiffServ interactif, les fournisseurs
être traités d’une manière différenciée, le routeur d’entrée doit tout devront approvisionner leurs réseaux en fonction des contrats éta-
d’abord effectuer une classification des paquets. Dans le modèle blis. L’entrée dans le réseau des paquets au-delà du contrat peut
DiffServ, cette opération est très similaire à celle définie pour l’archi- faire croître l’occupation des files d’attente dans les routeurs inter-
tecture IntServ [24]. Elle se base toujours sur des champs de l’en- médiaires et provoquer une augmentation dans le délai de transmis-
tête, mais le nombre de champs utilisés pour l’identification peut sion, ce qui rendrait l’interactivité impossible.
varier en fonction du contrat. Dans le modèle DiffServ, la classifi-
■ La mise en forme consiste à retarder, si nécessaire, le comporte-
cation peut aller jusqu’au niveau des microflux.
ment d’un flux pour le rendre conforme. Des services faisant appel
La classification au niveau des microflux s’effectue dans les à cette fonction peuvent être proposés aux clients qui n’ont pas les
points d’entrée des flux dans le réseau. Elle peut également avoir moyens de l’effectuer sur leur site. La mise en forme est une action
lieu dans un module de contrôle installé dans l’équipement de l’uti- très coûteuse en termes de ressources pour le routeur d’entrée, qui
lisateur. Dans ce cas, l’utilisateur est en charge de faire la mise en doit garder dans un tampon tous les paquets retardés jusqu’à ce
correspondance entre les applications et les classes de services. Le qu’ils deviennent conformes.
trafic est alors conditionné en tant qu’agrégat par le routeur d’entrée
du fournisseur. ■ Le marquage est l’action qui attribue une précédence, ou priorité,
aux paquets en fonction du résultat de la vérification. Cette action
La finesse de classification dépend du placement des routeurs
introduit un deuxième niveau de différenciation, puisque les
d’entrée dans le réseau. Plus un routeur est près du cœur, moins
paquets sont acheminés en fonction de leur classe de service et de
la classification est fine. Les flux dans ce cas peuvent être classifiés
leur priorité. Les fonctions de vérification et de marquage sont par-
et conditionnés, par exemple, en fonction de leur interface d’arrivée.
fois indivisibles. Elles forment le noyau des services basés sur le
Les routeurs de cœur du réseau réalisent une classification beau-
comportement assuré où le traitement que le réseau accorde à un
coup plus simple, basée uniquement sur la valeur du champ DSCP,
flux dépend de la distribution des priorités à ses paquets.
ce qui ne demande pas beaucoup de puissance de calcul ni de
mémoire. Nota : il ne faut pas confondre la fonction de marquage que l’on décrit ici avec l’ajout
d’une étiquette par les routeurs d’entrée. Dans DiffServ, tous les paquets se voient ajouter
une valeur dans leur champ DS, qu’ils subissent une pénalisation par mise en forme, par
élimination ou par « marquage ».
3.3.2 Vérification
L’élimination à l’entrée et la mise en forme sont deux actions
Un vérificateur est chargé de déterminer le niveau de conformité permettant de connaître statistiquement le débit maximal qu’un
pour chaque paquet du flux arrivant dans le routeur. Cette valeur routeur d’entrée peut injecter. Cela facilite l’approvisionnement du
dépend du comportement instantané du flux et des caractéristiques réseau et permet aux fournisseurs d’offrir des services dits « à bas
du contrat. Le nombre de niveaux varie en fonction du condition- délai ». Le service Premium [38] est un exemple de ce type de
nement requis par le service : service.
— pour des services à bas délai, il est nécessaire que seuls les En ce qui concerne les flux conditionnés par marquage, tous les
paquets conformes au contrat soient acceptés dans le réseau. Dans paquets entrent dans le réseau, mais avec une particularité : le
ce cas, une vérification à deux niveaux est suffisante : conforme ou résultat du contrôle de conformité est inscrit dans chaque paquet.
non conforme, in ou out ; En cas de congestion, les paquets de basse priorité, ceux qui ont
— pour des services profitant de la capacité d’élimination sélec- rendu un flux non conforme, sont éliminés en premier. Si des flux
tive dans le cœur du réseau, un nombre de niveaux supérieur à du type TCP sont conditionnés par marquage, le débit qu’une
deux augmente la granularité de la différenciation. Dans la défi- connexion peut atteindre est proportionnel au nombre des paquets
nition du comportement assuré, trois niveaux de priorité ont été marqués en haute priorité, ce qui dépend de la configuration du
définis : vert, orange et rouge. conditionneur. Cette capacité peut être utilisée pour effectuer une

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 565 − 10 © Techniques de l’Ingénieur

Dossier délivré pour

DOCUMENTATION
21/10/2008
 _______________________________________________________________________________________________________ LA DIFFÉRENCIATION DE SERVICES

distribution différenciée de la bande passante, un des objectifs

poursuivis par le modèle.
Contrairement à l’élimination ou à la mise en forme, le marquage

d’ordonnancement
permet d’exploiter au maximum les capacités du réseau. En
revanche, la qualité offerte est très relative et difficilement quanti-

Mécanisme
fiable. Elle dépend du niveau d’agrégation, c’est-à-dire du nombre
de microflux étant marqués ensemble, aussi bien que du nombre Paquet Classificateur
de flux qui traversent les mêmes routeurs.
Une application alternative de la notion de priorité consiste à
marquer les flux audio/vidéo, par nature hiérarchique, en fonction
de la valeur sémantique de l’information transportée.

3.3.4 Étiquetage Mécanismes

de gestion
Avant d’entrer dans le réseau, le champ DSCP de tous les paquets
qui traversent le routeur d’entrée est mis à jour. La valeur de cette
étiquette est le résultat des opérations de conditionnement. Si, par
définition, il n’est pas possible de décomposer le DSCP en deux par- Figure 11 – Architecture d’un routeur de cœur du réseau
ties, il est tout de même possible d’identifier les deux informations
qui établissent la différenciation : la classe de service et la priorité
du paquet. le comportement expédié, exigent une technique plutôt hybride, uti-
Le DSCP qui forme l’étiquette DiffServ ne doit pas être modifié lisant une combinaison de files prioritaires et de mécanismes de
par les routeurs de cœur du réseau. Les routeurs de frontière peu- partage de ressources comme le WFQ ou le WRR (§ 2.3).
vent, quant à eux, modifier cette valeur lors des nouveaux condi- À l’intérieur de chaque file, un mécanisme de gestion doit décider
tionnements ou d’un problème de sémantique entre deux domaines de la manière dont les paquets seront éliminés en cas de conges-
voisins. tion. Par exemple, pour une classe de service à bas délai, qui ne
Les différentes combinaisons de vérificateurs et d’actions forment devrait jamais observer de pertes (théoriquement), la traditionnelle
en grande partie un service. L’autre partie est formée par le choix méthode FIFO peut être utilisée. En revanche, pour les files mettant
du comportement dans le cœur du réseau et par la sélection d’une en œuvre le comportement assuré [51], le standard requiert une
classe de service. Ce paramètre est exploité dans les routeurs de méthode capable de discriminer les paquets en fonction de leur pré-
cœur du réseau. Étant donné que ces équipements ne doivent cédence. Des méthodes comme WRED ou RIO peuvent être utilisées
réaliser que des opérations simples et qu’ils doivent tous être pour assurer cette fonction (§ 2.4).
conformes au standard, ce sont les modules du routeur d’entrée qui Il a été mentionné (§ 3.2) que le DSCP exprime le comportement
pourront plus facilement évoluer pour offrir dans le futur de par nœud (PHB : Per-Hop Behavior) qui sera accordé au paquet. Un
nouveaux services. PHB est, d’après le RFC 2474 [48], la description des caractéristiques
d’acheminement qui seront observées par tous les paquets
comportant le même DSCP. L’utilisation d’un PHB ou d’un groupe
3.4 Routeurs de cœur du réseau de PHB ajoutée aux opérations de conditionnement réalisées à
l’entrée d’un domaine forment ce qui peut être appelé un service
DiffServ.
À la suite des traitements effectués dans le routeur d’entrée, les
paquets sont injectés dans le réseau. Les opérations propres aux Trois types de comportements ou PHB ont été standardisés. Le
routeurs de cœur du réseau sont relativement simples, mais celles- seul PHB qui peut être considéré comme obligatoire est celui des
ci vont déterminer les performances du réseau, en termes de pertes sélecteurs de classe ; il a été conçu pour garder une certaine
et de délai, observées par les sites terminaux [50]. Les mécanismes comptabilité avec l’existant (le champ ToS). L’implantation d’autres
DiffServ ont pour but de standardiser le traitement des paquets dans comportements dans un réseau dépend des besoins du domaine.
ces routeurs en fonction du champ DS. Tous les paquets portant une La seule contrainte pour le support d’un nouveau PHB exige que les
même valeur dans ce champ doivent être traités de la même PHB supportés auparavant ne soient pas affectés par l’implantation
manière. de celui-ci.
Le traitement différencié dans le cœur d’un réseau DiffServ impli- Il faut remarquer que, pour chaque PHB standardisé, les valeurs
que deux axes : les classes de services et la notion de priorité. La de DSCP proposées ne sont que des recommandations. À l’inté-
figure 11 montre l’architecture logique d’un routeur capable d’offrir rieur d’un domaine, l’administrateur est libre de choisir les valeurs
ces deux niveaux de différenciation. Il est composé d’un classifica- qui facilitent la mise en œuvre du modèle. Cela demande pourtant
teur, de plusieurs files d’attente, d’un mécanisme d’ordonnance- l’implantation des mécanismes de remarquage à l’entrée et à la
ment et d’un algorithme de gestion de file d’attente pour chaque file. sortie du domaine pour faire la correspondance entre les DSCP
locaux et leur équivalence dans les domaines voisins.
Le classificateur que l’on trouve dans ce type de routeur réalise (0)

une classification beaucoup moins coûteuse que ceux qui se

trouvent à l’entrée du domaine. Dans ce cas, les paquets sont
différenciés uniquement en fonction de l’étiquette qu’ils portent, 3.5 Comportements standardisés
c’est-à-dire de la valeur du champ DS attribuée par le routeur
d’entrée. Une partie de cette étiquette sert à identifier la file d’attente
sur laquelle le paquet doit être inséré, pendant qu’une autre partie 3.5.1 Sélecteurs de classe
de celle-ci peut être utilisée par l’algorithme de gestion de file La première famille de PHB a été définie en même temps que
d’attente pour améliorer la discrimination en cas de congestion. l’architecture générale du modèle. Les sélecteurs de classe (CS :
Chacune des files d’attente dans les routeurs représente une Class Selector) ont pour objectif d’assurer la compatibilité avec
classe de service. Leurs propriétés, en termes de bande passante l’ancienne sémantique du champ ToS. Avant l’apparition de DiffServ,
ou de retard moyen observé, dépendent du mécanisme d’ordon- le RFC 791 [21] spécifiait déjà une logique à suivre pour différencier
nancement. Les contraintes des comportements à bas délai, comme les paquets IP à partir de la précédence contenue dans ce paramè-

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 11

Dossier délivré pour

DOCUMENTATION
21/10/2008
LA DIFFÉRENCIATION DE SERVICES ________________________________________________________________________________________________________

respecter la relation entre le débit d’entrée et le débit de sortie dans

Tableau 1 – DSCP associés aux sélecteurs de classe tous les nœuds du domaine.
DSCP PHB DSCP PHB Pour la mise en œuvre du PHB, plusieurs techniques peuvent
être utilisées. Dans l’étude comparative faite dans l’annexe du
000 000 Défaut 100 000 CS 4 RFC 2598, il faut pourtant déduire que la meilleure option est l’uti-
lisation d’une file prioritaire réservée au trafic EF. Avec une telle
001 000 CS 1 101 000 CS 5
architecture, le délai observé par les flux EF est réduit au maxi-
010 000 CS 2 110 000 CS 6 (a.r.) mum, mais une mauvaise administration peut entraîner la famine
des autres classes de services. En conséquence, des mesures limi-
011 000 CS 3 111 000 CS 7 (a.r.)
tant le trafic EF doivent être prises dans chaque équipement qui
implante le comportement.
tre. Si le champ ToS n’a pas été utilisé exactement comme il était Le code DSCP recommandé pour le comportement EF est 101 110.
prévu, son utilisation est assez répandue dans l’Internet. Le
RFC 2474 [48] réserve donc les valeurs utilisées par l’ancienne
sémantique et définit le comportement que les routeurs devront
3.5.3 Comportement assuré
accorder aux paquets marqués avec ces valeurs. Avant la définition précise des PHB, plusieurs hypothèses ont été
Le RFC 2474 [48] définit huit classes qui représentent les huit examinées pour déterminer la manière dont les routeurs devraient
niveaux de précédence définis dans le RFC 791 [21]. Il établit une implanter la différenciation. D’un côté, nous trouvions les partisans
relation d’ordre entre les classes : pour deux classes CSx et CSy , si de la séparation du trafic en plusieurs classes de services (les
x > y, les paquets qui appartiennent à CSx doivent être acheminés sélecteurs de classe sont l’exemple parfait de ce type de différen-
avec une probabilité supérieure à celle accordée aux paquets ciation). D’un autre côté, plusieurs propositions [18] [19] centraient
appartenant à CSy . Cela demande que la quantité de ressources la différenciation sur les algorithmes de discrimination de paquets
réservées à chaque classe soit égale ou supérieure à celle réservée dans une même file d’attente.
à la classe sous-jacente. Le comportement assuré (AF : Assured Forwarding) est sans
Le standard signale que les paquets de deux classes différentes doute le comportement le plus général qui existe. Il est le résultat
doivent être acheminés indépendamment. Plus précisément, l’algo- de la fusion de plusieurs propositions [18] [19] [38]. Il est composé
rithme d’ordonnancement doit assurer que la charge dans une des de plusieurs classes de services au sein desquelles un deuxième
classes n’affecte pas l’opération des autres. niveau de différenciation est introduit : les précédences. La notion
Cette définition est assez vague, mais facilite la cohabitation avec de précédence existait déjà dans la sémantique du champ ToS (mais
d’autres PHB tout en gardant la compatibilité avec l’ancienne la mise en correspondance des précédences du ToS avec les sélec-
sémantique. Les numéros de code réservés aux sélecteurs de classe teurs de classe DiffServ, bien que valable, ne suit pas le même prin-
suivent le format x x x 0 0 0 (tableau 1). Le code 0 0 0 0 0 0 désigne le cipe). La précédence d’un paquet reflète sa priorité, c’est-à-dire le
comportement par défaut, c’est-à-dire le comportement Best Effort dommage que peut entraîner sa perte. Au sein d’un routeur, cette
tel qu’il est observé par tous les paquets de l’Internet aujourd’hui. information peut être utilisée pour améliorer considérablement la
Le RFC 2474 [48] exige que des mesures soient prises pour que la fonction de rejet de paquets en cas de congestion. Suivant le même
surcharge dans une des classes ne provoque pas la famine dans les principe, la précédence attribuée aux paquets d’un flux peut être
classes inférieures, en particulier dans la classe Best Effort. Il exige régie par un contrat de service. Plus le pourcentage des paquets
en même temps que les classes 11 x 0 0 0 0 soient traitées en priorité marqués prioritaires est important, moins le flux subit de pertes.
car, dans l’ancienne sémantique du ToS, les précédences 110 et 111 Le RFC 2597 [51], mis à jour par le RFC 3260, définit quatre classes
désignent un paquet d’administration de réseau (a.r.). comportant trois niveaux de précédence chacune. Le comportement
assuré est donc composé par un groupe de 12 PHB interdépendants.
Cela veut dire que l’implémentation d’un de ces PHB est inutile sans
3.5.2 Comportement expédié l’implémentation des autres. Après de longues discussions, il a été
Les PHB sont, par définition, des éléments indépendants qui décidé qu’aucune relation d’ordre ne devrait exister entre les clas-
peuvent être utilisés pour construire des services. Pour le moment, ses. L’administrateur réseau est responsable du partage des ressour-
il n’existe aucune proposition explicite qui utilise les sélecteurs de ces entre les classes en fonction de ses besoins. En revanche, il est
classe ou le comportement assuré pour construire un service. En nécessaire que tous les paquets d’un même microflux appartiennent
revanche, le comportement expédié (Expedited Forwarding) est une à la même classe pour éviter le déséquencement des paquets.
exception puisqu’il a été conçu, dès le départ, comme étant le En ce qui concerne la précédence, le standard demande que, dans
composant d’un service bien spécifique : le service Premium. une même classe, les paquets de précédence X soient acheminés
Le service Premium, ou câble virtuel [38], est destiné aux appli- avec une probabilité supérieure à celle donnée aux paquets de pré-
cations demandant un délai et une gigue très faibles telles que la cédence Y, si X < Y. Remarquons la relation inverse qui existe entre
téléphonie sur IP [TE 7 515]. Il part du principe que le délai introduit la précédence et le niveau de priorité. Des mécanismes capables de
par le réseau est dû à l’attente des paquets dans les files des satisfaire cette contrainte sont décrits au paragraphe 3.3.3.
routeurs. Il faut donc garantir que la taille de ces files soit presque Les PHB qui forment le comportement AF sont identifiés par AFij ,
nulle. Pour cela, il est nécessaire de mettre en œuvre des méca- où i indique la classe (1 à 4) et j la précédence (1 à 3). Le tableau 2
nismes d’administration qui assurent qu’à tout moment, le débit présente les codes DSCP proposés par le RFC 2597 [51] pour repré-
d’entrée soit inférieur à la capacité de sortie. La définition de tels senter les PHB AF.
mécanismes ne fait pas partie de la définition des PHB et elle est (0)

même au-delà de la responsabilité du groupe DiffServ. Dans [38],

Van Jacobson fait allusion aux bandwidth brokers, modules de Tableau 2 – DSCP associés à AF
gestion centralisée capables de garantir le bon fonctionnement du
service. La définition précise d’un tel outil est un sujet de recherche. PHB AFi j Classe 1 Classe 2 Classe 3 Classe 4
Le comportement expédié (EF) est défini dans [52]. Pour qu’un
routeur soit conforme à la définition de ce comportement, il doit Précédence 1 001 010 010 010 011 010 100 010
assurer que le débit d’émission du trafic EF soit toujours égal ou Précédence 2 001 100 010 100 011 100 100 100
supérieur à un certain seuil. Si ce seuil est connu et peut être
configuré, les mécanismes de gestion externes peuvent faire Précédence 3 001 110 010 110 011 110 100 110

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 565 − 12 © Techniques de l’Ingénieur

Dossier délivré pour

DOCUMENTATION
21/10/2008
 _______________________________________________________________________________________________________ LA DIFFÉRENCIATION DE SERVICES

Les définitions des services DiffServ qui peuvent être créés en

exploitant la notion de précédence sont encore assez floues. Leur Earliest Deadline First Scheduler
performance dépend fortement des mécanismes de marquage uti-
lisés à l’entrée ainsi que du paramétrage de l’algorithme de gestion
de file d’attente. Packet
Admission
Control

3.6 Comportements expérimentaux Drops

3.6.1 Less than Best Effort Figure 12 – Classe de service ABE

Le comportement LBE, proposé par Bless et Wehrle dans [25], a

pour objectif principal de définir une nouvelle classe de services L’ABE offre un compromis entre le taux de perte et le délai observés
inférieure, en priorité, au Best Effort classique. [25] identifie deux par un flux. Une source souhaitant réduire le délai observé par ses
types de flux qui pourraient être utilisés avec ce PHB : paquets sera pénalisée par une augmentation dans le nombre de
— le trafic dit « de fond ». Les transferts de sauvegarde de fichiers paquets perdus.
pendant les heures de travail et le trafic provoqué par les moteurs Dans l’ABE, il existe deux types de paquets : verts et bleus. Ces
de recherche lors de la mise à jour de leurs bases de données font couleurs n’ont aucune relation avec la notation tricolore utilisée
partie de cette catégorie ; par la précédence dans les services utilisant AF. Dans l’ABE, un flux
— le trafic non conforme d’un autre service. Dans certains servi- marqué bleu observe un comportement du réseau similaire à celui
ces, les paquets non conformes d’un flux sont acceptés dans le d’un réseau Best Effort classique ; aucune garantie n’est donnée
réseau. Pour les services basés sur AF, les paquets non conformes pour le délai de transmission, mais le throughput est maximisé. En
sont marqués avec la plus basse priorité. Les auteurs de [25] partent revanche, des flux colorés verts observent un taux de perte plus
de l’hypothèse que les classes AF seraient utilisées simultanément important mais un retard de transmission réduit.
par des flux conditionnés en trois priorités et par des flux Best Effort
(marqués par défaut en basse priorité). Pour éviter que les flux Best La mise en œuvre du comportement est basée sur l’utilisation de
Effort soient en compétition avec des paquets dégradés des flux AF, deux modules, représentés sur la figure 12. Le PAC (Packet Admis-
il est proposé d’attribuer une précédence plus élevée à ces derniers. sion Control) est un algorithme de gestion de file d’attente basé sur
La notion de différenciation entre les flux Best Effort est un WRED. Il limite le nombre de paquets à bas délai (verts) acceptés
concept qui a été bien reçu par le groupe de travail DiffServ. En dans le nœud en fixant des paramètres de configuration, en parti-
revanche, le PHB ne peut pas être utilisable dans toutes les situa- culier p max (§ 2.4.2), différents pour chaque couleur. À la différence
tions décrites dans [25]. Le LBE peut constituer une bonne alterna- des autres algorithmes de ce type, le module PAC ajoute une fonc-
tive pour le trafic de fond, mais son utilisation pour protéger les flux tion de boucle fermée destinée à la mise à jour dynamique des
Best Effort des flux non conformes part d’une hypothèse douteuse. paramètres de RED. Cette modification améliore considérablement
Il n’est pas certain que des flux non conditionnés par des marqueurs la performance offerte par ce comportement.
à trois couleurs soient acceptés dans les classes de services AF. Une Le deuxième module utilisé par l’ABE est l’EDFS (Earliest Dea-
telle action réduirait les assurances qui pourraient être offertes par dline First Scheduler). Comme le WFQ (§ 2.3.1), cet algorithme uti-
les services se servant de ces classes. La qualité de service observée lise une file unique ordonnée en fonction d’estampilles
deviendrait alors dépendante du trafic non conditionné (Best Effort) temporelles. Pour assurer un bas délai aux paquets verts, leur
injecté dans ces files d’attente. temps d’émission (deadline ) est fixé à leur temps d’arrivée, tandis
En revanche, une possible utilisation du LBE, qui n’est pas expli- que, pour les paquets bleus, un delta est ajouté. Grâce à cette opé-
citement citée dans sa définition, est l’amélioration des perfor- ration, les paquets à bas délai sont servis à l’avance, en évitant en
mances des flux TCP dans la classe Best Effort. En regroupant les même temps que les paquets insensibles au délai soient retardés
flux non adaptatifs dans une classe LBE, les flux TCP ne seraient plus indéfiniment. Un deuxième contrôle d’accès est effectué par
perturbés par la non-adaptabilité de ces flux UDP. l’EDFS : si le nombre de paquets à servir pendant une période don-
Deux solutions sont proposées pour implanter le LBE dans un née est si important qu’un bas délai ne peut être assuré pour un
routeur. La première consiste à lui attribuer une classe de service paquet arrivant, le paquet est éliminé.
dédiée ; la seconde consiste à faire cohabiter les deux types de tra- Des simulations [53] montrent l’utilité de cette proposition.
fic dans la même classe de service en attribuant aux paquets LBE Néanmoins, le manque de définition sur le rôle de ce comportement
un niveau de priorité inférieur. Dans le deuxième cas, un algo- vis-à-vis du modèle DiffServ ralentit son déploiement. Cette inté-
rithme d’élimination basé sur la priorité serait nécessaire dans la gration pourrait avoir lieu si une classe de service était réservée au
file mettant en œuvre cette classe de service. service offert par l’ABE, mais des adaptations aux EDFS seraient
Il reste à trouver le code DSCP qui serait utilisé par le trafic LBE. nécessaires afin de prendre en compte le délai introduit par les
Il est difficile de rendre logique un code qui soit inférieur à celui autres classes. D’ailleurs, [53] laisse imaginer qu’un conditionneur
réservé aux paquets Best Effort (000 000). La solution logique pourrait marquer une partie des paquets d’un flux en vert et une
consiste à attribuer le code 000 000 au trafic LBE et à déterminer un autre partie en bleu en fonction des besoins au niveau du délai. Une
nouveau code pour le trafic Best Effort (000 010 ?). Cela entraînerait telle action aurait une forte répercussion sur les performances de
des problèmes de compatibilité avec l’existant et constitue une des TCP. Dû à la nature de l’ordonnanceur utilisé, le réseau pourrait
raisons pour lesquelles cette proposition n’est pas plus avancée introduire des déséquencements importants. Pour respecter le
dans le processus de standardisation. modèle DiffServ, il est nécessaire que tous les paquets d’un flux uti-
lisant l’ABE soient marqués avec la même couleur.

3.6.2 Alternative Best Effort

L’ABE, décrit par Hurley et Le Boudec [53], peut être vu comme 3.7 Services
un comportement peu coûteux capable d’assurer un bas délai pour
les applications interactives. S’il n’a pas été conçu dans le cadre du Suite à la définition des différents éléments qui forment l’archi-
modèle DiffServ, son intégration dans le modèle ne provoque tecture DiffServ, le groupe de travail a produit d’autres documents
aucune perturbation sur la performance des autres composants. [50] [54] [55] servant à clarifier les interactions entre modules et les

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 13

Dossier délivré pour

DOCUMENTATION
21/10/2008
LA DIFFÉRENCIATION DE SERVICES ________________________________________________________________________________________________________

paramètres utilisés pour leur configuration et leur administration de mécanismes de réseau. Le travail effectué à l’IETF a permis de
mais aussi la définition de services. construire deux approches ayant des philosophies différentes afin
Dans [56] sont définies les caractéristiques d’un service intra- de donner un meilleur traitement à certains flux dans le réseau. La
domaine, ou PDB (Per Domain Behavior). Contrairement aux PHB première approche, IntServ, est fondée sur le paradigme de la réser-
(comportement par nœud), un PDB définit une combinaison parti- vation de ressources dans les équipements du réseau. Cela impli-
culière d’éléments DiffServ qui peut être utilisée à l’intérieur d’un que qu’un contexte doit être conservé dans les routeurs pour
domaine pour offrir un service dont la qualité de service est quan- chaque flux, pénalisant fortement le passage à l’échelle de ce pro-
tifiable. Les mécanismes de conditionnement et les comportements tocole. Afin d’offrir un meilleur passage à l’échelle, en concentrant
(PHB) doivent être considérés comme les composants d’un PDB, la complexité de la différenciation dans les équipements de bordure
l’enchaînement de PDB doit pouvoir servir à la création de services du réseau, l’IETF a défini une seconde approche : DiffServ. Dans le
différenciés de bout en bout. L’assurance de qualité de service entre modèle DiffServ, le rôle des routeurs varie en fonction de leur pla-
deux équipements terminaux, demandant la collaboration entre dif- cement dans le réseau. Les routeurs d’entrée sont chargés de l’iden-
férents domaines administratifs, implique des actions politiques et tification et du conditionnement des flux. Le résultat de ces actions
économiques qui ne concernent pas l’IETF. Il est donc imaginable est inscrit en tant qu’étiquette dans l’en-tête de chaque paquet. Dans
que le travail de standardisation s’arrête à ce stade de définition des le cœur du réseau, cette étiquette est le seul paramètre utilisé pour
services intradomaines. déterminer le comportement des routeurs vis-à-vis des flux les tra-
versant. La différenciation n’est plus assurée par la réservation de
Un comportement par domaine est exactement défini comme ressources mais par un bouquet de mécanismes gérant le traite-
étant « le traitement qu’un groupe identifiable de paquets reçoit de ment des flux dans chaque routeur. Le choix des mécanismes à ins-
frontière en frontière d’un domaine. Un comportement spécifique taller dans le réseau se fait en fonction des comportements qui
(EF, AF, etc.) et des caractéristiques de conditionnement sont asso- devront être offerts par l’équipement et par le réseau en général.
ciés à chaque PDB ».
Nota : l’expression frontière en frontière (edge to edge ) indique dans ce cas la partie de Bien que d’autres stratégies de différenciation telles que le Lower
la route, parcourue par un flux, appartenant au même domaine DiffServ.
Effort aient été standardisées, l’architecture DiffServ définit deux
Chaque PDB présente des attributs qui peuvent être mesurés et types de comportement, le comportement expédié et le comporte-
quantifiés afin de décrire ce qui arrive aux paquets traversant le ment assuré, qui offrent un traitement adapté en fonction de la sen-
domaine. Cela peut demander, pour certains services (ou PDB), la sibilité des flux au délai ou à la perte. La justification de l’utilisation
mise en œuvre, dans le plan de contrôle, de mécanismes de gestion de mécanismes de différenciation de services se heurte toujours aux
de ressources [11] [57]. Il n’existe pour le moment aucune proposi- oppositions des partisans de l’augmentation de capacité des
tion de PDB qui ait obtenu le statut de RFC. réseaux. Cependant, il reste beaucoup de réseaux pour lesquels
l’augmentation de bande passante pose des problèmes consé-
quents (par exemple, les réseaux d’accès ou les réseaux mobiles),
les mécanismes de différenciation de services prennent alors toute
4. Conclusion leur importance. La différenciation de services est maintenant pas-
sée dans le domaine opérationnel et de nombreux opérateurs l’ont
La différenciation de services a longtemps constitué un défi inté- mise en place. Son développement dépend dorénavant des appli-
ressant car elle nécessite la définition d’une architecture complète cations et de leur exploitation des mécanismes offerts par le réseau.

Bibliographie

[1] Congestion Avoidance and Control. Procee- [9] SEAMAN (M.) et SMITH (A.) et coll. – Integra- [17] Projet Alt-Q (Alternative Queueing)
dings of the ACM SIGCOMM’88, p. 314-329, ted Service Mappings on IEEE 802 Networks. [Link]
août 1988. Standards Track RFC 2815, mai 2000. [Link]
[2] ALLMAN (M.), PAXSON (V.) et STEVENS [10] CLAFFY (K.), MILLER (G.) et THOMPSON (K.). [18] KILKKI (K.) et RUUTU (J.). – Simple Integra-
(W.). – TCP Congestion Control. Standards – The nature of the beast : recent traffic ted Media Access – an Internet Service Based
Track RFC 2581, avr. 1999. measurements from an Internet Backbone. on Priorities. 6th International Conference on
[3] BRADEN (R.), CLARK (D.) et SHENKER (S.). – INET’98 (1998). Telecommunication Systems, mars 1998.
Integrated Services in the Internet Architec- [11] DURHAM (D.) et BOYLE (J.) et coll. – The [19] CLARK (D.) et FANG (W.). – Explicit Allocation
ture : an Overview. Informational RFC 1633, COPS (Common Open Policy Service) Proto- of Best Effort Packet Delivery Service. ACM
juin 1994. col. Standards Track RFC 2748, janv. 2000. Transactions on Networking, août 1998.
[4] TCPng BOF, San Jose IETF, déc. 1994. [20] Charte du groupe de travail DiffServ à l’IETF
[12] HERZOG (S.) et BOYLE (J.) et coll. – COPS
[Link] [Link]
usage for RSVP. Standards Track RFC 2749,
[Link] [Link]
janv. 2000.
[5] SHENKER (S.), PARTRIDGE (C.) et GUERIN [21] Internet Protocol Specification. Information
(R.). – Specification of Guaranteed Quality of [13] ATKINSON (R.). – Security Architecture for Sciences Institute, USC, sept. 1981.
Service. Standards Track RFC 2212, sept. the Internet Protocol. Standards Track RFC
[22] SHENKER (S.) et WROCLAWSKI (J.). – Gene-
1997. 1825, août 1995.
ral Characterization Parameters for Integra-
[6] WROCLAWSKI (J.). – Specification of the [14] BERGER (L.) et O’MALLEY (T.). – RSVP Exten- ted Service Network Elements. Standards
Controlled-Load Network Element Service. sions for IPSEC Data Flows. Standards Track Track RFC 2215, sept. 1997.
Standards Track RFC 2211, sept. 1997. RFC 2207, sept. 1997. [23] BRADNER (S.) et MANKIN (A.). – The Recom-
[7] CRAWLEY (E.) et BERGER (L.) et coll. – A Fra- [15] BERNET (Y.) et YAVATKAR (R.) et coll. – A Fra- mendation for the IP Next Generation Proto-
mework for Integrated Services and RSVP mework For Integrated Services Operation col. Standards Track RFC 1752, janv. 1995.
over ATM. Informational RFC 2382, août Over DiffServ Networks. Informational RFC [24] BRADEN (R.) et ZHANG (L.) et coll. –
1998. 2998, nov. 2000. Resource ReSerVation Protocol (RSVP) - Ver-
[8] JACKOWSKI (S.) et POTZOLU (D.) et coll. – [16] TOMASSI (F.) et MOLEDINI (L.). – Some sion 1 : Technical Specification. Standards
Integrated Services Mappings for Low Speed extensions to enhance the scalability of the Track RFC 2205, sept. 1997.
Networks. Standards Track RFC 2688, sept. RSVP protocol. Personal Internet Draft (draft- [25] BLESS (R.) et WEHRLE (K.). – A Lower than
1999. tomassi-rsvp-enhan-scalab-01), oct. 1999. Best Effort Per-Hop Behaviour. Personal

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 565 − 14 © Techniques de l’Ingénieur

Dossier délivré pour

DOCUMENTATION
21/10/2008
 _______________________________________________________________________________________________________ LA DIFFÉRENCIATION DE SERVICES

Internet Draft (draft-bless-diffserv-lbe-phb- [39] WANG (Z.) et CROWCROFT (J.). – A New [53] HURLEY (P.), LE BOUDEC (J.Y.) et THIRAN (P.).
01), sept. 1999. Congestion Control Scheme : Slow Start and – The Alternative Best-Effort Service. Institute
[26] GOYAL (P.) et VIN (H.M.). – Start-time Fair Search (Tri-S). Computer Communication for Computer Communication and Applica-
Queueing : A scheduling Algorithm for Inte- Review, 21, 1, 32-34, janv. 1991. tions, EPFL, SSC Technical Report SSC/1999/
grated Services Packet Switching Networks. [40] SANGHI (D.) et AGRAWALA (A.). – DTP : An 036, sept. 1999.
Proceedings ACM SIGCOMM’96, août 1996. Efficient Transport Protocol. University of [54] CHAN (K.), SAHITA (R.), HAHN (S.) et Mc CLO-
Maryland Tech Report, oct. 1991. GHRIE (K.). – Differentiated Services Quality
[27] GOLESTANI (S.J.). – A Self-clocked Fair
[41] FLOYD (S.) et JACOBSON (V.). – Random Early of Service Policy Information Base. Informa-
queueing scheme for Broadband Applica-
Detection Gateways for Congestion Avoi- tional RFC 3317, mars 2003.
tions. Proceedings IEEE Infocom’94, p. 636-
646, juin 1994. dance. IEEE/ACM Transactions on Networ- [55] BAKER (F.), CHAN (K.) et SMITH (A.). – Mana-
king,1, 4, p. 397-413, août 1993. gement Information Base for the Differentia-
[28] JA MALODDIN (S.). – Fair Queueing Algo- ted Services Architecture. Standards Track
rithms for Packet Scheduling in BISDN. [42] RAMAKRISHNAN (K.) et FLOYD (S.). – A Pro-
posal to add Explicit Congestion Notification RFC 3289, mai 2002.
International Zurich Seminar on Digital Com-
munications (1996). (ECN) to IP. Experimental RFC 2481, janv. 1999. [56] NICHOLS (K.) et CARPENTER (B.). – Definition
[43] Cisco IOS Quality of Service Solutions of Differentiated Services Per-domain Beha-
[29] ZHANG (L.). – Virtual Clock : A new Traffic viors and Rules for their Specification. Infor-
Control Algorithm for Packet Switching Configuration Guide.
[Link] mational RFC 3086, avril 2001.
Networks. ACM SIGCOMM 1990, p. 19-29,
sept. 1990. product/software/ios120/12cgcr/qos_c [57] AWDUCHE (D.), CHIU (A.), ELWALID (A.), WID-
JAJA (I.) et XIAO (X.). – A Framework for Inter-
[30] TOUTAIN (F.). – Gestion préemptive et équita- [44] CLARK (D.) et FANG (W.). – Explicit Allocation
net Traffic Engineering. WG Internet Draft
ble de la qualité de service dans les réseaux of Best Effort Packet Delivery Service. IEEE/
(draft-ietf-tewg-framework-02), juill. 2000.
de paquets à intégration de services. Thèse de ACM Transactions on Networking, 6, 4, p. 363-
373, août 1998. [58] SEDDIGH (N.), NANDY (B.) et coll. – Study of
doctorat, université de Rennes, juil. 1997.
TCP and UDP Interaction for the AF PHB. Per-
[45] BRADEN (R.) et ZHANG (L.). – Resource
[31] TOUTAIN (L.). – Réseaux Locaux et Internet. sonal Internet Draft (draft-nsbnpp-diffserv-
ReSerVation Protocol : Message Processing
Hermes Science (1999). tcpudppaf-00), juin 1999.
Rules. Informational RFC 2209, sept. 1997.
[32] SHREEDAR (M.) et VARGHESE (G.). – Efficient [59] FANG (W.), SEDDIGH (N.) et NANDY (B.). – A
[46] GREENBERG (A.G.) et MADRAS (N.). – How
Fair Queueing using Deficit Round Robin. Pro- Time Sliding Window Three Colour Marker.
fair is Fair Queueing. Journal of the ACM, 39,
ceedings SIGCOMM’95, août 1995. Experimental RFC 2859, juin 2000.
3, p. 568-598, juil. 1992.
[33] McKENNY (P.). – Stochastic Fairness [60] HEINANEN (J.) et GUERIN (R.). – A Two Rate
[47] MAY (M.), BONALD (T.) et BOLOT (J.C.). – Ana-
Queueing. Internetworking : Research and Three Color Marker. Informational RFC 2698,
lytic Evaluation of RED Performance. Info-
Experience, 2, p. 113-131, janv. 1991. sept. 1999.
com’2000, mars 2000.
[34] DEMERS (A.), KESHAV (S.) et SHENKER (S.). – [48] NICHOLS (K.), BLAKE (S.), BAKER (F.) et
Analysis and Simulation of a fair queueing BLACK (D.). – Definition of the Differentiated
algorithm. Journal of Internetworking Services Field (DS Field) in the IPv4 and IPv6 Dans les Techniques de l’Ingénieur
Research and Experiment, p. 3-26, oct. 1990. Headers. Standards Track RFC 2474, déc. 1998.
[35] FLOYD (S.) et JACOBSON (V.). – Link-Sharing [49] BLAKE (S.), BLACK (D.), CARLSON (M.), [61] NOËL (T.). – IP Mobile. TE 7 515, Réseaux –
and Resource Management Models for Packet DAVIES (E.), WANG (Z.) et WEISS (W.). – An Télécommunications (2002).
Networks. IEEE/ACM Transactions on Networ- Architecture for Differentiated Services. Stan- [62] MAKNAVICIUS-LAURENT (M.). – Protocole
king, janv. 1995. dards Track RFC 2475, déc. 1998. IPsec. TE 7 545, Réseaux – Télécommunica-
[36] SHENKER (S.), CLARK (D.) et ZHANG (L.). – A [50] BERNET (Y.), BLAKE (S.), GROSSMAN (D.) et tions (2003).
Schedulling Service Model and Schedulling SMITH (A.). – An Informal Management [63] RUBINO (G.) et TOUTAIN (L.). – Routage dans
Architecture for an Integrated Services Packet Model for Diffserv Routers. Informational RFC les réseaux Internet. H 1 428, Réseaux – Télé-
Network. Work paper, Xerox Park, août 1993. 3290, mai 2002. communications (2000).
[37] ZHANG (H.) et FERRARI (D.). – Rate-Controlled [51] BAKER (F.), HEINANEN (J.), WEISS (W.) et [64] PUJOLLE (G.). – Architecture TCP/IP. H 2 288,
Static-Priority queueing. Proceedings INFO- WROCLAWSKI (J.). – Assured Forwarding Technologies logicielles - Architectures des
COM’93, avr. 1993. PHB Group. Standards Track RFC 2597, juin systèmes (1997).
[38] NICHOLS (K.), JACOBSON (V.) et ZHANG (L.). 1999. [65] PUJOLLE (G.). – Principaux protocoles de
– A Two-bit Differentiated Services Architec- [52] JACOBSON (V.), NICHOLS (K.) et PODURI (K.). transmission de données. H 2 285, Technolo-
ture for the Internet. Informational RFC 2638, – An Expedited Forwarding PHB. Standards gies logicielles - Architectures des systèmes
juil. 1999. Track RFC 2598, juin 1999. (2003).

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur TE 7 565 − 15

Dossier délivré pour

DOCUMENTATION
21/10/2008