Présentation
En anglaisRÉSUMÉ
La différenciation des services et un enjeu de taille, car elle impose une architecture complète de mécanismes de réseau. Plusieurs groupes de travail de l’IETF se sont penchés sur ce problème. Cet article est essentiellement consacré au modèle DiffServ, aboutissement de ces réflexions et modèle simple, modulaire, dont la mise en œuvre peut s’effectuer d’une manière graduelle dans l’Internet existant. Après une présentation des briques élémentaires pouvant servir à la construction d’une telle architecture, il définit les caractéristiques et le fonctionnement du modèle DiffServ et de ses composants, ainsi qu’une description des services pouvant être offerts à l’aide de ce modèle.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleAuteur(s)
-
Octavio MEDINA : Ingénieur de recherche - GET/ENST Bretagne, département réseaux et services multimédias
-
Géraldine TEXIER : Maître de conférences - GET/ENST Bretagne, département réseaux et services multimédias
INTRODUCTION
L’Internet existant, fondé sur le principe du Best Effort (voir [H 2 285]), n’a pas été initialement conçu pour prendre en compte des informations de qualité de service (QoS). Le modèle Best Effort maximise l’utilisation de ressources tout en simplifiant l’opération des équipements d’interconnexion. Quand la mémoire d’un routeur est saturée, les paquets arrivants sont rejetés. Les mécanismes de retransmission de TCP (Transport Control Protocol) recouvrent ces pertes, garantissant un transfert sans faute de bout en bout. Simultanément, les algorithmes de « slow start » et de « congestion avoidance », implantés dans TCP, assurent une distribution de ressources relativement équitable .
Si le comportement de TCP répond aux besoins d’applications traditionnellement majoritaires dans le réseau comme telnet ou ftp , il est peu adapté pour la transmission des flux avec des contraintes temporelles. Les applications de visioconférence ou de voix sur IP (VoIP) sont pour la plupart basées sur le protocole UDP (User Datagram Protocol) . Ce protocole peut être utilisé pour obtenir un débit quasi constant, mais il n’implante pas de mécanisme de gestion de la congestion. La présence de flux non adaptatifs affecte la performance de TCP, pénalisant les applications basées sur ce protocole. Des mesures de contrôle sont nécessaires pour éviter la saturation du réseau par les flux non adaptatifs, en assurant qu’un minimum de ressources est disponible pour que les applications TCP puissent communiquer.
Les mécanismes de contrôle de TCP empêchent la gestion du partage des ressources. La quantité de ressources accordées à un flux dépend de la capacité des liens et de la présence d’autres flux dans le réseau. Des intérêts économiques poussent à la modification de ce comportement. Une distribution contrôlée de la bande passante permettrait aux opérateurs de définir de nouveaux services qui pourraient être facturés en conséquence. S’il devient possible dans l’Internet d’assurer le débit ou le délai observés, les opérateurs seront en position d’implanter une politique tarifaire conforme aux ressources accordées.
L’évolution d’Internet pour prendre en compte les besoins des nouveaux flux et pour contrôler la distribution de ressources se fait en modifiant, au niveau 3, les mécanismes de file d’attente dans les routeurs ou en se basant sur les propriétés offertes par le niveau 2 (priorités dans IEEE 802.1p, classes de services ATM - Asynchronous Transfer Mode) plutôt qu’en modifiant TCP. Les mécanismes de contrôle de flux de ce protocole sont très mal compris à grande échelle, les modèles analytiques ne sont pas assez précis et la simulation ne peut s’appliquer qu’à de petits réseaux. Comme le bon fonctionnement de l’Internet repose sur ces mécanismes, les modifications de TCP se font très lentement .
Afin d’avoir une vision claire sur la différenciation de services, cet article en montre dans une première partie les motivations ainsi que le cheminement suivi pour arriver aux solutions proposées aujourd’hui. Les mécanismes expliqués ensuite sont les briques de base nécessaires à la mise en œuvre de la différenciation dans les réseaux. L’une des tâches essentielles lors de la mise en place de la différenciation de services est de choisir les mécanismes appropriés et de les paramétrer de façon à ce que la composition de leurs actions accomplisse le traitement différencié des flux dans le réseau. Une dernière partie présente le modèle DiffServ défini à l’IETF (Internet Engineering Task Force) afin de mettre en œuvre la différenciation de services dans le réseau.
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Réseaux Télécommunications
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
2. Mécanismes élémentaires
Avant d’introduire le modèle à différenciation de services DiffServ, nous décrivons les briques de base qui peuvent servir à la construction d’une telle architecture. Les fonctions nécessaires à l’identification et à la caractérisation d’un flux sont analysées ainsi que les mécanismes d’ordonnancement et de gestion de la congestion. L’identification et la caractérisation d’un flux IP sont deux fonctions qui peuvent être utilisées pour déterminer le niveau de conformité du flux par rapport à son contrat de service. En revanche, la mise en place des mécanismes d’ordonnancement et de gestion de file d’attente peuvent servir à satisfaire les besoins de qualité de service que les flux réclament.
2.1 Identification d’un flux IP
Le protocole IP, orienté datagramme, ne comporte pas de notion de flux dans sa définition. Ce concept est néanmoins nécessaire à la mise en œuvre d’une architecture de différenciation de services. Les équipements intermédiaires du réseau doivent être capables d’identifier les paquets IP appartenant à un même « flux », afin de leur accorder le traitement dont ils ont besoin. Si l’un des principes du modèle DiffServ est l’agrégation, il existe toujours une première classification assez fine (qui peut avoir lieu directement dans la station émettrice) qui identifie les microflux IP avant qu’ils soient injectés dans le réseau.
Un microflux peut représenter une connexion TCP ou un stream UDP individuel. Au sens IP, un microflux est identifié par cinq champs dans l’en-tête . Tous les paquets portant des valeurs identiques sur ces champs appartiennent au même microflux IP. Les champs concernés sont :
-
adresse source IP ;
-
adresse destination IP ;
-
protocole de transport (TCP, UDP, autres) ;
-
port source (pour TCP ou UDP) ;
-
port destination.
Dans certaines situations, l’obtention du quintuple qui identifie un microflux...
Cet article fait partie de l’offre
Réseaux Télécommunications
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Mécanismes élémentaires
BIBLIOGRAPHIE
-
(1) - Congestion Avoidance and Control. - Proceedings of the ACM SIGCOMM’88, p. 314-329, août 1988.
-
(2) - ALLMAN (M.), PAXSON (V.), STEVENS (W.) - TCP Congestion Control. - Standards Track RFC 2581, avr. 1999.
-
(3) - BRADEN (R.), CLARK (D.), SHENKER (S.) - Integrated Services in the Internet Architecture : an Overview. - Informational RFC 1633, juin 1994.
-
(4) - * - TCPng BOF, San Jose IETF, déc. 1994. http://ftp.isi.edu/pub/braden/TCPng.BOF.Dec94.minutes.txt
-
(5) - SHENKER (S.), PARTRIDGE (C.), GUERIN (R.) - Specification of Guaranteed Quality of Service. - Standards Track RFC 2212, sept. 1997.
-
(6) - WROCLAWSKI (J.) - Specification of the Controlled-Load Network Element Service. - Standards Track RFC 2211, sept. 1997.
-
...
Cet article fait partie de l’offre
Réseaux Télécommunications
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive