Ce nouveau billet est consacré à la qualité de service sur les réseaux IP. En effet, je vais tenter ici de vulgariser un peu les concepts mis en oeuvre dans de la qualité de service afin de les rendre les plus limpides et compréhensibles possibles. Ce billet est, a priori, le premier d’une série consacrée à la QoS et ses fondements.

Tout d’abord, qu’est-ce que la QoS ? Son but est de fournir un système de priorisation des flux réseaux en cas de montée en charge réseau des équipements concernés, fournissant ainsi une bande passante adéquate pour certains paquets ainsi que des paramètres de latence et de gigue bien contrôlés. En temps normal, lorsqu’un lien réseau est surchargé, tous les flux arrivant en entrée sur l’équipement sont rejetés, sans distinction aucune. Un des concepts de la QoS est donc de catégoriser les différents flux concernés, en modifiant le comportement de l’équipement pour que les paquets rejetés ne soient pas ceux considérés critiques par l’administrateur réseau. Cependant, l’exercice peut s’avérer relativement compliqué, en fonction du nombre de types de flux à traiter et de la bande passante totale à répartir. Il est donc important d’en poser les jalons et d’établir des gabarits qui devront être implémentés sur des parties bien identifiées du réseau.

Il est relativement commun de lire ou d’entendre qu’il existe trois fondamentaux sur la QoS :

• Les méthodes d’identification et de marquage des paquets IP
• La gestion des congestions au niveau des équipements
• La gestion de la politique de QoS de bout en bout

Dans notre introduction, nous évoquions le fait que les flux doivent être « catégorisés » pour être traités comme nous le souhaitons. Pour cela, il est donc possible de réaliser une identification du flux en question, via des Access Lists par exemple pour les matériels Cisco, ou via le marquage des paquets. La première solution sera essentiellement appliquée dans le cas où la politique de QoS à appliquer est spécifique à un équipement et donc indépendante du reste du réseau. En outre, la deuxième solution sera préférable dans le cadre de l’application d’une politique de QoS étendue à l’ensemble du réseau.

Comment réagit un équipement réseau lorsqu’un de ces liens physique est saturé ? En temps normal, les équipements possèdent tous un buffer (une file d’attente) dans lequel ils entassent les paquets qui arrivent au fur et à mesure, jusqu’à saturation de ce buffer et rejet des paquets suivants. La QoS interne à l’équipement va permettre de créer plusieurs files d’attente et d’utiliser des algorithmes bien précis qui permettent de vider certaines files plus rapidement que d’autres (en règle générale, les flux les plus critiques). Parmi les algorithmes de gestion des files d’attente, on note principalement :

• Priority Queuing (PQ)
• First In First Out (FIFO)
• Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ)
• Class-based Weighted Faire Queuing (CBWFQ)
• Stochastic Fairness Queuing (SFQ)

L’objectif de ce billet n’est pas de faire le détail de ces différents algorithmes, sur lesquels nous reviendrons dans un billet ultérieur.

La mise en place de files d’attentes au niveau des équipements ne permet pas de résoudre le problème de saturation de celles-ci. Lorsque cela se produit, tous les nouveaux paquets qui arrivent sont systématiquement rejetés. Il existe donc des mécanismes qui permettent d’indiquer à l’équipement quels paquets rejeter en fonction des priorités affectés. Bien entendu, les paquets étant identifiés comme moins prioritaires auront plus tendance à être rejetés qu’un paquet marqué prioritaire.

Parmi ces mécanismes on distingue principalement :

• Random Early Detection (RED)
• Weighted Random Early Detection (WRED)

Au delà du traitement interne effectué par les équipements, il est intéressant de se pencher sur l’utilisation des liens réseaux et la gestion de la bande passante pour les différents types de flux afin d’anticiper les cas de congestion et de préparer le trafic. Il existe principalement deux types de comportements :

• Le « Traffic Shaping » : le concept est relativement simple. L’administrateur définit une bande passante maximale pour un flux donné. Lorsque le débit du flux concerné vient à dépasser ce seuil, les paquets sont mis en files d’attente et leur transmission retardée.
• Le « Traffic Policing » : cette approche est similaire au shaping, excepté le fait que les paquets arrivant une fois que le seuil de bande passante réservée est dépassé sont rejetés.

L’ensemble des concepts présentés précédemment forme donc un préambule à la QoS et à son implémentation sur un réseau IP. En règle générale, on évoque principalement deux approches de gestion de la QoS, qui mettent en oeuvre certains ou tous les concepts évoqués précédemment :

• DiffServ : Consiste à affecter les priorités au niveau d’un champ de l’entête IP appelé DSCP (cette partie sera détaillée dans un billet ultérieur). L’identification et le marquage du paquet est donc fait en entrée de réseau et les noeuds intermédiaires ou de coeur du réseau se contente d’appliquer les politiques de gestion du flux en fonction de cette valeur.
• IntServ : Consiste à réserver les ressources nécessaires au niveau de tous les noeuds du réseau avant de faire transiter les flux. Cette approche repose sur l’utilisation du protocole RSVP (ReSource reserVation Protocol) qui induit alors une couche de contrôle d’admission supplémentaire pour s’assurer que la bande passante requise est bien disponible à un instant T.

La granularité offerte par l’approche IntServ est beaucoup plus fine que celle offerte par DiffServ, dans la mesure où elle est réalisée au niveau de chaque flux, contrairement à DiffServ qui constitue des agrégats de flots applicatifs. En revanche, l’approche DiffServ permet un déploiement et une exploitation simplifiée car elle déporte la complexité de gestion de la QoS sur les équipements de périphérie, ainsi que des performances meilleures pour un réseau à grande échelle (Dans IntServ, les routeurs doivent maintenir des tables pour mémoriser l’état de chaque flux et des allocations de ressources).

 Dans les billets futurs, nous détaillerons les approches DiffServ et IntServ, ainsi que la gestion de la QoS au niveau 2 dans un environnement switching.

Enfin, je souhaite rappeler que cet article, comme tous les autres, n’est pas forcémment d’une science exacte, et toute modification ou critique de celui-ci sera la bienvenue !