Réseau d’entreprise, sécurité et automatisation – Modules 9 : Concepts QoS

9.0 Introduction

9.0.1 Pourquoi devrais-je suivre ce module?

Bienvenue sur les Concepts QOS!

Imaginez conduire sur une route fortement encombrée et vous êtes pressé de rencontrer un ami pour le dîner. Vous entendez la sirène et voyez les lumières d’une ambulance derrière vous. Vous devez quitter la route pour laisser passer l’ambulance. L’ambulance qui se rend à l’hôpital est prioritaire par rapport à celle qui se rend au restaurant en temps voulu.

Tout comme l’ambulance est prioritaire dans la circulation sur l’autoroute, certaines formes de circulation sur le réseau doivent être prioritaires sur d’autres. Pourquoi? Commencez avec ce module pour le savoir!

9.0.2 Qu’est-ce que je vais apprendre dans ce module?

Titre du module: Concepts QoS

Objectif du module: Expliquer comment les périphériques réseau mettent en œuvre la QoS.

9.1 Qualité des transmissions réseau

9.1.2 Hiérarchisation du trafic

Dans la vidéo précédente, vous avez appris l’objectif de la qualité de service (QoS). Les réseaux actuels nécessitent de plus en plus un haut niveau de qualité de service (QoS). Avec l’arrivée de nouvelles applications sur le marché, telles que la voix et la vidéo en direct, la qualité de service est au cœur de toutes les préoccupations parmi les utilisateurs.

Une congestion se produit lorsque plusieurs communications sont gérées par un seul appareil, par exemple un routeur, et qu’une grande partie de ces données est placée sur un nombre inférieur d’interfaces sortantes ou sur une interface moins rapide. Il peut également y avoir une congestion lorsque des paquets de données volumineux retardent la transmission de paquets de plus petite taille.

Lorsque le volume de trafic est supérieur au volume pouvant être transporté sur le réseau, les périphériques placent les paquets en file d’attente dans la mémoire en attendant que des ressources se libèrent. Cette mise en file d’attente peut provoquer des retards, car les nouveaux paquets ne peuvent pas être transmis avant le traitement des paquets précédents. Si le nombre de paquets dans la file d’attente continue à augmenter, la mémoire du périphérique se remplit et les paquets sont détruits. Pour résoudre ce problème, il est possible de mettre en œuvre une technique QoS qui consiste à répartir les données dans plusieurs files d’attente, comme indiqué sur la figure.

Remarque: Un appareil implémente la qualité de service uniquement en cas de congestion.

Utilisation des files d’attente pour hiérarchiser les communications

9.1.3 Bande passante, encombrement, délai et gigue

La bande passante réseau est mesurée en bits pouvant être transmis en une seconde, soit en «bits par seconde» (bits/s). Par exemple, un appareil réseau peut afficher un débit de traitement maximal de 10 gigabits par seconde (Gbit/s).

L’encombrement d’un réseau entraîne des délais. Une interface est encombrée lorsqu’elle reçoit plus de trafic que le volume qu’elle peut prendre en charge. Les points de congestion d’un réseau sont idéals pour l’implémentation d’un mécanisme de QoS La figure présente trois exemples de points d’encombrement typiques.

Exemples de points d’encombrement

Le délai ou la latence désigne le temps nécessaire à un paquet pour passer de la source à la destination. On distingue le délai fixe et le délai variable. Le délai fixe est le laps de temps nécessaire à l’exécution d’un processus donné, par exemple la durée requise pour placer un bit sur le support de transmission. Le délai variable, qui peut être plus ou moins long, dépend de plusieurs facteurs tels que le volume de trafic à traiter.

Les sources de délai sont récapitulées dans le tableau.

Sources of Delay

La gigue est la variation de délai entre les paquets reçus. Du côté émetteur, les paquets sont transmis selon un flux continu, à intervalles réguliers. Le délai de traitement des paquets peut varier en raison d’une congestion du réseau, d’une mise en file d’attente inappropriée ou d’erreurs de configuration. La prise en charge du trafic en temps réel et interactif nécessite de contrôler et de limiter au maximum le délai et la gigue.

9.1.4 Perte de paquets

En l’absence de mécanismes de QoS, les paquets sont traités dans l’ordre dans lequel ils arrivent. En cas d’encombrement, il se peut que les périphériques réseau comme les routeurs et les commutateurs abandonnent les paquets. ce qui signifie que les paquets soumis à une contrainte temporelle, tels que la vidéo en temps réel et la voix, seront abandonnés à la même fréquence que les données non soumises à cette contrainte, par exemple les e-mails et la navigation web.

Lorsqu’un routeur reçoit un flux de données audio numérique RTP (Real-Time Protocol) pour la voix sur IP (VoIP), il doit compenser la gigue générée. Le mécanisme qui gère cette fonction est la mise en mémoire tampon. La mise en mémoire tampon consiste à mettre les paquets dans un tampon pour ensuite les diffuser en flux régulier, comme illustré sur la figure. Les paquets numériques sont ensuite reconvertis en flux audio analogique.

Le tampon des délais de diffusion compense la gigue

Si la gigue est forte au point que certains paquets arrivent en dehors de la portée de ce tampon, ces paquets sont ignorés et les coupures s’entendent dans l’enregistrement sonore, comme illustré sur la figure.

Paquet ignoré en raison d’une gigue excessive

Si un seul paquet est perdu, le processeur de signal numérique (DSP) rajoute ce qu’il pense correspondre à l’enregistrement sonore manquant et l’utilisateur n’entendra rien. Cependant, lorsque la gigue est trop importante pour que le DSP compense les paquets manquants, des problèmes de son surviennent.

La perte de paquets est très souvent la cause des problèmes de qualité vocale sur un réseau IP. Dans un réseau correctement conçu, ce phénomène doit être proche de zéro. Le DSP intègre des codecs vocaux qui peuvent tolérer un certain degré de perte de paquets sans impact gênant sur la qualité vocale. Les ingénieurs réseau utilisent les mécanismes de QoS pour classer les paquets vocaux afin d’arriver à une perte de paquets nulle. Pour garantir la bande passante pour les appels vocaux, ils doivent accorder la priorité au trafic voix par rapport au trafic non soumis aux délais.

9.2 Caractéristiques du trafic

9.2.2 Tendances du trafic réseau

Dans une rubrique précédente, vous avez appris la qualité de la transmission réseau. Dans cette rubrique, vous découvrirez les caractéristiques du trafic (voix, vidéo et données). Au début des années 2000, la voix et les données constituaient les types de trafics IP prédominants. Le trafic voix nécessite un volume de bande passante prévisible et des délais de transmission des paquets constants. Le trafic de données n’est pas en temps réel et ses besoins en bande passante sont imprévisibles. Il peut temporairement se faire par salves, par exemple en cas de téléchargement d’un fichier volumineux, ce qui peut entraîner la consommation de la totalité de la bande passante d’une liaison.

