21

INFORMATION

Les errata existent

Groupe de travail sur le réseau R. Braden

Appel à commentaires: 1633 ISI

Catégorie: Informationnel D. Clark

MIT S. Shenker Xerox PARC juin-94

Services intégrés dans l'architecture Internet: un aperçu

Statut de ce mémo

Ce mémo fournit des informations à la communauté Internet. Cette note ne spécifie aucune norme Internet d'aucune sorte. Distribution de cette note est illimitée.

Abstrait

Cette note discute d'une extension proposée à l'architecture Internet protocoles pour fournir des services intégrés, c’est-à-dire pour prendre en charge temps actuel ainsi que le service IP actuel en temps non réel. Ce l'extension est nécessaire pour répondre au besoin croissant de service en temps réel pour une variété de nouvelles applications, y compris la téléconférence, le séminaires, télescience et simulation distribuée.

Cette note représente le produit direct des travaux récents de Dave Clark, Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, John Wroclawski, Shai Herzog et Bob Braden, et s’appuie indirectement sur le travail de beaucoup d'autres.

1 introduction

Les multidiffusions des réunions de l’IETF sur Internet ont formé un expérience à grande échelle d’envoi de voix et de vidéos numérisées à travers un infrastructure à commutation de paquets. Ces expériences très visibles ont dépendu de trois technologies habilitantes. (1) Beaucoup de moderne les postes de travail sont désormais équipés d'un matériel multimédia intégré, y compris les codecs audio et les cartes d’images, et le nécessaire le matériel vidéo est désormais peu coûteux. (2) Multidiffusion IP, qui n’est pas encore généralement disponible dans les routeurs commerciaux, est fournie par le MBONE, un "backbone multicast" temporaire. (3) très sophistiqué des applications audio et vidéo numériques ont été développées.

Ces expériences ont également montré qu’un élément technique important est la toujours manquant: les applications en temps réel ne fonctionnent souvent pas bien Internet en raison des délais d'attente et de la congestion variables pertes. Internet, tel que conçu à l'origine, n'offre qu'un très qualité de service simple (QoS), données au mieux d'effort point à point livraison. Avant les applications en temps réel telles que la vidéo à distance, conférence multimédia, la visualisation et la réalité virtuelle peuvent être largement utilisé, l’infrastructure Internet doit être modifiée pour prendre en charge QoS en temps réel, offrant un certain contrôle sur les paquets de bout en bout retards. Cette extension doit être conçue dès le début pour multidiffusion; généraliser simplement de la monodiffusion (point à point) cas ne fonctionne pas.

La qualité de service en temps réel n'est pas le seul problème pour la prochaine génération de trafic gestion sur Internet. Les opérateurs de réseau demandent la possibilité de contrôler le partage de la bande passante sur un lien particulier parmi différentes classes de trafic. Ils veulent pouvoir diviser le trafic dans quelques classes administratives et attribuer à chacun un pourcentage minimal de la largeur de bande de liaison dans des conditions de surcharge, tout en permettant à la bande passante "inutilisée" d'être disponible à d'autres fois. Ces classes peuvent représenter différents groupes d'utilisateurs ou différentes familles de protocoles, par exemple. Une telle facilité de gestion est communément appelé le partage de lien contrôlé. Nous utilisons le terme services intégrés (IS) pour un modèle de service Internet qui comprend service au mieux, service en temps réel et partage de liaison contrôlé.

Les exigences et les mécanismes pour des services intégrés ont été les sujets de nombreuses discussions et recherches au cours des dernières années (la littérature est beaucoup trop volumineuse pour énumérer même un représentant échantillon ici; voir les références dans [CSZ92, Floyd92, Jacobson91, JSCZ93, Partridge92, SCZ93, RSVP93a] pour une liste partielle). Ce travail a conduit à l’approche unifiée du soutien aux services intégrés qui est décrit dans ce mémo. Nous croyons qu'il est maintenant temps de commencer l'ingénierie qui doit précéder le déploiement de services intégrés sur Internet.

La section 2 de ce mémo présente les éléments d’une extension IS du l'Internet. La section 3 traite des modèles de service en temps réel [SCZ93a, SCZ93b]. La section 4 traite du contrôle de la circulation, du transfert algorithmes à utiliser dans les routeurs [ CSZ92 ]. La section 5 traite de la conception de RSVP, un protocole de configuration de ressources compatible avec le hypothèses de notre modèle SI [ RSVP93a , RSVP93b ].

2 Éléments de l'architecture

Le modèle de service fondamental de l’Internet, tel qu’il est décrit dans le service de livraison IP au meilleur effort, n'a pas changé depuis le début du projet de recherche sur Internet il y a 20 ans [ CerfKahn74 ]. Nous proposons maintenant de modifier ce modèle pour englober la un service. D'un point de vue académique, changer le modèle de service de Internet est une entreprise majeure. cependant, son impact est atténué par le fait que nous souhaitons seulement étendre l'architecture originale. Les nouveaux composants et mécanismes à ajouter viendront compléter mais non remplacer le service IP de base.

En résumé, l’extension architecturale proposée est composée de deux éléments: (1) un modèle de service étendu, appelé modèle IS, et (2) un cadre de mise en œuvre de référence, qui nous donne un ensemble de vocabulaire et une organisation de programme générique pour réaliser le SI modèle. Il est important de séparer le modèle de service, qui définit le comportement visible de l’extérieur, de la discussion du mise en œuvre, qui peut (et devrait) changer au cours de la vie de la modèle de service. Cependant, les deux sont liés; faire le service modèle crédible, il est utile de donner un exemple de la manière dont il pourrait être réalisé.

2.1 Modèle de services intégrés

Le modèle IS que nous proposons comprend deux types de services ciblé sur le trafic en temps réel: garanti et prédictif un service. Il intègre ces services avec des liens contrôlés partage, et il est conçu pour fonctionner correctement avec multicast ainsi que unicast. Reportant un résumé du modèle IS à la section 3 , nous Tout d’abord, discutez de certaines hypothèses clés derrière le modèle. La première hypothèse est que les ressources (par exemple, la bande passante) doivent être explicitement gérée afin de répondre aux exigences de l'application. Cela implique que "réservation de ressources" et "contrôle d'admission" sont des éléments clés du service. Une approche alternative, que nous rejetons, est d'essayer de soutenir le trafic en temps réel sans modifications explicites du modèle de service Internet.

L’essence du service en temps réel réside dans l’exigence de garanties de service, et nous affirmons que ces garanties ne peuvent être réalisé sans réserves. Le terme "garantie" doit ici être interprété de manière large; ils peuvent être absolus ou statistiques, stricts ou approximatif. Cependant, l'utilisateur doit pouvoir obtenir un service dont la qualité est suffisamment prévisible pour que l'application puisse fonctionner de manière acceptable sur une durée déterminée par l'utilisateur. Encore une fois, "suffisamment" et "acceptable" sont des termes vagues. En général, les garanties plus strictes ont un coût plus élevé en ressources qui sont rendus indisponibles pour le partage avec d'autres.

Les arguments suivants ont été soulevés contre ressource garanties sur Internet.

o "La bande passante sera infinie."

La capacité de charge incroyablement grande d'une fibre optique amène certains à conclure que dans le futur, la bande passante sera si abondant, omniprésent et bon marché qu’il n’y aura pas de les retards de communication autres que la vitesse de la lumière, et par conséquent, il ne sera pas nécessaire de réserver des ressources. Cependant, nous pensons que cela sera impossible à court terme. terme et peu probable à moyen terme. Alors que la bande passante brute peut sembler peu coûteux, bande passante fournie en tant que service réseau n'est pas susceptible de devenir si bon marché que le gaspiller sera le principe de conception le plus rentable. Même si peu coûteux la bande passante finit par devenir couramment disponible, nous le faisons pas accepter qu’il soit disponible "partout" dans le L'Internet. Sauf si nous prévoyons la possibilité de traiter avec des liens encombrés, les services en temps réel seront tout simplement exclu dans ces cas. Nous trouvons cette restriction inacceptable.

o "La simple priorité est suffisante."

Il est vrai que donner simplement une priorité plus élevée au temps réel le trafic conduirait à un service adéquat en temps réel à certains fois et sous certaines conditions. Mais la priorité est un mécanisme de mise en œuvre, pas un modèle de service. Si on définit service au moyen d’un mécanisme spécifique, il se peut que nous n’ayons pas les caractéristiques exactes que nous voulons. En cas de priorité simple, le problème est que dès qu'il y a trop de temps réel flux en compétition pour la priorité la plus élevée, chaque flux est dégradé. Limiter notre service à ce seul échec le mode est inacceptable. Dans certains cas, les utilisateurs exigeront que certains flux réussissent tandis que certaines nouvelles demandes reçoivent un "occupé" signal".

o "Les applications peuvent s'adapter."

Le développement d'applications temps réel adaptatives, telles que Le programme audio Jacobson TVA, n'élimine pas la nécessité de délai de livraison des paquets liés. Besoins humains pour l'interaction et l'intelligibilité limitent l'éventail des possibilités adaptation aux délais du réseau. Nous avons vu en vrai des expériences qui, bien que la TVA puisse s’adapter aux retards de plusieurs secondes, les utilisateurs trouvent que l'interaction est impossible dans ces cas.

