Actuellement, Internet ne permet pas d’offrir une qualité de service constante, ni de donner la priorité à certains types de trafic. Il faudra attendre pour cela l’éventuelle adoption IPv6. Il faut donc ajouter de nouvelles couches destinées à réguler les flux et assurer ainsi une qualité de service satisfaisante. RSVP (Resource Reservation Protocol) fait partie de ces couches, intervenant sur la couche applicative (niveau 7) du modèle OSI. Conçu par des chercheurs de l’université de Californie, de l’Information Sciences Institute et du PARC de Xerox, RSVP est un protocole de contrôle du réseau qui gère les niveaux de priorité en fonction des applications émettrices des flux de données. En général, et particulièrement en ce qui concerne RSVP, la qualité de service est assurée par l’utilisation de techniques de réservation de ressources. Réserver des ressources pour un trafic déterminé implique d’anticiper le comportement du réseau. Il est donc nécessaire de définir les critères de mesure normalisés afin de retenir le meilleur chemin et de s’assurer que les demandes sont bien respectées. RSVP assure, en partie, chacune de ces tâches. Schématiquement, pour assurer la qualité de service, RSVP se charge à la fois de trouver le meilleur chemin pour acheminer des données, et de dialoguer avec les équipements présents sur ce chemin pour leur demander de lui allouer une taille donnée de la fenêtre TCP.
Dans les faits, comme c’est le cas lors de l’établissement d’un circuit virtuel, RSVP établit et maintient un état logique entre les n?”uds du réseau (les routeurs) constituant le chemin réservé. Pour ce faire, il commande l’envoi de messages périodiques de rafraîchissement le long du chemin. RSVP dispose en plus de fonctions de qualité de service dynamiques et tient compte des modifications de ressources émanant du destinataire ou de l’émetteur, ou encore à la suite de l’introduction de nouveaux membres dans le cas d’un groupe multicast. Pour l’établissement du chemin, l’émetteur envoie ses exigences au destinataire. Cette émission (flow specification) est effectuée par l’intermédiaire d’une trame contenant les différentes instructions qui seront communiquées à la pile RSVP des routeurs et des commutateurs. Après réception, le destinataire RSVP utilise le même chemin pour renvoyer un message spécifiant la qualité de service souhaitée. Il fixe ainsi la réservation des ressources correspondantes dans chaque n?”ud traversé. Mais les ressources nécessaires au fonctionnement de RSVP sur les routeurs augmentent avec le nombre de réservations et influent sur leurs performances.
Déployer RSVP à grande échelle
Les performances de transmission sont aussi affectées par les mécanismes fournissant les classes différenciées de services. Ceci explique les réticences des organisations administrant les grands réseaux face au déploiement de RSVP, mais aussi les recherches effectuées sur ce protocole. Beaucoup de ces travaux concernent en effet le déploiement de RSVP à grande échelle. L’IETF a fait une proposition (RFC2208 : RSVP Version 1 Applicability Statement, Some Guidelines on Deployment) qui réduirait les effets négatifs de l’implémentation de RSVP en regroupant les flux de données semblables.
Mais RSVP pose un autre problème. Il ne définit pas la politique de qualité de service elle-même (les ordres de priorité entre applications), et ne se charge que de sa mise en fonction. De nombreux constructeurs se sont alors empressés de fournir des mécanismes propriétaires pour pallier ce manque. En réponse, un nouveau groupe de travail RAP de l’IETF a été créé fin 1997 pour définir des extensions à RSVP relatives aux politiques de contrôle et spécifier un protocole d’échange entre des n?”uds RSVP et des policy servers capables de fournir les informations relatives aux politiques de qualité de service. Tous ces éléments étant loin d’être finalisés, RSVP reste cantonné à la gestion de la qualité de service des réseaux locaux.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
