Le modèle à différentiation de Services (DiffServ) ajoute des nouvelles fonctionnalités aux routeurs de l’Internet afin d’améliorer la Qualité de Service offerte aux flux.
Des contraintes telles que la réduction du délai d’acheminement ou le contrôle dans la distribution de ressources peuvent être satisfaites grâce aux mécanismes proposés par ce modèle. A travers le Comportement Assuré, le modèle DiffServ introduit le concept d’élimination sélective basée sur un niveau de priorité.
D’un coté, cette notion peut être exploitée pour distribuer équitablement les ressources réseau indépendamment du comportement des sources. De l’autre, en utilisant des algorithmes de codage audio/vidéo multi-couches, la notion de priorités peut réduire considérablement l’effet de pertes sur la transmission de flux multimédia.
Mots-clés :
Internet à Différenciation de Services, Difusion Audio/Vidéo multi-couches, Qualité de Service, Conditionneurs de traffic, Comportement Assuré.
Sommaire
Bibliographie Conventions typographiques Préambule Glossaire 1. Introduction 2. Introduction à la qualité de service 2.1 Les principaux mécanismes de gestion de la QoS 3. Le modèle DiffServ 3.1 Historique 3.2 Principe de fonctionnement 3.3 Architecture Le champs DSCP Les contrats SLA/TCA Les domaines DiffServ Le fonctionnement des entités 1. Les noeuds d’extrémité
2. Les noeuds intermédiaires
3.4 Avantages & inconvénients 4. Conclusion
[CISCO02] Cisco, Implémentation du modèle DiffServ dans les routeurs Cisco, juin 2002 (accès sécurisé).
Conventions Typographiques
Dans cette étude, les termes ayant une définition dans le glossaire sont mis en italique.
Les notions importantes apparaissent en gras.
Les remarques utiles pour approfondir un sujet mais non nécessaires à sa compréhension sont précédées de l’îcone
Enfin, les fonctionnalités ne faisant pas partie de la norme DiffServ de l’IETF (généralement issues de constructeurs d’équipements réseau) sont précédées de l’îcone
.
Préambule
Cette étude est un état de l’art du modèle DiffServ de l’IETF. Elle a pour but de détailler les différents mécanismes de la QoS ainsi que son application à DiffServ.
Le modèle de l’IETF a eu des implémentations diverses parmi les constructeurs ; celles-ci ont apporté leur lot de nouveautés et ont aussi permis de préciser ce modèle.
Nous avons jugé utile d’indiquer au fil de l’étude ces fonctionnalités lorsqu’elles concouraient à une amélioration du modèle ou qu’elles en précisaient les modalités d’application. Ces notes seront dissociées du corps du texte pour que le lecteur puisse faire la distinction avec la norme officielle DiffServ.
Les différentes RFC consacrées à DiffServ donnent peu de précision sur les files d’attente à utiliser. L’analyse des différentes files d’attentes et algorithmes associés sont de plus des sujets complexes qui nécessiteraient des études dédiées.; ils n’apparaitront donc pas dans cette étude.
Glossaire
Best effort : Appellation généralement associée à une absence de qualité de service.
Ce mode de fonctionnement actuellement majoritaire dans Internet a tout de même l’avantage :
- d’une grande souplesse puisqu’il n’y a besoin d’aucune correspondance avec les flux qui transitent.
- de permettre des applications très variées.
- d’être moins coûteux et plus facile à maintenir qu’un réseau offrant de la qualité de service.
Domaine DiffServ : Zone contigue de nœuds DiffServ ayant une politique commune de policing et de PHB.
Champ PRECEDENCE: Il a été défini initialement dans la RFC 791 comme les 3 premiers bits du champs TOS réservé pour les applications du département de la Défense américaine.
Suite au passage du champ TOS au champs DSCP, on continue à utiliser ce terme pour désigner les classes de services principales qui y sont stockées.
IntServ : Modèle de QoS défini par l’IETF (RFC 1633) basé sur la réservation de ressources (via le protocole RSVP, le plus utilisé). Ce modèle a pour but d’offrir une QoS de bout en bout pour les applications. Il est toutefois complexe à mettre en œuvre, notamment en raison de son mécanisme d’allocation dynamique de ressources par flux sur l’ensemble des routeurs intermédiaires.
Leaky bucket : Algorithme de gestion de file d’attente. Le trafic arrivant dans la file d'attente est régulé pour sortir en flux fixes sur le réseau. La taille de la file d'attente et le taux de transmission sont configurables par l'utilisateur.Ce mécanisme est bien adapté pour envoyer des débits fixes sur le réseau mais, en contrepartie, ne permet pas d'utiliser plus de ressources lorsque le réseau est peu chargé.
Micro-flux : Flot de paquets entre deux instances d’application identifié par l’adresse source, le port source, l’adresse de destination, le port de destination et l’identifiant de protocole (généralement TCP ou UDP).
Token Bucket : Algorithme de gestion de file d’attente. Les paquets de données sont transmis sur la base de jetons (octets) présents dans un « seau ».
Ce mécanisme permet à un trafic en rafale d'être transmis tant qu'il y a des jetons dans la file d'attente (ceux-ci ayant pu être accumulés en situation de réseau peu chargé).
Des variantes du token bucket ne font plus correspondre un token à un paquet mais à un certain nombre d’octets. Cela permet une gestion plus fine de la bande passante.
MPLS : (Multi Protocol Label Switching): MPLS est une solution proposée pour répondre aux problèmes posés par les réseaux actuels. Elle est apparue comme une solution permettant d'organiser la rencontre entre l'administration de bande passante et le besoin de services pour les nouveaux réseaux IP. MPLS propose des solutions liées à la scalabilité (adaptation à l'échelle du réseau) et au routage (basé sur la QoS et les mesures de la QoS). Il peut s'adapter aux réseaux ATM et Frame Relay.
NBAR : Network Based Application Recognization, mécanisme propriétaire Cisco permettant de classifier les flux en interprêtant les données de la couche application. On obtient un suivi dit « statefull » particulièrement utile pour des applications complexes couplées avec des adresses de port dynamiques (SAP…)
NBAR est particulièrement adapté à la tendance actuelle de bouquets applicatif web (le filtrage par numéro de port étant alors impossible
QoS : Quality of Service. Voir Qualité de service.
Qualité de service : Décrit le niveau de performance attendu d'une application, d'un serveur, d'un réseau ou de tout autre dispositif. Par exemple pour un réseau, les paramètres principaux suivis sont en général la bande passante, le temps de latence, la perte de paquets et le temps de réponse à une requête.
RED : Random Early Detection, mécanisme prévenant les phénomènes de congestion en s’appuyant sur les mécanismes de contrôle de congestion TCP. En décrémentant aléatoirement les paquets lors des périodes de haute congestion, RED indique au paquet source de décrémenter son taux de transmission.
En supposant que la source des paquets utilise TCP, elle décrémentera son taux de transmossion jusqu’à ce que tous les paquets atteignent leur destination, indicant que la congestion est terminée.
RSVP : Ressource reSerVation Protocol, protocole de signalisation que les applications peuvent utiliser pour réserver des ressources sur un réseau. Les équipements correspondants peuvent alors accepter ou rejeter les requêtes de ce protcole.
Son association au modèle IntServ permet d’en étendre les possibilités : précision du type de service demandé ainsi que la quantification des ressources à allouer. Ils peuvent toutefois être utilisés séparément.
SLA : Service Level Agreement, contrat passé entre un domaine DiffServ et un client ou un autre domaine DiffServ. Ce contrat définit les caractéristiques du service associé à chaque classe. Les caractéristiques intégrées dans le contrat SLA sont nombreuses et peuvent constituer un TCA à part entière:
- taux de disponibilité moyen, taux de perte moyen.
- délai borné, délai moyen, gigue moyenne.
- bande passante garantie, pics de données acceptés.
- comportement en cas de dépassement (transmission, rejet, priorité moindre…).
TCA : Traffic Conditioning Agreement : Accord spécifiant les règles de classification des micro-flux, ainsi que les profils de trafic associés (bande passante garantie, pics de données acceptés, comportement en cas de dépassement de bande passante…).
TOS : Type Of Service, champ défini dans l’en-tête du protocole IPV4 pour apporter des fonctionnalités de QoS. Il est constitué des champs PRECEDENCE et DTS. Le nombre de classes disponibles ainsi que le manque de fonctionnalités en cas de congestion en ont limité l’usage et ont amené l’IETF à définir des modèles de QoS particuliers (IntServ puis DiffServ).
WFQ : Weighted Fair Queuing, algorithme de gestion de file d’attente propriétaire Cisco basé sur l’algorithme Flow-based queuing. Pour choisir les paquets à émettre, on tient compte de la bande passante allouée à chaque lien ainsi que du finished round number. La valeur de finished round number est calculée suivant la taille du paquet (les paquets de petite taille étant privilégié) et la date d’émission du dernier paquet (de la même session).
Une extension de WFQ appelée CBWFQ (Class Based Weighted Fair Queuing) ajoute la notion de classe de service des flux entrants (champs ip precedence ou dscp) comme critère pour effectuer un ordonnancement pondéré des paquets en sortie.
WRED : Weighted Random Early Detection, ce mécanisme propriétaire Cisco consitue une extension de RED (qui est une recommandation de l’IETF) en permettant le rejet sélectif des paquets suivant leur classe de service. Les paquets ayant la classe de service la plus élevée seront rejetés en dernier, et auront donc une plus forte probabilité d’atteindre leur destination que les paquets de classe inférieur.
WRR : Weighted Round Robin, algorithme de gestion de file d’attente allouant les ressources de manière pondérée suivant la bande bassante allouée à chaque lien.
1. Introduction
L’évolution actuelle des réseaux (débits, services, architecture) étend l’utilisation des services existants mais permet aussi l’intégration de nouveaux services (streaming vidéo, voix sur IP, commerce électronique, services « temps réel »…) qui se satisfont de moins en moins d’un traitement au mieux (ou best efforf).
Avant l’introduction de la QoS par l’IETF, l’IUT-T (International Union for Telecommunications, Telecommunication), l’ATM Forum (Asynchronous Transfer Mode), et le Frame-relay Forum avaient déjà réussi à établir un standard QoS de niveau 2 dans les réseaux ATM et Frame-relay.
Pour pallier à ces problèmes, l’IETF a élaboré le modèle IntServ qui a permis de répondre en partie à ces besoins, mais sa complexité de mise en œuvre en a limité l’utilisation.
Le modèle à différenciation de Services (DiffServ) constitue donc une évolution de la QoS en proposant une solution adaptée aux besoins actuels.
La première partie de cette étude vous propose un rappel des notions de base de la QoS.
Celles-ci sont indépendantes des différents protocoles implémentants la QoS et sont essentielles pour une bonne compréhension du modèle DiffServ.
S’en suivra la présentation des concepts clefs de DiffServ donnant une vision générale de son principe de fonctionnement.
Nous verrons comment il s’intègre dans l’en-tête du protocole IPV4 ainsi que IPV6 en précisant le rôle de chaque valeur.
Nous nous intéresserons ensuite à son architecture en présentant les différents modules, leur fonctionnement respectif, leurs intéractions.ainsi que leur paramétrage.
Enfin, nous traiterons des avantages de ce nouveau modèle mais aussi de ses inconvénients et des améliorations possibles.
2. Introduction à la qualité de service
Le déploiement d’applications multimédia ayant des exigences spécifiques en terme de QoS est en constante augmentation. Certains services comme les services vocaux ont besoin d’un faible délai point à point et d’une faible gigue, d’autres comme les trafics de données nécessitent des faibles taux de perte ou d’erreurs sans retransmission avec éventuellement une certaine garantie de bande passante pour le trafic de données transactionnel. Pour pouvoir garantir la QoS des flux transportés, il faut donc utiliser des mécanismes permettant de traiter de manière différenciée les différentes catégories de trafic dans les organes du réseau ainsi que des protocoles de signalisation de la QoS pour pouvoir allouer des ressources en fonction des besoins des applications.
On peut distinguer deux grandes problématiques pour la gestion de la QoS dans un réseau IP :
La gestion des phénomènes de congestion est un point fondamental pour garantir la QoS des flux. En effet, les mécanismes de gestion des QoS n’auront un impact effectif que lorsque le réseau sera chargé.
Il existe deux grandes approches pour la gestion des congestions : les méthodes réactives et les méthodes préventives.
La philosophie du contrôle réactif est d’accepter un maximum de connexions et lors de la congestion d’un équipement réseau (mesurée en terme de pertes, de délais et de remplissage des buffers), les sources réduisent leurs débit. Ainsi, dans le modèle Best-Effort de l’Internet actuel, la gestion du phénomène de congestion est faite de manière réactive par le mécanisme de fenêtre glissante du protocole TCP. Toutefois, ce contrôle n’est pas adapté pour pouvoir offrir des garanties de QoS par exemple à des flux vidéo temps réel (ils ne peuvent pas adapter leur débit).
A l’inverse, le contrôle préventif consiste à prendre des mesures à priori, pour minimiser l’apparition du phénomène de congestion et/ou pour qu’il n’affecte pas les services garantis. Ainsi, les techniques de contrôle d’admission ou de mise en forme des trafics permettent de réduire la fréquence des congestions tandis que les mécanismes de gestion de buffer (RED, WRED, etc.) permettent de respecter les QoS des services les plus prioritaires en cas de congestion.
L’ordonnancement (ou scheduling) des paquets est aussi un mécanisme fondamental pour garantir la QoS des flux transportés. Ceci est évident si on considère des flux hétérogènes, les rafales de certaines connexions pouvant perturber le trafic temps réel même s’il n’y a pas congestion. De ce fait, bien que la mise en œuvre d’ordonnancements autres que FIFO soit difficile sur des routers à très haut débit, les équipementiers réseau fournissent de plus en plus des mécanismes plus sophistiqués réalisant un scheduling prenant en compte les classes de trafic (WRR, WFQ, etc).
Ces différents mécanismes de contrôle de congestion et d’ordonnancement des paquets sont présents dans toutes les architectures développées pour le contrôle de la QoS dans les réseaux IP : le modèle IntServ et le modèle DiffServ.
Ces deux modèles de réseaux IP multiservices peuvent être utilisés avec le protocole MPLS qui permet un traitement très rapide des paquets sur les routeurs du coeur du réseau en remplaçant la fonction de routage par une fonction de commutation, beaucoup plus adaptée au débit des réseaux de transport actuels.
2.1 Les principaux mécanismes de gestion de la QoS
La gestion de la QoS dans les réseaux IP suppose un ensemble de traitements différenciés réalisés soit au niveau de la source de trafic (terminal émetteur) soit dans les organes du réseau.
On peut distinguer les mécanismes suivants :
Le traffic shaping, ou mise en forme du trafic, consiste principalement à introduire du délai entre les émissions de paquets de manière à éviter ou limiter les rafales de trafic. Le shaper fournit également une description simple du trafic au réseau.
Le traffic policing est une opération qui consiste à vérifier que le trafic émis est bien conforme à la description qui en a été faite par la source.
Le mécanisme de buffer management, ou gestion de buffer, consiste à éliminer des paquets en cas de congestion du buffer d’une interface de sortie de manière sélective, en fonction des paramètres de QoS associés aux flux.
L’opération de traffic scheduling consiste à ordonnancer la transmission des paquets présents dans les buffers de l’interface de sortie en fonction des paramètres de QoS associés aux flux.
Cette opération peut être effectuée par différents algorithmes tels que le Leaky bucket (le plus simple) ou le Token Bucket (Principe du Sceau à Jetons)
Le traitement différentié de paquets est un concept relativement ancien dans l’Internet. Il est présent dès l’origine du protocole IPv4 avec le champ ToS, mais une définition trop vague a limité son déploiement. Ce concept a été re-défini pour offrir un traitement adapté aux besoins très hétérogènes des applications.
Nous présenterons tout d’abord l’évolution du protocole de QoS IntServ (Integrated Service) vers le protocole DiffServ, ainsi que les rfc qui y sont associés.
Nous étudierons ensuite les concepts de base de DiffServ, son architecture, les particularités de ce modèle ainsi que les difficultés qui peuvent en découler.
3. Le modèle DiffServ
3.1 Historique
Du modèle IntServ au modèle DiffServ :
Historiquement, la première architecture qui a été proposée associe, comme ATM, une QoS à chaque flux que le réseau transporte. Il s’agit du modèle IntServ (Integrated Services, RFC 1633, 2212 et 2215) qui s’appuie sur le protocole RSVP pour effectuer la réservation des ressources dans les routeurs (nœuds) réseau intermédiaires.
- Nous considérons un flux comme une connexion réseau entre un équipement source et un ou plusieurs équipements d’extrémités (plusieurs dans le cas d’une diffusion multicast par exemple) -
Chaque routeur intermédiaire devait ainsi maintenir dynamiquement une liste des sessions IntServ en cours et, lors de la transmission d’un paquet IntServ, rechercher dans cette liste le niveau de qualité de service correspondant (processus coûteux en mémoire d’état du routeur).
Ceci posa des problèmes lors de l’application du modèle IntServ aux réseaux d’envergure (problème de scalabilité) dans lesquels on peut difficilement assurer la conformité de l’ensemble des routeurs.
IntServ est aussi un protocole complexe supportant le multicast et des mécanismes de filtrage lors des réservations.
Pour pallier à ces problèmes, l’IETF a également proposé le modèle DiffServ dans lequel la QoS est associée à une agrégation de flots (classe).
Evolution des RFC DiffServ :
Le schéma suivant présente l’évolution des RFC proposées par l’IETF concernant le protocole DiffServ dont le groupe de travail a été créé en 1997. Les RFC 2205 et 2216 (non représentés dans la figure 1) sont devenus des standards du protocole IntServ et ont aussi contribué à l’élaboration du protocole DiffServ.
Détail des RFC :
RFC 2474 (décembre 1998): Définition de l’architecture de base du modèle DiffServ.
Ce document comprend : - les domaines DiffServ.
- le conditionnement et la classification des services.
- la notion de comportement par saut (Per-hop Behaviors).
- l’allocation de ressources.
RFC 2475 (décembre 1998): Définition du champ DSCP, et de l’interprétation de chaque valeur de bit. Le champ DSCP vient en remplacement du champ TOS (RFC 1349) défini initialement dans le protocole IPV4.
RFC 2597 (juin 1999): Le groupe PHB : Traitement Assuré (AF, Assured Forwarding)
Cette RFC propose un nouveau groupe de services nommé AF qui fixe l’utilisation d’une partie des classes de service DSCP.
Ce groupe PHB AF fournit des niveaux de garantie d’acheminement des paquets.
Ce document fait aussi des recommandations sur les algorithmes de gestion de file d’attente ainsi que de rejet des paquets.
RFC 2598 (juin 1999):
Un nouveau groupe de services EF (Expedited Forwarding) est proposé dans ce document.
Il est destiné aux paquets nécessitant une haute disponibilité (faible gigue, latence et taux de perte).
Cette RFC préconise un ensemble de mesures contribuant à une haute disponibilité dans le traitement des paquets (type de file d’attente, dimensionnement des nœuds…).
RFC 3246 (mars 2002):
Ce document complète les éléments de la RFC 2598 en apportant plus de rigueur via des formules mathématiques (calcul de la gigue et du délai notamment).
RFC 3260 (avril 2002):
Ce document met à jour les RFC 2474, 2475, 2597 et 3246. Il clarifie un certain nombre de points concernant les valeurs du champ DSCP, le comportement des nœuds dans les cas particulier (valeurs DSCP incorrectes…).
A terme, les informations de cette RFC doivent concourir à la standardisation des RFC qu’il complète.
3.2 Principe de fonctionnement
Le modèle DiffServ apporte une QoS différenciée pour chaque classes de service (constituée d’une agrégation de micro-flux) selon un contrat prédéfini (SLA, Service Level Agreement) avec l’émetteur des flux de données.
Ce contrat définit un ensemble de paramètres (bande passante garantie, pic de données acceptés, comportement en cas de non-respect du contrat…) ainsi que les micro-flux associés à chaque classe de service.
On associe ensuite une SLA à un domaine DiffServ. Un domaine DiffServ définit un ensemble de nœuds réseau appliquant une politique de QoS commune.
Le modèle DiffServ s’articule autour de deux types de traitements :
- les traitements complexes effectués dans les nœuds d’extrémité.
- les traitements simples des nœuds intermédiaires.
Les nœuds d’extrémité sont les premiers équipements réseau auxquelles sont reliés les flux.
Chacun d’eux comporte un ensemble de modules appliquant des mécanismes complexes de QoS (classification, marking, metering, shaping, dropping).
Les nœuds intermédiaires ont des comportements plus statiques mais aussi plus simples que l’on regroupe sous le terme de PHB (Per-hop behaviour).
3.3 Architecture
Le champs DSCP :
Le modèle DiffServ a été conçu pour être utilisé avec la couche réseau IP. Il utilise le champ TOS (Type Of Service) défini initialement dans le protocole IPV4 (RFC 1122, Figure 2) mais peu utilisé jusqu’à présent et fait partie intégrante du protocole IPV6 (champs Traffic Class de la Figure 3).
Fig 2 et 3 (source cisco)
Le champ TOS a été renomé en DSCP (Differentiated Service Code Point) lors du passage au modèle diffServ. La signification de chaque bit de l’octet DSCP est détaillée dans le schéma suivant :
Figure 4 (source cisco)
Les bits 0 à 2 : Class Selector
Les codes DSCP de type xxx000 (ou x a la valeur 1 ou 0) correspondent aux classes de services principales. Ceux-ci seront associées aux PHB qui permettront le traitement différencié des flux dans les routeurs intermédiaires.
Plus la valeur de codepoint est élevée, plus le flux correspondant sera prioritaire.
Les bits 0 à 5 : DSCP (Differentiated Service CodePoint)
Ce champ étend les sélecteurs de classes (bits 0 à 2) via 3 bits supplémentaires. On obtient ainsi une granularité supplémentaire (8 sous-classes par sélecteur de classe).
Les bits 5 à 7 : CU (Currently Unused)
Ce champ est actuellement inutilisé et donc ignoré par les routeurs intermédiaires.
Il a pour but de faciliter les extensions futures du protocole.
L’intérêt de la QoS est de pouvoir offrir un service adapté à chaque classe.
Ce service est défini au sein d’un contrat appelé SLA entre un client (l’émetteur des flux de la classe ou un autre domaine DiffServ) et un opérateur.
Lors d’un contrat SLA pour une classe donnée, on définit le type de service offert ainsi qu’un ensemble de règles (plus ou moins détaillées suivant le contexte) pour le conditionnement du traffic :
taux de disponibilité moyen, taux de perte moyen.
délai borné, délai moyen, gigue moyenne.
Les types de micro-flux faisant partie de chaque classe.
La valeur de marquage DSCP (numéro de 0 à 63).
La bande passante alloué, pics de données acceptés.
Le choix d’une politique à appliquer (policing) en cas de dépassement du contrat parmi les possibilités suivantes:
Transmission.
Rejet des paquets.
Abaissement du niveau de priorité (changement de classe).
Lissage des flux (étalement du trafic en excédant dans le temps).
La taille des buffers de files d’attente.
Suivant les besoins, et éventuellement la criticité d’une classe, on définira une partie ou la totalité de ces règles.
Remarque : Lorsque les flux d’une classe ne dépassent pas le contrat SLA fixé, on dit qu’ils sont dans le profil fixé, sinon il sont hors profil.
Les domaines DiffServ
Un domaine DiffServ correspond à une zone contigue de nœuds conforme à au modèle DiffServ et ayant une politique commune de policing et de PHB.
Exemple de domaines DiffServ (Figure 7)
On associe généralement un domaine DiffServ à un opérateur de service ou un intranet. L’organisation responsable du domaine est aussi la garante du respect du contrat SLA établi avec les émetteurs des flux. Ceci implique une adéquation entre les ressources mises à disposition par l’organisation et les besoins (bande passante, latence…) du contrat SLA.
Si des nœuds réseau à l’intérieur d’un domaine ne sont pas conformes à DiffServ, les résultats sont alors imprévisibles.
Les régions DiffServ :
Ce terme regroupe un ensemble de domaines DiffServ appliquant des contrats de services SLA prédéfinis.
Ces domaines DiffServ effectuent sur leurs nœuds d’extrémité les conditionnements de trafic nécessaires (TCA) à la correspondance entre leurs PHB et ceux des autres domaines.
Le fonctionnement des entités
Le modèle DiffServ est une évolution de IntServ. Contrairement à celui-ci, DiffServ adopte la philosophie de limiter les temps de traitement des routeurs intermédiaires.
Cela se concrétise par un fonctionnement différent des entités sur les routeurs intermédiaires par rapport aux routeurs d’extrémité.
1. Les noeuds d’extrémité
Les traitements effectués sur les noeuds d’extrémité sont généralement les plus complexes et correspondent à un contrat SLA préalablement établi.
Ils ont aussi un rôle particulier d’interfaçage entre les PHB de chacun des deux domaines qu’ils associent.
Les nœuds d’extrémité pourront éventuellement effectuer un reconditionnement des paquets si les règles de classification et de conditionnement (TCA) ne sont pas les mêmes sur le domaine de destination.
Un contrat SLA d’une organisation X peut par exemple considérer un flux « Gold » (classe de service AF 3) d’un client Y entrant comme un flux « Silver » (classe AF 2) au sein de son domaine. Dans ce cas, le nœud d’extrémité du domaine DiffServ du client Y devra alors effectuer des opérations de conditionnement de trafic (TCA) pour le trafic sortant.
Les nœuds d’extrémité peuvent aussi être des stations (serveurs ou stations de travail) sur lesquelles s’exécutent les applications émettant les flux. La station effectue alors généralement une classification des flux à émettre. Si ce n’est pas le cas, le premier équipement du domaine DiffServ peut jouer le rôle d’équipement d’extrémité.
Figure 5
a. La classification (classifier) :
Cette fonction consiste à détecter les classes de service des micro-flux. La classification peut se faire de plusieurs manières. Généralement, on se base sur une association d’une ou plusieurs des caractéristiques de la couche réseau et/ou transport:
- adresse source
- adresse destination
- port source
- port de destination
- type de protocole (TCP ou UDP)
Des mécanismes propriétaires (NBAR) permettent d’étendre les critères de différenciation à la couche application.
La notion de PHB (Per Hop Behaviour):
Dans les premières RFC DiffServ (2474 et 2475), l’IETF n’avait pas défini de comportement particulier associé aux valeurs DSCP. Seul un comportement par défaut équivalent à un traitement de type « Best Effort » (traitement au mieux) avait été défini (valeur DSCP 000000).
Les RFC 2597 et 2598 ont apporté une première normalisation des valeurs en définissant respectivement deux types de comportement : le PHP AF (Assured Forwarding) et le PHB EF (Expedited Forwarding).
Le PHB AF fournit des niveaux de garantie d’acheminement des paquets.
Il est constitué d’un ensemble de 4 classes de service ayant chacune 3 niveaux de rejet de paquets différents.
Par exemple, en cas de congestion dans la classe de service 4, les paquets de valeur DSCP 100110 seront rejetés (drop) en premier lieu.
Le PHB EF est destiné aux paquets nécessitant une haute disponibilité (faible gigue, latence et taux de perte).
On utilise couramment ce type de comportement pour le passage de données temps réel tel que la voix ou la visio-conférence.
Le PHB EF est associé à une valeur unique DSCP 101110.
b. La métrologie (meter) :
Elle consiste à vérifier que les classes des flux entrants ne dépassent pas le contrat (SLA) défini dans le routeur. Cette information est transmise aux modules de marquage et de shaping/dropping qui effectueront alors des actions conformes au policing fixé.
Le module de marquage par exemple peut décider qu’en cas de dépassement du contrat, les flux excédentaires soient marqués avec une priorité moindre. Le module de shaping/dropping peut aussi rejeter (dropper) tous les paquets excédentaires lorsque le contrat est dépassé.
c. Le marquage (marquer) :
C’est dans ce module que sera affecté le champ DSCP (Cf. Figure 4). Les informations fournies en entrée par le meter et le classifier permettront de faire un choix sur la priorité à appliquer à chaque flux.
d. Le lissage et le rejet de paquet (shaper, dropper) :
Le lissage peut s’effectuer lorsque les flux d’une classe outrepassent le contrat SLA prédéfini.
Cette fonctionnalité n’est pas systématique et correspond à une règle de policing explicite dans le SLA. Les paquets sont alors mis en file d’attente afin d’être transmis un peu plus tard lorsque le débit de la classe sera considéré comme étant dans le profil du contrat.
Le rejet des paquets intervient pour garantir le débit fixé pour chaque classe de service.
Dans le cadre d’un lissage, les files d’attente ayant une taille finie, des dépassements de profil trop importants peuvent aussi provoquer un rejet des paquets.
Les routeurs intermédiaires
Le problème principal d’IntServ a été sa complexité de mise en œuvre dans les équipements intermédiaires via le mécanisme de réservation de ressources RSVP.
Le modèle DiffServ procède donc différemment en définissant des traitements plus simples dans les routeurs intermédiaires.
Lors de l’arrivée d’un paquet, le routeur intermédiaire récupère sa valeur DSCP. Il recherche alors une correspondance avec une recommandation de comportement (PHB) prédéfinie par l’IETF.
Si aucune recommandation ne correspond, il peut avoir défini des comportement particuliers non normalisés mais correspondant à un contrat SLA convenu avec l’émetteur des flux.
Si ce n’est pas le cas, alors le paquet est traité avec un service « best effort » (BE).
3.4 Avantages & inconvénients
Comme toute technologie, DiffServ apporte son lot de nouveautés tout en ajoutant un certain nombre de contraintes et de limitations.
Les avantages ont été décrits tout au long de cette étude.
On trouve d’abord la philosophie de limiter les temps de traitement des routeurs intermédiaires apportant une réponse aux opérateurs de réseaux qui pouvaient difficilement mettre en application sur l’ensemble de leur infrastructure la complexité induite par IntServ.
La normalisation des PHB (comportements) constitue un deuxième point fort de DiffServ simplifiant l’interconnexion entre les différents domaines DiffServ.
Pour le reste, DiffServ reprend le principe d’IntServ en normalisant un modèle QoS de niveau 3 permettant d’être indépendant de la technologie de niveau 2 sous-jacente et offrant une véritable QoS d’extrémité.
DiffServ n’est pas pour autant exempt d’inconvénients. Il nécessite en effet d’établir préalablement un contrat dans tous les équipements de son domaine. Ceci implique une connaissance approfondie des applicatifs pouvant transiter sur le réseau et peut se révéler parfois difficile à appliquer.
Le fonctionnement basé sur l’agrégation de flux implique aussi une perte de granularité des applications transitant sur le réseau. Cela peut se révéler dans certains cas inadapté.
Conclusion
Cette étude nous a permis d'aborder les principaux mécanismes de qualité de service indépendamment de tout protocole.
Nous avons ensuite vu comment ils pouvaient être appliqués dans le cadre du modèle DiffServ.
Le modèle DiffServ fonctionne grâce à cinq modules qui interagissent entre eux pour effectuer le conditionnement des paquets.
Il est architecturé autour du protocole IP dans lequel il s'intègre (champs TOS).
DiffServ introduit la notion de domaines et fixe des comportement prédéfinis pour chaque équipement.
Ce modèle dont la philosophie est de limiter les temps de traitement dans les équipements réseaux intermédiaires offre finalement une solution valable répondant aux besoins actuels des opérateurs.
Ce modèle implique toutefois une perte de granularité des flux et l'établissement préalable d'un contrat qui peuvent dans certains cas se révéler pénalisant.
.