Nous concluons qu'il existe une exigence incontournable pour les routeurs pour pouvoir réserver des ressources, afin de fournir une qualité de service spéciale pour des flux de paquets utilisateur spécifiques, ou "flux". Cela à son tour nécessite un état spécifique du flux dans les routeurs, ce qui représente une changement important et fondamental du modèle Internet. le L’architecture Internet a été fondée sur le concept que tous l'état lié à l'écoulement devrait être dans les systèmes d'extrémité [ Clark88 ]. La conception de la suite de protocoles TCP / IP sur ce concept a conduit à une la robustesse qui est l’une des clés de son succès. Dans la section 5 nous discutons de la façon dont l'état de flux ajouté aux routeurs pour la ressource réservation peut être faite "soft", pour préserver la robustesse du Suite de protocole Internet.

Il y a un effet secondaire réel de la réservation de ressources dans routeurs. Comme cela implique que certains utilisateurs obtiennent des privilèges service, la réservation de ressources nécessitera l’application de la politique et contrôles administratifs. Cela conduira à deux types de exigences d'authentification: authentification des utilisateurs qui font demandes de réservation et l’authentification des paquets utilisant la ressources réservées. Cependant, ces problèmes ne sont pas propres à "IS"; d'autres aspects de l'évolution d'Internet, y compris commercialisation et la sécurité commerciale, conduisent au même exigences. Nous ne discutons pas des questions de politique ou de sécurité plus loin dans ce mémo, mais ils nécessiteront une attention particulière.

Nous faisons une autre hypothèse fondamentale, qu’il est souhaitable de utiliser Internet comme une infrastructure commune pour prendre en charge les utilisateurs non communication en temps réel et en temps réel. On pourrait alternativement construire une toute nouvelle infrastructure parallèle pour le temps réel services, laissant Internet inchangé. Nous rejetons cela approche, car elle perdrait les avantages importants de partage statistique entre trafic temps réel et non temps réel, et il serait beaucoup plus complexe à construire et à administrer qu’un infrastructure commune.

Outre cette hypothèse d’infrastructure commune, nous adoptons un modèle de pile de protocole unifié, utilisant une seule couche Internet protocole pour les services en temps réel et non temps réel. Ainsi, nous propose d'utiliser le protocole de couche Internet existant (par exemple, IP ou CLNP) pour les données en temps réel. Une autre approche consisterait à ajouter un nouveau protocole en temps réel dans la couche Internet [ ST2-90 ]. Notre unifié L’approche par pile offre une économie de mécanisme et nous permet de plier contrôlé le partage de lien dans facilement. Il gère également les problème de couverture partielle, c’est-à-dire permettre l’interopérabilité Systèmes Internet compatibles IS et systèmes qui n'ont pas encore été étendu, sans la complexité du tunneling.

Nous estimons qu’il devrait exister un modèle de service unique pour l'Internet. S'il y avait différents modèles de service dans différents certaines parties d’Internet, il est très difficile de voir comment des déclarations de qualité de service peuvent être faites. Cependant, un modèle de service unique n'implique pas nécessairement un seul mise en œuvre pour la planification des paquets ou le contrôle d'admission. Bien que la planification des paquets et le contrôle d’admission soient spécifiques mécanismes répondant à notre modèle de service ont été développés, Il est tout à fait possible que d’autres mécanismes satisfassent également le modèle de service. Le cadre de mise en œuvre de référence, introduit ci-dessous, est destiné à permettre la discussion des problèmes de mise en œuvre sans imposer un seul dessin.

Sur la base de ces considérations, nous pensons qu'une extension IS qui comprend un état de flux supplémentaire dans les routeurs et un mécanisme de configuration est nécessaire pour fournir le service requis. UNE Une solution partielle en deçà de ce point ne serait pas sage investissement. Nous croyons que les extensions que nous proposons préservent la robustesse et l'efficacité essentielles de l'Internet architecture, et ils permettent une gestion efficace du réseau Ressources; ce seront des objectifs importants même si la bande passante devient très bon marché.

2.2 Cadre de mise en œuvre de référence

Nous proposons un cadre d'implémentation de référence pour réaliser le SI modèle. Ce framework comprend quatre composants: le paquet planificateur, la routine de contrôle d'admission, le classificateur et le protocole de configuration de réservation. Ceux-ci sont discutés brièvement ci-dessous et plus en détail dans les sections 4 et 5 .

Dans la discussion qui a suivi, nous définissons l'abstraction du "flux" comme une flux distinctif de datagrammes liés qui résulte d'un activité mono-utilisateur et requiert la même qualité de service. Par exemple, un le flux peut consister en une connexion de transport ou un flux vidéo entre une paire d'hôtes donnée. C'est la plus fine granularité de paquet flux distinguable par le SI. Nous définissons un flux comme étant simplex, c'est-à-dire d'avoir une seule source mais N destinations. Ainsi, un N-way téléconférence nécessitera généralement N flux, un en provenance de chaque site.

Dans Internet actuel, la transmission IP est totalement égalitaire. tout les paquets reçoivent la même qualité de service, et les paquets sont généralement transmis en utilisant une stricte discipline de mise en file d'attente FIFO. Pour services intégrés, un routeur doit implémenter une QoS appropriée pour chaque flux, conformément au modèle de service. Le routeur fonction qui crée différentes qualités de service est appelée contrôle de la circulation. Le contrôle du trafic est à son tour mis en œuvre par trois composants: le planificateur de paquets, le classificateur et controle d'admission.

o Planificateur de paquets

Le planificateur de paquets gère le transfert de différents flux de paquets en utilisant un ensemble de files d'attente et peut-être d'autres des mécanismes comme des minuteries. Le planificateur de paquets doit être mis en œuvre au point où les paquets sont mis en file d'attente; c'est le niveau de pilote de sortie d'un système d'exploitation typique, et correspond au protocole de couche liaison. Les détails de la algorithme de planification peut être spécifique à la sortie particulière moyen. Par exemple, le pilote de sortie devra appeler les contrôles de couche liaison appropriés lors de l'interface avec un technologie de réseau qui a une allocation de bande passante interne mécanisme.

Un planificateur de paquets expérimental a été construit pour implémente le modèle IS décrit dans la section 3 et [SCZ93]; c'est ce qu'on appelle le planificateur CSZ et on en discute plus avant dans la section 4 . Nous notons que le schéma CSZ n'est pas obligatoire pour accomplir notre modèle de service; en effet pour des parties du réseau connu pour être toujours sous-chargé, la FIFO sera fournir un service satisfaisant.

Il y a un autre composant qui pourrait être considéré comme faisant partie de l'ordonnanceur de paquets ou séparé: l'estimateur [ Jacobson91 ]. Cet algorithme est utilisé pour mesurer les propriétés des données sortantes. flux de trafic, pour développer des statistiques qui contrôlent les paquets planification et contrôle d'admission. Ce mémo examinera l'estimateur faisant partie du planificateur de paquets.

o classificateur

Aux fins du contrôle du trafic (et de la comptabilité), chaque le paquet entrant doit être mappé dans une classe; tous les paquets dans la même classe reçoivent le même traitement du paquet planificateur. Ce mappage est effectué par le classificateur. Le choix d’une classe peut être fondé sur le contenu de la en-têtes de paquets existants et / ou certains numéro de classification ajouté à chaque paquet.

Une classe peut correspondre à une grande catégorie de flux, par exemple: tous les flux vidéo ou tous les flux imputables à un particulier organisation. D'autre part, une classe peut ne contenir qu'un flux unique. Une classe est une abstraction qui peut être locale à un routeur particulier; le même paquet peut être classifié différemment par différents routeurs le long du chemin. Pour exemple, les routeurs dorsaux peuvent choisir de mapper de nombreux flux dans un quelques classes agrégées, tandis que les routeurs plus proches de la périphérie, où il y a beaucoup moins d'agrégation, peut utiliser un classe pour chaque flux.

o Contrôle d'admission

Le contrôle d'admission implémente l'algorithme de décision qui routeur ou hôte utilise pour déterminer si un nouveau flux peut être accordé la qualité de service demandée sans impacter plus tôt des garanties. Le contrôle d'admission est appelé à chaque noeud pour rendre une décision locale d'acceptation / rejet, au moment où un hôte demande un service en temps réel le long d'un chemin à travers le L'Internet. L'algorithme de contrôle d'admission doit être cohérent avec le modèle de service, et il fait logiquement partie du trafic contrôle. Bien que des problèmes de recherche restent en suspens dans contrôle d'admission, une première coupe existe [ JCSZ92 ].

Le contrôle d’admission est parfois confondu avec maintien de l'ordre ou application, qui est une fonction paquet par paquet au bord du réseau pour s'assurer qu'un hôte ne viole pas ses caractéristiques de trafic promises. Nous considérons la police être l'une des fonctions du planificateur de paquets.

En plus de veiller à ce que les garanties de qualité de service soient remplies, le contrôle d'admission sera concerné par l'application politiques administratives sur les réservations de ressources. Certains les politiques exigeront l'authentification de ceux qui demandent Réservations. Enfin, le contrôle des entrées jouera un rôle important dans le reporting comptable et administratif.

La quatrième et dernière composante de notre cadre de mise en œuvre est un protocole de configuration de réservation, nécessaire pour créer et maintenir l'état spécifique du flux dans les hôtes d'extrémité et les routeurs le long du chemin d'un flux. La section discute d'une configuration de réservation protocole appelé RSVP (pour "ReSerVation Protocol") [RSVP93a, RSVP93b]. Il n’est peut-être pas possible d’insister pour qu’il n’y ait qu’un seul protocole de réservation sur Internet, mais nous ferons valoir que les choix multiples pour les protocoles de réservation vont semer la confusion. Nous pensons que plusieurs protocoles ne devraient exister que s’ils soutenir différents modes de réservation.

