Architecture de services différenciés à deux bits pour l'Internet

Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.

Résumé

Le présent document a été soumis à l'origine comme projet internet en novembre 1997. En tant que document ayant préludé à la formation du groupe de travail Services différenciés de l'IETF, beaucoup des idées présentées ici, de concert avec les présentations ultérieures de Dave Clark à la réunion de décembre 1997 du groupe de travail Services intégrés de l'IETF, ont joué un rôle clé dans ce qui a conduit aux RFC 2474 et 2475 et la section sur l'allocation reste une proposition parfaitement justifiée. C'est la raison pour laquelle il est présenté dans sa forme originale, ainsi que pour fournir une référence. La partie du document sur le chemin de transmission est destinée aux archives pour voir où nous en étions fin 1997 et non comme indication de la direction des évolutions futures.

La version postscript de ce document comporte les transparents de Clark en appendice. La version postscript de ce document comporte aussi de nombreuses figures qui aident grandement à sa lisibilité.

1.   Introduction

Le présent document expose une architecture de services différenciés pour l'Internet. Dave Clark et Van Jacobson ont présenté chacun leurs travaux sur les services différenciés à la réunion de Munich de l'IETF [2], [3]. Chacun a expliqué comment utiliser un bit de l'en-tête IP pour fournir un nouveau type de service aux paquets dans l'Internet. Ce sont deux types de service très différents avec des hypothèses de politique assez différentes. La discussion qui a suivi nous a convaincu que les deux types de service ont des mérites et que tous deux peuvent être mis en œuvre avec un ensemble de mécanismes très similaires. Nous proposons un cadre architectural qui permet l'utilisation de ces deux types de service et qui exploite leurs similitudes dans les mécanismes de chemin de transmission. Le but principal de cette architecture est partagé par les deux propositions : garder la simplicité du chemin de transmission, repousser la complexité à la bordure du réseau dans toute la mesure possible, fournir un service qui évite de faire des hypothèses sur le type de trafic qui l'utilise, employer une politique d'allocation qui soit compatible avec l'approvisionnement à la fois à long et à court terme, rendre possible que le modèle dominant du trafic Internet reste au mieux.

Les contributions majeures à ce document présentent deux types de service distincts, un ensemble de mécanismes généraux pour le chemin de transmission qui peuvent être utilisés pour mettre en œuvre une gamme de services différenciés et proposer un cadre souple pour l'approvisionnement d'un réseau de services différenciés. C'est précisément cette sorte d'architecture qui est nécessaire pour un déploiement efficace de services différenciés : nous avons besoin d'un cadre et d'un ensemble de primitives qui puissent être mises en œuvre à court terme et qui fournisse des services interopérables, et puisse donc fournir une "boîte à outils" pour l'expérimentation et l'élaboration et conduise à terme à plus de niveaux de différenciation au sein de chaque service autant que de besoin.

Au prix d'une analogie un peu osée, nous voulons fournir une gamme de services un peu de la même façon que les compagnies aériennes font avec la première classe, la classe affaires et la classe touriste. Cette dernière a aussi une gradation du fait des diverses restrictions à l'achat. L'analogie mise à part, nous voulons souligner que le trafic au mieux, tout comme les sièges de la classe touriste dans les avions, sont quand même supposés constituer la masse du trafic de l'Internet. La classe affaires et la première classe portent un petit nombre de passagers, mais ils sont très importants pour l'économie de l'industrie aéronautique. Les diverses forces et réalités économiques se combinent pour dicter l'allocation relative des sièges et essayer de remplir les avions. On ne s'attend pas à ce que les services différenciés englobent tout le trafic de l'Internet, mais on espère bien que les nouveaux services conduisent à un environnement économique et de service en bonne santé.

Le présent document est organisé en sections qui décrivent l'architecture des services, les mécanismes, l'architecture d'allocation de la bande passante, comment cette architecture peut interopérer avec RSVP/services intégrés, et donnent des recommandations pour son déploiement.

2.   Architecture

2.1   Fondements

L'Internet actuel livre un seul type de service, au mieux, à tout le trafic. Un certain nombre de propositions ont été faites concernant l'ajout de services améliorés à l'Internet. Nous nous concentrons sur deux méthodes particulières d'ajout de niveaux différenciés de service à IP, chacun désigné par un bit [1], [2], [3]. Ces services représentent une séparation radicale du service traditionnel de l'Internet, mais ils se distinguent aussi radicalement des architectures traditionnelles de "qualité de service" qui s'appuient sur des modèles fondés sur le circuit. Ces deux propositions cherchent à définir un seul mécanisme commun qui est utilisé par les routeurs intérieurs du réseau, repoussant la plus grande partie de la complexité et de l'état des services différenciés sur les bordures du réseau. Tous deux utilisent la bande passante comme ressource demandée et allouée. Clark et Wroclawski ont défini un service "garanti" qui suit les profils d'utilisation "à capacité attendue" qui sont approvisionnés statistiquement [3]. L'assurance que reçoit l'utilisateur d'un tel service est qu'un tel trafic ne sera vraisemblablement pas éliminé tant qu'il reste dans le profil de capacité attendue. La signification exacte de "vraisemblablement" dépend de la façon dont le service est bien approvisionné. Un flux de trafic à service garanti peut excéder son profil, mais le trafic en excès ne reçoit pas le même niveau d'assurance. Jacobson a défini un service "Premium" qui est approvisionné conformément aux profils de capacité de crête auquel l'abonnement est strictement limité et auquel est donnée sa propre priorité supérieure dans les files d'attente des routeurs [2]. Un flux de trafic du service Premium est formaté et limité strictement à son taux de crête provisionné et est formaté de telle sorte que les salves ne soient pas injectées dans le réseau. Les service Premium présente un "réseau virtuel" où les salves d'un flux peuvent être mises en file d'attente dans le formateur à la bordure du réseau, mais ensuite, seulement en proportion du nombre de connexions entrantes sur chaque routeur. En dépit de leurs nombreuses similitudes, ces deux approches résultent en des services fondamentalement différents. Le premier utilise la gestion de mémoire tampon pour fournir un service de "meilleur effort" alors que le second crée un service avec peu de gigue et de délai de mise en file d'attente et sans besoin de gestion de file d'attente sur la file d'attente des paquets du service Premium.

Un service garanti a été introduit dans [3] par Clark et Wroclawski, bien qu'ils aient fait quelques altérations à sa spécification pour notre architecture. D'autres raffinements et un cadre de "capacité attendue" soit donné dans Clark et Fang [10]. Ce cadre se concentre sur la "fourniture de différents niveaux de service au mieux à des moments d'encombrement du réseau" mais mentionne aussi qu'il est possible d'avoir une file d'attente de routeur séparée pour mettre en œuvre un niveau "garanti" d'assurance. Nous pensons que ce cadre et notre architecture à deux bits sont compatibles mais cela doit être exploré plus en détails. Comme le service Premium n'a pas été documenté ailleurs, nous le décrivons ci-dessous avant la description de l'architecture à deux bits.

2.2   Service Premium

Dans [2], un service Premium a été présenté avec des différences fondamentales par rapport au service au mieux actuel de l'Internet. Ce service n'est pas destiné à remplacer le service au mieux mais principalement à satisfaire une demande émergeante pour un service commercial qui pourrait partager l'utilisation du réseau avec le trafic au mieux. Cela est économiquement souhaitable, car le même réseau peut être utilisé pour les deux sortes de trafic. On s'attend à ce que le trafic Premium s'attribue un faible pourcentage de la capacité totale du réseau, mais il serait tarifé à un prix bien plus élevé. Une utilisation d'un tel service pourrait être de créer des "lignes louées virtuelles", économisant leur coût de construction et entretenant un réseau distinct. Le service Premium, de la même façon qu'une ligne téléphonique standard, est une capacité que le consommateur s'attend à avoir lorsque le récepteur est décroché, bien qu'elle puisse, selon les foyers, être inactive une bonne partie du temps. Approvisionner le service Premium de cette façon réduit la capacité de l'Internet au mieux de la quantité de Premium allouée, dans le pire des cas, et donc, il devrait être tarifé en conséquence. D'un autre côté, chaque fois que cette capacité n'est pas utilisée, elle est disponible pour le trafic au mieux. À la différence du trafic au mieux qui est saccadé et exige une gestion de file d'attente pour traiter équitablement les épisodes d'encombrement, ce service Premium crée par conception des schémas de trafic réguliers et des files d'attentes petites ou non existantes.