Plus récemment, le trafic vidéo a acquis une importance de plus en plus cruciale pour les communications et les opérations professionnelles. Selon l’indice VNI (Virtual Networking Index) Cisco, le trafic vidéo représentait 70% du trafic en 2017. En 2022, le vidéo représentera 82% de tous les trafics. En outre, le trafic vidéo mobile atteindra 60,9 exaoctets par mois en 2022, contre 6,8 exaoctets par mois en 2017.Le type de demandes que la voix, la vidéo et le trafic de données placent sur le réseau sont très différents.

9.2.3 Voix (Voice)

Comme le montre la figure, le trafic voix est prévisible et fluide. Toutefois, le voix est très sensible aux délais et aux paquets abandonnés. Il n’est pas logique de retransmettre la voix si les paquets sont perdus ; par conséquent, les paquets de voix doivent être prioritaires par rapport aux autres types de trafic. Par exemple, les produits Cisco utilisent la plage de ports RTP de 16384 à 32767 afin de placer ce trafic en priorité maximale. La voix peut tolérer un certain degré de latence, de gigue et de perte sans effets notables. La latence ne doit pas dépasser 150 ms. la gigue ne doit pas dépasser 30 ms; la perte de paquets de voix ne doit pas dépasser 1%. Le trafic voix nécessite au moins 30 Kbps de bande passante. Le tableau récapitule les caractéristiques et les exigences du trafic vocal.

9.2.4 Vidéo

À défaut de mécanismes de QoS et d’une capacité de bande passante supplémentaire significative, en règle générale, la qualité vidéo se dégrade. L’image est floue, hachée ou lente. La partie audio du flux peut perdre sa synchronisation avec la vidéo.

Par rapport au trafic voix, le trafic vidéo est imprévisible, incohérent et en salve. Contrairement à la voix, la vidéo récupère moins bien en cas de perte et comporte un plus grand volume de données par paquet. Notez dans la figure que les paquets de voix arrivent toutes les 20 ms et ont toujours la même taille de 200 octets.

En revanche, le nombre et la taille des paquets vidéo varient toutes les 33 ms selon le contenu de la vidéo, comme illustré dans la figure. Par exemple, si le flux vidéo se compose d’un contenu qui ne change pas beaucoup de trame en trame, les paquets vidéo seront de taille et de nombre limités. Cela suffira pour maintenir une expérience utilisateur acceptable. Par contre, si le contenu du flux vidéo change rapidement, comme par exemple au cours d’une scène d’action dans un film, alors les paquets vidéo seront plus volumineux. Il faudra donc davantage de paquets par intervalle de 33 ms pour maintenir la qualité de l’image.

Les ports UDP, par exemple le port 554 sont utilisés pour le protocole RSTP (Real-Time Streaming Protocol), doivent être prioritaires par rapport au trafic réseau moins soumis à des contraintes temporelles. Tout comme la voix, la vidéo peut tolérer un certain degré de latence, de gigue et de perte sans subir d’effets apparents. La latence ne doit pas dépasser 400 ms. la gigue ne doit pas dépasser 50 ms; la perte de paquets vidéo ne doit pas dépasser 1%. Le trafic vidéo nécessite au moins 384 Kbit/s de bande passante. Le tableau récapitule les caractéristiques et les exigences du trafic vidéo.

9.2.5 Données

La plupart des applications utilisent le protocole TCP ou le protocole UDP. Contrairement à UDP, TCP utilise un mécanisme de reprise sur erreur. Les applications de données qui ne tolèrent pas la perte de données, comme les e-mails et les pages web, utilisent le protocole TCP pour garantir que les éventuels paquets perdus lors du transit seront renvoyés. Le trafic de données peut être fluide ou en salve. Le trafic du réseau est généralement fluide et prévisible. Lors d’une modification de topologie, il est possible que ce trafic se fasse par salves pendant quelques secondes. Mais, les réseaux actuels présentent des capacités leur permettant de gérer facilement l’augmentation du trafic pendant leur convergence.

Cependant, certaines applications TCP peuvent être très extrêmement gourmandes et consommer une grande partie de la capacité du réseau. Lorsque vous téléchargez un fichier volumineux, par exemple un film ou un jeu, le protocole FTP consomme autant de bande passante qu’il peut. Le tableau récapitule les caractéristiques du trafic de données.

Bien que le trafic de données soit beaucoup moins sensible aux pertes de paquets et aux délais par rapport à la voix et à la vidéo, un administrateur réseau a quand même besoin d’assurer la qualité de l’expérience de l’utilisateur, parfois appelée «Qualité d’Expérience» ou QoE. Les deux principales questions qu’un administrateur réseau doit se poser à propos du flux d’un trafic de données sont les suivantes:

• Les données proviennent-elles d’une application interactive?
• Les données sont-elles essentielles?

Le tableau compare ces deux points.

Factors to Consider for Data Delay

9.3 Algorithmes de mise en file d’attente

9.3.2 Présentation de la mise en file d’attente

La rubrique précédente abordait les caractéristiques du trafic. Cette rubrique explique les algorithmes de mise en file d’attente utilisés pour implémenter la qualité de service. La politique QoS que l’administrateur réseau a implémentée devient active en cas d’encombrement sur la liaison. La mise en file d’attente est un outil de gestion des congestions qui permet de stocker en mémoire tampon, de hiérarchiser et, si nécessaire, de réorganiser les paquets avant leur transmission à la destination.

Différents algorithmes de mise en file d’attente sont disponibles. Dans ce cours, nous allons nous concentrer sur les suivants:

• Premier entrant premier sorti (FIFO)
• File d’attente équitable pondérée (WFQ)
• File d’attente équitable pondérée basée sur la classe (CBWFQ)
• File d’attente à faible latence (LLQ)

9.3.3 Premier entrant premier sorti (FIFO)

Dans sa forme la plus simple, la mise en file d’attente FIFO, qui repose sur le principe du premier arrivé, premier servi, consiste à mettre le trafic en mémoire tampon et à transférer les paquets dans leur ordre d’arrivée.

Le FIFO n’a pas de concept de priorité ou de classe de trafic et de ce fait, ne prend pas de décision sur la priorité des paquets. Il n’y a qu’une seule file d’attente et tous les paquets sont traités de la même manière. Les paquets sont envoyés par une interface dans l’ordre dans lequel ils arrivent, comme indiqué sur la figure. Même si une partie du trafic peut être plus important ou soumis à des contraintes temporelles selon la classification des priorités, le trafic est envoyé dans l’ordre dans lequel il arrive.

