FLASH INFORMATIQUE FI



La gestion de la qualité de service dans les réseaux d’entreprise




Stefano Ventura

Stephan Robert


Introduction

A l’heure actuelle, Internet a largement dépassé le stade de la nouveauté. Bon nombre d’applications liées aux services de la téléphonie fonctionnent dans ce contexte, comme par exemple Netmeeting, NetToPhone, Voix sur IP (VoIP), qui sont relativement bien connues du grand public. Leur réalisation n’a rien d’extraordinaire mais la qualité n’est hélas pas toujours au rendez-vous, car le réseau Internet n’offre pas encore des garanties suffisantes en termes de retards et de débits de façon généralisée. Dans la mesure où les opérateurs seraient appelés à n’employer plus que de la téléphonie sur IP par exemple, il faudrait que ce service fonctionne en tous cas aussi bien que la téléphonie traditionnelle. Il s’agirait alors de pouvoir effectuer un appel d’une qualité qui ne dépende pas de la charge du réseau. La notion de qualité de service (QoS) prend toute son ampleur lorsqu’il y a un partage des ressources. Il est bien entendu clair que le préjudice causé par les baisses de performances du réseau n’affecte pas toutes les applications de la même façon. Un fichier qui met une minute de plus pour être chargé n’a pas la même conséquence qu’une interruption de 60 secondes au milieu d’une conversation téléphonique. Pour résoudre le problème posé par le partage des ressources, plusieurs techniques sont proposées, que nous allons examiner dans la section suivante.

Schémas de QoS disponibles actuellement

Les mécanismes les plus connus définis par IETF (Internet Engineering Task Force) sont les Services Différenciés (DiffServ) [1] et les Services Intégrés (IntServ) [2]. Le modèle DiffServ consiste à introduire plusieurs classes de service offrant chacune une qualité de service différente. Chaque flux de trafic se voit attribuer une classe de service appropriée. Cette classification de trafic est effectuée en périphérie du réseau, directement à la source ou sur un routeur d’accès, selon des critères préconfigurés (adresses IP ou ports TCP/UDP). Chaque paquet est marqué avec un code qui indique la classe de trafic assignée. Les routeurs dans le coeur du réseau (backbone) utilisent ce code, transporté dans un champ du datagramme IP, pour déterminer la qualité de service requise par le paquet. Tous les paquets ayant le même code reçoivent ainsi le même traitement. Les critères de classification des paquets doivent refléter les besoins réels de l’information qu’ils transportent en termes de largeur de bande, sensibilité aux pertes de paquets, sensibilité aux délais et aux variations de délai (gigue). Par exemple, laVoIP, qui justifie à elle seule l’introduction de la QoS, est sensible aux délais ainsi qu’aux variations de délai, beaucoup plus qu’à la perte de paquets. IntServ est un modèle d’architecture qui propose de réserver des ressources dans les noeuds intermédiaires avant de commencer à les utiliser. Contrairement au modèle DiffServ, chaque application est libre de demander une qualité de service spécifique à ses besoins. Les routeurs le long du chemin de transmission vérifient s’ils peuvent accorder cette qualité de service ou non, et acceptent ou refusent en conséquence la réservation de l’application. Si la réservation est acceptée, l’application est alors assurée d’obtenir des garanties pour le transfert des données, selon ce qui a été négocié lors de la réservation. Le principal défaut du modèle IntServ est que tous les routeurs, même les routeurs au coeur du réseau travaillant à haut débit, doivent inspecter plusieurs champs de chaque paquet afin de déterminer la réservation associée à ce dernier. Après la classification, chaque paquet est placé dans la file d’attente qui correspond à la réservation. La classification et la gestion de files d’attentes pour chaque flux individuel empêchent l’utilisation du modèle IntServ dans les réseau à haut débit. De plus il suffit qu’un seul routeur sur le chemin de transmission n’offre pas le service d’IntServ pour que le service IntServ soit mis à mal.