Les niveaux de service Premium sont spécifiés comme un débit binaire de crête désiré pour un flux spécifique (ou un agrégat de flux). Le contrat de l'utilisateur avec le réseau est de ne pas excéder le débit de crête. Le contrat du réseau est que la bande passante contractuelle sera disponible lorsque le trafic est envoyé. Les routeurs de premier bond (ou d'autres appareils de bordure) filtrent les paquets qui entrent sur le réseau, établissent le bit Premium de ceux qui correspondent à la spécification de service Premium, et effectuent le formatage du trafic sur le flux qui étale toutes les salves de trafic avant qu'elles entrent sur le réseau. Cette approche n'exige pas de changement chez les hôtes. Un routeur conforme le long du chemin a besoin de deux niveaux de priorité de mise en file d'attente, pour envoyer en premier tous les paquets qui ont le bit Premium établi. Le trafic au mieux n'est pas marqué et est mis en file d'attente et envoyé avec la priorité inférieure. Il en résulte deux "réseaux virtuels" : un qui est identique à l'Internet d'aujourd'hui avec des mémoires tampon conçues pour absorber les salves de trafic ; et un autre où le trafic est limité et formaté à un débit de crête contractuel, mais les paquets se déplacent à travers un réseau de files d'attentes où ils ne rencontrent presque pas de délais de mise en file d'attente.

Dans cette architecture, les décisions sur les chemins de transmission sont prises séparément et plus simplement que l'établissement des accords de service et les profils de trafic. À l'exception de la régulation et du formatage aux frontières administratives ou "de confiance", les seules actions qui doivent être entreprises dans le chemin de transmission sont de classer un paquet dans une des deux file d'attente sur un seul bit et de servir les deux files d'attentes en utilisant une simple priorité. Le formatage doit inclure les paramètres de débit et de salve ; ce dernier est supposé être faible, dans la gamme de un ou deux paquets. La régulation aux frontières met en application la conformité du débit, et peut être mise en œuvre par un simple baquet de jetons. Les procédures d'admission et d'établissement sont supposées évoluer, avec le temps, pour être configurables de façon dynamique et devenir assez complexes alors que les mécanismes restent simples dans le chemin de transmission.

Un service Premium construit selon cette architecture peut être déployé de façon utile une fois que les mécanismes du chemin de transmission sont en place en faisant des allocations statiques. Les flux de trafic peuvent être conçus pour un traitement particulier grâce à la configuration de gestion du réseau. Les flux de trafic devraient être conçus par la source, par la destination, ou par toute combinaison des champs de l'en-tête du paquet. Les routeurs de premier bond (ou terminaux) vont filtrer les flux sur tout ou partie du tuplet d'en-tête consistant en l'adresse IP de source, l'adresse IP de destination, l'identifiant de protocole, le numéro d'accès de source, et le numéro d'accès de destination. Sur la base de cette classification, un routeur de premier bond effectue le formatage du trafic et établit le bit Premium désigné du champ de préséance. Les hôtes d'extrémité ne sont pas obligés d'être "à capacité de service différencié", bien que si et quand les systèmes d'extrémité deviendront universellement "capables", ils pourront faire leur propre formatage et les routeurs de premier bond auront simplement à réguler.

Le respect du débit et de la taille de salve souscrits doit être appliqué à l'entrée du réseau, soit par le système d'extrémité, soit par le routeur de premier bond. Au sein d'un intranet, d'un domaine administratif, ou d'une "région de confiance" les paquets peuvent alors être classés et servis sur la seule base du bit Premium. Lorsque les paquets traversent une frontière, la fonction de régulation est critique. La région d'entrée va vérifier la conformité du flux de paquets prioritaire au débit auquel les deux régions se sont accordées, éliminant les paquets qui excèdent ce débit. Il est donc du meilleur intérêt d'une région de s'assurer de la conformité au débit objet de l'accord à la sortie. Cette exigence signifie que le trafic Premium est sans salves, ce qui, avec la règle de non dépassement, conduit directement à l'observation que les file d'attentes Premium peuvent être facilement dimensionnées pour prévenir l'élimination de paquets et donc le besoin d'une politique de gestion des files d(attente. À chaque routeur, la plus grande taille de file d'attente se rapporte au nombre d'autres routeurs en relation et est donc assez petite, de l'ordre d'une dizaine de paquets.

Les allocations de bande passante Premium ne doivent pas être surdimensionnées car elles représentent une obligation du réseau être devraient être tarifées en conséquence. Noter que, dans cette architecture, le trafic Premium va aussi rencontrer une variation de délai considérablement moindre que le trafic au mieux ou le trafic de données Garanti de [3]. Les débits Premium pourraient être configurés sur la base d'un abonnement à court terme, ou à la demande lorsque l'établissement ou la signalisation dynamique sont disponibles.