Avec la méthode FIFO, le trafic important ou soumis à des contraintes temporelles peut être abandonné en cas de congestion sur l’interface du routeur ou du commutateur. Lorsqu’aucune autre stratégie de mise en file d’attente n’est configurée, toutes les interfaces à l’exception des interfaces série au niveau d’E1 (2048 Mbits/s) et en dessous utilisent FIFO par défaut. (Les interfaces série sur E1 et en dessous utilisent WFQ par défaut.)

FIFO, la méthode la plus rapide de mise en file d’attente, est efficace pour les liaisons volumineuses dont le délai et l’encombrement sont minimes. Si votre liaison subit une congestion limitée, vous pouvez très bien vous contenter de la mise en file d’attente FIFO.

Exemple de mise en file d’attente FIFO

9.3.4 File d’attente équitable pondérée (WFQ)

WFQ (Weighted Fair Queuing) est une méthode de programmation automatisée grâce à laquelle la bande passante est allouée au trafic réseau de façon équitable. WFQ n’autorise pas la configuration des options de classification. WFQ applique le principe de priorité, ou de pondération, au trafic identifié, puis le répartit en conversations ou en flux, comme illustré sur la figure.

Exemple de WFQ (Weighted Fair Queuing)

WFQ détermine alors la quantité de bande passante autorisée pour chaque flux par rapport à d’autres flux. L’algorithme basé sur les flux utilisé dans la méthode WFQ programme simultanément le trafic correspondant à un échange interactif en tête de la file d’attente pour réduire le temps de réponse. Il partage ensuite équitablement le reste de la bande passante entre les flux à large bande. Avec WFQ, vous pouvez donner la priorité au trafic interactif de faible volume, par exemple les sessions Telnet et la voix, sur le trafic de volume élevé, par exemple les sessions FTP. Lorsque plusieurs flux de transferts de fichiers se produisent simultanément, les transferts bénéficient de la même quantité de bande passante.

WFQ permet de classer le trafic en différents flux selon l’adressage des en-têtes de paquets, notamment selon les caractéristiques telles que les adresses IP source et de destination, les adresses MAC, les numéros de port, le protocole, et la valeur du type de service (ToS). La valeur ToS de l’en-tête IP permet de classer le trafic.

Les flux de trafic à faible bande passante, qui constituent la majorité du trafic, reçoivent le service préférentiel, ce qui permet l’envoi en temps voulu de la totalité de leurs charges offertes. Les flux de trafic à volume élevé se partagent le reste de la capacité proportionnellement entre eux.

Limitations

La méthode WFQ n’est pas prise en charge en cas de tunnélisation et de chiffrement, car ces fonctionnalités entraînent la modification des informations de contenu des paquets dont cette méthode a besoin à des fins de classification.

Bien que la stratégie WFQ s’adapte automatiquement aux changements du trafic réseau, elle n’offre pas le même degré de précision dans le contrôle de l’allocation de la bande passante que la méthode CBWFQ.

9.3.5 File d’attente équitable pondérée basée sur la classe (CBWFQ)

CBWFQ étend la fonctionnalité de mise en file d’attente pondérée (WFQ) standard afin de fournir la prise en charge des classes de trafic définies par l’utilisateur. Avec le CBWFQ, vous définissiez des classes de trafic en fonction de critères de correspondance incluant les protocoles, les listes de contrôle d’accès (ACL) et les interfaces d’entrée. Les paquets qui répondent à ces critères pour une classe constituent le trafic pour cette classe. Chaque classe dispose de sa propre file d’attente de type FIFO. Le trafic est dirigé vers la file d’attente de sa classe, comme le montre la figure.

Lorsqu’une classe a été définie en fonction de ses critères de correspondance, vous pouvez lui attribuer des caractéristiques. Caractériser une classe signifie lui attribuer de la bande passante, un poids et une limite maximale de paquets. La bande passante attribuée à une classe sera la bande passante garantie à cette classe lors d’un encombrement.

Pour caractériser une classe, vous devez également spécifier sa limite de file d’attente, c’est-à-dire le nombre maximal de paquets autorisés à s’accumuler dans la file d’attente correspondant à cette classe. Les paquets faisant partie d’une classe sont soumis à la bande passante et aux limites de file d’attente qui la caractérisent.

Exemple de CBWFQ

Une fois qu’une file d’attente a atteint sa limite configurée, l’ajout d’autres paquets à la classe entraîne la perte de queues (Tail drop) ou de paquets, selon la configuration de la politique de classe. Le « Tail drop » signifie que le routeur détruira les nouveaux paquets arrivant sur la file d’attente lorsque celle-ci a épuisé ses ressources. C’est la réponse par défaut de mise en file d’attente en cas de congestion. Le «Tail drop» d’attente s’applique de manière identique à tout le trafic et à toutes les classes de service.

9.3.6 File d’attente à faible latence (LLQ)

Avec la fonctionnalité LLQ, la stratégie CBWFQ bénéficie d’une capacité de mise en file d’attente à priorité stricte. La priorité stricte permet aux paquets soumises à des contraintes temporelles, par exemple la voix, d’être envoyées avant les paquets présents dans d’autres files d’attente. LLQ implique une mise en file d’attente à priorité stricte, dans le cadre de CBWFQ, ce qui permet de réduire la gigue dans les conversations vocales, comme indiqué sur la figure.

Sans LLQ, CBWFQ gère la mise en file d’attente pondérée (WFQ) basée sur des classes n’incluant pas de possibilité de définir de priorité pour le trafic en temps réel. Le poids d’un paquet appartenant à une classe spécifique provient de la bande passante allouée à la classe comme vous l’avez configurée. Par conséquent, la bande passante allouée aux paquets d’une classe détermine l’ordre dans lequel les paquets sont envoyés. Tous les paquets sont traités de façon équitable en fonction du poids; il n’est pas possible d’attribuer la priorité stricte à aucune classe de paquet. Ce schéma pose des problèmes pour le trafic voix qui, globalement, ne tolère pas les délais, notamment les variations de délai. Pour le trafic voix, les variations de délai entraînent des irrégularités de transmission, qui se manifestent sous la forme de gigue lors des conversations.

Ainsi, les paquets soumises à des contraintes temporelles comme la voix sont envoyées en premier (avant les paquets présents dans d’autres files d’attente), leur offrant un traitement préférentiel par rapport au reste du trafic. S’il est possible de définir d’autres types de trafic en temps réel à la file d’attente à priorité stricte, Cisco recommande de n’y placer que le trafic voix.

Exemple de LLQ

9.4 Modèles de QoS

9.4.2 Sélection d’un modèle de politique QoS approprié