Configuration requise pour la partie de partage de lien du service les modèles sont beaucoup moins clairs que ceux des réservations de ressources. Bien que nous nous attendions à ce que cela soit possible en grande partie via le réseau interfaces de gestion, et ne doivent donc pas nécessairement faire partie de la l’architecture, nous aurons peut-être aussi besoin de RSVP pour jouer un rôle l'état requis.

Pour énoncer ses besoins en ressources, une application doit spécifier la QoS souhaitée à l'aide d'une liste de paramètres appelée un "flowspec" [ Partridge92 ]. Le flowpec est porté par le protocole de configuration de réservation, passé au contrôle d'admission pour tester l'acceptabilité, et finalement utilisé pour paramétrer la mécanisme de planification de paquets.

La figure montre comment ces composants peuvent s'intégrer dans un routeur IP qui a été étendu pour fournir des services intégrés. Le routeur comporte deux grandes divisions fonctionnelles: le chemin de transmission situé au-dessous du double ligne horizontale et le code d’arrière-plan au-dessus de la ligne.

Le chemin de transmission du routeur est exécuté pour chaque paquet et doit donc être hautement optimisé. En effet, dans la plupart des commerces routeurs, sa mise en œuvre implique une assistance matérielle. le chemin de transmission est divisé en trois sections: pilote d'entrée, Internet transitaire et pilote de sortie. Le transitaire internet interprète l'en-tête de protocole d'interconnexion de réseau approprié au suite de protocoles, par exemple, l'en-tête IP pour TCP / IP ou l'en-tête CLNP pour OSI. Pour chaque paquet, un redirecteur Internet exécute un classificateur dépendant de la suite puis passe le paquet et son classe au pilote de sortie approprié. Un classificateur doit être à la fois général et efficace. Pour plus d'efficacité, un mécanisme commun devrait être utilisé pour la classification des ressources et la recherche d'itinéraire.

Le pilote de sortie implémente le planificateur de paquets. (Layerists observera que le pilote de sortie a maintenant deux sections distinctes: le planificateur de paquets qui est en grande partie indépendant du détail la mécanique de l’interface, et le pilote d’E / S réel qui est seulement préoccupé par la granularité du matériel. L'estimateur vit quelque part entre les deux. Nous notons seulement ce fait, sans suggérant que cela devienne un principe.).

_____________________________________________________________
|  ____________ ____________ ___________ |
|  |  |  |  Réservation |  |  |  |
|  |  Routage |  |  Setup |  |  Gestion |  |
|  |  Agent |  |  Agent |  |  Agent |  |
|  | ______._____ |  | ______._____ |  | _____._____ |  |
|  .  .  |  .  |
|  .  .  _V________.  |
|  .  .  |  Entrée |  .  |
|  .  .  |  Contrôle |  .  |
|  V.  | __________ |  .  |
|  [Routage] VV |
|  [Base de données] [Base de données de contrôle du trafic] |
| ============================================== ============ |
|  |  |  _______ |
|  |  __________ |  | _ | _ | _ | _ |  => o |
|  |  |  |  |  Paquet |  _____ |
|  ====> | Classificateur |  =====> Planificateur | ===> | _ | _ | _ |  ===>
|  |  | __________ |  |  _______ |  |
|  |  |  | _ | _ | _ | _ |  => o |
|  Entrée |  Internet |  |
|  Conducteur |  Transitaire |  O utput D river |
| ________ | __________________ | _________________________________ |

Figure 1: Modèle de référence d'implémentation pour les routeurs

Le code d’arrière-plan est simplement chargé dans la mémoire du routeur et exécuté par une CPU polyvalente. Ces routines de fond créer des structures de données qui contrôlent le chemin de transfert. le agent de routage implémente un protocole de routage particulier et construit une base de données de routage. L'agent de configuration de réservation implémente le protocole utilisé pour configurer les réservations de ressources; voir section . Si Le contrôle d'admission donne le "OK" pour une nouvelle demande, le les modifications appropriées sont apportées au classificateur et au paquet base de données du planificateur pour mettre en œuvre la QoS souhaitée. Enfin, chaque Le routeur prend en charge un agent pour la gestion du réseau. Cet agent doit pouvoir modifier les bases de données du classificateur et du planificateur de paquets pour mettre en place un partage de liaison contrôlé et définir le contrôle d'admission politiques.

Le cadre de mise en œuvre pour un hôte est généralement similaire à que pour un routeur, avec l'ajout d'applications. Plutôt que en cours de transfert, les données de l'hôte commencent et se terminent dans application. Une application nécessitant une QoS en temps réel pour un flux doit en quelque sorte appeler un agent de configuration de réservation local. La meilleure façon l'interface avec les applications reste à déterminer. Pour Par exemple, il pourrait y avoir une API explicite pour la ressource réseau configuration, ou la configuration peut être invoquée implicitement dans le cadre du fonction de planification du système d'exploitation. La routine de sortie IP d’un l’hôte peut ne pas avoir besoin d’un classifieur, puisque l’affectation de classe le paquet peut être spécifié dans la structure de contrôle d'E / S locale correspondant au flux.

Dans les routeurs, le service intégré nécessitera des modifications à la fois chemin de transfert et les fonctions d'arrière-plan. La réexpédition chemin, qui peut dépendre de l'accélération matérielle pour la performance, sera le plus difficile et coûteux à changer. Ce sera vital de choisir un ensemble de mécanismes de contrôle du trafic qui soit général et adaptable à une grande variété d'exigences politiques et futures circonstances, et cela peut être mis en œuvre efficacement.

3 Modèle de services intégrés

Un modèle de service est intégré à l'interface de service réseau invoqué par les applications pour définir l'ensemble des services qu'elles peuvent demande. Alors que la technologie de réseau sous-jacente et la suite d’applications sous-jacentes évoluera, la nécessité de la compatibilité nécessite que cette interface de service reste relativement stable (ou plus exactement extensible; nous nous attendons à ajouter de nouveaux services à l’avenir, mais nous espérons aussi qu’il sera difficile de changer les services existants). En raison de son impact durable, le modèle de service ne doit pas être conçu en référence à une artefact de réseau, mais devrait plutôt être basé sur le service fondamental exigences.

Nous décrivons maintenant brièvement une proposition concernant un ensemble de services de base pour le L'Internet; Ce modèle de service de base proposé est décrit plus en détail dans [ SCZ93a , SCZ93b ]. Ce modèle de service de base s’adresse à ces services qui se rapportent le plus directement au moment de la livraison des paquets. nous laisser les services restants (tels que le routage, la sécurité ou le flux synchronisation) pour d’autres lieux de normalisation. Un modèle de service se compose d'un ensemble d'engagements de service; en réponse à un service demander au réseau de s’engager à fournir certains services. Ces service les engagements peuvent être classés par entité à qui ils sont faits: ils peuvent être faits à des flux individuels ou à des entités collectives (classes de flux). Les engagements de service pris pour des flux individuels sont destinés à fournir une performance d'application raisonnable, et donc sont guidés par les exigences ergonomiques des applications; celles-ci engagements de service ont trait à la qualité du service fourni à un flux individuel. Les engagements de service pris envers les entités collectives sont motivés par le partage des ressources ou par des impératifs économiques; celles-ci les engagements de service concernent les ressources globales mises à disposition aux différentes entités.

Dans cette section, nous commençons par explorer les exigences de service de flux individuels et propose un ensemble de services correspondant. nous puis discuter des exigences de service et des services pour les ressources partage. Enfin, nous concluons avec quelques remarques sur le paquet goutte.

3.1 Exigences de qualité de service

Le modèle de service de base concerne presque exclusivement le heure de livraison des paquets. Ainsi, le délai par paquet correspond au délai quantité centrale sur laquelle le réseau fournit la qualité de service engagements. Nous faisons l'hypothèse encore plus restrictive que la seule quantité sur laquelle nous faisons un service quantitatif les engagements sont des limites sur les délais maximum et minimum.

La mesure dans laquelle les performances de l'application dépendent d'un faible délai le service varie considérablement et nous pouvons faire plusieurs analyses qualitatives. distinctions entre les applications en fonction du degré de leur dépendance. Une classe d'applications a besoin des données dans chaque paquet à une certaine heure et, si les données ne sont pas arrivées à ce moment-là, les données sont essentiellement sans valeur; nous appelons ces temps réel applications. Une autre classe d'applications attendra toujours données à arriver; nous appelons ces applications "élastiques". Nous maintenant considérons les exigences de délai de ces deux classes séparément.

3.1.1 Applications en temps réel

Une classe importante de telles applications temps réel, qui sont les seules applications en temps réel que nous considérons explicitement dans le les arguments qui suivent sont des applications de "lecture". Dans un application de lecture, la source prend un signal, paquetise puis transmet les paquets sur le réseau. le réseau introduit inévitablement une certaine variation dans le délai de les paquets livrés. Le récepteur dépackète les données et tente ensuite de reproduire fidèlement le signal. C'est fait en tamponnant les données entrantes puis en rejouant le signal à certains délais compensés fixes par rapport à l'heure de départ initiale; la le terme "point de lecture" désigne le point dans le temps qui est décalé par rapport à l'heure de départ d'origine par ce délai fixe. Toutes les données qui arrivent avant le point de lecture associé peuvent être utilisé pour reconstruire le signal; données arrivant après la le point de lecture est essentiellement inutile dans la reconstruction du signal en temps réel.

Afin de choisir une valeur raisonnable pour le délai de décalage, un demande nécessite une caractérisation "a priori" de la délai maximum que ses paquets connaîtront. Cet "a priori" la caractérisation pourrait être fournie par le réseau dans un engagement de service quantitatif à un délai lié, ou par l'observation des retards subis par la précédente paquets arrivés; l'application doit savoir quels délais attendre, mais cette attente n’a pas besoin d’être constante pour toute la durée du flux.

Les performances d’une application de lecture sont mesurées sur deux dimensions: latence et fidélité. Quelques applications de lecture, en particulier ceux qui impliquent une interaction entre les deux les extrémités d’une connexion, comme un appel téléphonique, sont plutôt sensibles à la latence; autres applications de lecture, telles que transmettre un film ou une conférence, ne le sont pas. De même, applications présentent un large éventail de sensibilité à la perte de fidélité. Nous considérerons deux artificiellement deux classes dichotomiques: applications intolérantes, qui nécessitent une lecture absolument fidèle, et les applications tolérantes, qui peut tolérer une perte de fidélité. Nous nous attendons à ce que le vaste la plupart des applications audio et vidéo seront tolérantes, mais nous soupçonnent également qu’il y aura d’autres applications, telles que émulation de circuit, qui sont intolérants.

Le retard peut affecter les performances des applications de lecture en deux manières. Tout d'abord, la valeur du délai de décalage, qui est déterminé par les prévisions concernant les retards de paquets futurs, détermine la latence de l'application. Deuxièmement, les retards de paquets individuels peut diminuer la fidélité de la lecture en dépassant le délai de décalage; l'application peut alors soit changer le délai de décalage afin de lire les paquets en retard (qui introduit de la distorsion) ou simplement rejeter les paquets en retard (ce qui crée un signal incomplet). Les deux manières différentes de faire face aux paquets en retard offrent un choix entre un signal incomplet et déformé, et le choix optimal dépendra des détails de l'application, mais la Le point important est que les paquets en retard diminuent nécessairement fidélité.

Les applications intolérantes doivent utiliser un délai de décalage fixe, car toute variation du délai de décalage introduira une certaine distorsion dans la lecture. Pour une distribution de paquet donnée retards, ce délai de décalage fixe doit être supérieur au délai délai maximum absolu, pour éviter toute possibilité de retard paquets. Une telle application ne peut définir que son délai de décalage de manière appropriée si on lui donne une limite supérieure parfaitement fiable sur le délai maximum de chaque paquet. Nous appelons un service caractérisé par une limite supérieure du délai parfaitement fiable " service garanti ", et le propose comme moyen approprié modèle de service pour les applications de lecture intolérantes.

En revanche, les applications tolérantes n'ont pas besoin de définir leur décalage délai supérieur au délai maximum absolu, car ils peuvent tolérer certains paquets en retard. De plus, au lieu d’utiliser un seule valeur fixe pour le délai de décalage, ils peuvent essayer de réduire leur temps de latence en faisant varier les délais de réponse aux retards de paquets réels enregistrés au cours des dernières années. nous les applications d’appel qui modifient leurs délais de décalage de cette manière applications de lecture "adaptative".

Pour les applications tolérantes, nous proposons un modèle de service appelé " service prédictif "qui fournit un service assez fiable, mais pas parfaitement fiable, délai lié. Cette limite, contrairement à la borne dans le service garanti, ne repose pas sur le pire des cas hypothèses sur le comportement des autres flux. Au lieu de cela, cela lié pourrait être calculé avec des prédictions bien conservatrices sur le comportement des autres flux. Si le réseau s'avère être se tromper et le lien est violé, l'application de les performances vont peut-être en souffrir, mais les utilisateurs sont prêts à tolérer de telles interruptions de service en contrepartie de la coût présumé moins élevé du service. En outre, parce que beaucoup des applications tolérantes sont adaptatives, nous augmentons la service prédictif de donner également le service "minimax", qui consiste à tenter de minimiser le délai maximum ex post. Ce service est ne cherche pas à minimiser le délai de chaque paquet, mais plutôt à essayer de tirer dans la queue de la distribution de retard.

Il est clair que, étant donné le choix, toutes les autres choses étant égale, une application ne serait pas pire avec absolument limites fiables qu'avec des limites assez fiables. Pourquoi alors, offrons-nous un service prédictif? La considération clé ici est Efficacité; quand on assouplit les exigences de service de parfaitement à des limites assez fiables, cela augmente le niveau d’utilisation du réseau pouvant être maintenue, et donc la le prix du service prédictif sera vraisemblablement inférieur à celui du service garanti. La classe de service prédictive est motivé par la conjecture que la pénalité de performance sera être petit pour les applications tolérantes mais l'efficacité globale le gain sera assez important.

Afin de fournir un délai lié, la nature du trafic de la source doit être caractérisé, et il doit y avoir quelques algorithme de contrôle d'admission qui assure qu'un flux demandé peut effectivement être logé. Un point fondamental de notre l'architecture globale est que la caractérisation du trafic et le contrôle d'admission est nécessaire pour ces délais en temps réel liés prestations de service. Jusqu'à présent, nous avons supposé que les données d'une application processus de génération est une propriété intrinsèque non affectée par la réseau. Cependant, il y aura probablement beaucoup de contenus audio et vidéo applications qui peuvent ajuster leur schéma de codage et ainsi modifier le processus de génération de données résultant en fonction de la service de réseau disponible. Cette modification du codage Le schéma présentera un compromis entre la fidélité (du code de codage) schéma lui-même, pas du processus de lecture) et la bande passante exigences du flux. Une telle lecture "adaptative" les applications ont l’avantage de pouvoir s’adapter à la les conditions réseau actuelles non seulement en réinitialisant leur lecture point, mais aussi en ajustant le profil de trafic lui-même. Pour applications à adaptation de débit, les caractérisations de trafic utilisées dans l'engagement de service ne sont pas immuables. Nous pouvons donc augmenter le modèle de service en permettant au réseau de notifier (soit implicitement par l’abandon de paquets, soit explicitement par paquets de contrôle) applications à débit adaptatif pour changer leur caractérisation du trafic.