La Figure 1 montre comment un flux de paquets Premium est établi au sein d'un domaine administratif particulier, la compagnie A, et envoyé à travers la liaison d'accès au FAI (fournisseur d'accès Internet) de la compagnie A. On suppose que le routeur de premier bond de l'hôte a été configuré pour correspondre à un flux provenant de l'adresse IP de l'hôte à l'adresse IP de destination qui est atteinte à travers le FAI. Un flux Premium est configuré d'un hôte avec un débit qui est à la fois inférieur à l'allocation Premium totale que la compagnie A a de son FAI, r octets par seconde, et inférieure à la quantité de cette allocation qui a été allouée aux autres hôtes de la compagnie A. Les paquets ne sont pas marqués de façon particulière lorsque ils quittent l'hôte. Le routeur de premier bond élimine le bit Premium sur tous les paquets arrivants, établit le bit Premium sur tous les paquets dans le flux désigné, formate les paquets dans le flux Premium à un débit et taille de salve configurés, met en file d'attente les paquets au mieux non marqués dans la file d'attente de faible priorité et formate les paquets Premium dans la file d'attente de priorité élevée, et envoie les paquets à partir de ces deux files d'attente à simple priorité. Les routeurs internes intermédiaires à la compagnie A mettent en file d'attente les paquets dans une des deux files d'attentes de sortie sur la base du bit Premium et desservent les files d'attente avec une priorité simple. Les routeurs frontière effectuent des tâches assez différentes, selon qu'ils traitent un flux sortant ou un flux entrant. Un routeur frontière sortant peut effectuer du reformatage sur le trafic Premium agrégé pour le rendre conforme au débit r, selon le nombre de flux Premium agrégés. Les routeurs frontière d'entrée ont seulement besoin d'effectuer une simple fonction de régulation qui peut être mise en œuvre avec un baquet de jetons. Dans l'exemple, le FAI accepte tous les paquets Premium provenant de A pour autant que le flux n'excède pas r octets par seconde.

Figure 1 : Flux de trafic Premium de l'hôte d'extrémité au FAI de l'organisation

2.3   Architecture de services différenciés à deux bits

Les propositions de Clark et Jacobson sont sensiblement similaires dans la localisation et le type des blocs fonctionnels qui sont nécessaires pour les mettre en œuvre. De plus, ils mettent en œuvre des services assez différents qui ne sont pas incompatibles dans un réseau. Le service Premium met en œuvre un service à bande passante de crête garantie avec un délai de mise en file d'attente négligeable qui ne peut pas affamer le trafic au mieux et peut être alloué d'une façon très équitable. Ce service semble avoir une forte attractivité pour les applications commerciales, les diffusion vidéo, la voix sur IP, et les VPN (réseaux privés virtuels). D'un autre côté, ce service peut se révéler à la fois trop restrictif (par ses limites rigides) et surabondant (par de sur allocation) pour certaines applications. Le service Garanti met en œuvre un service qui a les mêmes caractéristiques de délai que les paquets au mieux (non éliminés) et le caractère ferme de sa garantie dépend de la façon dont les liaisons individuelles sont bien approvisionnées pour les salves de paquets Garantis. D'un autre côté, il permet que les flux de trafic utilisent toute capacité supplémentaire disponible sans pénalité et l'élimination occasionnelle de paquets pour de courtes périodes d'encombrement peut être acceptable pour de nombreux utilisateurs. Ce service pourrait être ce qu'un FAI fournirait à des consommateurs individuels qui veulent payer un peu plus pour un service internet qui semble non affecté par des périodes d'encombrement. Les deux services ne valent qu'autant que leurs schémas de contrôle d'admission, bien que ce soit plus difficile pour du trafic qui n'a pas d'allocation de débit de crête.

Il peut y avoir des bénéfices supplémentaires au déploiement des deux services. Dans la mesure ou le service Premium est une allocation prudente des ressources, la bande passante inutilisée qui a été allouée à Premium peut fournir un peu "d'oxygène" pour des périodes sous dotées ou de salve de trafic Assuré ou au mieux. Les éléments de réseau qui déploient les deux services effectueront la gestion de file d'attente RED sur tous le trafic non Premium, comme suggéré dans [4], et les effets du mélange de flux Premium avec des flux au mieux peut servir à réduire la sporadicité de ce dernier. Une des forces du service Assuré est qu'il permet que des salves se produisent de façon naturelle, mais cela rend aussi les problèmes d'approvisionnement, de contrôle d'admission et d'allocation plus difficiles, de sorte qu'il peut se passer plus de temps et d'expérimentations avant que cette politique d'admission pour ce service soit complètement définie. Un service Premium pourrait être développé en employant des allocations statiques sur les débits de crête sans partage statistique.

Comme il paraît y avoir un certain nombre d'avantages à une architecture qui permette ces deux types de service et parce que comme nous allons le voir, on peut faire qu'ils partagent de nombreux mécanismes,nous proposons de concevoir des schémas à deux bits pour le champ de préséance de l'en-tête IP. Nous laissons au processus de normalisation le soin d'une désignation explicite de ces schémas binaires et nous utilisons donc la notation abrégée pour noter chaque schéma binaire par un bit, que nous appellerons l'un Premium ou bit P, et l'autre le bit d'assurance ou bit A. Il est possible qu'un réseau ne mette en œuvre qu'un seul de ces services, et d'avoir des éléments de réseau qui cherchent seulement un des bits applicables, mais nous nous concentrerons sur l'architecture à deux services. De plus, on suppose le cas où aucun changement n'est fait chez les hôtes, le marquage approprié des paquets étant entièrement fait dans le réseau, au routeur de premier bond, ou au routeur d'extrémité. Nous décrivons l'architecture du chemin de transmission dans cette section, en supposant que le service a été alloué par des mécanismes qui sont exposés à la section 4.

Dans un sens plus général, le service Premium note des paquets qui sont mis en file d'attente avec une priorité supérieure à celle de la file d'attente ordinaire au mieux. De même, le service assuré note des paquets qui sont traités de façon préférentielle par rapport à la probabilité d'abandon au sein de la file d'attente "normale". Il y a un certain nombre de façons d'ajouter plus de niveaux de service au sein de chacun de ces types de service [7], mais le présent document prend pour position de spécifier les services de niveau de base de Premium et Assuré.

Les mécanismes de chemin de transmission peuvent être répartis entre ceux qui surviennent à l'interface d'entrée, avant la transmission du paquet, et ceux qui surviennent à l'interface de sortie, après la transmission du paquet. Les routeurs intermédiaires ont seulement besoin de mettre en œuvre les fonctions qui suivent la transmission du paquet, alors que les routeurs d'extrémité et de frontière doivent effectuer les fonctions à l'arrivée des paquets avant la transmission. Nous décrivons les mécanismes de cette façon pour illustrer la processus ; d'autres façons de composer leurs fonctions sont possibles.

Les routeurs d'extrémité sont configurés avec un profil de trafic pour un flux particulier sur la base de son en-tête de paquet. Cette fonctionnalité a été définie par le groupe de travail RSVP dans la RFC 2205. La Figure 2 montre ce qui se passe pour un paquet qui arrive au routeur d'extrémité, avant qu'il soit passé au moteur de transmission. Tout paquet arrivant doit avoir le bit A et le bit P à zéro après que chaque paquet est classé sur la base de son en-tête. Si l'en-tête ne correspond pas à une valeur configurée, il est immédiatement transmis. Les flux qui correspondent passent à travers les marqueurs individuels qui ont été configurés à partir du profil d'usage pour ce flux : la classe de service (Premium ou Assuré), le taux (de crête pour Premium, "attendu" pour Assuré), et la taille de salve permise (peut être facultative pour Premium). Les paquets de flux Assuré émergent du marqueur avec leurs bits A établis lorsque le flux est conforme à son profil, mais le flux est inchangé par ailleurs. Pour un flux Premium, le marqueur va retenir les paquets quand c'est nécessaire pour les faire se conformer à leur taux configuré. Et donc les paquets de flux Premium émergent du marqueur dans un flux formaté avec leurs bits P établis. (Il est possible que les paquets de flux Premium soient abandonnés à l'intérieur du marqueur comme on le décrit ci-dessous.) Les paquets sont passés au moteur de transmission lorsque ils sortent des marqueurs. Les paquets qui ont leurs bits P ou A établis sont appelés des paquets marqués.

Figure 2. Diagramme des fonctions d'entrée d'un routeur d'extrémité

La Figure 3 montre le travail interne du marqueur. Aussi bien pour les paquets du service Assuré que Premium, un baquet de jetons "se remplit" au débit de flux qui a été spécifié dans le profil d'usage. Pour le service Assuré, la profondeur du baquet de jetons est réglée par la taille de salve du profil. Pour le service Premium , la profondeur du baquet de jetons doit être limitée à l'équivalent de seulement un ou deux paquets. (On suggère une profondeur de un paquet dans les premiers déploiements.) Lorsque un jeton est présent, les paquets des flux Assuré ont leur bit A mis à un, autrement, le paquet est passé au moteur de transmission. Pour le marqueur configuré pour Premium, les paquets arrivants qui voient un jeton présent ont leur bit P mis et ils sont transmis, mais lorsque il n'y a pas de jeton présent, les paquets de flux Premium sont détenus jusqu'à ce qu'un jeton arrive. Si un flux Premium a des salves telles qu'elles submergent la file d'attente, ses paquets seront abandonnés. Bien que les données d'établissement du flux puissent être utilisées pour configurer une limite de taille pour la file d'attente (ce qui serait la signification d'une "salve" dans le service Premium) cela n'est pas nécessaire. Les files d'attente de détention non configurées devraient être capables de détenir au moins deux produits de délai de bande passante, adéquats pour les connexions TCP. Une plus petite valeur peut être utilisée pour satisfaire à des exigences de délai d'une application spécifique.

Figure 3 : Marqueurs pour mettre en œuvre les deux différents services

En pratique, le baquet de jetons devrait être mis en œuvre en octets et un jeton est considéré comme présent si le nombre d'octets dans le baquet est égal ou supérieur à la taille du paquet. Pour Premium, le baquet ne peut être admis à remplir que jusqu'à la taille maximum de paquet; alors que pour Assuré, il peut atteindre le paramètre de salve configuré. Le trafic Premium est détenu jusqu'à ce qu'un crédit d'octets suffisant ait été accumulé et cette mémoire tampon de détention fournit la seule file d'attente réelle que voit le flux dans le réseau. Pour le trafic Assuré, on vérifie juste si les octets dans le baquet sont suffisants pour la taille du paquet et on établit le bit A si il en est ainsi. Sinon, la seule différence est que A n'est pas établi. Le trafic Assuré va dans une file d'attente après cette étape et peut voir une file d'attente à chaque bond le long de son chemin.

Chaque interface de sortie d'un routeur doit avoir deux files d'attente et doit mettre en œuvre un test sur le bit P pour choisir la file d'attente de sortie du paquet. Les deux files d'attente doivent être servies par simple priorité, les paquets Premium en premier. Chaque interface de sortie doit mettre en œuvre le mécanisme RIO fondé sur RED décrit dans [3] sur la file d'attente de priorité inférieure. RIO utilise deux seuils pour savoir quand commencer à abandonner des paquets, un seuil inférieur fondé sur l'occupation totale de la file d'attente pour le trafic ordinaire au mieux, et un autre fondé sur le nombre de paquets en file d'attente qui ont leur bit A établi. Cela signifie que toute action préférentielle pour le trafic du service Assuré ne sera entreprise que lorsque la capacité de la file d'attente excède la valeur du seuil pour le service ordinaire au mieux. Dans ce cas, seuls les paquets non marqués seront abandonnés (en utilisant l'algorithme RED) sauf si la valeur du seuil pour le service Assuré est aussi atteinte. Garder un compte précis du nombre de paquets avec le bit A qui sont actuellement dans une file d'attente exige soit de tester les bits A à la fois à l'entrée et à la sortie de la file d'attente, soit d'avoir un état supplémentaire dans le routeur. La Figure 4 est un diagramme d'états de l'interface de sortie pour tous les routeurs.

Figure 4 : Interface de sortie de routeur pour architecture à deux bits

La sortie de paquet d'un routeur d'extrémité est donc un flux formaté de paquets avec les bits P établis mélangé avec un flux de paquets au mieux, dont certains peuvent avoir les bits A établis. Le service Premium ne peut évidemment pas affamer le trafic au mieux parce qu'il est à la fois contrôlé dans ses salves et dans sa bande passante. Le service Assuré pourrait seulement s'appuyer sur une allocation prudente pour empêcher d'affamer le trafic non marqué, mais les salves de trafic Assuré peuvent alors enfermer le trafic au mieux dans des goulets d'étranglement de files d'attentes durant les périodes d'encombrement.