Comment implémenter une stratégie de qualité de service (QoS) sur un réseau? Il existe trois modèles de mise en œuvre de la qualité de service:

• Remise au mieux (Best effort)
• Services intégrés (IntServ)
• Services différenciés (DiffServ)

Le tableau récapitule ces trois modèles. La QoS est implémentée dans un réseau à l’aide du modèle IntServ ou DiffServ. Si le modèle IntServ offre un meilleur niveau de qualité de service, il est extrêmement gourmand en ressources et donc limité en matière d’évolutivité. A contrario, le modèle DiffServ mobilise moins de ressources et est plus évolutif. Les deux modèles sont parfois déployés conjointement dans les implémentations QoS du réseau.

Models for Implementing QoS

9.4.3 Remise au mieux (Best effort)

La conception de base d’Internet prévoit la remise des paquets «au mieux» et n’offre aucune garantie. Toujours prédominante sur Internet aujourd’hui, cette approche reste adaptée dans la plupart des cas. Comme ce modèle applique un traitement identique à tous les paquets réseau, le message vocal d’urgence est traité de la même manière qu’une photo numérique jointe à un e-mail. Sans la stratégie QoS, le réseau ne peut pas faire la différence entre les paquets et, par conséquent, ne peut pas leur appliquer un traitement préférentiel.

D’un point de vue conceptuel, le modèle de remise au mieux est comparable à l’envoi d’une lettre par courrier postal standard. Toutes les lettres bénéficient du même traitement. Avec ce modèle de remise au mieux, la lettre ne peut jamais arriver et, sauf si vous en avez convenu avec le destinataire de lettre d’un moyen de contrôle, vous ne saurez peut-être jamais si votre lettre est arrivée ou non.

Le tableau répertorie les avantages et les inconvénients du modèle de remise au mieux.

Benefits and Drawbacks of Best-Effort Model

9.4.4 Services intégrés

Les besoins des applications en temps réel, notamment la vidéo à distance, les systèmes de conférence multimédia, la visualisation et la réalité virtuelle, ont contribué au développement du modèle d’architecture de services intégrés (IntServ) en 1994 (RFC 1633, 2211 et 2212). IntServ est un modèle multi-services et peut donc s’adapter aux nombreuses exigences possibles en termes de qualité de service.

IntServ offre la qualité de service de bout en bout dont les applications en temps réel ont besoin. IntServ gère explicitement les ressources réseau, ce qui permet de garantir la qualité de service requise aux flux de paquets de certains utilisateurs, parfois appelés microflux. Pour garantir et préserver la qualité de service exigée, le modèle IntServ met en œuvre des mécanismes de contrôle d’admission et de réservation des ressources. Ce modèle est similaire à celui des services garantis ou « hard QoS ». Les services garantis prévoient que certains critères de qualité de service du trafic (par exemple la bande passante, la latence et le taux de perte de paquets) sont préservés de bout en bout. Ils assurent des niveaux de service à la fois prévisibles et garantis aux applications stratégiques.

La figure illustre un exemple simple du modèle de services intégrés.

Exemple simple de services intégrés

Le modèle IntServ se fonde sur un modèle de connexion orienté héritée du réseau téléphonique. Chaque communication individuelle doit spécifier explicitement son descripteur de trafic et les ressources demandées au réseau. Le routeur de périphérie responsable du contrôle d’admission s’assure qu’il existe suffisamment de ressources disponibles sur le réseau. La norme IntServ suppose que, tout au long du chemin, les routeurs définissent et préservent l’état de chaque communication individuelle.

Dans le modèle IntServ, l’application demande un type de service spécifique au réseau avant de transmettre les données. L’application avertit le réseau de son profil de trafic et demande un type particulier de service, dont ses exigences en termes de bande passante et de latence. Le modèle IntServ utilise le protocole RSVP (Resource Reservation Protocol) pour communiquer les besoins QoS du trafic d’une application à tous les périphériques du chemin du réseau. Si les périphériques du chemin sont en mesure de réserver la bande passante nécessaire, l’application source peut commencer à transmettre les données. Si la réservation demandée échoue à un emplacement quelconque du chemin, l’application source n’envoie pas de données.

Le routeur de périphérie procède au contrôle d’admission en se basant sur les informations collectées auprès de l’application et sur les ressources réseau disponibles. Le réseau s’engage à satisfaire les exigences de qualité de service de l’application pour autant que le trafic continue de répondre aux spécifications du profil. Le réseau respecte ses engagements en préservant l’état par flux puis en procédant à une classification des paquets, à une surveillance et à une mise en file d’attente intelligente sur la base de cet état.

Le tableau répertorie les avantages et les inconvénients du modèle IntServ.

Benefits and Drawbacks of IntServ Model

9.4.5 Des services différenciés

Le modèle QoS de services différenciés (DiffServ) propose un mécanisme simple et évolutif pour classer et gérer le trafic réseau. Par exemple, le modèle DiffServ peut offrir un service garanti, avec une latence faible, pour les trafics réseaux critiques tels que la voix ou la vidéo ainsi qu’une garantie de remise au mieux pour le trafic non critique, comme le trafic web ou les transferts de fichiers.

La conception du modèle DiffServ s’affranchit des limites associées aux modèles de remise au mieux et des services intégrés. Il est décrit dans la RFC 2474, 2597, 2598, 3246 et 4594. Le modèle DiffServ peut fournir une qualité de service «quasiment garantie» tout en restant rentable et évolutif.

D’un point de vue conceptuel, il se rapproche de l’envoi d’un colis par service de courrier. Vous demandez et payez un certain niveau de service lorsque vous envoyez un colis. L’ensemble du réseau par lequel transite votre colis est en mesure d’identifier le niveau de service que vous avez payé et votre colis bénéficie d’un service normal ou préférentiel, selon ce que vous avez demandé.

Le modèle DiffServ n’est pas une stratégie QoS de bout en bout car il ne peut pas appliquer les garanties de bout en bout. Toutefois, il représente une approche plus évolutive de l’implémentation de la qualité de service. Contrairement aux services intégrés (IntServ) et hard QoS qui demandent aux hôtes finaux de signaler leurs besoins de qualité de service au réseau, les services différenciés n’utilisent pas la signalisation. Il adopte à la place une approche de qualité de service sans garantie stricte «soft QoS». Il s’inspire du modèle QoS de mise à disposition où les éléments réseau sont configurés pour servir différentes classes de trafic, chacun présentant diverses exigences de qualité de service.

La figure illustre un exemple simple du modèle de services différenciés.

Exemple simple de DiffServ