3.1.2 Applications élastiques

Bien que les applications en temps réel n’attendent pas les données en retard arriver, les applications élastiques attendront toujours que les données arrivée. Ce n’est pas que ces applications soient insensibles à la retard; au contraire, augmentant de manière significative le délai d’un Ce paquet nuit souvent aux performances de l'application. Plutôt, le point clé est que l'application utilise généralement le les données arrivant immédiatement, plutôt que de les mettre en mémoire tampon pour certains plus tard, et choisira toujours d'attendre le courrier entrant données plutôt que de continuer sans elle. Parce que les données arrivant peuvent être utilisés immédiatement, ces applications ne nécessitent aucune caractérisation à priori du service afin de permettre application à fonctionner. De manière générale, il est probable que pour une distribution donnée de retards de paquets, la perception les performances des applications élastiques dépendront davantage de la délai moyen que sur la queue de la distribution de retard. Un peut penser à plusieurs catégories de telles applications élastiques: rafale interactive (Telnet, X, NFS), transfert de masse interactif (FTP), et transfert en bloc asynchrone (courrier électronique, fax). Les exigences de délai de ces applications élastiques varient de plutôt exigeant pour les applications interactives en rafale plutôt laxiste pour le transfert de masse asynchrone, avec le transfert de masse interactif le transfert étant intermédiaire entre eux.

