Services intégrés

Dans les réseaux informatiques , l'intégration de services ou IntServ est une architecture qui spécifie les éléments permettant de garantir la qualité de service (QoS) sur les réseaux. IntServ peut par exemple être utilisé pour permettre à la vidéo et au son d'atteindre le récepteur sans interruption.

IntServ spécifie un système QoS à granularité fine , qui est souvent contrasté avec le système de contrôle à granularité grossière de DiffServ .

Dans le cadre d'IntServ, chaque routeur du système implémente IntServ et chaque application qui nécessite une sorte de garantie de qualité de service doit effectuer une réservation individuelle. Les spécifications de flux décrivent à quoi sert la réservation, tandis que RSVP est le mécanisme sous-jacent pour la signaler sur le réseau.

Une spécification de flux comprend deux parties :

• À quoi ressemble le trafic ? Cela se fait dans la partie Spécification du trafic, également appelée TSPEC.
• Quelles garanties faut-il ? Cela se fait dans la partie Demande de SPECIFICATION du service, également appelée RSPEC.

Les TSPEC incluent des paramètres d'algorithme de seau de jetons . L'idée est qu'il existe un seau de jetons qui se remplit lentement de jetons, arrivant à un rythme constant. Chaque paquet envoyé nécessite un jeton, et s'il n'y a pas de jeton, il ne peut pas être envoyé. Ainsi, le rythme auquel les jetons arrivent dicte le débit moyen du flux de trafic, tandis que la profondeur du seau dicte le degré de « rafale » autorisé pour le trafic.

Les TSPEC spécifient généralement simplement le taux de jeton et la profondeur du bucket. Par exemple, une vidéo avec un taux de rafraîchissement de 75 images par seconde, chaque image prenant 10 paquets, peut spécifier un taux de jeton de 750 Hz et une profondeur de bucket de seulement 10. La profondeur du bucket serait suffisante pour prendre en charge la « rafale » associée à l'envoi d'une image entière en une seule fois. D'un autre côté, une conversation nécessiterait un taux de jeton inférieur, mais une profondeur de bucket beaucoup plus élevée. En effet, il y a souvent des pauses dans les conversations, de sorte qu'elles peuvent se contenter de moins de jetons en n'envoyant pas les intervalles entre les mots et les phrases. Cependant, cela signifie que la profondeur du bucket doit être augmentée pour compenser le trafic plus sporadique.

Les RSPEC précisent les exigences relatives au flux : il peut s'agir d'un « meilleur effort » Internet normal, auquel cas aucune réservation n'est nécessaire. Ce paramètre est susceptible d'être utilisé pour les pages Web, le FTP et les applications similaires. Le paramètre « Charge contrôlée » reflète les performances d'un réseau peu chargé : il peut y avoir des problèmes occasionnels lorsque deux personnes accèdent à la même ressource par hasard, mais en général, le délai et le taux d'abandon sont assez constants au taux souhaité. Ce paramètre est susceptible d'être utilisé par les applications à QoS souple. Le paramètre « Garanti » donne un service absolument limité, où le délai est promis de ne jamais dépasser une valeur souhaitée et les paquets ne sont jamais abandonnés, à condition que le trafic reste dans les limites des spécifications.

Le protocole de réservation de ressources (RSVP) est décrit dans la RFC 2205. Toutes les machines du réseau capables d'envoyer des données QoS envoient un message PATH toutes les 30 secondes, qui se propage sur les réseaux. Ceux qui veulent les écouter envoient un message RESV (abréviation de "Reserve") correspondant qui trace ensuite le chemin jusqu'à l'expéditeur. Le message RESV contient les spécifications de flux.

Les routeurs entre l'expéditeur et l'auditeur doivent décider s'ils peuvent prendre en charge la réservation demandée et, s'ils ne le peuvent pas, ils envoient un message de rejet pour en informer l'auditeur. Sinon, une fois qu'ils ont accepté la réservation, ils doivent acheminer le trafic.

Les routeurs stockent ensuite la nature du flux et le surveillent. Tout cela se fait dans un état souple , donc si rien n'est entendu pendant un certain temps, le lecteur expire et la réservation est annulée. Cela résout le problème si l'expéditeur ou le récepteur tombe en panne ou est arrêté de manière incorrecte sans avoir au préalable annulé la réservation. Les routeurs individuels peuvent, à leur choix, surveiller le trafic pour vérifier qu'il est conforme aux spécifications du flux.

Pour que IntServ fonctionne, tous les routeurs le long du chemin de trafic doivent le prendre en charge. De plus, de nombreux états doivent être stockés dans chaque routeur. Par conséquent, IntServ fonctionne à petite échelle, mais à mesure que le système évolue vers des réseaux plus grands ou vers Internet , il devient gourmand en ressources pour suivre toutes les réservations.

Une façon de résoudre le problème d'évolutivité consiste à utiliser une approche à plusieurs niveaux, où la réservation de ressources par microflux (comme la réservation de ressources pour des utilisateurs individuels) est effectuée dans le réseau périphérique, tandis que dans le réseau central, les ressources sont réservées aux flux agrégés uniquement. Les routeurs qui se situent entre ces différents niveaux doivent ajuster la quantité de bande passante agrégée réservée au réseau central afin que les demandes de réservation pour les flux individuels du réseau périphérique puissent être mieux satisfaites.