Dès lors qu’un hôte transmet du trafic à un routeur, ce dernier organise (agrège) les flux en classes et propose la stratégie QoS appropriée aux classes. Le modèle DiffServ met en œuvre et applique des mécanismes QoS saut par saut, en appliquant des critères globaux à chaque classe de trafic pour garantir la flexibilité et l’évolutivité. Par exemple, le modèle DiffServ peut être configuré pour regrouper tous les flux TCP dans une même classe et attribuer de la bande passante pour celle-ci, alors que le modèle IntServ attribuerait de la bande passante pour chaque flux. Outre la classification du trafic, le modèle DiffServ réduit les besoins de signalisation et de préservation de l’état sur chaque nœud du réseau.

Plus précisément, DiffServ divise le trafic réseau en classes selon les besoins métier. Un niveau de service différent peut être ensuite affecté à chaque classe. Lorsque les paquets transitent sur un réseau, les différents périphériques réseau identifient la classe du paquet et lui appliquent un niveau de service spécifique à cette classe. Le modèle DiffServ propose un large choix de niveaux de service. Par exemple, le trafic vocal des téléphones IP bénéficie souvent d’un traitement préférentiel par rapport au trafic des autres applications, le courrier électronique d’un service « au mieux » et le trafic non professionnel d’un service de qualité faible, lorsqu’il n’est pas bloqué.

La figure répertorie les avantages et les inconvénients du modèle DiffServ.

Remarque: Les réseaux modernes utilisent principalement le modèle DiffServ. Cependant, en raison des volumes croissants de trafic sensible à la latence et à la gigue, les modèles InteServ et RSVP sont parfois également déployés.

Benefits and Drawbacks of DiffServ Model

9.5 Techniques d’implémentation QoS

9.5.2 Prévention de la perte de paquets

Maintenant que vous avez appris les caractéristiques du trafic, les algorithmes de mise en file d’attente et les modèles QoS, il est temps d’en apprendre davantage sur les techniques d’implémentation QoS.

Commençons par la perte de paquets. La perte de paquets est généralement due à une congestion au niveau d’une interface. La plupart des applications qui utilisent TCP enregistrent un ralentissement car TCP s’adapte automatiquement à l’encombrement du réseau. La perte de segments TCP entraîne une réduction de la taille de fenêtre des sessions TCP. Certaines applications n’utilisent pas le protocole TCP et ne sont pas en mesure de gérer les abandons de paquets (flux fragiles).

Plusieurs mesures permettent d’éviter la perte de paquets pour les applications à risques:

• Augmenter la capacité des liaisons pour réduire ou éviter la congestion.
• Garantir suffisamment de bande passante et augmenter l’espace de la mémoire tampon pour pouvoir prendre en charge les pics de trafic des flux fragiles. WFQ, CBWFQ et LLQ peuvent garantir la bande passante et fournir un transfert hiérarchisé vers des applications sensibles aux pertes de données.
• Rejeter les paquets moins prioritaires avant que la congestion se produise. Les fonctions QoS du logiciel Cisco IOS proposent des mécanismes de mise en file d’attente, tel que WRED (weighted random early detection), qui commencent à supprimer les paquets à priorité plus faible avant que la congestion se produise.

9.5.3 Outils QoS

On distingue trois catégories d’outils QoS, tels que décrits dans le tableau:

• Outils de classification et de marquage
• Outils de prévention de l’encombrement
• Outils de gestion de l’encombrement

Tools for Implementing QoS

Reportez -vous à la figure pour comprendre la séquence d’utilisation des outils lorsqu’une stratégie QoS est appliquée aux flux de paquets.

Séquence QoS 

Comme vous pouvez le voir dans la figure, les paquets en entrée (carrés gris) sont classés et leur en-tête IP est marqué (carrés de couleur). Pour éviter l’encombrement du réseau, des ressources sont allouées aux paquets sur la base des stratégies définies. Ils sont ensuite placés en file d’attente puis transmis vers l’interface de sortie en fonction de la stratégie de surveillance et de régulation QoS définie.

Remarque: La classification et le marquage peuvent être effectués à l’entrée ou à la sortie tandis que d’autres tâches QoS, notamment la mise en file d’attente et la régulation, sont généralement effectuées à la sortie.

9.5.4 Classification et marquage

Avant de pouvoir appliquer une stratégie QoS à un paquet, ce dernier doit être classé. La classification et le marquage permettent d’identifier, ou «marquer», les types de paquets. La classification détermine la classe de trafic à laquelle les paquets ou les trames appartiennent. Les politiques ne peuvent être appliquées qu’une fois le trafic est marqué.

La classification des paquets varie selon l’implémentation QoS choisie. Les méthodes de classification des flux de trafic aux couches 2 et 3 comprennent l’utilisation d’interfaces, les listes de contrôle d’accès et les mappages de classes. Il peut également être classé au niveau des couches 4 à 7 à l’aide de la fonction NBAR (Network Based Application Recognition).

Remarque: NBAR est une fonction de classification et de détection de protocole du logiciel Cisco IOS, compatible avec les fonctionnalités QoS. La fonction NBAR n’est pas abordée dans ce cours.

Le marquage consiste à ajouter une valeur à l’en-tête du paquet. Les périphériques qui reçoivent le paquet examinent ce champ pour voir s’il correspond à une stratégie définie. Le marquage doit être effectué le plus près possible du périphérique source. Cela permet d’établir la limite de confiance.

Le marquage appliqué au trafic dépend de la technologie. Le tableau de la figure décrit certains champs de marquage utilisés par les différentes technologies. La décision de marquer le trafic au niveau de la couche 2 ou 3 (ou des deux) n’est pas anodine. Voici quelques points à prendre en compte avant de faire un choix:

• Le marquage des trames au niveau de la couche 2 peut être effectué pour le trafic non-IP.
• Le marquage des trames au niveau de la couche 2 est la seule option QoS disponible pour les commutateurs qui ne prennent pas en charge le trafic IP.
• Le marquage de la couche 3 porte les informations QoS de bout en bout.

Traffic Marking for QoS

9.5.5 Marquage au niveau de la couche 2

802.1Q est le standard IEEE qui prend en charge l’étiquetage (Tag) des VLAN au niveau de la couche 2 des réseaux Ethernet. Lorsque le protocole 802.1Q est activé, deux champs sont ajoutés à la trame Ethernet. Comme le montre la figure, ces deux champs sont insérés dans la trame Ethernet juste après l’adresse MAC source.

Valeurs de classe de service (CoS) Ethernet

Le standard 802.1Q inclut également le schéma de hiérarchisation QoS plus connu sous le terme IEEE 802.1p. Le standard 802.1p utilise les trois premiers bits du champ Données de contrôle des balises (TCI). Ce champ de 3 bits, ou champ de Priorité (PRI), contient le marquage de la classe de service (COS). Le codage de la priorité sur 3 bits implique qu’une trame Ethernet de couche 2 peut être marquée avec l’un des huit niveaux de priorité (de 0 à 7), comme le montre la figure.

