La qualité de service sur IP

Améliorer les performances du réseau

Notre réseau est de plus en plus sollicité par de nouvelles applications aux besoins très divers : connexions Telnet pour se connecter à une machine Unix, transferts de fichiers, bases de données en mode client-serveur et, maintenant, flux audio et vidéo. La charge du réseau augmente, et les flux générés se perturbent mutuellement : quel utilisateur n’a pas expérimenté des temps de réponse très longs alors que son voisin a lancé le transfert d’un gros fichier ? Affecter des priorités sur les files d’attente Le moyen le plus rudimentaire d’améliorer la qualité du service rendu par votre réseau est de définir manuellement, et sur tous vos routeurs, des priorités. Cette approche consiste surtout à améliorer les performances du réseau en favorisant des applications au détriment d’autres. La qualité est améliorée mais non garantie. Le cas le plus couramment rencontré est celui d’une liaison WAN qui doit véhiculer des connexions Telnet (de type conversationnel) et des transferts de fichiers FTP. Les temps de réponse Telnet se dégradent dès qu’un transfert FTP est lancé. Aucune qualité de service n’étant gérée, la bande passante du réseau est, en effet, accaparée par celui qui en consomme le plus, cela bien sûr au détriment des autres. Afin d’éviter que les applications Telnet ne soient gênées par un transfert de fichiers, le moyen le plus simple est de définir des priorités sur la base des ports TCP qui identifient les applications (23 pour Telnet et 20 pour le canal de données FTP). Routeur 2 Telnet : utilise peu de débit mais nécessite des bons temps de réponse Routeur 1 LS 128 Kbit/s FTP : utilise le plus de débit possible et le transfert peut durer longtemps En classant les paquets Telnet en priorité haute, les paquets IP comportant le port TCP 23 seront placés dans la file d’attente à priorité haute, tandis que les paquets FTP seront stockés dans la file d’attente à priorité basse. Nos routeurs, qui sont de marque Cisco, gèrent ainsi quatre files d’attente correspondant à quatre priorités : haute, moyenne, normale et basse (high, medium, normal, low).  Il existe un jeu de files d’attente par interface réseau. La priorité doit donc être activée sur les interfaces série qui émettent les flux FTP perturbateurs. Étant donné que le transfert de fichiers peut avoir lieu dans les deux sens, la même configuration doit être appliquée aux deux routeurs : priority-list 1 protocol ip high tcp 23 priority-list 1 protocol ip low tcp 20 priority-list 1 protocol ip low tcp 21 int s 0 priority-group 1 En positionnant une priorité basse pour les flux FTP, les transferts de fichiers prendront plus de temps mais ne perturberont pas les sessions Telnet. Lorsque plusieurs paquets sont en file d’attente, le routeur enverra de préférence davantage de paquets Telnet que de paquets FTP. Afin d’offrir le même comportement sur l’ensemble du réseau, il faut configurer de manière identique tous les routeurs. De même, les interfaces Ethernet pourraient être traitées de manière identique si les réseaux locaux étaient chargés. En fonctionnement normal, le débit de 10 Mbit/s suffit, en effet, à absorber les flux FTP et Telnet. Ce n’est qu’en cas de charge que la perturbation se manifeste et que l’activation des priorités permet de conserver le même niveau de service que celui obtenu en fonctionnement non chargé. Il est intéressant de spécifier plus en détail un flux en utilisant une access-list : priority-list 1 protocol ip low list 10 access-list 10 permit 10.0.0.1 0.255.255.255 Par défaut, tous les autres paquets seront traités de la manière suivante : priority-list 1 default medium Il est également possible de contrôler indirectement le débit en définissant le nombre maximal de paquets pouvant être en attente : priority-list 1 queue-limit 20 40 60 80 Les quatre chiffres indiquent le nombre maximal de paquets pouvant être stockés dans les files d’attente haute, moyenne, normale et basse (les valeurs indiquées sont celles par défaut). Si la file d’attente est pleine, les paquets en excès sont rejetés, et un message ICMP source-quench est envoyé à l’émetteur pour lui indiquer de ralentir le flux. Cette stratégie a des limites, car elle est à double tranchant lorsque le flux de paquets est important : si la file d’attente est de trop grandes dimensions, les paquets s’accumulent, ce qui a pour conséquence d’augmenter le temps de réponse global. Si, en revanche, elle est de trop Telnet FTP , © Éditions Eyrolles Préparer son réseau au multimédia 290 petite taille, des paquets peuvent être perdus, notamment entre deux réseaux de débits différents (depuis un réseau Ethernet à 10 Mbit/s vers un lien série, par exemple) : le routeur rejette tout paquet entrant tant que ses files d’attente sont saturées. Dans notre exemple, en abaissant ainsi à 60 le nombre de paquets dans la file d’attente basse, le débit maximal du flux FTP sera encore abaissé

Gérer la qualité de service