D'après [3], on désigne les objets de chemin de transmission qui testent les flux par rapport à leurs profils d'utilisation des "profil mètres". Les routeurs frontière vont exiger des profil mètres à leurs interfaces d'entrée. Les accords bilatéraux entre domaines administratifs adjacents doivent spécifier un taux de crête sur tout le trafic P et un taux et une salve pour le trafic A (et éventuellement une heure de début et une durée). Un profil mètre est exigé à l'entrée d'une région de confiance pour s'assurer que les flux de paquets de service différencié sont conformes aux taux objets de l'accord. Les paquets non conformes des flux Premium sont éliminés lorsque des paquets non conformes de flux Assuré ont leurs bits A rétablis. Par exemple, à la figure 1, si le FAI a accepté de fournir à la compagnie A r octets/s de service Premium, les paquets au bit P marqué qui entrent chez le FAI à travers la liaison de la compagnie A seront éliminés si ils excèdent r. Au lieu de cela, si le service de la figure 1 est du service Assuré, les paquets seront simplement non marqués, et transmis au mieux.

La plus simple interface d'entrée de routeur frontière est un profil mètre construit à partir d'un baquet de jetons configuré avec le taux contractuel à travers cette liaison d'entrée (voir la figure 5). Chaque type, Premium ou Assuré, et chaque interface; doit avoir son propre profil mètre correspondant à une classe particulière à travers une frontière particulière. (Ceci est différent des modèles dans lesquels chaque flux qui traverse la frontière doit être régulé séparément et/ou formaté.) Le mécanisme exact exigé à une interface d'entrée de routeur frontière dépend de la politique d'allocation déployée ; une approche plus complexe est présentée à la section 4.

Figure 5 : Profil mètres d'interface d'entrée de routeur frontière

3.   Mécanismes

3.1   Primitives du chemin de transmission

Le paragraphe 2.3 introduisait les objets de chemin de transmission Marqueur et Profil mètre. Dans cette section on spécifie les blocs de construction primitifs exigés pour les composer. Les primitives sont : classeur général, classeur de schéma binaire, réglage binaire (bit setter), files d'attentes de priorité (priority queues), baquet de jetons de régulation (policing token bucket) et baquet de jetons de formatage (shaping token bucket). Ces primitives peuvent composer un marqueur (un baquet de jetons de régulation ou de formatage plus un réglage binaire) et un profile mètre (un baquet de jetons de régulation plus un élimineur ou régleur binaire).

Classeur général : Les routeurs d'extrémité ou de premier bond doivent effectuer une correspondance de signature de niveau transport fondés sur un tuplet qui se trouve dans l'en-tête de paquet, une fonctionnalité qui fait partie de tout routeur à capacité RSVP. Comme décrit ci-dessus, les paquets dont les tuplets correspondent à un des flux configurés sont vérifiés quant à la conformité et ont le bit de service approprié établi. Cette fonction est consommatrice de mémoire et de traitement, mais elle reste sur les bordures du réseau où il y a moins de flux.

Classeur de schéma binaire : Cette primitive comporte une simple décision bidirectionnelle sur la base de l'établissement ou non d'un schéma binaire particulier dans l'en-tête IP. Comme dans la figure 4, le bit P est testé quand un paquet arrive à un routeur qui n'est pas d'extrémité pour déterminer si il faut le mettre en file d'attente dans la file de sortie à haute priorité ou dans la file de paquets à faible priorité. Le bit A des paquets destinés à la file de faible priorité est vérifié pour 1) incrémenter le compte de paquets Assurés dans la file d'attente si il est mis et 2) déterminer quelle probabilité d'abandon sera utilisée pour ce paquet. Les paquets qui sortent de la file à faible priorité doivent aussi avoir le bit A vérifié afin que le compte de paquets Assurés dans la file d'attente puisse être décrémenté si nécessaire.

Réglage binaire : Les bits A et les bits P doivent être établis ou retirés en plusieurs endroits. Un bloc fonctionnel qui établit les bits appropriés de l'en-tête IP selon un schéma binaire configuré serait le plus général.

Files d'attentes de priorité : Chaque élément de réseau doit comporter (au moins) deux niveaux de simple mise en file d'attente de priorité. La file d'attente de forte priorité est pour le trafic Premium et la règle de service est d'envoyer les paquets dans cette file d'abord et jusqu'à épuisement. On rappelle que le trafic Premium ne doit jamais être sursouscrit, et donc le trafic Premium ne devrait voir que peu ou pas de file d'attente.

Baquet de jetons de formatage :C'est le baquet de jetons exigé chez le routeur d'extrémité pour le trafic Premium et qui est montré à la figure 3. Comme on peut le voir, le formatage est aussi utile aux points de sortie d'une région de confiance. Un paquet arrivant est immédiatement transmis si il y a un jeton présent dans le baquet, autrement, le paquet est mis en file d'attente jusqu'à ce que le baquet contienne des jetons suffisants pour l'envoyer. Le formatage exige des mécanismes d'horloge, de la mémoire de paquets, et des blocs d'état pour chaque flux, et c'est donc un processus gros consommateur de mémoire et de capacité de calcul.

Baquet de jetons de régulation : C'est le baquet de jetons exigé pour les profil mètres qui est montré à la figure 5. Les baquets de jetons de régulation ne détiennent jamais de paquets arrivants, mais vérifient à l'arrivée pour voir si un jeton est disponible pour la classe de service du paquet. Si c'est le cas, le paquet est immédiatement transmis. Sinon, l'action de régulation est effectuée, l'abandon pour un paquet Premium et le reclassement ou le démarquage pour Assuré.

3.2   Passage des information de configuration

Il est clair que des mécanismes sont nécessaires pour communiquer les informations sur la demande au routeur d'extrémité. Ces informations de configuration sont le débit, la taille de salve, et si le type est Premium ou Assuré. Il peut aussi y avoir besoin d'un champ spécifique pour établir ou ôter cette configuration. Ces informations peuvent être passées d'un certain nombre de façons, y compris en utilisant la sémantique de RSVP, de SNMP, ou être directement établies par l'administrateur de réseau d'une autre façon. Il doit y avoir un mécanisme pour authentifier l'envoyeur de ces informations. On s'attend à ce que la configuration soit faite de façons diverses dans les déploiements précoces et un protocole avec un mécanisme pour cela est un sujet pour les travaux de normalisation futurs.

3.3   Discussion

Les exigences des formateurs motivent leur placement aux bordures du réseau où l'état pour chaque routeur peut être plus petit que dans le milieu d'un réseau. La plus grosse charge de mise en correspondance et de formatage des flux sera sur les routeurs d'extrémité où la vitesse et les exigences de mémoire tampon devraient être inférieures à celles qui seraient nécessaires plus loin dans le réseau. Cette fonctionnalité n'est pas exigée à chaque élément de réseau sur le chemin. Les routeurs qui sont à l'intérieur d'une région de confiance n'auront pas besoin de formater le trafic. Les routeurs frontières peuvent avoir besoin de, ou désirer, formater le flux agrégé de paquets marqués à leur sortie afin de s'assurer qu'il ne vont pas faire des salves non conformes au mécanisme de régulation à leur entrée dans l'autre domaine (bien que cela puisse n'être pas nécessaire si le nombre d'arêtes entrantes du routeur est faible). De plus, le formatage serait appliqué à une agrégation de tous les flux Premium qui sortent du domaine via ce chemin, et non à chaque flux individuel.