Ethernet Class of Service (CoS) Values

9.5.6 Marquage au niveau de la couche 3

Le marquage des paquets avec IPv4 et IPv6 s’effectue à l’aide d’un champ de 8 bits situé au niveau des en-têtes de paquet. Comme le montre la figure, IPv4 et IPv6 prennent en charge un champ de 8 bits pour le marquage: le champ Type de service (ToS) pour IPv4 et le champ Classe de trafic pour IPv6.

En-têtes de paquet IPv4 et IPv6

9.5.7 Champ Type de service/Classe de trafic

Le type de service (IPv4) et la classe de trafic (IPv6) portent le marquage des paquets tel qu’attribué par les outils de classification QoS. Le champ est ensuite référencé par des périphériques de réception qui transmettent les paquets en fonction de la politique de qualité de service appropriée.

La figure illustre le contenu du champ de 8 bits. Dans RFC 791, le champ Priorité IP (IPP) a été défini comme le champ à utiliser pour les marquages QoS. Toutefois, dans la pratique, ces huit bits n’offraient pas la granularité suffisante pour mettre en œuvre la qualité de service.

RFC 2474 remplace RFC 791 et redéfinit le champ ToS en renommant et en élargissant le champ IPP. Le nouveau champ, comme le montre la figure, a 6 bits alloués pour la qualité de service. Ces six bits s’appellent le champ DSCP (Differentiated Services Code Point) et proposent jusqu’à 64 classes de service. Les deux bits IP ECN (Extended Congestion Notification) restants peuvent être utilisés par les routeurs compatibles ECN pour marquer les paquets au lieu de les abandonner. Le marquage ECN indique aux routeurs en aval qu’il y a une congestion sur les flux de paquets.

9.5.8 Valeurs DSCP

Les 64 valeurs DSCP sont réparties en trois catégories:

• Remise au mieux (Best effort) – Il s’agit de la catégorie par défaut pour l’ensemble des paquets IP. La valeur du champ DSCP est 0. Un routage normal est appliqué au niveau de chaque tronçon. En cas de congestion sur un routeur, ces paquets seront abandonnés. Aucune politique de QoS n’a été implémentée.
• Traitement Accéléré (EF) – RFC 3246 defines EF as the DSCP decimal value 46 (binary 101110). Les trois premiers bits (101) correspondent à la valeur CoS 5, qui est utilisé à la couche 2 pour le trafic voix. Pour la couche 3, Cisco conseille d’utiliser les valeurs EF uniquement pour marquer les paquets voix.
• Transmission Assurées (AF) – Dans le cadre de la norme RFC 2597, AF implique l’utilisation des 5 bits DSCP les plus pertinents pour indiquer la probabilité de perte et de mise en file d’attente. La définition de l’AF est illustrée dans la figure.

Valeurs de transmission assurées (AF)

La formule AFxy est spécifiée comme suit:

• Les 3 bits les plus pertinents sont utilisés pour spécifier la classe. La classe 4 correspond à la meilleure file d’attente, et la classe 1 à la file d’attente la moins bonne.
• Les 4e et 5e bits, les plus pertinents, sont utilisés pour indiquer la probabilité d’abandon.
• Le 6e bit le plus pertinent est mis à zéro.

Par exemple, AF32 appartient à la classe 3 (binaire 011), avec une probabilité d’abandon moyen (binaire10). La valeur du champ DSCP est égale à 28, car elle intègre 6e bit qui à zéro, soit en binaire 011100.

9.5.9 Bits sélecteurs de classe (CS)

Comme ils identifient la classe, les trois bits les plus pertinents du champ DSCP sont également appelés bits sélecteurs de classe (CS). Comme le montre la figure, ces 3 bits sont directement mappés vers les 3 bits des champs CoS et IPP pour assurer la conformité avec les normes 802.1p et RFC 791.

CoS de couche 2 et ToS de couche 3

Le tableau dans la figure illustre comment les valeurs CoS sont mappées vers les sélecteurs de classe et la valeur DSCP 6 bits correspondante. Le même tableau peut être utilisé pour mapper les valeurs IPP vers les sélecteurs de classe.

Mappage de CoS aux sélecteurs de classe dans DSCP

9.5.10 Limites de confiance

Où le marquage doit-il intervenir? Le classement et le marquage du trafic doivent s’effectuer le plus près possible, techniquement et administrativement, de la source. Cela permet de définir la limite de confiance, comme illustré dans la figure.

1. Les terminaux sécurisés disposent de fonctionnalités et de renseignements qui leur permettent de marquer le trafic des applications à l’aide de valeurs CoS de couche 2 et/ou DSCP de couche 3. Les téléphones IP, les points d’accès sans fil, les passerelles et systèmes de vidéoconférence et les stations de conférence IP sont des exemples de terminaux de confiance.

2. Pour les terminaux sécurisés, le trafic peut être marqué au niveau du commutateur de couche 2.

3. Le trafic peut également être marqué au niveau des commutateurs/routeurs de couche 3.

Le marquage du trafic, par exemple le marquage des valeurs de CoS en valeurs IP Précédent ou DSCP, est généralement nécessaire.

Diverses limites de confiance

9.5.11 Prévention de la congestion

La gestion de la congestion repose sur des méthodes de mise en file d’attente et de planification, selon lesquelles le trafic excédentaire est mis en mémoire tampon ou en attente (et parfois abandonné) lorsqu’il attend d’être envoyé sur une interface de sortie. Les outils d’évitement de la congestion sont plus simples. Ils surveillent les charges de trafic réseau pour anticiper et éviter tout encombrement au niveau des goulots d’étranglement réseau et inter-réseau habituels avant que la situation ne devienne problématique. Ces outils surveillent la profondeur moyenne d’une file d’attente, tel qu’illustré dans la figure. Lorsque la file d’attente est inférieure au seuil minimal, il n’y a pas de suppressions. Au fur et à mesure que la file d’attente se remplit pour atteindre le seuil maximal, un faible pourcentage des paquets est supprimé. Une fois le seuil maximal atteint, tous les paquets sont supprimés.

Mécanismes de prévention de la congestion

Certaines techniques de prévention de la congestion appliquent un traitement préférentiel au moment de choisir les paquets à abandonner. La fonctionnalité QoS de Cisco IOS inclut par exemple une solution de prévention de l’encombrement basée sur la détection anticipée aléatoire pondérée (WRED). WRED permet d’éviter l’encombrement des interfaces réseau en gérant les tampons et en autorisant la réduction ou la diminution du trafic TCP avant que ceux-ci soient remplis. Grâce à WRED, il est possible d’éviter les pertes de paquet tout en optimisant l’utilisation du réseau et les performances des applications utilisant TCP. Aucune fonctionnalité d’évitement des congestions n’est disponible pour le trafic UDP (User Datagram Protocol), notamment le trafic voix. Pour ce type de trafic, il faut utiliser des techniques de mise en file d’attente et de compression pour réduire, voire empêcher, la perte de paquets.

