DOSSIER a ommutation et adressage : typologie des flux et perpectives Mots-clés : Trafic multiservice, Qualité de service, ATM, Internet d'acheminement parj.w. ROBERTS, France Télécom, CNETIDACIOAT Lors de la définition d'un réseau multiservice, il convient de définir la nature de différents types de trafic à mettre en oeuvre et de choisir les bonnes solutions. INTRODUCTION Du fait que l'utilisation d'internet se développe et se diversifie à un rythme exceptionnellement rapide, le problème d'offrir des niveaux de qualité de service diversifiés, requis par un nombre croissant de types de service, devient de plus en plus important. Le RNIS large bande est une plate-forme possible pour constituer un réseau multiservice capable d'offrir une gamme diversifiée de garanties de qualité de service, bien qu'il reste encore beaucoup d'incertitude en ce qui concerne la manière dont les utilisateurs et les opérateurs de réseau pourraient tirer parti de manière optimale des classes de service normalisées de l'atm. Le terme " qualité de service " désigne l'ensemble des exigences de performances du réseau qui doivent être satisfaites conjointement par la définition d'un modèle de service approprié et par l'ingénierie du trafic. Nous classons les exigences de qualité de service selon qu'elles s'adressent à la transparence (intégrité temporelle ou sémantique), au temps de réponse (ou, de manière équivalente, au débit moyen réalisé par un flux) ou à l'accessibilité (disponibilité de ressources de réseau appropriées pour satisfaire en temps réel la demande). Le modèle de service, en définissant certaines classes de service et des priorités pour accéder aux ressources offertes par le réseau, autorise la fourniture de garanties de transparence et de temps de réponse pour certains utilisateurs. L'ingénierie du trafic consiste quant à elle, à assurer qu'une telle qualité de service est disponible pour toute une population d'utilisateurs, essentiellement en dimensionnant le réseau de manière à faire face à la demande estimée. Dans cet article, nous discutons d'abord la nature de la demande dans un réseau multiservice, en distinguant différentes applications essentiellement par leurs exigences spécifiques de qualité de service. Nous mettons en évidence ensuite les modèles de service actuellement proposés ou en discussion à la fois pour l'atm et pour l'internet. Le trafic des réseaux multiservices est essentiellement de deux types : " à débit intrinsèque " pour les flots audio et vidéo, ou " à débit élastique " pour le transfert de documents comme des fichiers, des images ou des textes. A cause de la variabilité extrême de leur débit, il s'avère très difficile de caractériser les flux de trafic afin de leur réserver les ressources nécessaires pour assurer la qualité de service, surtout lorsque les flux résultent de l'agrégation de multiples flots individuels. L'UIT et l'atm Forum ont défini un certain nombre de catégories de service, à commande préventive ou à commande réactive, chacune adaptée aux exigences particulières des diverses applications. L'Internet fait évoluer le modèle de service actuel, dit " au mieux ", pour permettre la réservation de ressources (modèle int-serv) ou la différenciation de services pour les paquets de plusieurs classes (modèle diff-serv). Traffic in multiservice neiworks is essentially of two types : " intrinsic rate " for audio and video flows, " elastic " for the transfer of files, images or texts. Because of their extremely variable bit rate, it proves very difficult to characterise traffic streams to allow adequate resource reservation to ensure qualily of service, especially when the traffic stream results from the aggregation of individual flows. ITU and the ATM Forum have standardized a certain number of service categories, based on preventive or reactive control, each variously adapted to the characteristics and performance requirements of different applications. The present " best effort " service model of the Internet is being enhanced to allow resource reservation (the int-serv model) and service differentiation for packets of several classes (the diff-serv model).
Commutation et adressage : typologie des flux et perpectives d'acheminement NATURE DU TRAFIC Deux types de trafic : débit intrinsèque, débit élastique Il est possible d'identifier d'innombrables catégories de services de télécommunications, chacune ayant ses caractéristiques particulières de trafic et ses propres exigences de performance. Souvent, cependant, ces services sont adaptables et il n'y a pas besoin de demander au réseau d'offrir plusieurs classes de service, chacune adaptée à une application particulière. Dans le but de simplifier l'exposé, nous préférons ne distinguer ici que deux grandes catégories d'applications selon qu'elles produisent un flux de trafic dont les variations de débit font partie de l'information transmise, ou un flux dont le débit est complètement modulable en fonction de la disponibilité de bande passante. Nous qualifierons les applications de la première catégorie d'applications " à débit intrinsèque ". Cette catégorie inclut naturellement les applications audio et vidéo interactives comme le téléphone ou la visioconférence. Les variations de débit doivent être (plus ou moins) conservées en traversant le réseau. Un service réseau adapté au transport de tels flux pourrait servir également à la consultation en temps réel de bandes audio ou vidéo préenregistrées. Les flux à débit intrinsèque sont caractérisés par leur débit (généralement variable) et par leur durée. La seconde catégorie d'applications est dite " à débit élastique ". Il s'agit ici du transfert de documents numériques de divers types : des fichiers de données, des textes, des images ou des séquences vidéo transférées pour être stockées localement avant d'être visualisées. Ce trafic est " élastique " dans le sens où le débit du flot d'information peut varier en raison de causes extérieures (par exemple la disponibilité de bande passante) sans effet de dégradation de la qualité de service [1]. Le trafic à débit intrinsèque La manière dont le débit d'un flot d'information important varie est pour la conception du contrôle du trafic. Les signaux vocaux sont du type tout ou rien (on-off) avec des bribes de parole séparées par des silences. Les signaux vidéo manifestent généralement des variations de débit plus complexes, reflétant les changements d'activité dans la séquence filmée. La nature de ces variations pour des séquences codées selon la norme MPEG est discutée par exemple dans le chapitre 1 de la référence [5]. Il est mis en évidence, en particulier, que les moments du débit par trame et son autocorrélation dépendent significativement de la nature de la séquence. En vue de l'ingénierie de trafic, il est important de noter que le débit sur de longues séquences vidéo manifestent une variabilité à plusieurs échelles de temps, allant de celle de la trame (une dizaine de millisecondes) à celle de la scène (une dizaine de secondes). Les séquences de visioconférence ne présentent pas de variations de scène à scène. Le débit dépend cependant de facteurs comme le nombre de personnes filmées et leur costume, ce qui rend difficile les prévisions a priori. Pour dimensionner correctement le réseau, il est nécessaire de tenir compte de la nature aléatoire de la demande pour les applications à débit intrinsèque. On pourrait, par exemple, essayer de généraliser les pratiques actuelles du réseau téléphonique, c'est-à-dire, identifier une " heure chargée " et dimensionner le réseau pour écouler (avec une forte probabilité) tout le trafic généré pendant cette heure. Pour mener à bien ces calculs, il serait au moins nécessaire de revoir l'hypothèse usuelle que les arrivées de nouvelles demandes constituent un processus poissonnien, dans le cas de certains services comme la visioconférence vidéo à la demande. ou la La demande peut se quantifier en établissant le produit du taux d'arrivée des nouvelles demandes (à l'heure chargée), de leur débit moyen et de leur durée, ce produit représentant le débit moyen des flux en cours. Des variables supplémentaires décrivant le mélange de flux à débit plus ou moins fort, ont aussi un impact significatif sur les performances du réseau. Cependant, en règle générale, pour assurer la qualité de service en terme d'accessibilité, il faudrait une capacité du réseau supérieure à la demande, avec un facteur de surallocation qui est d'autant plus faible que la demande est plus importante (loi d'économie d'échelle). Le trafic à débit élastique L'Internet actuel écoule surtout un trafic élastique généré par le transfert de documents selon le protocole HTTP de " la toile " (ou World Wide Web). A chaque clic de souris, une ou plusieurs connexions de la couche transport sont établies permettant l'affichage d'un fichier vers l'ordinateur d'un utilisateur. d'une page ou le transfert De nombreuses campagnes d'observation ont permis de mieux cerner la nature du trafic de la toile (voir [2,3], par exemple). Les requêtes pour un même document situé sur un serveur particulier peuvent être assimilées à un processus de Poisson. Cependant, les corrélations entre requêtes simultanées (dues à un même clic) et successives (dans une même session) devraient être prises en compte dans la description du trafic. La taille des documents demandés présente des statistiques remarquables. Il s'avère que la très grande majorité des documents est de taille faible (environ 99,9% des documents sont de moins d'un megaoctet) mais une proportion non négligeable est de taille très grande. Cette dernière proportion a un impact important sur les caractéristiques du trafic, notamment par la valeur de la demande moyenne. Afin de dimensionner le réseau pour qu'il transfère le trafic élastique avec la qualité de service requise (un temps de réponse acceptable pour toutes les requêtes en heure chargée, par exemple), il serait nécessaire d'assurer que la capacité dépasse la demande moyenne exprimée ici comme le produit du taux d'arrivée des requêtes par la
E INTERNET : AVENIR DE LA COMMUTATION ET DE L'ADRESSAGE taille moyenne des documents transférés. Comme pour le trafic à débit intrinsèque, la surallocation de débit par rapport à la demande est d'autant plus faible que le réseau est grand (loi d'économie d'échelle), bien que les règles précises de dimensionnement pour ce type de trafic restent largement à établir. Tout le trafic élastique ne nécessite pas une livraison en temps réel. Le courrier électronique peut être délivré plusieurs heures après avoir été envoyé, avec des instants d'arrivée différents suivant les destinations.. Le trafic produit entre des serveurs de courrier électronique ( " centres de tri ") peut cependant être identique aux autres catégories de trafic élastique. Un serveur établit un flux avec un autre serveur en fonction des besoins, choisissant le moment le plus approprié (suivant les tarifs et/ou l'encombrement). Il ne semble donc pas nécessaire de créer un service réseau spécifique au trafic de ce type. Rôle des caches Un développement récent et important dans Internet est l'usage croissant des serveurs cache. Les requêtes d'un navigateur comme Netscape ne sont pas dirigées immédiatement vers le serveur du document en question indiqué par l'url. Au lieu de cela, la requête est d'abord prise en charge par un serveur " proxy " situé tout prés de l'utilisateur. Si ce serveur contient une copie du document dans sa mémoire (ou cache), cette copie est délivrée à l'utilisateur ; sinon, le serveur lui-même émet une requête pour le document, éventuellement à travers un autre cache situé plus haut dans la hiérarchie du réseau. Quand le serveur proxy récupère le document, il l'envoie à l'utilisateur et en garde une copie dans sa propre mémoire. Etant donné qu'une population d'utilisateurs réclame souvent les mêmes documents, il arrive fréquemment que les documents demandés soient déjà stockés localement. Cela réduit largement le trafic sur les chemins longue distance (par exemple les liens transatlantiques), économisant de la bande passante et réduisant les temps de réponse. Les serveurs cache se présentent comme un troisième type de constituant, qui doit être pris en compte dans le dimensionnement du réseau, au même titre que les lignes de transmission et les noeuds de commutation. Autres types de trafic Distinguer seulement deux catégories d'applications constitue une simplification contestable. Par exemple, le trafic de restitution de bandes audio ou vidéo (play back) n'est pas clairement à débit intrinsèque ou à débit élastique. Un service réseau intermédiaire pourrait être conçu, permettant un délai de transfert plus long que celui nécessaire pour un service interactif. Cependant, il n'est pas évident que ce relâchement d'exigence de qualité produise une économie significative en dimensionnement de réseau. Nous avons envisagé la caractérisation du trafic sous la forme de flux individuels correspondant à la mise en oeuvre d'applications particulières. Or, dans les réseaux ATM et relais de trame actuels, la demande s'exprime plutôt en termes d'agrégations de flux : il faut, par exemple, transporter tout le trafic émis d'un réseau local d'entreprise (RLE) en direction d'un autre. Dans ce cas, il devient très difficile de respecter des exigences de qualité de service car le trafic d'agrégation est très difficile à caractériser. En effet, l'observation détaillée du trafic d'un RLE de type Ethernet effectuée par Bellcore en 1988 et 1989, manifeste des variations de débits très importantes à toute échelle de temps [4]. On parle d'un trafic " auto-similaire ". Une explication plausible de cette propriété est le fait que le trafic résulte de la superposition de transferts de documents dont la taille a la variabilité extrême dont on a parlé à propos du trafic Web. Une particularité de ce type de trafic est qu'il est quasiment impossible de cerner même le débit moyen, sans parler des autres paramètres dont il faudrait connaître la valeur afin de garantir la qualité de service. Le contrôle du trafic et l'allocation des ressources sont grandement facilités en distinguant les flux individuels, au risque, cependant, d'une plus grande complexité dans les équipements de réseau. Volumes de trafic La part relative de trafic à débit intrinsèque et de trafic à débit élastique dans un réseau multiservice futur reste une inconnue. Actuellement, le réseau téléphonique est bien plus grand que l'internet. Cependant, ce dernier croît très rapidement et le volume du trafic de données a déjà dépassé celui de la voix sur certaines artères aux Etats-Unis. Nous prétendons simplement qu'il y aura un volume non négligeable de chaque type de trafic, de sorte que le modèle de service du réseau devrait comporter au moins une classe de service adaptée à chacun. Nous considérons maintenant successivement les modèles de service ATM et Internet conçus pour acheminer les types de trafic décrits ci-dessus, avec leurs exigences particulières de qualité de service. MODELE DE SERVICE ATM Les catégories de service ATM L'UIT et l'atm Forum ont normalisé un certain nombre de classes de services adaptées aux différentes utilisations envisagées d'un réseau en technologie ATM. Les noms utilisés par les deux organismes sont parfois différents et certaines classes ne sont normalisées [11,12]. que par l'un d'eux Débit binaire constant (CBR, constant bit rate) La classe CBR fut la première classe normalisée par l'ult (où elle est connue sous le sigle DBR pour deterministic bit rate) lors de la première période d'étude concernant B-ISDN, 1988-1992. Elle permet l'établissement de connexions dont le débit crête est limité. Ce débit est défini
Commutation et adressage : typologie des flux et perpectives d'acheminement en conjonction avec une certaine tolérance de gigue, tenant compte de la variation du délai subi par les cellules en amont de l'interface réseau. La spécification du débit et sa tolérance se fait par rapport à un algorithme de type " seau percé ", connu sous le nom d'algorithme de débit de cellule générique (GCRA, generic cell rate algorithm). Pour une discussion sur l'impact de la variation de délai de cellule (CDV, cell delay variation) sur le contrôle de débit et les performances du réseau, voir [5], chapitre 3. Débit binaire variab) e (VBR, variabte La classe VBR fut spécifiée par l'atm bit rate) Forum au début de ses délibérations (1993) et adoptée ultérieurement l'ult (sous la dénomination SBR pour statistical bit rate). En plus du débit crête, les connexions de la classe VBR admettent un " débit soutenable " SCR (pour sustainable bit par rate) associé à une taille maximale de rafale MBS (maximum burst size). Ces paramètres sont contrôlés à l'entrée du réseau au moyen de deux instances de l'algorithme GCRA, l'une pour le débit crête, l'autre pour le débit soutenable. Les cellules non conforme aux GCRA peuvent être marquées au moyen du bit CLP (cellloss priority) dans l'en-tête de cellule : CLP=O pour les cellules normales, CLP=L pour les cellules à faible priorité. En cas de congestion, les cellules à CLP=1 sont rejetées les premières. L'ATM Forum distingue des variantes VBR temps réel et VBR non temps réel pour lesquelles les paramètres de qualité de service peuvent être spécifiés appel par appel. L'UIT définit des classes de qualité de service ; la classe 1 correspondant aux exigences des services temps réel. Les paramètres de qualité de service sont :. CLR : cell loss ratio, le taux de perte des cellules. CTD : cell transfer delay, le délai de transfert des cellules. CDV : cell delay variation, la variation de délai des cellules Contrôle des débits La catégorie de service VBR repose sur une description de variabilité de débit au moyen du " seau percé " (ou GCRA). Ce choix résulte d'un compromis entre l'utilité du descripteur pour l'allocation des ressources et la facilité de contrôler la conformité du flux de données réellement émis. Il est de l'avis de l'auteur que ce compromis n'est pas judicieux et que le seau percé ne permet pas le degré de contrôle nécessaire pour garantir la qualité de service de manière efficace. En effet, il s'avère difficile de choisir des paramètres SCR et MBS décrivant convenablement la variabilité de flux à débit intrinsèque tels que des séquences vidéo codées en MPEG. Ces variations sont tout simplement trop complexes pour être décrites convenablement par les deux paramètres de l'algorithme du " seau percé ". Le trafic à débit élastique pourrait être mis en forme de manière à satisfaire le descripteur de trafic, mais il est difficile de choisir un taux de fuite SCR satisfaisant. Pour le trafic auto-similaire résultant d'une agrégation de flux en particulier, n'importe quel choix de SCR résulterait, après mise en forme, en un flux au débit quasi-constant égal à SCR. Utiliser les paramètres du " seau percé " pour l'allocation de ressource demande généralement d'adopter une hypothèse du pire cas pour le trafic. C'est en général une hypothèse très pessimiste, conduisant à une surallocation significative de bande passante. La renégociation Transfer) de débit (ABT, ATM block La capacité de transfert ABT, normalisée par l'ult mais pas par l'atm Forum, se passe du " seau percé " comme descripteur de variabilité en allouant dynamiquement les ressources pour des rafales à débit constant. Les changements de débit sont demandés au moyen de cellules de gestion des ressources (cellules RM pour resource management) insérées dans le flux de cellules de données. L'ABT est définie avec les variantes " transmission immédiate " et " transmission différée " pour un contrôle préventif. Une version " élastique " est aussi définie pour le contrôle réactif. Pour cette dernière, le réseau impose des changements de débit dépendant de la bande passante disponible, constituant ainsi une alternative à l'abr [8]. Débit disponible (ABR, Available Bit Rate) ABR fut introduit par l'atm Forum et ensuite adopté par l'ult. Il vise le trafic à débit élastique. Cependant, il n'est pas adapté pour des transferts de documents individuels qui sont en général trop courts pour justifier la signalisation et les débits de services impliqués par l'établissement de la connexion. A l'opposé, il vise à répartir la bande passante disponible entre des agrégations de flux correspondant, par exemple, au trafic de données entre deux RLE. Le protocole ABR a, dans ce cas, à traiter des trafics d'entrée hautement variables, ce qui complique considérablement sa définition. La norme ABR spécifie comment les utilisateurs doivent se comporter en fonction des informations sur le débit disponible transmises dans des cellules de gestion RM. La manière dont le réseau détermine quand ses ressources sont saturées ou quelle quantité de bande passante allouer via l'indication de débit explicite n'est pas normalisée, voir [9], [10]. Débit de trame garanti (GFR, guaranteed frame rate) L'UBR (unspecified bit spécifiée rapidement par l'atm rate) fut une classe de service Forum pour des réseaux privés dont les utilisateurs mettent en oeuvre un protocole de couche supérieure comme TCP pour assurer un contrôle réactif. Il fut bientôt reconnu, cependant, que le rejet de cellules sans discrimination était inefficace pour des applications reposant sur des trames : un taux de perte de cel-
INTERNET : AVENIR DE LA COMMUTATION ET DE L'ADRESSAGE Iules faible se traduit ainsi en un taux de perte de trames beaucoup plus fort. La catégorie de service GFR, actuellement en cours de normalisation, constitue un raffinement de l'ubr tenant compte de la structure des données en trames et permettant à l'utilisateur minimal. MODELES DE SERVICE INTERNET de demander un débit Au cours des quelques dernières années, l'ietf (Internet engineering task force) s'est penché sur l'extension du modèle de service actuel caractéristique d'internet, qui " fait de son mieux " (best effort), pour permettre d'offrir des garanties de qualité de service. i L'Internet actuel Le modèle de service actuel de l'internet n'offre pas de garantie de qualité de service. Le réseau " fait de son mieux " pour transporter les flux présentés. La grande majorité du trafic sur Internet consiste en des flux à débit élastiques qui mettent en oeuvre TCP (transmission control protocol). TCP retransmet les paquets perdus et adapte le débit de l'émetteur à la capacité du récepteur. Plus significativement, pour la qualité de service, le protocole met en oeuvre des procédures d'évitement des encombrements qui ont comme résultat de partager la bande passante entre les flux en concurrence de manière plus ou moins équitable. Le deuxième protocole le plus communément utilisé est UDP (Liser data protocol). UDP n'a pas de procédure de correction d'erreur ou d'ajustement de débit. Une application de plus en plus courante d'udp concerne les flux temps réel comme la voix ou la vidéo sur IP. Les flux UDP sont considérés comme agressifs vis-à-vis de TCP : ils ne se replient pas en cas de congestion et acquièrent en conséquence une part disproportionnée de la bande passante. Le succès du modèle " au mieux " d'internet repose largement sur des utilisateurs mettant en oeuvre correctement les mécanismes TCP. Le besoin de garantie de qualité de service pour les services nouveaux a poussé l'ietf à envisager des moyens de réserver des ressources de réseau pour des flux particuliers. L'effort de normalisation a d'abord conduit à la définition d'un protocole de signalisation RSVP (ReSerVation Protocol) et ensuite à la définition de deux classes de service reposant sur la réservation de capacité. L'Internet à intégration de service Le protocole RSVP est décrit dans [11]. Ce protocole révèle des différences significatives avec la signalisation téléphonique classique : il est adapté dès le départ aux communications multi-participants avec une base d'utilisateurs hétérogène ; ce sont les récepteurs qui réservent les ressources et non pas l'émetteur (qui n'est pas supposé connaître les possibilités des différents récepteurs) ; les réservations doivent être renouvelées périodiquement cours de la communication. Après de longues discussions qui ont duré plusieurs années, le groupe de travail Int-serv a défini deux classes de service : service garanti et service à charge contrôlée [12, 131. Ces deux classes ont été choisies pour la normalisation parmi un grand nombre de possibilités. Elles sont considérées comme des extrêmes en ce qui concerne la rigueur des garanties de qualité de service. Il est prévu que l'expérience acquise à l'usage permettra de définir les futures classes de service de manière plus appropriée aux besoins des utilisateurs. Pour une discussion plus approfondie sur int-serv, voir [14]. Service garanti Les flux à service garanti sont définis par les paramètres de service suivants : débit crête, débit de fuite et taille du groupe de jetons du " seau percé ". Les derniers paramètres décrivent la variabilité du débit du flux, comme dans la catégorie de service VBR de l'atm. Contrairement à l'atm, le service garanti spécifie des garanties strictes sur le délai maximum des paquets : 100% des paquets doivent être délivrés dans le temps spécifié T. (Dans l'atm, garanties sont exprimées comme des quantiles d'une distribution de probabilité : par exemple, 99,99% des paquets doivent être fournis dans un délai T). Cette contrainte de délai déterministe exige que les routeurs mettent en oeuvre des mécanismes particuliers au les de séquencement comme les files d'attente pondérées équitables (weighted fair queuing). Des applications du service garanti pourraient inclure [10] : - les jeux de guerre où jusqu'à " 100 000 participants... devraient voir les avancées d'une manière ordonnée et séquentielle " ; - le marché d'actions où les changements de prix doivent être perçus par tout le monde en même temps. Service à contrôle de charge Le service à contrôle percé pour décrire la variabilité de charge utilise aussi un seau du trafic. Cependant, la garantie de délai stricte du service garanti est remplacée par l'engagement flou d'offrir une qualité de service similaire à celle d'un réseau qui " fait de son mieux " et qui n'est pas encombré. Les applications envisagées sont les communications temps réel adaptatives ou la mise en oeuvre de SNA sur IP [10]. Une alternative : la différenciation de service Le modèle int-serv (à intégration de services) n'a jamais été mis en oeuvre à grande échelle. On s'est rendu compte en effet que les mécanismes de séquencement nécessaires Fé,ic, 1999
Commutation et adressage : typologie des flux et perpectives d'acheminement pour fournir les garanties requises ne pouvaient pas être mis en oeuvre dans des conditions économiques satisfaisantes pour un grand nombre de flux. Le besoin croissant de qualité de service pour les usages commerciaux d'internet et l'avènement du trafic voix ont poussé l'ietf à rechercher des solutions alternatives. Le groupe int-serv de l'ietf qui avait défini les services garantis et à contrôle de charge a, depuis la mi-97, considéré des propositions alternatives pour introduire des services meilleurs que " faire de son mieux ". Le nouveau modèle de service est connu sous le nom de Services différenciés (Differenciated services). Un nouveau groupe de travail IETF a été formé en février 1998 avec pour mission de définir les mécanismes et protocoles appropriés. Une exigence particulière est que ces propositions conduisent rapidement à des mises en oeuvre expérimentales en vraie grandeur. L'architecture diff-serv Le modèle de service diff-serv repose sur un repérage des paquets, et des modes de prise en charge des paquets différentes suivant ces repères. Les repères sont constitués par la valeur d'un champ particulier de l'en-tête IP et sont introduits à la périphérie du réseau, suivant certaines règles résultant d'un accord entre l'utilisateur et l'opérateur. Par exemple, tous les paquets dans un flux se conformant à un certain schéma de " seau percé " sont repérés d'une certaine manière, ceux qui ne s'y conforment pas sont repérés autrement. Le traitement des paquets est différencié sur la base d'agrégations : tous les paquets avec un certain repère sont traités de la même manière sans distinguer les flux auxquels ils appartiennent. Il y a actuellement clairement défi- paquets (PHB, packet handling behaviour) nis : trois modes de prise en charge des. transfert rapide : EF (expedited forwarding), typiquement réalisé par positionnement file d'attente, du paquet en tête de. transfert assuré : AF (assured forwarding), permet de définir 4 classes de flux avec, chacune, 3 niveaux de priorité concernant le rejet des paquets, traitement par défaut : DE (default handling), en gros équivalent à l'actuel service " au mieux " (best effort). En dépit de leur nom, les classes AF n'offrent aucune autre assurance concernant la qualité de service que le fait que la classe 1 est meilleure que la classe 2 et ainsi de suite. En parallèle avec l'effort diff-serv, l'ietf développe actuellement une activité considérable dans le groupe MPLS (Multi-Protocollabel Switching). Cette technique, reposant sur l'identification d'un flux ou d'un groupe de flux par une étiquette, permet une allocation de ressource adaptée, et par voie de conséquence une mesure de contrôle de la qualité de service. CONCLUSION Dans le présent article nous nous sommes bornés à décrire la nature des différents types de trafic à prendre en compte dans la définition d'un futur réseau multiservice et à présenter les différentes solutions proposées actuellement par les instances de normalisation. Il conviendrait de compléter cette exposé par une discussion des avantages et des inconvénients de ces différents modèles de services et de l'adéquation des classes de service définies. Contentons nous de suggérer, de manière tout à fait personnelle, quelle serait la meilleure façon de gérer le trafic, à débit intrinsèque ou à débit élastique, si l'on pouvait faire abstraction des contraintes imposées par le processus de normalisation et par le poids de l'existant. Les flux de trafic à débit intrinsèque (audio ou vidéo) requièrent un transfert rapide comme envisagé dans le cadre de la classe EF du modèle diff-serv. Bien que de tels flux soient essentiellement à débit variable, il n'est pas utile d'essayer de caractériser cette variabilité au moyen d'un ou de plusieurs seaux percés. Il serait plus judicieux de ne spécifier que le débit crête (comme dans la catégorie CBR de l'atm) mais de tenir compte du débit réellement observé en décidant s'il est possible ou non d'admettre de nouvelles connexions sur un lien chargé. L'objectif de ce contrôle d'admission serait de s'assurer que le débit cumulé de tous les flots actifs reste inférieur à la bande passante disponible (avec une très grande probabilité). Quant aux flux à débit élastique, on souhaiterait garder la simplicité (pour le réseau) d'une commande distribuée à la TCP en permettant néanmoins d'offrir des garanties de qualité de service vis-à-vis du temps de réponse. La gestion d'une agrégation de flots élastiques comme, par exemple, dans le cas d'une connexion ATM (ABR, VBR ou GFR) ou celui d'une classe AF du modèle diff-serv, pose des problèmes d'équité et d'efficacité. Il serait préférable, selon l'auteur, de pouvoir gérer les flots individuellement au sein du réseau en sélectionnant le chemin le plus approprié (par exemple, en évitant d'envoyer de plus en plus de flots sur un même lien saturé) et en protégeant la qualité de service de chacun en réalisant une gestion de file d'attente par flot. Les progrès récents dans les technologies de routeurs IP laissent penser qu'une telle gestion de trafic devient possible, malgré le nombre potentiellement grand de flots simultanés à prendre en compte [15]. Références très [1] J. Roberts, " Realizing quality of service guarantees in multiservice networks ", Proceedings of IFIP Seminar PMCCN'97, Chapman and Hall, 1998. [2] M.F. Arlitt, C. Williamson (1996) Web server workload characterisation : The search for invariants. ACM SIGMETRICS 96. [3] M. Crovella, A. Bestavros (1996) Self-similarity in World Wide Web traffic : Evidence and possible causes. ACM SIGME- TRICS 96.
INTERNET : AVENIR DE LA COMMUTATION ET DE L'ADRESSAGE [4] W. Leland, M. Taqqu, W. Willinger, D. Wilson (1994) On the self-similar nature of Ethernet traffic. IEEE/ACM Trans. Networking, Vol 2, No 1, Février 1994. [5] J. Roberts, U. Mocci, J. Virtamo (Ed), Broadband Network Teletraffic (final Report of COST 242), LNCS 1155, Springer Verlag, 1996, [6] ITU Recommandation 1.371, " Traffic control and congestion control in BISDN ", août 1996. [7] ATM Forum, " Traffic Management Specification ", Version 4.0, avril 1996. [12] S. Shenker, C. Partridge, R. Guérin, " Specification of Guaranteed Quality of Service ", RFC 2212,! ETF, Sept. 97. [13] J. Wrocklawski et al, " Specification of the controlled-load network element service ", RFC 2211, leïf, Sept. 1997. [14] P. White, J. Crowcroft, " The integrated services in the Internet : State of the art ", Proceeding of IEEE, Vol. 85, N) 12, Dec. 1997. [15] V.P. Kumar, T.V. Lakshman and D. Sti! iadis. Beyond best effort : router architectures for the differentiated services of tomorrow's Internet. IEEE Commun. Mag., pp 152-164, May 1998. [8] F. Guillemin, " ATM block transfer service vs available bit rate service ", European Trans Telecom., Vol.8, n'l, Jan/Feb. 1997. [9] F. Bonomi, F. Fendick, " The rate-based flow control framework for the available bit rate service ", IEEE Networks, Vol.9, N-2, 1995. [10] K.W. Fendick, Evolution of controls for the Available Bit Rate service. IEEE Comm. Mag., Nov. 1996. [11] L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala, " RSVP : A new resource reservation protocol ", IEEE Networks, Vol 7, No 5, Sept 1993. mr Jim ROBERTS est titulaire d'un doctorat de l'université Pierre et Marie Curie, Paris VI. Il est actuellement chargé d'une unité de recherch et développement pour les questions d'écoulement du trafic dans les réseaux large bande du CNET. Il est reconnu comme " expert émérite " pour ses travaux sur l'ingénierie du trafic pour les réseaux multiservices. Il est membre de plusieurs comités de rédaction de revue et de comités de programme de congrès dans le domaine des réseaux et participe comme rapporteur associé aux travaux de l'uit.