Ces mécanismes sont à la portée des technologies actuelles et il nous semble plausible que les services Premium et Assuré soient tout ce qui est nécessaire dans l'Internet. Si, en leur temps, ces services sont trouvés insuffisants, cette architecture prévoit un chemin de migration pour la livraison d'autres sortes de niveaux de service au trafic. Les bits A et P continueraient d'être utilisés pour identifier le trafic qui obtient un service de marquage, mais une analyse de filtrage plus poussée pourrait être faite sur les en-têtes de paquets pour encore différencier les niveaux de service. Utiliser les bits de cette façon réduit le nombre de paquets qui doivent subir d'autres correspondances plutôt que de filtrer chaque paquet entrant. D'autres niveaux de file d'attente et des programmations plus complexes pourraient être ajoutés pour le trafic de bit P et d'autres niveaux de priorité d'abandon pourraient être ajoutés pour le trafic de bits A si l'expérience montre qu'ils sont nécessaires, et que les vitesses de traitement sont suffisantes. Nous proposons que les services décrits ici soient considérés comme des services "a minima". Donc, un élément de réseau devrait au moins être capable de transposer tout le trafic de bits P en service Premium et de transposer tout le trafic de bit A pour qu'il soit traité avec le premier niveau de priorité dans la file d'attente "au mieux" (il apparaît qu'un seul niveau de trafic de bit A devrait se transposer en une priorité qui soit équivalente au meilleur niveau dans un élément multi niveau qui serait aussi dans le chemin).

D'un autre côté, quel est l'inconvénient de déployer une architecture pour les deux classes de service si l'expérience ultérieure nous convainc qu'un seul d'entre eux est nécessaire ? Les blocs fonctionnels des deux classes de service sont similaires et peuvent être fournis par le même mécanisme, paramétré différemment. Si le service Assuré n'est pas utilisé, la perte est faible. Une file d'attente au mieux gérée par RED a été fortement recommandée dans [4] et, dans la mesure où le déploiement de cette architecture pousse au déploiement des files d'attente au mieux gérées par RED, c'est clairement positif. Si le service Premium se trouve inutilisé, les deux files d'attente avec un service à simple priorité ne sont pas nécessaires et la fonction de formatage du marqueur peut ne pas servir, donc, cela imposerait un coût de mise en œuvre inutile.

4.   Cadre architectural pour l'allocation du trafic marqué

Nous nous sommes concentrés jusqu'à présent sur les définitions de service et les mécanismes du chemin de transmission. Tournons nous maintenant vers le problème de l'allocation du niveau de trafic marqué à travers l'Internet. On observe que la plupart des organisations ont fixé une portion de leur budget, y compris de communications de données, qui est déterminée annuellement ou trimestriellement. Quelques financements supplémentaires peuvent être consacrés à des projets spécifiques pour des coûts discrétionnaires qui surviennent à court terme. De leur côté, les fournisseurs de service (FAI et opérateurs) doivent faire leurs prévisions sur des bases annuelles ou trimestrielles et donc ne sont pas censés fournir des services différenciés purement "à la demande". L'approvisionnement établit des niveaux statiques de trafic marqué alors que l'établissement d'appel crée une allocation de trafic marqué pour la durée d'un seul flux. Les niveaux statiques peuvent être approvisionnés avec des spécifications heure par heure, mais ne peuvent pas être changés en réponse à un message dynamique. On s'attend à ce que les deux sortes d'allocation de bande passante soient importantes. On peut s'attendre à ce que les acheteurs de services marqués travaillent sur des cycles budgétaires à long terme où ces services seront comptabilisés de la même façon que de nombreux services d'information aujourd'hui. Une entreprise de vente par correspondance peut souhaiter acheter une allocation fixe de bande passante en entrée et en sortie de son serveur de la Toile pour donner à ses abonnés un sentiment de rapidité d'accès lorsqu'ils consultent son site. Cette allocation peut être fondée sur le nombre de consultations du trimestre précédent ou sur des moyennes d'activité. De plus, il faut qu'il y ait une capacité d'allocation dynamique pour répondre à des événements particuliers, tels qu'une manifestation, une émission du directeur de l'entreprise, ou un essai de réseau particulier. De plus, une capacité dynamique peut être nécessaire pour satisfaire un niveau de service résultant d'un engagement antérieur lorsque la source ou destination particulière peut être "n'importe où dans l'Internet". "Dynamique" couvre une gamme qui va d'une demande téléphonée ou résultant d'un message électronique à un modèle de type de signalisation. Un scénario d'allocation strictement statique est supposé être utile dans le déploiement initial des services différenciés et pour constituer une portion majeure du trafic marqué dans un avenir prévisible.

Sans un établissement dynamique "appel par appel", la pré configuration des profils d'usage peut toujours être perçue comme "payer pour les bits qu'on utilise pas", que le type de service soit Premium ou Assuré. On préfère voir cela comme payer pour le niveau de service disponible à tout moment qu'on s'attend à avoir, par exemple, de payer pour une ligne téléphonique. Un consommateur peut payer un forfait supplémentaire pour avoir le privilège d'appeler dans une large zone locale sans coûts supplémentaires au lieu de payer pour l'appel. Bien qu'un usager puisse payer à l'appel pour tous les appels qu'il fait vers toutes les destinations, c'est généralement l'option qui se révèle la plus économique pour la plupart des usagers. Il est possible que des structures de tarification similaires apparaissent dans l'internet.

Nous utilisons le terme d'allocation pour nous référer au processus de prise d'engagements de trafic marqué tout le long du continuum qui va de la pré allocation stricte à l'établissement d'appel dynamique et nous demandons à une architecture d'allocation qu'elle soit capable d'englober toutes les combinaisons de la totalité du spectre. On observe en outre que l'allocation doit suivre des hiérarchies organisationnelles, c'est-à-dire que chaque organisation doit avoir une responsabilité complète de l'allocation de la ressource de trafic marqué au sein de son domaine. Finalement, on observe que la seule chance de succès d'un déploiement incrémentaire réside dans une architecture d'allocation qui soit constituée d'accords bilatéraux, car les accords multilatéraux sont beaucoup trop complexes à administrer. Donc, l'architecture d'allocation est constituée d'accords à travers les frontières portant sur les quantités de trafic marqué qui pourra les franchir. Ceci est similaire aux modèles de "taxes de répartition" en vigueur aujourd'hui.

4.1   Courtiers en bande passante : Allocation et contrôle des parts de bande passante

Le but des services différenciés est le partage contrôlé de la bande passante Internet de certaines organisations. Le contrôle peut être fait de façon indépendante par des individus, c'est-à-dire, les utilisateurs établissent un ou des bits dans leurs paquets pour distinguer leur trafic plus important, ou cela peut être fait par des agents qui ont connaissance des priorités et des politiques de l'organisation, et allouent la bande passante en fonction de ces politiques. L'étiquetage indépendant par des individus est simple à mettre en œuvre mais sera vraisemblablement insuffisant car il n'est pas raisonnable de penser que des individus connaissent toutes les priorités et l'utilisation actuelle du réseau de leur organisation et marquent toujours son trafic en accord avec elles. Cette architecture est donc conçue avec des agents appelés courtiers en bande passante (BB, Bandwidth Broker) [2], qui peuvent être configurés avec les politiques organisationnelles, garder trace de l'allocation actuelle de trafic marqué, et interpréter les nouvelles demandes de marquage de trafic à la lumière des politiques et des allocations en cours.

On notera que de tels agents sont inhérents à toutes les notions de partage, sauf les plus triviales. Ni les individus ni les routeurs par qui transitent ces paquets n'ont les informations nécessaires pour décider quels paquets sont les plus importants pour l'organisation. Comme ces agents doivent exister, ils peuvent être utilisés pour allouer la bande passante pour les connexions de bout en bout avec beaucoup moins d'informations d'état et de plus simples relations de confiance que de déployer des garanties par flux ou par filtre dans tous les éléments de réseau sur un chemin de bout en bout. Les courtiers en bande passante rendent possible à l'allocation de bande passante de suivre les hiérarchies organisationnelles et, de concert avec les mécanismes de chemin de transmission exposés à la section 3, réduisent la quantité d'état requise pour établir et entretenir un flux sur des architectures qui exigent de vérifier l'en-tête de la totalité du flux à chaque élément de réseau. Du point de vue de l'organisation, l'architecture BB est motivée par l'observation que les accords multilatéraux fonctionnent rarement et que cette architecture permet de construire des services de bout en bout à partir d'accords purement bilatéraux. Les BB ont seulement besoin d'établir des relations de confiance limitées avec leurs homologues dans les domaines adjacents, à la différence des schémas qui exigent l'établissement de spécifications de flux dans les routeurs tout au long d'un chemin de bout en bout. En termes techniques pratiques, l'architecture BB rend possible de conserver l'état sur la base d'un domaine administratif, plutôt qu'à chaque routeur, et les définitions de service de Premium et Assuré rendent possible de confiner l'état par flux aux seuls routeurs d'extrémité.

Les BB ont deux responsabilités. La principale est de répartir les allocations de trafic marqué de leur région et d'établir les routeurs d'extrémité au sein du domaine local. L'autre est de gérer les messages qui sont envoyés à travers les frontières aux BB des régions adjacentes. Un BB est associé à une région de confiance particulière, une par domaine. Un BB a une base de données de politique qui conserve les informations sur qui peut faire quoi quand et une méthode d'utilisation de cette base de données pour authentifier les demandeurs. Seul un BB peut configurer les routeurs d'extrémité pour délivrer un service particulier aux flux, ce qui est crucial pour déployer un système sûr. Si le déploiement des services différenciés a avancé jusqu'au stade où des flux marqués alloués de façon dynamique sont possibles entre deux domaines adjacents, les BB fournissent aussi le moyen nécessaire pour le mettre en œuvre. Chaque BB de domaine établit une association sécurisée avec ses homologues dans le domaine adjacent pour négocier ou configurer un débit et une classe de service (Premium ou Assuré) à travers la frontière commune et à travers le domaine de l'homologue. Comme nous le verrons, il est possible dans certains types de service et en particulier dans les premières mises en œuvre, que cette "association de sécurité" ne soit pas automatique mais accomplie par une négociation humaine et une configuration subséquente manuelle des BB adjacents conformément à l'accord négocié. Ce débit négocié est une capacité qu'un BB contrôle pour tous les hôtes dans sa région.

Lorsque une allocation est désirée pour un flux particulier, une demande est envoyée au BB. Les demandes comportent un type de service, un débit cible, une taille de salve maximum, et la période à laquelle le service est demandé. La demande peut être faite manuellement par un administrateur de réseau ou par un usager ou elle peut venir du BB d'une autre région. Un BB authentifie d'abord les accréditifs du demandeur, puis vérifie qu'il existe une bande passante non allouée suffisante pour satisfaire la demande. Si une demande réussit ces essais, la bande passante disponible est réduite de la quantité demandée et la spécification du flux est enregistrée. Dans le cas où le flux a une destination en dehors de cette région de confiance, la demande doit tomber dans l'allocation de classe à travers la région de confiance du "prochain bond" qui a été établie par un accord bilatéral des deux régions de confiance. Le BB du demandeur informe le BB de la région adjacente qu'il va utiliser une partie de cette allocation de débit. Le BB configure le routeur d'extrémité approprié avec les informations sur le flux de paquets auquel le service est donné à l'heure où le service doit commencer. Cette configuration est un "état conditionnel" que le BB va rafraîchir périodiquement. Le BB dans la région adjacente est responsable de la configuration du routeur frontière pour permettre au flux de paquet alloué de passer et des configurations et négociations supplémentaires au sein et à travers ses frontières qui vont permettre au flux d'atteindre sa destination finale.

Dans les réseaux intermédiaires, il doit y avoir une façon non ambiguë de déterminer la source locale d'un paquet. La source d'une interface peut être déterminée à partir de son adresse MAC qui serait alors utilisée pour classer les paquets comme venant à travers une liaison logique directement du domaine source correspondant à cette adresse MAC. Cela étant compris, nous pouvons dont continuer à utiliser les figures qui illustrent un seul tuyau entre deux différents domaines.

De cette façon, tous les accords et négociations sont effectués entre deux domaines adjacents. Une demande initiale peut causer une communication entre les BB sur plusieurs domaines le long d'un chemin, mais chaque communication est seulement entre deux BB adjacents. Au départ, ces accords seront pré négociés et très statiques. Certains pourront devenir plus dynamiques avec l'évolution du service.

4.2   Exemples

Ce paragraphe donne des exemples des transactions de BB dans un domaine multi transit Internet non trivial. Le cadre des BB permet des points de fonctionnement qui vont de "pas de signalisation à travers les frontières" à "chaque flux est établi de façon dynamique". On peut s'attendre à un déplacement le long de ce spectre de possibilités avec le temps, lorsque les mécanismes nécessaires seront universellement déployés et que les BB deviendront plus sophistiqués, mais la portion du spectre des possibilités qui est allouée de façon statique devrait toujours avoir son utilité. Nous pensons que la capacité à prendre en charge simultanément ce large spectre de choix sera importante à la fois dans le déploiement incrémentaire et en permettant aux FAI de faire une large palette d'offres et de tarifs aux usagers. Les exemples de ce paragraphe suivent en gros la gamme d'une sophistication croissante. Noter que nous supposons que les domaines souscrivent à une certaine quantité de trafic marqué qui peut être demandé comme Assuré ou comme Premium dans chaque transaction individuelle d'établissement de flux. Les exemples disent "marqué" là, ou une transaction réelle spécifierait Assuré ou Premium.

Exemple de configuration statique sans échange de messages de BB : Ici, toutes les allocations sont pré allouées de façon statique à travers des accords purement bilatéraux entre utilisateurs (TCP individuels, hôtes individuels, réseaux universitaires, ou des FAI) [6]. Les allocations sont de la forme de profils d'utilisation de débit, taille de salve, est des heures durant lesquelles le profil doit être activé. Les usagers et les fournisseurs négocient ces profils qui sont ensuite installés dans le BB du domaine utilisateur et dans le BB de domaine du fournisseur. Aucune message de BB ne traverse la frontière ; on suppose que cette négociation est menée par des représentants humains de chaque domaine. Dans ce cas, les BB ont seulement à effectuer une de leurs deux fonctions, celle d'allouer ce profil au sein de leur domaine local. Il est même possible d'établir toutes ces sous allocations à l'avance et alors le BB a seulement à établir et supprimer le profil à l'heure voulue et à rafraîchir l'état conditionnel dans les routeurs d'extrémité. À partir du BB du domaine utilisateur, le profil est envoyé comme état conditionnel au routeur de premier bond du flux durant la période spécifiée. Ces profils peuvent être établis en utilisant RSVP, une variante de RSVP, SNMP, ou quelque mécanisme spécifique du fabricant. Bien que cette approche statique puisse fonctionner pour tout le trafic marqué, du fait de l'exigence stricte de non sur souscription, elle n'est appropriée que pour le trafic Premium pour autant qu'il s'en tienne à un faible pourcentage du chemin encombré à travers un domaine ou qu'il soit par ailleurs contraint par un comportement bien connu. Des restrictions similaires tiennent pour le trafic Assuré selon les attentes associées au service.

Dans la figure 6, on montre un exemple d'établissement d'un profil dans un routeur d'extrémité. Un profil d'usage a été négocié avec le FAI pour le domaine entier et le BB le morcelle comme demandé entre les flux individuels. Le mécanisme de routeur d'extrémité est celui qui est montré à la figure 3, avec le baquet de jetons réglé aux paramètres du profil d'usage. Le BB du FAI va configurer son propre profil mètre chez le routeur de sortie de ce consommateur pour s'assurer que le profil est tenu. Ce mécanisme est montrée à la figure 5. On suppose que la durée et l'heure de début pour tout profil actif sont conservées dans le BB. Le profil est envoyé à l'appareil d'entrée ou supprimé de l'appareil d'entrée par des messages envoyés à partir du BB. Dans cet exemple, on suppose que van@lbl veut parler à ddc@mit. Il est envoyé au LBL-BB une demande venant de Van qui demande que le service Premium soit alloué à un flux qui est désigné comme ayant l'adresse de source "V:4" et qui va à l'adresse de destination "D:8". Ce flux devrait être configuré pour un débit de 128 kbit/s et alloué de 13 h à 15 h. La demande doit être "signée" d'une façon sûre, vérifiable. La demande devrait être envoyée comme données au LBL-BB, un message électronique à un administrateur de réseau, ou par un appel téléphonique à un administrateur de réseau. Le LBL-BB reçoit ce message, vérifie qu'il y a 128 kbit/s de service Premium inutilisé pour le domaine de 13 à 15 h, puis envoie un message à Leaf1 qui établit un profil mètre approprié. Le message à Leaf1 peut être un message RSVP, ou SNMP, ou quelque méthode protégée. Tous les domaines traversés doivent avoir une capacité de réserve suffisante pour satisfaire cette demande.

Figure 6 : Courtier en bande passante qui établit des profils dans les routeurs d'extrémité

mètre à la frontière d'entrée de ESNet aurait un baquet de jetons réglé au taux de 100 kbit/s. (Il PEUT y avoir un formateur établi à la sortie de LBL pour garantir que le trafic marqué se conforme au profil agrégé.) Les tableaux à l'intérieur des "bulles" du réseau de transit montrent leurs bases de données de politique et reflètent les valeurs après l'achèvement de la transaction. Dans la Figure 7, V veut transmettre un flux de LBL à D chez MIT à 10 kbit/s. Comme dans la figure 6, une demande est faite pour ce profil par le BB de LBL. Le BB de LBL authentifie la demande et vérifie qu'il reste bien 10 kbit/s dans son allocation de service marqué dans cette direction. Ils y sont, de sorte que le BB de LBL passe un message au BB de ESNet pour dire qu'il aimerait utiliser 10 kbit/s de son allocation de trafic marqué pour ce flux. ESNet authentifie le message, vérifie dans sa base de données et voit qu'il a 10 kbit/s d'allocation de trafic marqué pour NEARNet (la prochaine région dans cette direction) qui est inutilisée. La politique est que le BB de ESNet doit toujours informer ("demander") au BB de NEARNet lorsque qu'il va utiliser une partie de son allocation. Le BB de NEARNET authentifie le message, vérifie dans sa base de données et découvre que 20 kbit/s de l'allocation pour MIT sont inutilisés et que la politique à cette frontière est de ne pas informer MIT lorsque une partie de l'allocation va être utilisée ("<50 ok" si l'allocation totale est de 50). Les lignes en pointillé indiquent la transaction "impliquée", c'est-à-dire, la transaction qui serait survenue si la politique n'avait pas dit "ne me demandez pas". Maintenant, chaque BB peut passer un message "ok" à cette demande à travers sa frontière. Cela permet à V d'envoyer à D, mais pas vice versa. Il serait aussi possible que la demande provienne de D.

Figure 7 : Exemple de bout en bout avec allocation statique

Considérons le même exemple où le BB d'ESNet trouve toute son allocation marquée pour NEARNet, 10 kbps, utilisée. Avec les allocations statiques, ESNet doit retransmettre un "non" à la demande du BB de LBL. Vraisemblablement, le BB de LBL va enregistrer cette information pour se plaindre à ESNet de la surréservation à la fin du mois ! Une solution à cette sorte de "signal d'occupation" est que ESNet anticipe mieux les besoins de ses clients ou exige des réservations longtemps à l'avance pour chaque flux, mais il est aussi possible que les décisions de courtage de bande passante deviennent dynamiques.

Figure 8 : Exemple d'allocation statique de bout en bout dans allocation restante

Allocation dynamique et mécanisme supplémentaire : Comme nous allons le voir, l'allocation dynamique exige des BB plus complexes ainsi qu'une politique aux frontières plus complexe, incluant la nécessité de conserver plus d'états. Cependant, elle permet un service important avec une faible augmentation d'état.

L'ensemble de figures suivant (qui commence avec la figure 9) montre ce qui arrive dans le cas d'allocation dynamique. Comme précédemment, V demande 10 kbit/s pour parler à D chez MIT. Comme l'allocation est dynamique, les régulateurs de frontière n'ont pas de valeur pré-établie, ayant à la place été réglés pour refléter la valeur actuelle de crête de trafic marqué à qui il est permis de traverser cette frontière. La demande est envoyée au BB LBL.

Figure 9 : Première étape de l'exemple d'allocation dynamique de bout en bout

À la figure 10, noter que ESNet n'a pas d'allocation établie avec NEARNet. Ce système est capable d'allocations dynamiques en plus des statiques, de sorte qu'il demande à NEARNet si il peut "ajouter 10" à son allocation en provenance de ESNet. Comme dans l'exemple de la figure 7, la politique de MIT est réglée à "ne pas demander" pour ce cas, de sorte que les lignes en pointillée représentent les "transactions implicites" dans lesquelles aucun message n'est échangé. Cependant, NEARNet met bien à jour son tableau pour indiquer qu'il utilise maintenant 20 kbit/s de l'allocation de trafic marqué pour MIT.

Figure 10: Seconde étape de l'exemple d'allocation dynamique de bout en bout

À la figure 11, nous voyons la troisième étape où le "ok virtuel" de MIT permet au BB de NEARNet de dire à son routeur frontière d'augmenter l'allocation de trafic marqué à travers la frontière ESNet-NEARNet de 10 kbit/s.

Figure 11 : Troisième étape de l'exemple d'allocation dynamique de bout en bout

La Figure 11 montre le "ok" du BB de NEARNet pour cette demande retransmise au BB de ESNet. Cela cause l'envoi d'un message par le BB de ESNet à son routeur frontière pour créer une sous classe de 10 kbit/s pour le flux "V->D". Ceci est exigé afin de s'assurer que les 10 bit/s qui ont juste été alloués de façon dynamique ne sont utilisés que pour cette connexion. Noter que cela exige bien que l'état par flux soit passé du BB de LBL au BB de ESNet, mais c'est la seule frontière que a besoin de ce niveau d'informations de flux et cette classification supplémentaire n'a besoin d'être faite qu'à ce routeur frontière là, et seulement sur les paquets venant de LBL. Donc, l'allocation dynamique exige une mesure de profil plus complexe que ce qui est montré à la figure 5.

Figure 12 : Quatrième étape de l'exemple d'allocation dynamique de bout en bout

Dans la figure 12, l routeur frontière ESNet donne le "ok" à la création d'une sous -classe, causant l'envoi par le BB de ESNet d'un "ok" au BB de LBL qui fait connaître à V que la demande a été approuvée.

Figure 13 : Étape finale de l'exemple d'allocation dynamique de bout en bout

Pour l'allocation dynamique, une version de base d'un programmeur CBQ [5] aurait toutes les fonctionnalités exigées pour établir les sous classes. RSVP fournit actuellement un moyen pour déplacer la TSpec pour le flux.

Pour les flux en diffusion groupée, on suppose que les paquets qui sont destinés à au moins une sortie peuvent être portés à travers un domaine à ce niveau de service à tous les points de sortie. Si une branche particulière de diffusion groupée a été souscrite au mieux lorsque les branches vers l'amont sont en trafic marqué, elle va avoir son réglage de bits purgé avant qu'elle ne traverse la frontière. Les informations requises pour cette identification de flux sont utilisées pour augmenter l'état existant qui est déjà conservé sur ce flux parce que c'est un flux en diffusion groupée. On note qu'on a déjà "saisi" ce flux, mais on doit maintenant éventuellement éliminer ce schéma binaire.

5.   RSVP/service intégré et cette architecture

Un grand travail a été accompli ces dernières années sur la définition de services intégrés pour l'internet et la spécification du protocole de signalisation RSVP. L'architecture à deux bits proposée dans cet ouvrage peut facilement interopérer avec ces spécifications. Dans cette section, nous exposons d'abord comment les mécanismes de transmission décrits à la section 3 peuvent être utilisés pour la prise en charge des services intégrés. Nous exposons ensuite comment RSVP pourrait interopérer avec la structure administrative des BB pour fournir un meilleur échelonnement.

5.1   Fourniture de la charge contrôlée et du service garanti

Nous pensons que les mécanismes de chemin de transmission décrits à la section 3 sont assez généraux pour qu'ils puissent aussi être utilisés pour fournir le service de charge contrôlée de [8] et une version de la qualité de service garantie de [9], comme développé par le groupe de travail int-serv. Noter d'abord que le service Premium peut être vu comme un cas forcé de service à charge contrôlée où la taille de salve est limitée à un seul paquet et où les paquets non conformes sont abandonnés. Un élément de réseau qui a mis en œuvre le mécanisme de prise en charge du service Premium peut facilement prendre en charge le service plus général de charge contrôlée en faisant un ou plusieurs ajustements mineurs de paramètres, par exemple, en relevant la contrainte sur la taille du baquet de jetons, ou en configurant le taux du service Premium avec le paramètre de taux de trafic de crête dans la spécification de la charge contrôlée, et en changeant l'action de régulation des paquets hors profil de l'abandon à l'envoi des paquets dans la file d'attente au mieux.

Il est aussi possible de mettre en œuvre la qualité de service garantie en utilisant les mécanismes du service Premium. D'après la RFC 2212 [9]: "La définition du service garanti s'appuie sur le résultat que le délai de fluidité d'un flux obéissent à un baquet de jetons (r, b) et servi par une ligne avec une bande passante R est lié par b/R tant que R n'est pas inférieur à r. Le service garanti avec un taux de service de R, où maintenant R est une part de la bande passante plutôt que la bande passante d'une ligne dédiée, approxime ce comportement." Le modèle de service de Premium convient clairement à ce modèle. La RFC 2212 déclare que "les datagrammes non conformes DEVRAIENT être traités comme des datagrammes au mieux." Donc, un profil mètre de régulation qui élimine les datagrammes non conformes serait acceptable, mais il est aussi possible de changer l'action pour les paquets non conformes de l'abandon à l'envoi à la file d'attente du trafic au mieux.

5.2   RSVP et les BB

Ce paragraphe expose comment la signalisation RSVP peut être utilisée en conjonction avec les BB décrits à la section 4 pour délivrer un établissement de ressource de bout en bout plus échelonnable pour les services intégrés. On note d'abord que l'architecture de BB a trois différences majeures avec le modèle original d'établissement de ressource RSVP :

1.   Il existe des relations de travail bilatérales a priori entre les BB de régions de confiance adjacentes avant qu'on puisse établir une allocation de ressource de bout en bout ; la signalisation en temps réel n'est utilisée que pour activer/confirmer la disponibilité de la bande passante pré négociée de trafic marqué, et pour réajuster de façon dynamique la quantité allouée si nécessaire. On note que cette signalisation en temps réel à travers les domaines n'est pas exigée, mais dépend de la nature de l'accord bilatéral (par exemple, l'accord pourrait déclarer "Je vous dirai chaque fois que je vais utiliser une partie de mon allocation" ou non).

2.   Quelques bits dans l'en-tête de paquet, c'est-à-dire, les bits P et A, sont utilisés pour marquer la classe de service de chaque paquet, donc une classification complète des paquets (en vérifiant tous les champs pertinents dans l'en-tête) ne doit être faite qu'une seule fois dans le routeur d'extrémité ; les paquets seront ensuite servis conformément au réglage de leur bit de classe.

3.   L'établissement de ressource RSVP suppose que des ressources seront réservées bond par bond à chaque routeur le long du chemin de bout en bout tout entier.

Les messages RSVP envoyés aux routeurs d'extrémité par les hôtes peuvent être interceptés et envoyés au BB du domaine local. Le BB traite le message et, si la demande est approuvée, transmet un message au routeur d'extrémité qui établit une classification de paquet par flux appropriée. Un message devrait aussi être envoyé au routeur frontière de sortie pour qu'il l'ajoute à l'allocation agrégée de trafic marqué en vue du formatage de paquets par le profil mètre sur le trafic sortant. (Il est possible que ce soit toujours réglé à l'allocation complète.) Un message RSVP doit être envoyé à travers la frontière aux routeur frontière du FAI adjacent, soit du routeur frontière du domaine local, soit du BB du domaine local. Si le FAI met aussi en œuvre RSVP avec un BB et un cadre Diff-serv, son routeur frontière transmet le message au BB local du FAI. Un processus similaire (à celui qui se fait dans le premier domaine) peut être réalisé dans le domaine du FAI, puis un message RSVP est transmis au prochain FAI le long du chemin. À l'intérieur d'un domaine, les paquets ne sont servis que conformément aux bits marqués. Le BB local sait exactement combien de trafic Premium est permis en entrée à chaque routeur frontière et de quel routeur frontière les paquets sortent.

6.   Recommandations

Le présent document a présenté une architecture de référence pour les services différenciés. Plusieurs variantes peuvent être envisagées, en particulier pour les premiers déploiements partiels, mais ces variantes ne seront pas toutes énumérées ici. Il y a eu ultérieurement une grande demande de la part du marché pour les services différenciés. Au titre d'un des nombreux efforts pour satisfaire cette demande, le présent mémoire trace les grandes lignes du cadre d'une architecture souple d'offre de services différenciés, et en particulier définit un ensemble simple de mécanismes de transmission de paquets pour la prise en charge de deux types de base de services différenciés. Bien que subsistent un certain nombre de problèmes et que des paramètres doivent être explorés et précisés, nous pensons qu'il est à la fois possible et faisable de commencer dès maintenant le déploiement incrémentaire de services différenciés. D'abord, étant donné que les mécanismes de base requis dans le chemin de transmission du paquet sont bien compris, les services Assuré et Premium peuvent tous deux être mis en œuvre dès aujourd'hui avec des BB à configuration manuelle et une allocation statique de ressource. Nous recommandons initialement des choix prudents sur la quantité de trafic marqué qui sera admis dans le réseau. Ensuite, nous prévoyons de poursuivre l'effort commencé par ce mémoire et les travaux expérimentaux des auteurs pour définir et déployer des BB de plus en plus sophistiqués. Nous espérons transformer l'expérience acquise dans les mises en œuvre d'essai ESNet et CAIRN en cours en futures propositions à l'IETF.

Les futures révisions du présent mémoire présenteront en détails les allocations fondées sur le receveur et de flux en diffusion groupée. Après la fin de cette étape, nous pensons que sera achevé le tableau de base d'un système échelonnable, robuste et sûr d'allocation et de gestion de ressources. Dans ce mémoire, nous avons décrit comment l'architecture proposée prend en charge deux services qui nous semblent fournir au moins un bon point de départ pour le déploiement à l'essai de services différenciés. Notre intention principale est de définir une architecture avec trois services, Premium, Assuré, et Au mieux, qui puissent être déterminés par des schémas binaires spécifiques, mais de ne pas empêcher des niveaux supplémentaires de différenciation au sein de chaque service. Il semble que des expérimentations et plus d'expérience sont nécessaires avant qu'on puisse normaliser plus qu'un niveau par classe de service. Notre approche du niveau de base nous dit que tout le monde doit fournir "au moins" les services Premium et Assuré comme décrit ici. Nous pensons fermement 1) que nous ne devrions pas essayer de définir, pour l'instant, quelque chose au delà de l'approche minimaliste des deux services et 2) que l'architecture que nous définissons doit être ouverte afin que d'autres niveaux de différenciation puissent être normalisés à l'avenir. Nous pensons que cette architecture est entièrement compatible avec les approches qui vont définir plus de niveaux de différenciation au sein d'un service particulier, si les bénéfices en sont bien compris.

7.   Remerciements

Les auteurs ont bénéficié de nombreuses discussions, à la fois directes et par messagerie électronique et souhaitent remercier particulièrement Dave Clark qui est responsable de la genèse de nombre des idées présentées ici, bien qu'il ne soit pas d'accord avec la totalité du contenu de ce document. Nous remercions aussi Sally Floyd pour ses commentaires sur le premier projet. Un commentaire de Jon Crowcroft est partiellement responsable de l'inclusion de la section 5. Les commentaires de Fred Baker nous ont fait essayer d'être plus clairs dans la définition des deux service de base, sans considération des schémas binaires utilisés pour les coder.

8.   Considérations sur la sécurité

Aucune considération sur la sécurité n'est associée au présent document.

9.   Références

(Les liens dans le corps du titre pointent sur la traduction française, ceux des numéros sur la version originale)

[1]   D. Clark, "Adding Service Discrimination to the Internet", Proceedings of the 23rd Annual Telecommunications Policy Research Conference (TPRC), Solomons, MD, octobre 1995.

[2]   V. Jacobson, "Differentiated Services Architecture", communication au groupe de travail Int-Serv à la réunion de Munich de l'IETF, août 1997.

[3]   Clark, D. and J. Wroclawski, "An Approach to Service Allocation in the Internet", Travail en cours, aussi communication de D. Clark dans Int-Serv WG à la réunion de Munich de l'IETF, août 1997.

[4]   B. Braden et autres, "Recommandations sur la gestion de file d'attente et l'évitement d'encombrement dans l'Internet", RFC2309, avril 1998.

[4]   R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", RFC2205, septembre 1997. (MàJ parRFC2750, RFC3936, RFC4495) (P.S.)

[5] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, pp 365-386, août 1995.

[6]   D. Clark, communication privée, octobre 26, 1997.

[7]   "Advanced QoS Services for the Intelligent Internet", Cisco Systems White Paper, 1997.

[8]   J. Wroclawski, "Spécification du service d'élément de réseau à charge contrôlée", RFC2211, septembre 1997. (P.S.)

[9]   S. Shenker, C. Partridge, R. Guerin, "Spécification de la qualité de service garantie", RFC2212, septembre 1997. (P.S.)

[10]   D. Clark and W. Fang, "Explicit Allocation of Best Effort packet Delivery Service", IEEE/ACM Transactions on Networking, août 1998, Vol 6, n° 4, pp. 362-373. aussi à : http:// diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf

Adresse des auteurs

Appendice : Une approche combinée des services différenciés dans l'Internet par David D. Clark

Après la présentation du projet draft-nichols-diff-svc-00, les co-auteurs ont eu une discussion avec Dave Clark et John Wroclawski dont il a résulté l'utilisation par Clark du créneau de présentation du projet à la réunion de décembre 1997 du groupe de travail Services intégrés de l'IETF. La lecture des transparents montre que c'est la proposition de Clark sur les "mécanismes", les "services", et les "règles" et sur la façon de procéder dans le processus de normalisation qui a servi de guide pour beaucoup du traitement retenu par le groupe de travail Services différenciés ultérieurement formé au sein de l'IETF. Nous pensons que la conférence de Dave Clark nous a donnés une approche solide pour traiter la qualité de service dans l'Internet d'une manière compatible avec ses principes.

Les transparents présentés au groupe de travail de décembre 1997 Services intégrés de l'IETF sont inclus dans la version postscript.

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les procédures des normes d' l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement fourni par la Internet Society.