Un modèle de service approprié pour les applications élastiques consiste à: fournir un service "dès que possible" ou ASAP. (Pour compatibilité avec l'utilisation historique, nous utiliserons le terme service au mieux lorsque vous vous référez au service ASAP.). nous proposons en outre d’offrir plusieurs classes de best-effort service afin de refléter la sensibilité relative des retards différentes applications élastiques. Ce modèle de service permet applications rafales interactives d'avoir des retards inférieurs à applications en vrac interactives, qui auraient à leur tour une plus faible retards que les applications asynchrones en bloc. Contrairement à la modèles de service en temps réel, les applications utilisant ce service sont non soumis au contrôle d'admission.

La taxonomie des applications en lecture tolérante, intolérante lecture, et élastique n'est ni exact ni complet, mais était utilisé uniquement pour guider le développement du modèle de service de base. Le modèle de service principal résultant ne doit pas être jugé sur la validité de la taxonomie sous-jacente, mais plutôt sur sa capacité répondre de manière adéquate aux besoins de tout le spectre des applications. En particulier, pas toutes les applications en temps réel sont des applications de lecture; par exemple, on pourrait imaginer un application de visualisation qui n'a fait que montrer l'image encodé dans chaque paquet quand il est arrivé. Cependant, les non Les applications de lecture peuvent toujours utiliser la garantie ou la modèle de service prédictif en temps réel, bien que ces services soient pas spécifiquement adaptés à leurs besoins. De même, la lecture les applications ne peuvent pas être soigneusement classées comme tolérantes ou intolérant, mais plutôt tomber dans un continuum; offrant les deux service garanti et prédictif permet aux applications de faire leur propre compromis entre fidélité, latence et coût. Malgré ces lacunes évidentes dans la taxonomie, nous nous attendons à qu'il décrit les exigences de service des utilisateurs actuels et futures applications assez bien pour que notre modèle de service de base peut répondre de manière adéquate à tous les besoins de l'application.

3.2 Exigences de partage de ressources et modèles de service

La dernière section a examiné les engagements en matière de qualité de service; celles-ci les engagements dictent la manière dont le réseau doit affecter ses ressources parmi les flux individuels. Cette allocation de ressources est généralement négocié sur une base de flux par flux comme chaque demande de flux l'admission au réseau, et ne traite pas de la politique problèmes qui se posent lorsque l’on regarde des collections de flux. À aborder ces questions de politique collective, nous discutons maintenant des partage des engagements de service. Rappelons que pour la qualité individuelle des engagements de service, nous nous sommes concentrés sur le retard comme la seule quantité de intérêt. Ici, nous postulons que la quantité de primaire l'intérêt pour le partage des ressources est la bande passante globale sur liens. Ainsi, cette composante du modèle de service, appelée "lien partage ", aborde la question de savoir comment partager l'ensemble bande passante d'un lien entre diverses entités collectives selon un ensemble de partages spécifiés. Il y a plusieurs exemples qui sont communément utilisé pour expliquer la nécessité du partage de lien entre entités collectives.

Partage de liens multi-entités. - Un lien peut être acheté et utilisé conjointement par plusieurs organisations, agences gouvernementales ou similaires. Ils souhaiteront peut-être s'assurer que le lien est partagé en cas de surcharge de manière contrôlée, peut-être proportionnellement à l'investissement en capital de chaque entité. Dans le même temps, ils pourraient souhaiter que lorsque le lien est sous-chargé, l’une des entités peut utiliser tous les bande passante inactive.

Partage de liens multiprotocole - Dans un Internet multiprotocole, il peut être souhaité pour empêcher une famille de protocoles (DECnet, IP, IPX, OSI, SNA, etc.) de surcharger le lien et d’exclure les autres familles. Ceci est important car différentes familles peuvent avoir différentes méthodes de détection et de réponse à la congestion, et certaines méthodes peuvent être plus "agressives" que d'autres. Cela pourrait conduire à une situation dans laquelle un protocole recule plus rapidement que un autre sous congestion, et finit par ne pas avoir de bande passante. Un contrôle explicite du routeur peut être nécessaire pour corriger cela. Là encore, on peut s’attendre à ce que ce contrôle ne s’applique que surcharge, tout en permettant l’utilisation d’un lien inactif dans proportion.

Partage multiservice - Au sein d’une famille de protocoles telle que IP, un l'administrateur peut souhaiter limiter la fraction de bande passante alloué à différentes classes de services. Par exemple, un l'administrateur peut souhaiter limiter la quantité de trafic en temps réel à une fraction du lien, pour éviter de préempter le trafic élastique comme FTP.

En termes généraux, le modèle de service de partage de liens consiste à partager les bande passante globale en fonction de certains partages spécifiés. nous pouvons étendre ce modèle de service de partage de liens à une version hiérarchique. Par exemple, un lien pourrait être divisé entre plusieurs organisations, dont chacune diviserait l'allocation résultante parmi un certain nombre de protocoles, chacun d’eux étant divisé entre un certain nombre de services. Ici, le partage est défini par un arbre avec les actions assignées à chaque nœud feuille.

Un modèle fluide idéalisé de partage de lien instantané avec partage proportionnel de l'excès est le partage de processeur de fluide modèle (introduit dans [ DKS89 ] et approfondi dans [ Parekh92 ] et généralisé au cas hiérarchique) où à chaque instant la bande passante disponible est partagée entre les entités actives (c'est-à-dire ceux qui ont des paquets dans la file d'attente) proportionnellement à la les parts attribuées de la ressource. Ce modèle fluide présente les le comportement politique souhaité mais est, bien sûr, irréaliste idéalisation. Nous proposons ensuite que le modèle de service actuel devrait être de se rapprocher le plus possible de la largeur de bande actions produites par ce modèle fluide idéal. Il n'est pas nécessaire de exiger que l'ordre spécifique des départs de paquets corresponde à ceux du modèle fluide puisque nous supposons que tous détaillés par paquet les exigences de retard des flux individuels sont traitées par engagements de qualité de service et, par ailleurs, la satisfaction avec le service de partage de lien fourni ne dépendra probablement pas très sensible sur les petits écarts par rapport à la planification implicite par le modèle de partage de lien fluide.

Nous avions précédemment observé que le contrôle d'admission était nécessaire pour veiller à ce que les engagements de service en temps réel puissent être respectés. De même, le contrôle d’admission sera à nouveau nécessaire pour garantir que les engagements de partage de liens peuvent être respectés. Pour chaque entité, le contrôle d'admission doit conserver le cumulatif garanti et le trafic prédictif de dépasser le partage de lien attribué.

3.3 abandon de paquets

Jusqu'à présent, nous avons implicitement supposé que tous les paquets d'un flux étaient tout aussi importants. Cependant, dans de nombreux flux audio et vidéo, certains paquets ont plus de valeur que d'autres. Nous proposons donc augmenter le modèle de service avec un service de paquets "préemptable", dans lequel certains des paquets d'un flux pourraient être marqués comme préemptable. Lorsque le réseau risquait de ne pas rencontrer certains ses engagements de service quantitatifs, il pourrait exercer une option de préemptabilité de certains paquets et rejeter le paquet (pas simplement le retarder, car cela introduirait un désordre problèmes). En éliminant ces paquets préemptables, un routeur peut réduire les délais des paquets non préemptés.

De plus, on peut définir une classe de paquets qui n'est pas soumise au contrôle d'admission. Dans le scénario décrit ci-dessus où les paquets préemptables ne sont abandonnés que lorsque le service quantitatif engagements risquent d’être violés, on s’attend à ce que que les paquets préemptables seront presque toujours livrés et donc ils doivent être inclus dans la description du trafic utilisée lors de l'admission contrôle. Cependant, nous pouvons étendre la préemptabilité à l'extrême cas de paquets "consommables" (le terme "consommable" est utilisé pour connote un degré extrême de préemptabilité), où le On s’attend à ce que beaucoup de ces paquets consomptibles ne soient pas livré. On peut alors exclure les paquets consomptibles de la description du trafic utilisé dans le contrôle d'admission; c'est à dire les paquets ne sont pas considérés comme faisant partie du flux du point de vue de contrôle d'admission, puisqu'il n'y a aucun engagement à ce qu'ils soient livré.

3.4 Commentaires sur l'utilisation

Un autre problème important dans le service est le modèle d'utilisation. retour d'informations, également connu sous le nom de "comptabilité", pour éviter les abus de réseau Ressources. Le service de partage de liens décrit précédemment peut être utilisé pour limiter l'utilisation imposée par l'administration. Cependant, un modèle d’accès au réseau plus libre sur le marché nécessitera pression sur les utilisateurs pour les ressources réseau réservées. C'est une question très controversée, et nous ne sommes pas disposés à dire plus à ce sujet en ce moment.

3.5 Modèle de réservation

Le "modèle de réservation" décrit comment une application négocie pour un niveau de QoS. Le modèle le plus simple est que l'application demande pour une qualité de service donnée et que le réseau l’accorde ou refuse. Souvent, la situation sera plus complexe. De nombreuses applications vont pouvoir obtenir un service acceptable à partir d'une gamme de niveaux de qualité de service, ou plus généralement, de n’importe où dans une région du monde espace dimensionnel d'une flowpec.

Par exemple, plutôt que de simplement refuser la demande, le réseau pourrait accorder un niveau de ressources inférieur et informer l'application de quelle QoS a été réellement accordée. Un exemple plus complexe est le modèle de réservation "deux passes", dans ce schéma, un "offert" flowpec est propagé le long de l’arbre de distribution multicast de chaque expéditeur Si à tous les destinataires Rj. Chaque routeur le long du chemin enregistre ces valeurs et peut-être les ajuste pour refléter la disponibilité capacité. Les destinataires reçoivent ces offres, génèrent les demandés flowpecs, et les propager de nouveau le même itinéraires aux expéditeurs. À chaque noeud, un rapprochement local doit être effectué. être exécutée entre les flux offerts et les flux demandés créer une réservation et une demande modifiée en conséquence FlowSpec est transmis. Ce schéma en deux passes permet de nombreuses des propriétés telles que le délai autorisé à être réparties entre les sauts dans le chemin [ Tenet90 , ST2-90 ]. Des travaux supplémentaires sont nécessaires pour définir quantité de généralité, avec un niveau de complexité correspondant, cela est requis dans le modèle de réservation.

4 Mécanismes de contrôle de la circulation

Nous examinons d’abord très brièvement les mécanismes de contrôle de la circulation possibles. Ensuite, à la section 4.2, nous appliquons un sous-ensemble de ces mécanismes pour soutenir les différents services que nous avons proposés.

4.1 Fonctions de base

Dans le chemin de transmission des paquets, il existe en réalité un nombre très limité ensemble d'actions qu'un routeur peut entreprendre. Étant donné un paquet particulier, un routeur doit choisir un itinéraire pour cela; en plus le routeur peut soit le transférer, soit le laisser tomber, et le routeur peut le réorganiser avec par rapport aux autres paquets en attente de départ. Le routeur peut aussi tenir le paquet, même si le lien est inactif. Voici les blocs de construction à partir desquels nous devons façonner le comportement souhaité.

4.1.1 Planification de paquets

La fonction de base de la planification de paquets est de réorganiser le file d'attente de sortie. Il y a beaucoup de papiers qui ont été écrits sur manières possibles de gérer la file d'attente de sortie et les résultats comportement. L’approche la plus simple est peut-être un schéma de priorité, dans lequel les paquets sont classés par priorité et par priorité les paquets partent toujours les premiers. Cela a pour effet de donner quelques la préférence absolue des paquets par rapport aux autres; s'il y a assez de les paquets de priorité supérieure, la classe de priorité inférieure peut être complètement empêché d'être envoyé.

Un schéma de planification alternatif est le round robin ou certains variante, qui donne à différentes classes de paquets l'accès à un part du lien. Une variante appelée Weighted Fair Queuing, ou WFQ, s’est avéré efficace pour allouer la bande passante totale d’un lien en partages spécifiés.

Il existe des systèmes plus complexes pour la gestion des files d'attente, la plupart des qui impliquent le respect des objectifs de service de chaque tels que le délai de livraison et la commande de paquets en fonction sur ces critères.

4.1.2 Abandon de paquets

Le largage contrôlé des paquets est aussi important que leur la planification.

Le plus évidemment, un routeur doit abandonner des paquets lorsque ses tampons sont tout plein. Ce fait, cependant, ne détermine pas quel paquet devrait être abandonné. Laisser tomber le paquet qui arrive, bien que simple, peut provoquer un comportement indésirable.

Dans le contexte actuel d’Internet, avec le protocole TCP opérant sur service IP, le rejet d’un paquet est pris par TCP en tant que signal d’encombrement et le fait réduire sa charge sur le réseau. réseau. Ainsi, choisir un paquet à déposer est la même chose que choisir une source à étrangler. Sans entrer dans aucun particulier algorithme, cette relation simple suggère que certains la suppression des contrôles doit être mise en œuvre dans les routeurs pour améliorer contrôle de congestion.

Dans le contexte des services en temps réel, abandonner plus directement concerne l’atteinte de la qualité de service souhaitée. Si un la file s’accumule, abandonner un paquet réduit le délai de tous les paquets derrière lui dans la file d'attente. La perte d'un peut contribuer au succès de beaucoup. Le problème pour le l’implémenteur est de déterminer quand l’objectif de service (l’objectif retard lié) risque d'être violé. On ne peut pas regarder à la longueur de la file d'attente pour indiquer combien de temps les paquets sont restés dans une file d'attente. Si un schéma de priorité est en place, des paquets de priorité inférieure peut être préemptée indéfiniment, donc même une courte la file d'attente peut contenir de très vieux paquets. En temps réel les timbres pourraient être utilisés pour mesurer le temps de maintien, la complexité peut être inacceptable.

Quelques schémas simples, tels que la combinaison de tous les tampons dans un seul pool global, en laissant tomber le paquet qui arrive si la piscine est pleine, peut vaincre l'objectif de service d'un WFQ schéma de planification. Ainsi, le largage et la planification doivent être coordonné.

4.1.3 Classification des paquets

La discussion ci-dessus sur la planification et l’abandon présumé que le paquet avait été classé dans un flux ou une séquence de les paquets qui doivent être traités de manière spécifiée. UNE préliminaire à ce type de traitement est la classification lui-même. Aujourd'hui, un routeur examine l'adresse de destination et sélectionne un itinéraire. L’adresse de destination n’est pas suffisante pour sélectionnez la classe de service qu'un paquet doit recevoir; plus l'information est nécessaire.

Une solution consisterait à abandonner le modèle de datagramme IP pour une modèle de circuit virtuel, dans lequel un circuit est mis en place avec attributs de service spécifiques, et le paquet porte un circuit identifiant. C’est l’approche de l’ATM ainsi que des protocoles tels que ST-II [ ST2-90 ]. Un autre modèle, moins hostile à l’IP, est pour permettre au classifieur d'examiner plus de champs dans le paquet, telles que l'adresse source, le numéro de protocole et le port des champs. Ainsi, les flux vidéo pourraient être reconnus par un champ de port particulièrement connu dans l'en-tête UDP, ou un flux particulier pourrait être reconnu en regardant à la fois la numéros de port source et de destination. Il serait possible de regarder encore plus loin dans les paquets, par exemple tester un champ dans la couche d'application pour sélectionner un sous-ensemble d'un flux vidéo codé de manière hiérarchique.

Les problèmes de mise en œuvre du classificateur sont complexes et complexes. frais généraux de traitement. L’expérience actuelle laisse penser que la mise en œuvre d’algorithmes efficaces peut conduire à des classification des paquets IP. Ce résultat est très important, car cela nous permet d’ajouter une prise en charge de la qualité de service aux applications existantes, tels que Telnet, basés sur les en-têtes IP existants.

Une approche pour réduire les frais généraux de la classification serait être de fournir un champ "flow-id" dans le paquet de couche Internet entête. Ce flux-id serait un handle qui pourrait être mis en cache et utilisé pour raccourcir la classification du paquet. Il y a un certain nombre de variantes de ce concept, et l’ingénierie est nécessaire pour choisir le meilleur design.

4.1.4 Contrôle d'admission

Comme nous l'avons indiqué dans l'introduction, le service en temps réel dépend la mise en place de l’état dans le routeur et l’engagement de certaines classes de paquets. Afin de s'assurer que ces engagements peuvent être respectés, il est nécessaire que les ressources soient explicitement demandé, de sorte que la demande puisse être refusée si les ressources ne sont pas disponibles. La décision sur la ressource la disponibilité s'appelle le contrôle d'admission.

Le contrôle d'admission nécessite que le routeur comprenne les demandes qui sont actuellement faites sur ses actifs. le approche traditionnellement proposée est de se rappeler le service paramètres des requêtes passées, et faire un calcul basé sur les limites du cas le plus défavorable sur chaque service. Une proposition récente, qui est susceptible de fournir une meilleure utilisation des liens, est de programmer le routeur pour mesurer l’utilisation réelle par flux de paquets, et d'utiliser ces informations mesurées comme base d'admission de nouveaux flux [ JCSZ92 ]. Cette approche est sujette à risque plus élevé de surcharge, mais peut s'avérer beaucoup plus efficace dans en utilisant la bande passante.

Notez que, même si la nécessité de contrôler l’admission fait partie des modèle de service global, les détails de l'algorithme exécuté dans chaque Le routeur est une affaire locale. Ainsi, les vendeurs peuvent se faire concurrence en développer et commercialiser de meilleurs algorithmes de contrôle d'admission, qui conduisent à des charges de liaison plus élevées avec moins de service surcharges.

4.2 Application des mécanismes

Les différents outils décrits ci-dessus peuvent être combinés pour soutenir la services dont il a été question à la section 3 .

o délais garantis

Un résultat théorique de Parekh [ Parekh92 ] montre que si le routeur implémente une discipline de planification WFQ, et si le la nature de la source de trafic peut être caractérisée (par exemple si s'inscrit dans une certaine limite, comme un seau à jetons) sera une limite supérieure absolue sur le délai réseau de la trafic en question. Ce résultat simple et très puissant s’applique non pas à un commutateur, mais aux réseaux généraux de routeurs. Le résultat est constructif. c'est-à-dire, Parekh affiche un comportement source qui mène à la borne, puis montre que ce comportement est le pire possible. Ça signifie que la borne qu'il calcule est la meilleure qui puisse exister, sous ces hypothèses.

o partage de lien

Le même schéma WFQ peut fournir un partage de liaison contrôlé. le L’objectif du service ici n’est pas de lier le retard, mais de limiter surcharger les partages sur un lien, tout en permettant n'importe quel mélange de trafic procéder s'il y a une capacité disponible. Cette utilisation de WFQ est disponible dans les routeurs commerciaux aujourd'hui, et est utilisé pour séparer le trafic en classes basées sur des éléments tels que type de protocole ou application. Par exemple, on peut allouer séparer les partages vers TCP, IPX et SNA, et on peut assurer que le trafic de contrôle du réseau obtient une part garantie du lien.

o Service prédictif en temps réel

Ce service est en réalité plus subtil que le service garanti. Son objectif est de donner un délai lié qui est, d’une part, main, aussi bas que possible, et d’autre part, stable assez pour que le récepteur puisse l’estimer. Le mécanisme WFQ conduit à une limite garantie, mais pas nécessairement à une limite basse. En fait, mélanger le trafic dans une file d'attente plutôt que en le séparant comme dans WFQ, conduit à des limites inférieures, tant que le trafic mixte est généralement similaire (par exemple, le trafic de mélange de multiples codeurs vidéo est logique, mélanger vidéo et FTP ne fait pas).

Cela suggère que nous avons besoin d’un mécanisme à deux niveaux, dans lequel le premier niveau sépare le trafic qui a un service différent objectifs, et les flux de second niveau ordonne au sein de chaque première classe pour atteindre son objectif de service.

4.3 Un exemple: le schéma CSZ

Pour valider le concept, un paquet de code a été implémenté qui réalise les services discutés ci-dessus. Il utilise en fait un numéro des outils de base, combinés de manière spécifique au service Besoins. Nous décrivons en termes généraux comment cela fonctionne, pour suggérer comment les services peuvent être réalisés. Nous soulignons qu'il existe d'autres moyens de construire un routeur pour répondre aux mêmes besoins de service, et il existe en fait d'autres implémentations utilisées aujourd'hui.

Au niveau supérieur, le code CSZ utilise WFQ comme mécanisme d’isolation séparer les flux garantis les uns des autres, ainsi que des reste de la circulation. Le service garanti a la plus haute priorité quand et seulement quand il a besoin de l’accès à respecter ses délais. WFQ fournit une garantie distincte pour chaque flux garanti.

Le service prédictif et le service au mieux sont séparés par priorité. Dans la classe de service prédictive, une autre priorité est utilisé pour fournir des sous-classes avec différentes limites de délai. Dans chaque sous-classe prédictive, une mise en file d'attente FIFO simple est utilisée pour: mélanger le trafic, ce qui semble produire un bon retard global comportement. Cela fonctionne parce que l'algorithme de niveau supérieur s'est séparé hors du trafic meilleur effort tel que FTP.

Dans la classe du meilleur effort, WFQ est utilisé pour fournir le partage de lien. Puisqu'il existe une exigence possible pour les actions imbriquées, ce WFQ le code peut être utilisé de manière récursive. Il y a donc deux utilisations différentes de WFQ dans ce code, un pour séparer les classes garanties, et un pour séparer les partages de liens. Ils sont similaires, mais diffèrent par détail.

Dans chaque partage de lien de la classe de meilleur effort, la priorité est utilisée permettre un trafic élastique plus sensible au facteur temps que d'autres trafic élastique, par exemple pour permettre le passage d'un trafic interactif transferts en masse asynchrones.

Le code CSZ utilise donc à la fois WFQ et la priorité dans une alternance manière à mettre en place un mécanisme permettant de soutenir une gamme de offres de services sophistiquées. Cette discussion est très brève, et ne touche pas à un certain nombre de questions importantes, telles que la le code CSZ intègre le trafic en temps réel dans le partage de lien objectifs. Mais les blocs de construction de base sont très simples, et très puissant. En particulier, bien que la priorité ait été proposée comme clé pour les services en temps réel, WFQ peut être le plus général et puissant des deux régimes. Il soutient plutôt que prioritaire service garanti et partage de liens.

5 . Protocole de configuration de réservation

La conception d’un système informatique doit répondre à un certain nombre d’exigences. protocole setuop de réservation. Il devrait être conçu fondamentalement pour un environnement de multidiffusion, et il doit prendre en charge des besoins de service. Il doit permettre un contrôle souple de la manière dont quelles réservations peuvent être partagées le long des branches du multicast arbres de livraison. Il devrait être conçu autour de l'action élémentaire d'ajouter un expéditeur et / ou un destinataire à un ensemble existant, ou de supprimer un. Il doit être robuste et adapté aux grands groupes de multidiffusion. Enfin, il doit prévoir la réservation préalable des ressources, et pour la préemption que cela implique. Le protocole de configuration de la réservation RSVP a été conçu pour répondre à ces exigences [ RSVP93a , RSVP93b ]. Cette section donne un aperçu de la conception de RSVP.

5.1 Aperçu de RSVP

La figure illustre la livraison de données multi-sources et multi-destinations pour une application particulière partagée et distribuée. Les flèches indiquent flux de données des expéditeurs S1 et S2 aux récepteurs R1, R2 et R3, et le nuage représente le maillage de distribution créé par le protocole de routage multidiffusion. Multicast distribution réplique chaque paquet de données provenant d'un émetteur Si, à remettre à chaque destinataire Rj. Nous traitons la livraison non prédite de S1 à R1 comme un cas particulier et nous appelons cette distribution multidiffusion une session. Une session est défini par l'adresse de destination IP commune (multidiffusion) du récepteur (s).

                 Expéditeurs Récepteurs
                              _____________________
                            () ===> R1
                    S1 ===> (multidiffusion)
                            () ===> R2
                            ( Distribution )
                    S2 ===> ()
                            () ===> R3
                            (_____________________)

                   Figure 2: Session de distribution en multidiffusion

5.1.1 Spécifications de flux et de filtres

En général, une demande de réservation RSVP spécifie le montant de ressources à réserver à tous ou à un sous-ensemble des paquets dans une session particulière. La quantité de ressource est spécifiée par un flowspec, tandis que le sous-ensemble de paquets à recevoir ces ressources sont spécifiées par une spécification de filtre. En supposant le contrôle d'admission réussit, le flowspec sera utilisé pour paramétrer une classe de ressources dans le planificateur de paquets, et le filtre spec sera instancié dans le classifieur de paquets à mappez les paquets appropriés dans cette classe. Le sous-ensemble du état de classificateur qui sélectionne une classe particulière est appelé dans la documentation RSVP en tant que "filtre" (paquet).

Les mécanismes de protocole RSVP fournissent une facilité très générale pour créer et maintenir l'état de réservation distribuée à travers le maillage des chemins de livraison multicast. Ces mécanismes traiter les flowpecs et les spécifications de filtre comme des données binaires essentiellement opaques, en les remettant au contrôle local de la circulation pour interprétation. Bien entendu, le modèle de service présenté à un l'application doit spécifier comment encoder les flowspecs et filtrer specs.

5.1.2 Styles de réservation

RSVP propose plusieurs "styles" de réservation différents, qui déterminer la manière dont les besoins en ressources de plusieurs récepteurs sont regroupés dans les routeurs. Ces styles permettre aux ressources réservées de se rencontrer plus efficacement exigences de l'application. Il y a actuellement trois styles de réservation, "wildcard", "fixed-filter" et "dynamic- filtrer ". Une réservation générique utilise une spécification de filtre qui n'est pas spécifique à la source, de sorte que tous les paquets destinés aux destination (session) peut utiliser un pool commun de ressources réservées Ressources. Cela permet d’allouer une seule ressource. sur tous les chemins de distribution pour le groupe. Le joker Le style de réservation est utile dans le cadre d'une conférence audio. où au plus un petit nombre de sources sont actives simultanément et peuvent partager l’allocation de ressources.

Les deux autres styles utilisent des spécifications de filtre qui sélectionnent sources. Un destinataire peut souhaiter recevoir d’un ensemble fixe de sources, ou à la place, il peut souhaiter que le réseau bascule entre source différente, en modifiant ses spécifications de filtre de manière dynamique. Une réservation de style de filtre fixe ne peut pas être modifiée pendant son exécution. durée de vie sans avoir à invoquer de nouveau le contrôle d'admission. Filtre dynamique réservations permettent à un destinataire de modifier son choix de source (s) au fil du temps sans contrôle d'admission supplémentaire; cependant, cela nécessite que des ressources suffisantes soient allouées pour gérer le pire des cas lorsque tous les récepteurs en aval prennent apport de différentes sources.

5.1.3 Initiation du récepteur

Une question de conception importante est de savoir si les expéditeurs ou les destinataires devrait avoir la responsabilité d'initier les réservations. UNE l'expéditeur connaît les qualités du flux de trafic qu'il peut envoyer, alors qu'un destinataire sait ce qu'il veut (ou peut) recevoir. Le choix le plus évident est peut-être de laisser l'expéditeur initier la réservation. Cependant, cela revient mal pour les grands, arbres de distribution multicast dynamiques et pour hétérogène récepteurs.

Ces deux problèmes d’échelle sont résolus en rendant le destinataire responsable de l’initiation d’une réservation. Receveur l'initiation gère facilement les récepteurs hétérogènes; chaque récepteur demande simplement une réservation appropriée pour lui-même, et toutes les différences entre les réservations de différents destinataires sont résolus ("fusionnés") au sein du réseau par RSVP. Receveur L’initiation est également liée à la multidiffusion IP, dans laquelle le groupe de multidiffusion est créé implicitement par les destinataires qui le rejoignent.

Bien que la réservation à l'initiative du destinataire soit le choix naturel pour les sessions de multidiffusion, la justification du destinataire l’initiation peut sembler plus faible pour les sessions unicast, où l'expéditeur peut être l'initiateur de la session logique. Cependant, nous s’attendre à ce que chaque application en temps réel ait son protocole de signalisation et de contrôle de niveau, et ce protocole peut être utilisé pour signaler au récepteur de lancer une réservation (et peut-être indiquer la flowpec à utiliser). Pour la simplicité et économie, un protocole de configuration ne devrait prendre en charge que l’un des initiation, et, et l'initiation du récepteur nous semble être le gagnant clair.

RSVP utilise le récepteur qui initie des réservations [ RSVP93b ]. UNE récepteur est supposé apprendre les flux offerts par les expéditeurs en mécanisme de niveau supérieur ("hors bande"), il génère alors son possède le flowpec souhaité et le propage vers les expéditeurs, faire des réservations dans chaque routeur en cours de route.

5.1.4 Etat souple

Il existe deux styles possibles pour la configuration de la réservation. protocoles, l’approche "hard state" (HS) (également appelée orientée connexion), et l'approche "soft state" (SS) (également appelé "sans connexion"). Dans les deux approches, la multidiffusion la distribution est effectuée en utilisant un état spécifique au flux dans chaque routeur le long du chemin. Dans l’approche HS, cet état est créé et supprimé de manière totalement déterministe par coopération entre les routeurs. Une fois qu'un hôte demande une session, le "réseau" prend la responsabilité de créer et plus tard détruire l'état nécessaire. ST-II est un exemple du SH approche [ ST2-90 ]. Depuis la gestion de l'état de session HS est complètement déterministe, le protocole de configuration HS doit être fiable, avec accusés de réception et retransmissions. En ordre pour effectuer un nettoyage déterministe de l’état après une défaillance, il doit exister un mécanisme de détection des défaillances, c’est-à-dire une protocole "up / down". Le routeur en amont (vers la source) d'un échec prend la responsabilité de la reconstruction de la nécessaire sur le (s) routeur (s) le long d’un autre itinéraire.

RSVP adopte l'approche SS, qui concerne l'état de réservation en tant qu'informations en cache qui est installé et périodiquement rafraîchi par les hôtes finaux. L'état inutilisé est expiré par le routeurs. Si la route change, les messages d'actualisation installe automatiquement l’état nécessaire le long du nouvel itinéraire. L’approche SS a été choisie pour obtenir la simplicité et la la robustesse démontrée par les systèmes sans connexion protocoles tels que IP [ Clark88 ].

5.2 Routage et réservations

Il existe une interaction fondamentale entre la réservation de ressources configuration et routage, car la réservation nécessite l’installation de état de flux le long de la route des paquets de données. Si et quand un itinéraire changements, il doit y avoir un mécanisme pour mettre en place une réservation le long du nouvel itinéraire.

Certains ont suggéré que la configuration de la réservation nécessite nécessairement tracé de la route, c’est-à-dire l’imposition d’un réseau Internet à circuit virtuel couche. Cependant, notre objectif est simplement d’étendre Internet l'architecture, pas le remplacer. Le fondamental sans connexion La couche Internet [ Clark88 ] a eu beaucoup de succès et nous souhaitons de le conserver comme fondement architectural. Nous proposons plutôt modifier quelque peu le mécanisme de transmission de datagramme pur du Internet présent pour accueillir "IS".

Une configuration de réservation pose quatre problèmes de routage. protocole tel que RSVP.

1. Recherchez un itinéraire prenant en charge la réservation de ressources.

Il s’agit simplement d’un routage "type de service", une installation déjà disponible dans certains protocoles de routage modernes.

2. Trouvez un itinéraire ayant une capacité suffisante sans réserve pour un

nouveau flux.

Les premières expériences sur l'ARPANET ont montré qu'il est difficile faire un routage dynamique dépendant de la charge sur un paquet par paquet base sans problèmes d'instabilité. Cependant, l'instabilité ne devrait pas être un problème si le routage dépendant de la charge est effectué uniquement au moment de la configuration de la réservation.

Deux approches différentes peuvent être adoptées pour trouver un itinéraire avec assez de capacité. On pourrait modifier le routage protocole (s) et interface avec le contrôle du trafic mécanisme, de sorte que le calcul de la route peut prendre en compte la moyenne chargement récent. Alternativement, le protocole de routage pourrait être (re) conçu pour fournir plusieurs itinéraires alternatifs, et La configuration de la réservation peut être tentée à tour de rôle.

3. S'adapter à une défaillance de la route

Lorsqu'un nœud ou un lien échoue, le routage adaptatif trouve un chemin alternatif. Les messages de rafraîchissement périodiques de RSVP seront demander automatiquement une réservation le long du nouveau chemin. De Bien sûr, cette réservation peut échouer car il y a insuffisance de capacité disponible sur le nouveau chemin. C'est un problème de provisionnement et d’ingénierie réseau, qui ne peut être résolus par les protocoles de routage ou de configuration.

Il y a un problème de rapidité d'établissement de la réservation Etat sur le nouveau chemin. Le mécanisme de robustesse de bout en bout des mises à jour est limitée en fréquence par les frais généraux, ce qui peut provoquer une interruption du service en temps réel quand une ancienne route casse et un nouveau est choisi. Il devrait être possible de concevoir RSVP sypplement le mécanisme de rafraîchissement global avec un local mécanisme de réparation, en utilisant des conseils sur les changements d'itinéraire de la mécanisme de routage.

4. S'adapter à un changement d'itinéraire (sans échec)

Les changements d'itinéraire peuvent se produire même sans échec dans la zone touchée chemin. Bien que RSVP puisse utiliser les mêmes techniques de réparation que ceux décrits dans (3), cette affaire soulève un problème de robustesse des garanties de QoS. S'il devait arriver que le contrôle d'admission échoue sur le nouvel itinéraire, l'utilisateur verra dégradation inutilement et capricieusement du service, la voie originale est toujours fonctionnelle.

Pour éviter ce problème, un mécanisme appelé "route pinning" a été suggéré. Cela modifierait le protocole de routage mise en œuvre et l'interface avec le classificateur, de sorte que itinéraires associés aux réservations de ressources seraient épinglé. Le protocole de routage ne changerait pas un épinglé route si elle était encore viable.

Il peut éventuellement être possible de plier l’acheminement et le problèmes de configuration de réservation, mais nous ne comprenons pas encore assez pour fais ça. De plus, le protocole de réservation doit coexister avec un certain nombre de protocoles de routage différents utilisés dans le L'Internet. Par conséquent, RSVP est actuellement conçu pour fonctionner avec protocole de routage de la génération actuelle sans modification. C'est un compromis à court terme pouvant entraîner une défaillance occasionnelle pour créer la meilleure, voire une session en temps réel, ou un dégradation occasionnelle du service due à un changement d'itinéraire. Nous attendons que les futures générations de protocoles de routage élimineront cette compromis, en incluant des crochets et des mécanismes qui, conjointement avec RSVP, résoudra les problèmes (1) à (4) énumérés ci-dessus. Ils prendront en charge le repérage de route, la notification de RSVP pour déclencher réparation locale et sélection des itinéraires avec support "IS" et capacité adéquate.

Le dernier problème lié au routage est fourni par les hôtes mobiles. Notre conjecture est que la mobilité n'est pas essentiellement différente de d’autres changements de route, de sorte que le mécanisme suggéré en (3) et (4) suffira. Plus d’études et d’expérimentation sont nécessaires pour prouver ou réfuter cette conjecture.

6 . REMERCIEMENTS

De nombreux chercheurs sur Internet ont contribué aux travaux décrits dans cette note. Nous voulons particulièrement reconnaître, Steve Casner, Steve Deering, Deborah Estrin, Sally Floyd, Shai Herzog, Van Jacobson, Sugih Jamin, Craig Partridge, John Wroclawski et Lixia Zhang. Ce approche des services intégrés à Internet a été initialement discutée et organisé dans le groupe de recherche de bout en bout d'Internet Research Taskforce, et nous sommes reconnaissants à tous les membres de ce groupe pour leur discussions intéressantes (et parfois passionnées).

RÉFÉRENCES

[ CerfKahn74 ] Cerf, V. et R. Kahn, "Un protocole pour le réseau de paquets Intercommunication ", Communication IEEE, vol. Com-22, n ° 5, mai.

1974.

[ Clark88 ] Clark, D., "La philosophie de conception de l'Internet DARPA Protocols ", ACM SIGCOMM '88, août 1988.

[ CSZ92 ] Clark, D., Shenker, S. et L. Zhang, "Supporting Real-Time Applications dans un réseau de paquets de services intégrés: Architecture and Mechanisms ", Proc. SIGCOMM '92, Baltimore, MD, août 1992.

[ DKS89 ] Demers, A., Keshav, S. et S. Shenker. "Analyse et Simulation d'un algorithme de file d'attente équitable ", Journal of Internetworking: Research and Experience, 1, pp. 3-26, 1990. Également dans Proc. ACM SIGCOMM '89, pp 3-12.

[ SCZ93a ] Shenker, S., Clark, D. et L. Zhang, "Un service de planification Modèle et architecture de planification pour des services intégrés Packet Network ", soumis à ACM / IEEE Trans. On Networking.

[ SCZ93b ] Shenker, S., Clark, D. et L. Zhang, "Un modèle de service pour le Integrated Services Internet ", Travaux en cours, octobre 1993.

[ Floyd92 ] Floyd, S., "Problèmes de gestion flexible des ressources pour Datagram Networks ", Actes du 3ème atelier sur le très haut niveau Speed ​​Networks, mars 1992.

[ Jacobson91 ] Jacobson, V., "Communication privée", 1991.

[ JCSZ92 ] Jamin, S., S. Shenker, L. Zhang et D. Clark, "Une admission Algorithme de contrôle pour le service prédictif en temps réel ", étendu résumé, dans Proc. Troisième atelier international sur les réseaux et Système d'exploitation pris en charge pour l'audio et la vidéo numériques, San Diego, CA, Nov. 1992, p. 73-91.

[ Parekh92 ] Parekh, A., "Une approche généralisée du partage des processeurs pour Contrôle de flux dans les réseaux de services intégrés ", Rapport technique LIDS-TR-2089, Laboratoire de systèmes d'information et de décision, Institut de technologie du Massachusetts, 1992.

[ Partridge92 ] Partridge, C., "Spécification d'écoulement proposée", RFC 1363 , BBN, juillet 1992.

[ RSVP93a ] Zhang, L., Deering, S., Estrin, D., Shenker, S. et D. Zappala, "RSVP: Un nouveau protocole de réservation de ressources", accepté pour publication dans IEEE Network, 1993.

[ RSVP93b ] Zhang, L., R. Braden, D. Estrin, S. Herzog et S. Jamin, "Protocole de réservation de ressources (RSVP) - Fonctionnel version 1 Spécification , Work in Progress, 1993."

[ ST2-90 ] Topolcic, C., "Protocole de flux Internet expérimental: version

2 (ST-II) ", RFC 1190 , BBN, octobre 1990.

[ Tenet90 ] Ferrari, D. et D. Verma, "Un programme pour la chaîne en temps réel Établissement dans les réseaux étendus ", IEEE JSAC, vol. 8, n ° 3, pp

368-379, avril 1990.

Considérations sur la sécurité

Comme indiqué à la section 2.1 , la possibilité de réserver des ressources créera une exigence d'authentification, les deux utilisateurs demandant une ressource garanties et des paquets qui prétendent avoir le droit d’utiliser ces des garanties. Ces problèmes d'authentification ne sont pas traités autrement dans ce mémo, mais doivent faire l’objet d’une étude ultérieure.