Présentation
EnglishRÉ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
(141 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
4. Conclusion
La différenciation de services a longtemps constitué un défi intéressant car elle nécessite la définition d’une architecture complète de mécanismes de réseau. Le travail effectué à l’IETF a permis de construire deux approches ayant des philosophies différentes afin de donner un meilleur traitement à certains flux dans le réseau. La première approche, IntServ, est fondée sur le paradigme de la réservation de ressources dans les équipements du réseau. Cela implique qu’un contexte doit être conservé dans les routeurs pour chaque flux, pénalisant fortement le passage à l’échelle de ce protocole. Afin d’offrir un meilleur passage à l’échelle, en concentrant la complexité de la différenciation dans les équipements de bordure du réseau, l’IETF a défini une seconde approche : DiffServ. Dans le modèle DiffServ, le rôle des routeurs varie en fonction de leur placement dans le réseau. Les routeurs d’entrée sont chargés de l’identification et du conditionnement des flux. Le résultat de ces actions est inscrit en tant qu’étiquette dans l’en-tête de chaque paquet. Dans le cœur du réseau, cette étiquette est le seul paramètre utilisé pour déterminer le comportement des routeurs vis-à-vis des flux les traversant. La différenciation n’est plus assurée par la réservation de ressources mais par un bouquet de mécanismes gérant le traitement des flux dans chaque routeur. Le choix des mécanismes à installer dans le réseau se fait en fonction des comportements qui devront être offerts par l’équipement et par le réseau en général.
Bien que d’autres stratégies de différenciation telles que le Lower Effort aient été standardisées, l’architecture DiffServ définit deux types de comportement, le comportement expédié et le comportement assuré, qui offrent un traitement adapté en fonction de la sensibilité des flux au délai ou à la perte. La justification de l’utilisation de mécanismes de différenciation de services se heurte toujours aux oppositions des partisans de l’augmentation de capacité des réseaux. Cependant, il reste beaucoup de réseaux pour lesquels l’augmentation de bande passante pose des problèmes conséquents (par exemple, les réseaux d’accès ou les réseaux mobiles), les mécanismes de différenciation de services prennent alors toute leur importance....
Cet article fait partie de l’offre
Réseaux Télécommunications
(141 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
Conclusion
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
(141 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