9.5.12 Mise en forme et régulation

La régulation et la limitation du trafic sont deux mécanismes proposés par la solution QoS de Cisco IOS pour éviter l’encombrement.

La régulation du trafic maintient les paquets excédentaires dans une file d’attente et planifie une transmission ultérieure, répartie graduellement dans le temps. La mise en forme du trafic permet de lisser le débit de sortie des paquets, comme illustré sur la figure.

Exemple de mise en forme du trafic

Contrairement au mécanisme de limitation de trafic, la régulation implique l’existence d’une file d’attente et d’une mémoire suffisante pour stocker les paquets retardés.

Assurez-vous de disposer de suffisamment de mémoire si vous activez la mise en forme. En outre, la mise en forme nécessite une fonction de planification pour la transmission ultérieure des paquets retardés. Cette fonction permet d’organiser la file d’attente de mise en forme en plusieurs files. CBWFQ et LLQ sont des exemples de fonctions de planification.

La mise en forme est un concept sortant ; Les paquets envoyés à partir d’une interface sont mis en file d’attente, puis éventuellement mis en forme. La régulation (policing) s’applique quant à elle au trafic entrant d’une interface. Lorsque le débit du trafic atteint le débit maximal configuré, le trafic en excès est abandonné (ou marqué).

La régulation est généralement mise en œuvre par les prestataires de services dans le cadre d’un contrat avec débit garanti (CIR). Le prestataire de services peut toutefois autoriser le dépassement du débit garanti lorsque son réseau n’est pas encombré.

Exemple de régulation du trafic

9.5.13 Conseils de régulation QoS

Votre régulation QoS doit prendre en compte le chemin complet de la source à la destination. Si un périphérique en cours de route utilise une régulation différente de celle souhaitée, c’est toute la régulation de qualité de service qui est affectée. Par exemple, le bégaiement dans la lecture vidéo pourrait être le résultat d’un commutateur dans la route qui n’a pas la valeur CoS définie de manière appropriée.

Voici quelques conseils qui aident à garantir la meilleure expérience pour les utilisateurs finaux:

• Activer la mise en file d’attente sur chaque périphérique dans le chemin entre la source et la destination.
• Classifier et marquer le trafic le plus près possible de la source.
• Mise en forme et régulation des flux de trafic le plus près possible de leurs sources.

9.6 Module pratique et questionnaire

9.6.1 Qu’est-ce que j’ai appris dans ce module?

Qualité des transmissions réseau

Les transmissions vocales et vidéo en direct créent des attentes plus élevées en matière de qualité parmi les utilisateurs et créent un besoin de qualité de service (QoS). Une congestion se produit lorsque plusieurs communications sont gérées par un seul appareil, par exemple un routeur, et qu’une grande partie de ces données est placée sur un nombre inférieur d’interfaces sortantes ou sur une interface moins rapide. Il peut également y avoir une congestion lorsque des paquets de données volumineux retardent la transmission de paquets de plus petite taille. En l’absence de mécanismes de QoS, les paquets sont traités dans l’ordre dans lequel ils arrivent. En cas d’encombrement, il se peut que les périphériques réseau comme les routeurs et les commutateurs abandonnent les paquets. ce qui signifie que les paquets soumis à une contrainte temporelle, tels que la vidéo en temps réel et la voix, seront abandonnés à la même fréquence que les données non soumises à cette contrainte, par exemple les e-mails et la navigation web. Lorsque le volume de trafic est supérieur au volume pouvant être transporté sur le réseau, les périphériques placent les paquets en file d’attente dans la mémoire en attendant que des ressources se libèrent. Cette mise en file d’attente peut provoquer des retards, car les nouveaux paquets ne peuvent pas être transmis avant le traitement des paquets précédents. Une technique de QoS qui peut aider à résoudre ce problème consiste à classer les données dans plusieurs files d’attente. Les points d’encombrement du réseau sont des candidats idéaux pour les mécanismes QoS afin d’atténuer les retards et la latence. On distingue le délai fixe et le délai variable. Les sources de délai sont délai de code, délai de mise en paquet, délai de mise en file d’attente, délai de sérialisation, délai de propagation, délai de gigue. La gigue est la variation de délai entre les paquets reçus. Le délai de traitement des paquets peut varier en raison d’une congestion du réseau, d’une mise en file d’attente inappropriée ou d’erreurs de configuration. La prise en charge du trafic en temps réel et interactif nécessite de contrôler et de limiter au maximum le délai et la gigue.

Caractéristiques du trafic

La voix et le trafic vidéo sont deux des principales raisons de la qualité de service. Le trafic vocal est fluide et bénin, mais il est sensible aux abandons et aux délais. La voix peut tolérer un certain degré de latence, de gigue et de perte sans effets notables. La latence ne doit pas dépasser 150 ms. la gigue ne doit pas dépasser 30 ms; la perte de paquets de voix ne doit pas dépasser 1%. Le trafic voix nécessite au moins 30 Kbps de bande passante. Le trafic vidéo est plus exigeant que le trafic vocal car la taille des paquets qu’il envoie sur le réseau est plus importante. Le trafic vidéo est en salve, consommateur de ressources, sensible aux abandons de paquets et aux délais. En l’absence de qualité de service (QoS) et d’une importante capacité de bande passante supplémentaire significative, on constate généralement la qualité de vidéo se dégrade. Les ports UDP, par exemple le port 554 sont utilisés pour le Real-Time Streaming Protocol (RSTP), doivent être prioritaires par rapport au trafic réseau moins soumis à des contraintes temporelles. Tout comme la voix, la vidéo peut tolérer un certain degré de latence, de gigue et de perte sans subir d’effets apparents. La latence ne doit pas dépasser 400 ms. la gigue ne doit pas dépasser 50 ms; la perte de paquets vidéo ne doit pas dépasser 1%. Le trafic vidéo nécessite au moins 384 Kbit/s de bande passante. Le trafic de données n’est pas aussi exigeant que le trafic vocal et vidéo. Les paquets de données utilisent souvent des applications TCP qui peuvent retransmettre des données et, par conséquent, ne sont pas sensibles aux abandons et aux délais. Bien que le trafic de données soit beaucoup moins sensible aux pertes de paquets et aux délais par rapport à la voix et à la vidéo, un administrateur réseau a quand même besoin d’assurer la qualité de l’expérience de l’utilisateur, parfois appelée «Qualité d’Expérience» (QoE). Les deux principaux facteurs qu’un administrateur de réseau doit demander concernant le flux du trafic de données sont de savoir si les données proviennent d’une application interactive et si les données sont critiques.