Pour mettre en oeuvre la QoS il s’agit de contrôler la totalité du trajet emprunté par les données, y compris les équipements en bout de ligne, qui sont en général constitués de réseaux locaux. A ce niveau l’alternative la plus souvent utilisée consiste à surdimensionner les réseaux. La plupart des réseaux locaux Ethernet fonctionnent actuellement à 100 Mb/s. Néanmoins il existe des mécanismes permettant de contrôler le trafic au niveau de la couche 2 du modèle OSI : Subnet Bandwidth Manager (SBM) qui est une extension de l’architecture IntServ-RSVP. SBM est un protocole de signalisation, basé sur le contrôle d’admission de RSVP, pour les réseaux de type IEEE 802 et qui permet la gestion de la largeur de bande. Il fait le lien entre la couche 2 et la couche 3 du modèle OSI et comble ainsi le vide entre le routeur et l’utilisateur.

Gestion de la QoS

Les principes énoncés dans le paragraphe précédent sont généraux. La QoS se réfère à la classification des paquets dans le but de traiter différemment certaines classes ou flots de paquets par rapport à d’autres. Idéalement la QoS va rendre le service d’acheminement de paquets déterministe, contrairement à ce qui se passe normalement sur Internet avec le service best effort. Puisque les services sont différenciés, il est admis que ceux qui bénéficient de la meilleure qualité de service devront payer plus que ceux qui devront se contenter de la moindre qualité. Nous pouvons par exemple penser à une entreprise qui a besoin d’assurer un service de qualité à large bande et dont le temps est une denrée précieuse par rapport à des teenagers qui consomment une grande largeur de bande pour télécharger des fichiers MP3, DivX,... Il serait raisonnable de traiter différemment ces deux types d’utilisateurs, en leur offrant des qualités différentes mais aussi en les faisant payer différemment le service. Il y a donc un besoin de vérifier l’identité de l’utilisateur et d’identifier le trafic transporté sur le réseau à partir des paquets échangés. L’introduction de règles est insuffisante si elles ne peuvent pas être contrôlées et si leur violation ne peut pas être sanctionnée. Donc il faut introduire un système consistant qui permette de satisfaire les contraintes fixées. La politique des règles mises sur pied correspond à un contrat (SLA : Service Level Agreement) passé entre le fournisseur qui gère le réseau et le client. Les termes de ce contrat sont très génériques et de haut niveau. Néanmoins les règles à appliquer pour satisfaire le client doivent être vérifiables et ne pas comporter d’ambiguïté. A chaque règle doit correspondre une série d’actions.

Le groupe de travail de l’IETF [3,4,5] qui défini un protocole d’allocation de ressources a commencé son activité dans le cadre des Services Intégrés mais il a été vite reconnu que les résultats étaient aussi applicables aux Services Différenciés. Le modèle est très simple ; il nécessite deux composants distincts : un PEP (Policy Enforcement Point) et un PDP (Policy Decision Point). Le PEP contrôle et le PDP prend des décisions basées sur la politique des règles qui a été définie. Les échanges entre PEP et PDP sont effectués à l’aide de COPS (Common Open Policy Service Protocol) [6]. Un schéma de fonctionnement est représenté à la figure 1.

 

fig.1 - Eléments fonctionnels pour assurer le maintien d’une qualité de service dans le réseau. Ces éléments sont définis de manière logique et ne se restreignent pas à une implémentation particulière

 

La séparation entre le PEP et le PDP est surtout fonctionnelle. Les deux entités peuvent être localisées au même endroit. La spécification décrit un composant du PEP qui est appelé LPDP (Local PDP) qui est capable de prendre certaines décisions localement. Néanmoins, pour éviter des brèches dans la sécurité du mécanisme il est requis du PEP de s’en référer toujours au PDP quant aux décisions finales. Beaucoup, au sein du groupe de travail, pensent que LDAP (Lightweight Directory Access Protocol) n’a pas les caractéristiques nécessaires pour maintenir la consistance dans un grand réseau dynamique. D’autres systèmes utilisent des bases de données à cause de leurs capacités à faire des transactions, entre autres. Dans un réseau où la QoS est gérée, il est très probable que la densité des PEP soit bien plus élevée que la densité des PDP, ce qui est compréhensible au vu de leurs fonctions respectives.