À la base, un réseau IP tel que l’Internet ne garantit pas que tous les paquets émis seront délivrés au destinataire. Il assure simplement que les paquets effectivement remis le seront sans erreur ni duplication en routant les paquets au mieux de ses possibilités (principe du best effort). C’est également le principe de la poste qui s’efforce d’acheminer le courrier dans les meilleurs délais. Mais, pour s’assurer qu’un colis arrivera à destination en temps et en heure, il faut payer un service supplémentaire. De même, pour les réseaux, il faut mettre en œuvre des moyens supplémentaires afin de garantir ce niveau de service. Alors que les flux de données classiques (Telnet, FTP, etc.) se contentent du service de base (celui du meilleur effort), le transport des flux audio et vidéo nécessite plus que cela. Il faut en effet garantir : • qu’une application disposera du minimum de débit réseau nécessaire à son bon fonctionnement ; • un temps de réponse ; • que le temps de réponse variera peu dans le temps. Afin de gérer la qualité de service nécessaire au traitement des flux multimédias, deux modèles sont actuellement proposés : • La différenciation de service (modèle appelé DiffServ) repose sur l’affectation de priorités et de classes de service dont les valeurs sont transportées dans les paquets IP. Le flux est formaté (classé) à l’entrée du réseau, puis la qualité de service est appliquée de la même manière dans tous les routeurs en fonction de la valeur indiquée dans les paquets. • L’intégration de service (modèle appelé IntServ) consiste à réserver les ressources tout le long du chemin qu’emprunteront les paquets, puis à appliquer à tout le flot de paquets qui suivent la qualité de service demandée lors de la réservation. La qualité de service selon DiffServ Le modèle DiffServ est une norme en cours de spécification qui ne précise pas encore les classes de service. C’est pour cela que les implémentations actuelles ne traitent que de la priorité (champ IP Precedence). Le champ TOS Dès l’origine, les concepteurs des protocoles TCP/IP ont pensé à intégrer la notion de qualité de service dans un champ du paquet IP, appelé TOS (Type of Service). Ce champ était destiné à transporter des informations relatives à la priorité et à la classe de service, mais il n’a jamais été réellement utilisé, jusqu’à ce que la qualité de service soit d’actualité. Mais, entre temps, les besoins ont évolué, et différents groupes de travail au sein de l’IETF ont proposé de modifier la signification de ce champ.  Les algorithmes WFQ et WRED prennent en compte le champ Precedence (d’où le “ W ” pour Weighted). L’activation de ces files d’attente est donc particulièrement judicieuse au sein du réseau, car elles permettent de réguler le flux en fonction des priorités fixées à l’entrée de celui-ci. L’exemple suivant, qui montre quelques valeurs par défaut, permet d’expliquer comment WRED interagit avec les priorités : random-detect precedence 0 109 218 10 random-detect precedence 1 122 218 10 … random-detect precedence 7 194 218 10 LE CHAMP TOS (RFC 791 ET 1349) Le champ TOS (Type of Service) consiste en un unique octet : IP precedence TOS 3 bits 4 bits 0 Le champ IP precedence (bits 0 à 2) détermine une priorité allant de 0 à 7 : 0 = Routine 1 = Priority 2 = Immediate 3 = Flash 4 = Flash override 5 = Critical 6 = Internetwork control 7 = Network control Les bits TOS (la RFC utilise malencontreusement le même terme TOS pour l’octet entier ainsi que pour ces 4 bits) indiquent la classe de service souhaitée : Bit Description Signification des valeurs 3 minimize Delay (0 = Normal delay ; 1 = Low Delay) 4 maximize Throughput (0 = Normal throughput ; 1 = High throughput) 5 maximize Reliability (0 = Normal reliability ; 1 = Reliability) 6 minimize monetary cost (ajouté par la RFC 1349) Ces 4 bits positionnés à 0 indiquent tout simplement le service normal (le best effort). Le dernier bit est réservé à un usage futur. © Éditions Eyrolles Préparer son réseau au multimédia 296 La première valeur (de 0 à 7) correspond à la priorité indiquée dans le champ Precedence. Les trois paramètres suivants indiquent quant à eux : • le seuil minimal, en nombre de paquets dans la file d’attente, à partir duquel les paquets commenceront à être rejetés ; • le seuil maximal, en nombre de paquets dans la file d’attente, à partir duquel les paquets seront rejetés au rythme indiqué dans le paramètre suivant ; • la fraction de paquets rejetés lorsque le seuil maximal est atteint, par défaut un sur dix. Afin de favoriser les paquets prioritaires, le seuil minimal est d’autant plus élevé que la priorité est grande. L’algorithme WRED calcule la taille moyenne de la file d’attente et la compare aux seuils. Le seuil maximal est déterminé automatiquement en fonction du débit de l’interface et de la mémoire disponible, tandis que le seuil minimal correspond à une fraction du seuil maximal dépendant de la priorité (par exemple, 1/2 pour 0, 10/18 pour 1, 11/18 pour 2, etc.). Les commandes “ sh queueing ” et “ sh int random-detect ” permettent de visualiser les paramètres actifs. Configuration des routeurs Les routeurs sont de nos jours destinés à opérer sur le réseau WAN et donc à être enfouis au sein du réseau. En vertu de cette conception, seule la fonction de policing du modèle DiffServ est implémentée sur nos routeurs, les autres fonctions opérant en entrée. À la différence du Trafic shaping qui régule un flux erratique, le policing veille au respect du flux selon le profil de flux qui lui est indiqué. Il peut alors rejeter les paquets non conformes ou les marquer pour une régulation ultérieure sur d’autres équipements au sein du réseau : int e0 rate-limit output 5000000 32000 45000 conform-action transmit exceedaction drop Le mot clé “ output ” indique que la classification du flux est appliquée en sortie de l’interface : • le premier paramètre indique le débit moyen autorisé, ici 5 Mbit/s ; • le deuxième précise la taille du burst, ici 32 Ko ; • la troisième valeur est le burst en excès, ici 45 Ko. Si le flux est conforme à ce profil (conform-action), le paquet est placé dans la file d’attente tel quel. Dans le cas contraire (exceed-action), il est rejeté.