Algorithmes de mise en file d’attente

La regulation QoS que l’administrateur réseau a implémentée devient active en cas d’encombrement sur la liaison. La mise en file d’attente est un outil de gestion des congestions qui permet de stocker en mémoire tampon, de hiérarchiser et, si nécessaire, de réorganiser les paquets avant leur transmission à la destination. Ce cours se concentre sur les algorithmes de mise en file d’attente suivants: FIFO (First-In, First-Out), WFQ (Weighted Fair Queuing), CBWFQ (Class Weighted Fair Queuing) et LLQ (Low Latency Queuing). L’algorithme FIFO met en file d’attente les paquets et les transfère dans l’ordre de leur arrivée. L’algorithme FIFO n’a pas de concept de priorité ou de classe de trafic et de ce fait, ne prend pas de décision sur la priorité des paquets. Avec la méthode FIFO, le trafic important ou soumis à des contraintes temporelles peut être abandonné en cas de congestion sur l’interface du routeur ou du commutateur. WFQ est une méthode de programmation automatisée grâce à laquelle la bande passante est allouée au trafic réseau de façon équitable. Elle applique des priorités ou des pondérations au trafic identifié et le classe en conversations ou flux. WFQ permet de classer le trafic en différents flux selon l’adressage des en-têtes de paquets, notamment selon les caractéristiques telles que les adresses IP source et de destination, les adresses MAC, les numéros de port, le protocole, et la valeur du type de service (ToS). La valeur ToS de l’en-tête IP permet de classer le trafic. CBWFQ étend la fonctionnalité de mise en file d’attente pondérée (WFQ) standard afin de fournir la prise en charge des classes de trafic définies par l’utilisateur. Avec le CBWFQ, vous définissiez des classes de trafic en fonction de critères de correspondance incluant les protocoles, les listes de contrôle d’accès (ACL) et les interfaces d’entrée. Avec la fonctionnalité LLQ, la stratégie CBWFQ bénéficie d’une capacité de mise en file d’attente à priorité stricte (PQ). La priorité stricte permet aux paquets soumises à des contraintes temporelles, par exemple la voix, d’être envoyées avant les paquets présents dans d’autres files d’attente et réduire la gigue dans les conversations vocales.

Modèles de QoS

Il existe trois modèles d’implémentation de QoS: Remise au mieux (Best effort), les Services intégrés (IntServ) et les Services différenciés (DiffServ). Le modèle Remise au mieux est le plus évolutif mais ne garantit pas la livraison et ne donne aucun traitement préférentiel de paquets. Le modèle d’architecture IntServ a été développé pour répondre aux besoins des applications en temps réel, telles que la vidéo à distance, les conférences multimédia, les applications de visualisation de données et la réalité virtuelle. IntServ est un modèle multi-services et peut donc s’adapter aux nombreuses exigences possibles en termes de qualité de service. IntServ gère explicitement les ressources réseau, ce qui permet de garantir la qualité de service requise aux flux de paquets de certains utilisateurs, parfois appelés microflux. Il utilise les mécanismes de réservation des ressources et de contrôle des admissions comme éléments de base pour établir et maintenir la qualité de service. Le modèle de QOS DiffServ spécifie un mécanisme simple et évolutif pour la classification et la gestion du trafic réseau. La conception du modèle DiffServ s’affranchit des limites associées aux modèles de remise au mieux et des services intégrés. Le modèle DiffServ peut fournir une qualité de service «quasiment garantie» tout en restant rentable et évolutif. DiffServ divise le trafic réseau en classes selon les besoins de l’entreprise. Un niveau de service différent peut être ensuite affecté à chaque classe. Lorsque les paquets transitent sur un réseau, les différents périphériques réseau identifient la classe du paquet et lui appliquent un niveau de service spécifique à cette classe. Le modèle DiffServ propose un large choix de niveaux de service.

Techniques d’implémentation QoS

Il existe trois catégories d’outils de qualité de service : les outils de classification et de marquage, les outils de prévention des encombrements et les outils de gestion de l’encombrement. Avant de pouvoir appliquer une stratégie QoS à un paquet, ce dernier doit être classé. La classification et le marquage permettent d’identifier, ou «marquer», les types de paquets. La classification détermine la classe de trafic à laquelle les paquets ou les trames appartiennent. Les méthodes de classification des flux de trafic aux couches 2 et 3 comprennent l’utilisation d’interfaces, les listes de contrôle d’accès et les mappages de classes. Il peut également être classé au niveau des couches 4 à 7 à l’aide de la fonction NBAR (Network Based Application Recognition). Le type de service (IPv4) et la classe de trafic (IPv6) portent le marquage des paquets tel qu’attribué par les outils de classification QoS. Le champ est ensuite référencé par des périphériques de réception qui transmettent les paquets en fonction de la politique de qualité de service appropriée. Ces champs ont 6 bits alloués pour la qualité de service. Ces six bits s’appellent le champ DSCP (Differentiated Services Code Point) et proposent jusqu’à 64 classes de service. Le champ est ensuite référencé par des périphériques de réception qui transmettent les paquets en fonction de la politique de qualité de service appropriée. Les 64 valeurs DSCP sont réparties en trois catégories: Remise au mieux(BE), Expedited Forwarding (EF), Assured Forwarding (AF). Comme ils identifient la classe, les trois bits les plus pertinents du champ DSCP sont également appelés bits sélecteurs de classe (CS). Le classement et le marquage du trafic doivent s’effectuer le plus près possible, techniquement et administrativement, de la source. Cela permet de définir la limite de confiance. La gestion de la congestion repose sur des méthodes de mise en file d’attente et de planification, selon lesquelles le trafic excédentaire est mis en mémoire tampon ou en attente (et parfois abandonné) lorsqu’il attend d’être envoyé sur une interface de sortie. Les outils de prévention des encombrements permettent de surveiller les charges de trafic sur les réseaux afin d’anticiper et d’éviter les encombrements au niveau des congestions du réseau commun et de l’internet avant que les encombrements ne deviennent un problème. Cisco IOS inclut une solution de prévention de l’encombrement basée sur la détection anticipée aléatoire pondérée (WRED). WRED permet d’éviter l’encombrement des interfaces réseau en gérant les tampons et en autorisant la réduction ou la diminution du trafic TCP avant que ceux-ci soient remplis. La régulation et la limitation du trafic sont deux mécanismes proposés par la solution QoS de Cisco IOS pour éviter l’encombrement.