Ce modèle générique de contrôle de réseau permet de réaliser deux fonctions de contrôle distincts : l’outsourcing et le provisioning.

La fonctionnalité de l’outsourcing est surtout utilisée en relation avec le modèle IntServ. Nous avons déjà vu qu’une application doit explicitement réserver des ressources avant de commencer la transmission et que tous les routeurs concernés doivent accepter ou refuser la réservation. Souvent, cette décision nécessite des informations autres que les ressources disponibles localement sur le routeur. Il faudrait par exemple vérifier si cette source de trafic a le droit d’effecteur une réservation ou quelle quantité maximale de ressources elle peut occuper. Pour faciliter la gestion, il est judicieux de centraliser ces informations, d’où l’intérêt de l’utilisation d’un contrôleur central. Dans ce modèle, un routeur devant prendre une décision sur l’admission d’une réservation envoie une requête au PDP et celui-ci renvoie la décision prise à partir des règles des politiques.

La fonctionnalité de provisioning est orientée sur les réseaux DiffServ. La principale faiblesse du modèle DiffServ est que la configuration des classes de qualité de service est statique. Les routeurs d’accès doivent être configurés pour assigner une classe à chaque type d’application, donc pour marquer tous les paquets entrant avec un code. Pour chaque classe, il est nécessaire de configurer les ressources utilisées (largeur de bande par exemple). Cependant, le trafic dans un réseau change périodiquement et d’une manière imprévisible. Dans un réseau avec le service VoIP, il faudra normalement réserver des ressources pour la classe DiffServ transportant ce service. Or, pendant la nuit, il y aura peu de trafic voix sur IP mais peut-être des flux des données importants lors de la sauvegarde des serveurs. Un tel réseau travaille donc dans deux régimes et nécessite une modification périodique de la configuration des routeurs. Clairement, ceci n’est possible qu’avec un processus automatisé. En utilisant le modèle de gestion de qualité de service, un administrateur de réseau peut définir deux types de politiques, appropriées pour les deux régimes de trafic et les stocker sur le contrôleur central (PDP). Quand une modification de la configuration des routeurs est nécessaire, le PDP communique à travers le protocole COPS avec les routeurs et leur transmet la nouvelle configuration.

Conclusion

L’évolution des méthodes de gestion de la QoS des réseaux de données montre une tendance à centraliser l’intelligence en certains points, même dans un contexte de réseaux très largement décentralisés. En même temps, la complexité du traitement de l’information augmente dans les routeurs qui implantent de tels mécanismes. C’est certainement le prix à payer pour une administration centralisée du contrôle de l’usage des ressources. Néanmoins, ces nouvelles méthodes aident à la gestion des réseaux et des applications de manière indépendante, assez facile, et offrent une large palette de fonctions de support pour l’administration de réseaux. COPS est sûrement en train d’ouvrir la voie à des méthodes plus performantes qui, idéalement, devraient être complètement distribuées, intelligentes, et auto-réguler les réseaux d’aujourd’hui et de demain.

Références

 [1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Wang, An Architecture for Differenciated Services, RFC 2475, Décembre 1998.
 [2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification, RFC 2205, Septembre 1997.
 [3] R. Yavatkar, D. Pendarakis, R. Guérin, A Framework for Policy-based Admission Control, Avril 1999, work in progress.
 [4] F. Reichmeyer, K. H. Chan, D. Durham, R. Yavatkar, S. Gai, K. McCloghie, S. Herzog, A. Smith, COPS Usage for Policy Provisioning, Février 1999, work in progress.
 [5] J. Strassner, E. Ellesson, Terminology for describing network policy and services, Février 1999, work in progress.
 [6] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, The COPS (Common Open Policy Service Protocol), Août 1999, work in progress.

Pour en savoir plus, rendez-vous au forum sur les réseaux d’entreprise du 18 juin, voir http://dit-archives.epfl.ch/FI03/fi-5-3/forum_030618.pdf.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.