Spécification de la qualité de service garantie

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé

Le présent mémoire décrit le comportement exigé des éléments de réseau pour la livraison d'un service garanti (à délai et bande passante garantis) dans l'Internet. Le service garanti donne des limites fermes (prouvables mathématiquement) sur les délais de mise en file d'attente de bout en bout des datagrammes. Ce service rend possible la fourniture d'un service qui garantisse à la fois le délai et la bande passante. La présente spécification suit le gabarit de spécification de service décrit en [1].

1   Introduction

Le présent document définit les exigences pour les éléments de réseau qui prennent en charge le service garanti. Le présent mémoire fait partie d'une série de documents qui spécifient le comportement exigé des éléments de réseau pour la prise en charge de diverses qualités de service dans l'inter réseautage IP. Les services décrits dans ces documents sont utiles à la fois dans l'Internet mondial et dans les réseaux IP privés.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la RFC 2119.

Le présent document se fonde sur le gabarit de spécification de service donné en [1]. Prière de se référer à ce document pour les définitions et les informations supplémentaires sur la spécification des qualités de service au sein de la famille des protocoles IP.

En bref, le concept qui sous-tend le présent mémoire est qu'un flux est décrit en utilisant un baquet de jetons et que cette description d'un flux étant donnée, un élément de service (un routeur, un sous réseau, etc.) calcule divers paramètres qui décrivent comment l'élément de service va traiter les données du flux. En combinant les paramètres provenant des divers éléments de service dans un chemin, il est possible de calculer le délai maximum qu'un ensemble de données va subir lors de sa transmission via ce chemin.

Il est important de noter trois caractéristiques du présent mémoire et du service qu'il spécifie :

1.   Bien que les exigences que doit respecter un mécanisme d'établissement pour réaliser une réservation garantie soient spécifiées avec soin, ni le mécanisme d'établissement ni la méthode d'identification des flux ne sont spécifiés. On peut créer une réservation garantie en utilisant un protocole comme RSVP, une configuration manuelle des routeurs pertinents ou un protocole de gestion de réseau tel que SNMP. La présente spécification est intentionnellement indépendante du mécanisme d'établissement.

2.   Réaliser une limite de délai exige que chaque élément de service du chemin prenne en charge le service garanti ou simule de façon adéquate le service garanti. Cependant, cette exigence n'implique pas que le service garanti soit déployé dans tout l'Internet pour être utile. Le service garanti peut avoir des avantages évidents même avec un déploiement partiel. Si il est pleinement déployé dans un intranet, cet intranet peut prendre en charge le service garanti en interne. Et un FAI peut mettre le service garanti dans son cœur de réseau et fournir le service garanti entre les consommateurs (ou entre les POP).

3.   Comme les éléments de service produisent une limite de délai par suite de leur activité plutôt que de prendre une limite de délai comme objectif à réaliser, il est parfois supposé que les applications ne peuvent pas contrôler le délai. En réalité, le service garanti donne aux applications un contrôle considérable sur leurs délais.

En bref, le délai a deux parties : un délai fixe (délai de transmission, etc.) et un délai de mise en file d'attente. Le délai fixe est une propriété du chemin choisi, qui n'est pas déterminé par un service garanti mais par le mécanisme d'établissement. Seul le délai de mise en file d'attente est déterminé par le service garanti. Et, comme le montrent les équations données plus loin dans le présent mémoire, le délai de mise en file d'attente est principalement une fonction de deux paramètres : le baquet de jetons (en particulier la taille du baquet b) et le débit des données (R) que demande l'application. Ces deux valeurs sont entièrement sous le contrôle de l'application. En d'autres termes, une application peut normalement estimer précisément a priori quel délai de mise en file d'attente le service garanti va vraisemblablement promettre. De plus, si le délai est supérieur à celui espéré, l'application peut modifier son baquet de jetons et son débit de données de façon prévisible pour réaliser un délai inférieur.

2   Comportement de bout en bout

Le comportement de bout en bout fourni par une série d'éléments de réseau qui se conforment au présent document est un niveau assuré de bande passante qui, lorsque utilisé par un flux régulé, produit un service à délai limité sans perte de mise en file d'attente pour tous les datagrammes conformes (en supposant qu'aucune défaillance des composants du réseau ni changement de l'acheminement ne surviennent durant la vie du flux).

Le comportement de bout en bout se conforme au modèle fluide (décrit ci-dessous à la section "Exigences du traitement des données par l'élément de réseau" en ce que les délais de mise en file d'attente fournis ne dépassent pas les délais fluides de plus que les marges d'erreur spécifiées. Plus précisément, la limite de délai de bout en bout est [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot pour p>R>=r, et (M+Ctot)/R+Dtot pour r<=p<=R, (où b, r, p, M, R, Ctot, et Dtot sont définis plus loin dans le présent document).

NOTE : Bien que les termes d'erreur par bond nécessaires pour calculer les délais de bout en bout soient exportés par le module de service (voir à Informations exportées ci-dessous) les mécanismes nécessaires pour collecter les limites par bond et faire connaître les quantités Ctot et Dtot de bout en bout aux applications ne sont pas décrits dans la présente spécification. Ces fonctions sont fournies par les protocoles d'établissement de réservation, les protocoles d'acheminement ou les autres fonctions de gestion de réseau et sortent du domaine d'application du présent document.

Le délai maximum de mise en file d'attente de bout en bout (tel que caractérisé par Ctot et Dtot) et la bande passante (caractérisée par R) fournis le long d'un chemin seront stables. C'est à dire qu'ils ne vont pas changer tant que le chemin de bout en bout ne change pas.

Le service garanti ne contrôle pas le délai minimal ou moyen des datagrammes, mais simplement le délai maximal de mise en file d'attente. De plus, pour calculer le délai maximum que va subir un datagramme, la latence du chemin DOIT être déterminée et ajoutée au délai de mise en file d'attente garanti. (Cependant, comme noté ci-dessous, une limite prudente de la latence peut être calculée en observant le délai rencontré par un paquet quelconque.

Ce service est soumis au contrôle d'admission.

3   Motivation

Le service garanti garantit que les datagrammes vont arriver dans les délais de livraison garantis et ne seront pas éliminés à cause de débordements de files d'attente, pourvu que le trafic du flux reste dans les paramètres de trafic spécifiés. Ce service est destiné aux applications qui ont besoin d'une garantie ferme qu'un datagramme ne va pas arriver plus tard qu'un certain délai après son émission par sa source. Par exemple, certaines applications d'audio et vidéo en "réexécution" ne tolèrent pas qu'un datagramme arrive après son moment d'exécution. Les applications qui ont des exigences fortes de temps réel vont aussi avoir besoin du service garanti.

Ce service n'essaye pas de minimiser la gigue (la différence entre le délai minimal et maximal des datagrammes) ; il contrôle simplement le délai maximal de mise en file d'attente. Parce que la limite de délai garantie est ferme, le délai doit être fixé assez largement pour couvrir les cas extrêmement rares de longs délais de mise en file d'attente. Plusieurs études ont montré que le délai réel pour la grande majorité des datagrammes peut être très inférieur au délai garanti. Les auteurs d'applications en réexécution devraient noter que les datagrammes vont souvent arriver bien plus tôt que l'instant limite de livraison et qu'ils devront être mis en mémoire tampon dans le système de réception jusqu'au moment où l'application doit les traiter.

Ce service représente une fin ultime du contrôle de délai pour les réseaux. La plupart des autres services de contrôle du délai fournissent des assurances bien moins fortes quant aux délais résultants. Afin de fournir ce haut niveau d'assurance, le service garanti n'est normalement utile que si il est fourni par tous les éléments de réseau le long du chemin (c'est à dire, par tous les routeurs et toutes les liaisons qui interconnectent les routeurs). De plus, comme décrit dans la section 6 Informations exportées, la fourniture et l'utilisation effectives du service exigent que le protocole d'établissement ou les autres mécanismes utilisés pour demander le service fournissent les caractérisations de service aux routeurs intermédiaires et aux points d'extrémité.

4   Exigences du traitement des données par l'élément de réseau

L'élément de réseau DOIT s'assurer que le service se rapproche du "modèle fluide" de service. Le modèle fluide au taux de service R est essentiellement le service qui serait fourni par une liaison dédiée de bande passante R entre la source et le receveur. Donc, dans le modèle de service fluide à un taux fixé de R, le service du flux est complètement indépendant de celui de tout autre flux.

Le niveau de service du flux est caractérisé à chaque élément de réseau par une bande passante (ou taux de service) R et une taille de mémoire tampon de B. R représente la part de la bande passante de la liaison que le flux est en droit d'utiliser et B représente l'espace de mémoire tampon dans l'élément de réseau que le flux a le droit de consommer. L'élément de réseau DOIT s'assurer que son service correspond au modèle fluide au même taux que dans des limites d'erreur strictes.

La définition du service garanti s'appuie sur le fait que le délai fluide d'un flux obéit à un baquet de jetons (r,b) et est servi par une ligne dont la bande passante R est limitée par b/R tant que R n'est pas inférieur à r. Le service garanti avec un taux de service R, où maintenant R est une part de la bande passante plutôt que la bande passante d'une ligne dédiée, se rapproche de ce comportement.

Par conséquent, l'élément de réseau DOIT s'assurer que le délai de mise en file d'attente de tout datagramme est inférieur à b/R+C/R+D, où C et D décrivent la déviation locale maximale du modèle fluide. Il est important de souligner que C et D sont des maximums. Ainsi, par exemple, si une mise en œuvre a un trou occasionnel dans le service (peut-être à cause du traitement de mises à jour de l'acheminement) D a besoin d'être assez grand pour tenir compte du temps qu'un datagramme peut perdre durant l'interruption de service. (C et D sont décrits plus en détail dans la section 6 Informations exportées).

NOTE : Strictement parlant, le présent mémoire exige seulement que le service que reçoit un flux ne soit jamais pire que ce qu'il recevrait avec cette approximation du modèle fluide. Il est parfaitement acceptable de fournir un meilleur service. Par exemple, si un flux n'utilise pas sa part, R, des algorithmes tels que la mise en file d'attente à pondération équitable (WFQ, Weighted Fair Queueing) qui donnent temporairement à d'autres flux la bande passante inutilisée, sont parfaitement acceptables (et sont bien sûr, encouragés).

Il n'est pas permis aux liaisons de fragmenter les datagrammes au titre du service garanti. Les datagrammes plus longs que la MTU de la liaison DOIVENT être régulés comme non conformes, ce qui signifie qu'ils seront régulés conformément aux règles décrites dans le section 5 Régulation, ci-dessous.

5   Informations pour l'invocation

Le service garanti est invoqué en spécifiant le trafic (TSpec) et le service désiré (RSpec) à l'élément de réseau. Une demande de service pour un flux existant qui a une nouvelle TSpec et/ou RSpec DEVRAIT être traité comme une nouvelle invocation, en ce sens que le contrôle d'admission DEVRAIT être appliqué de nouveau au flux. Les flux qui réduisent leur TSpec et/ou leur RSpec (c'est-à-dire que leur nouvelle TSpec/RSpec est strictement plus petite que l'ancienne TSpec/RSpec conformément aux règles d'ordre décrites dans la section 8 Ordre ci-dessous) NE DEVRAIENT PAS se voir refuser le service.

La TSpec prend la forme d'un baquet de jetons plus un débit de crête (p), une unité régulée minimum (m), et une taille maximum de datagramme (M).

Le baquet de jetons a une profondeur de baquet, b, et un débit de baquet, r. b et r DOIVENT tous deux être positifs. Le débit, r, est mesuré en octets de datagrammes IP par seconde, et peut aller de un octet par seconde à 40 téraoctets par seconde (ou proche de ce qui est estimé être la bande passante théorique maximum d'un seul brin de fibre). Évidemment, en particulier pour les grandes bandes passantes, seuls les quelques premiers chiffres sont significatifs de sorte que l'utilisation des représentations de virgule flottante, précises à au moins 99,9 % est encouragée.

La profondeur de baquet, b, est aussi mesurée en octets et peut aller de un octet à 250 gigaoctets. Là encore, les représentations de virgules flottantes précises au moins à 99,9 % sont conseillées.

La gamme des valeurs est intentionnellement grande pour permettre les bandes passantes de l'avenir. La gamme n'est pas destinée à impliquer qu'un élément de réseau doit prendre en charge la gamme entière.

Le débit de crête, p, est mesuré en octets de datagrammes IP par seconde et a la même gamme et représentation suggérée que le débit de baquet. Le débit de crête est le débit maximum auquel la source et tous points de reformatage (les points de reformatage sont définis plus loin) peuvent injecter des salves de trafic dans le réseau. Plus précisément, il est exigé que pour toute période de temps, la quantité de données envoyées ne puisse excéder M+pT où M est la taille maximum de datagramme et T est la longueur de la période. De plus, p DOIT être supérieur ou égal au débit du baquet de jetons, r. Si le débit de crête est inconnu ou non spécifié, p DOIT alors être réglé à l'infini.

L'unité régulée minimum, m, est un entier mesuré en octets. Tous les datagrammes IP dont la taille est inférieure à m seront comptés, pour la régulation et la vérification de conformité à la TSpec, comme étant de taille m. La taille maximum de datagramme, M, est le plus gros datagramme qui est conforme à la spécification du trafic ; elle est aussi mesurée en octets. Le flux DOIT être rejeté si la taille maximum de datagramme demandée est supérieure à la MTU de la liaison. m et M DOIVENT tous deux être positifs, et m DOIT être inférieur ou égal à M.

Le service garanti utilise le paramètre général TOKEN_BUCKET_TSPEC défini dans la RFC 2215 [8] pour décrire les caractéristiques de trafic d'un flux de données. La description ci-dessus est celle de ce paramètre. Le TOKEN_BUCKET_TSPEC est le paramètres général numéro 127. L'utilisation de ce paramètre pour la TSpec de service garanti simplifie l'utilisation du service garanti dans un environnement multiservice.

La RSpec est un débit R et un terme de surlongueur S, où R DOIT être supérieur ou égal à r et S DOIT être non négatif. Le débit R est ici encore mesuré en octets de datagrammes IP par seconde et a la même gamme et représentation suggérée que les débits de baquet et de crête. Le terme de surlongueur (slack term) S est en microsecondes. Le débit de la RSpec peut être supérieur à celui de la TSpec parce que des débits plus élevés vont réduire le délai de mise en file d'attente. Le terme de surlongueur signifie la différence entre le délai désiré et le délai obtenu en utilisant le niveau de réservation R. Ce terme de surlongueur peut être utilisé par l'élément de réseau pour réduire sa réservation de ressources pour ce flux. Lorsque un élément de réseau choisit d'utiliser de la surlongueur dans la RSpec, il DOIT suivre des règles spécifiques en mettant à jour les champs R et S de la RSpec ; ces règles sont spécifiées à la section 8 Ordre et fusion. Si au moment de l'invocation du service, aucune surlongueur n'est spécifiée, le terme de surlongueur, S, est réglé à zéro. Aucune spécification de mémoire tampon n'est incluse dans la RSpec parce que l'élément de réseau est supposé déduire l'espace de mémoire tampon requis pour assurer qu'aucune perte due à la mise en file d'attente ne surviendra, d'après les débits de baquet de jetons et de crête de la TSpec, du débit réservé et de la surlongueur dans la RSpec, des information exportées reçues à l'élément de réseau, c'est-à-dire, Ctot et Dtot ou Csum et Dsum, combinés avec les informations internes sur la façon dont l'élément gère son trafic.

La TSpec peut être représentée par trois nombres en virgule flottante à précision simple dans le format de virgule flottante défini par l'IEEE, suivi par deux entiers de 32 bits dans l'ordre des octets du réseau. La première valeur en virgule flottante est le débit (r), la second valeur en virgule flottante est la taille du baquet (b), la troisième valeur en virgule flottante est le débit de crête (p), le premier entier est l'unité régulée minimum (m), et le second entier est la taille maximum de datagramme (M).

Le terme de débit de la RSpec, R, peut aussi être représenté en utilisant la virgule flottante de l'IEEE à simple précision.

Le terme de surlongueur, S, peut être représenté comme un entier de 32 bits. Sa valeur va de 0 à (2**32)-1 microsecondes.

Lorsque les termes r, b, p, et R sont représentés par des valeurs en virgule flottante IEEE, le bit de signe DOIT être zéro (toutes les valeurs DOIVENT être non négatives). Les exposants inférieurs à 127 (c'est à dire, 0) sont interdits. Les exposants supérieurs à 162 (c'est-à-dire, 35 positif) sont déconseillés, excepté pour spécifier un débit de crête infini. L'infini est représenté avec un exposant tout de uns (255) et un bit de signe et une mantisse tous de zéros.

6   Informations exportées

Chaque module de service garanti DOIT exporter au moins les informations suivantes. Tous les paramètres décrits ci-dessous sont des paramètres de caractérisation.

Une mise en œuvre du service garanti d'un élément de réseau est caractérisée par deux termes d'erreur, C et D, qui représentent la façon dont la mise en œuvre par l'élément du service garanti dévie du modèle fluide. Ces deux paramètres ont une règle de composition additive.

Le terme d'erreur C est celui qui dépend du débit. Il représente le délai qu'un datagramme dans le flux peut rencontrer du fait des paramètres de débit du flux. Un exemple d'un tel terme d'erreur est la nécessité de tenir compte du temps pour remettre en ordre un datagramme coupé par des cellules ATM, les cellules étant envoyées à la fréquence de 1/r.

NOTE : Il est important d'observer que lors du calcul des limites de délai, le paramètre C est divisé par le taux de réservation R. Cette division est effectuée parce que comme avec l'exemple de la mise en série de datagrammes, l'effet du terme C est une fonction du taux de transmission. Une mise en œuvre devrait veiller à confirmer que ses valeurs de C, lorsque elles sont divisées par divers taux, donnent des résultats appropriés. Les valeurs de délai qui ne dépendent pas du débit DEVRAIENT être incorporées dans la valeur du paramètre D.

Le terme d'erreur D est celui qui est indépendant du débit, élément par élément, et représente le pire cas de variation du temps de transit non fondée sur le débit à travers l'élément de service. Il est généralement déterminé ou réglé au moment de l'amorçage ou de la configuration. Un exemple de D est un réseau à créneaux temporels, dans lequel les flux garantis se voient allouer des créneaux particuliers dans un cycle de créneaux temporels. Certaines parties du délai flux par flux peuvent être déterminés par les créneaux du cycle qui sont alloués au flux. Dans ce cas, D mesurerait la durée maximum que les données d'un flux, une fois qu'elles sont prêtes à l'envoi, vont devoir attendre un créneau. (On observe que cette valeur peut être calculée avant l'allocation des créneaux et peut donc être annoncée. Par exemple, imaginons qu'il y a 100 créneaux. Dans le pire des cas, un flux peut prendre toute la grappe des N créneaux ensemble, de sorte que si un paquet se trouve prêt à l'envoi juste après la fin de la grappe, le paquet peut devoir attendre 100-N durées de créneau avant l'émission. Dans ce cas, on peut facilement approximer ce délai en réglant D à 100 durées de créneau).

Si la fonction de composition est appliquée tout le long du chemin pour calculer les sommes de C et D de bout en bout (Ctot et Dtot) et si les valeurs résultantes sont fournies aux nœuds d'extrémité (vraisemblablement par le protocole d'établissement) les nœuds d'extrémité peuvent calculer les délais maximums de mise en file d'attente de datagramme. De plus, si les sommes partielles (Csum et Dsum) provenant du point de reformatage le plus récent (les points de reformatage sont définis plus loin) en aval vers les receveurs sont traitées par chaque élément de réseau, ces éléments de réseau peuvent alors calculer les allocations de mémoire tampon nécessaires pour faire qu'il n'y ait aucune perte de datagramme, comme précisé dans la section 9, Lignes directrices pour la mise en œuvre. La bonne utilisation et fourniture de ce service exige que les quantités Ctot et Dtot, et les quantités Csum et Dsum soient calculées. Donc, nous supposons que l'usage du service garanti se fera principalement dans des contextes où ces quantités sont rendues disponibles aux nœuds d'extrémité et aux éléments de réseau.

Le terme d'erreur C est mesuré en unités d'octets. Un élément individuel peut annoncer une valeur C entre 1 et 2**28 (un petit peut plus que 250 mégaoctets) et le total ajouté sur tous les éléments peut atteindre (2**32)-1. Si la somme des délais des différents éléments excède (2**32)-1, le terme d'erreur de bout en bout DOIT être réglé à (2**32)-1.

Le terme d'erreur D est mesuré en unités de une microseconde. Un élément individuel peut annoncer une valeur de délai entre un 1 et 2**28 (un peu plus de deux minutes) et le délai total ajouté sur tous les éléments peut monter à (2**32)-1. Si la somme des délais des différents éléments excède (2**32)-1, le délai de bout en bout DOIT être réglé à (2**32)-1.

Le service garanti a le nom de service 2.

Le numéro du paramètre RSpec est 130.

Les paramètres de caractérisation d'erreur C et D portent les numéros 131 et 132. Les valeurs composées de bout en bout pour C et D (Ctot et Dtot) sont numérotées 133 et 134. Les valeur composées depuis le dernier point de reformatage pour C et D (Csum et Dsum) sont numérotées 135 et 136.

7   Régulation

Il y a deux formes de régulation dans le service garanti. Une forme est la régulation simple (ci-après appelée simplement régulation pour la cohérence avec les autres documents) dans laquelle le trafic arrivant est comparé à une TSpec. L'autre forme est le reformatage, dans lequel il est tenté de restaurer la forme du trafic (éventuellement distordu) pour se conformer à la TSpec, et le fait que le trafic viole la TSpec est découvert parce que le reformatage échoue (la mémoire tampon de reformatage déborde).

La régulation est faite sur les bordures du réseau. Le reformatage est fait à tous les points d'embranchement de source hétérogènes et à tous les points de fusion de source. Un point d'embranchement de source hétérogène est l'endroit où l'arborescence de distribution de diffusion groupée se divise en plusieurs chemins distincts, et les TSpec des réservations sur les diverses liaisons sortantes ne sont pas toutes les mêmes. Le reformatage a seulement besoin d'être fait si la TSpec sur la liaison sortante est "inférieure à" (dans le sens décrit dans la section 8 "Ordre et fusion") la TSpec réservée sur la liaison immédiatement en amont. Un point de fusion de source est l'endroit où les chemins ou arbres de distribution provenant de deux sources différentes (qui partagent la même réservation) fusionnent. Il est de la responsabilité de l'invocateur du service (protocole d'établissement, outil de configuration local, ou mécanisme similaire) d'identifier les points où la régulation est requise. Le reformatage peut être fait à d'autres points aussi bien qu'à ceux décrits ci-dessus. La régulation NE DOIT PAS être faite ailleurs qu'à la bordure du réseau.

Les paramètres baquet de jetons et débit de crête exigent que le trafic obéisse à la règle que sur toutes les périodes de temps, la quantité de données envoyées ne puisse pas excéder M+min[pT, rT+b-M], où r et b sont les paramètres de remplissage de jetons, M est la taille maximum de datagramme, et T est la durée de la période (noter que quand p est infini, cela réduit l'exigence de remplissage de jetons standard). Pour les besoins de cette comptabilité, les liaisons DOIVENT compter les datagrammes qui sont plus petits que l'unité de régulation minimum comme étant de taille m. Les datagrammes qui arrivent à un élément et causent une violation de la limite M+min[pT, rT+b-M] sont considérés non conformes.

À la bordure du réseau, le trafic est régulé pour s'assurer qu'il se conforme au baquet de jetons. Les datagrammes non conformes DEVRAIENT être traités comme des datagrammes au mieux. [Si et lorsque une capacité de marquage devient disponible, ces datagrammes non conformes DEVRAIENT être ''marqués'' comme étant non conformes et ensuite être traités comme datagrammes au mieux par tous les routeurs suivants.]

Le service au mieux est défini comme le service par défaut qu'un élément de réseau donnerait à un datagramme qui ne fait pas partie d'un flux et a été envoyé entre la source du flux et sa destination. Entre autres implications, cette définition signifie que si un datagramme d'un flux est changé en datagramme au mieux, tout le contrôle de flux (par exemple, RED [2]) qui est normalement appliqué aux datagrammes au mieux est aussi appliqué à ce datagramme.

NOTE : Il peut y avoir des situations qui sortent du domaine d'application du présent document, telles que lorsque un module de service met en œuvre le service garanti pour du partage de trafic plutôt que pour la qualité de service, et où l'action désirée est d'éliminer les datagrammes non conformes. Pour permettre de telles utilisations, les mises en œuvre DEVRAIENT s'assurer que l'action à entreprendre pour les datagrammes non conformes est configurable.

À l'intérieur du réseau, la régulation ne produit pas les résultats désirés, parce que les effets de la mise en file d'attente vont occasionnellement être cause que le trafic d'un flux qui est entré dans le réseau comme conforme ne l'est plus à un certain élément de réseau en aval. Donc, à l'intérieur du réseau, les éléments de réseau qui souhaitent réguler le trafic DOIVENT le faire en reformatant le trafic au baquet de jetons. Le reformatage entraîne de retarder les datagrammes jusqu'à ce qu'ils soient en conformité avec la TSpec.

Le reformatage est fait en combinant une mémoire tampon avec un régulateur de baquet de jetons et de débit de crête et en mettant les données en mémoire tampon jusqu'à ce qu'elles puissent être envoyées en conformité avec les paramètres de baquet de jetons et de débit de crête. (Le régulateur de baquet de jetons DOIT commencer avec son baquet de jetons plein de jetons). Dans le service garanti, la quantité de mémoire tampon requise pour reformater tout trafic conforme au format de son baquet de jetons d'origine est b+Csum+(Dsum*r), où Csum et Dsum sont les sommes des paramètres C et D entre le dernier point de reformatage et le point de reformatage actuel. Noter que la connaissance du débit de crête chez les reformateurs peut être utilisée pour réduire les exigences de mémoire tampon (voir la section 9 "Lignes directrices pour la mise en œuvre"). Un élément de réseau DOIT fournir les mémoires tampon nécessaires pour assurer que le trafic conforme n'est pas perdu chez le reformateur.

NOTE : On observe qu'un routeur qui ne reformate pas peut quand même identifier les datagrammes non conformes (et les éliminer ou les programmer avec une priorité inférieure) en observant quand le trafic mis en file d'attente pour le flux excède b+Csum+(Dsum*r).

Si un datagramme arrive à découvrir que la mémoire tampon de reformatage est pleine, le datagramme est alors non conforme. On observe que cela signifie qu'un reformateur est effectivement aussi un régulateur. Comme avec un régulateur, le reformateur DEVRAIT reléguer les datagrammes non conformes au traitement au mieux. [Si le marquage est disponible, les datagrammes non conformes DEVRAIENT être marqué.]

NOTE : Comme avec les régulateurs, il DEVRAIT être possible de configurer comment les reformateurs traitent les datagrammes non conformes.

Noter qu'alors qu'une grande mémoire tampon fait apparaître que les reformateurs ajoutent un délai considérable, ce n'est pas le cas ici. Si on a une TSpec valide qui décrit le trafic avec précision, le reformatage va causer peu de délai réel supplémentaire au point de reformatage (et cela n'affectera pas du tout la limite du délai). De plus, dans le cas normal, le reformatage ne causera la perte d'aucune données.

Cependant, (normalement aux points de fusion ou d'embranchement), il peut arriver que la TSpec soit plus petite que le trafic réel. Si cela arrive, le reformatage va causer le développement d'une grande file d'attente au point de reformatage, ce qui cause à la fois des délais supplémentaires substantiels et force certains datagrammes à être traités comme non conformes. Ce scénario rend possible une déplaisante attaque de déni de service dans laquelle un receveur qui reçoit bien le trafic d'un flux via le service au mieux est préempté par un nouveau receveur qui demande une réservation pour le flux, mais avec des TSpec et RSpec inadéquates. Le trafic du flux va alors être régulé et éventuellement reformaté. Si la fonction de régulation choisie élimine les datagrammes, le receveur au mieux ne recevra plus de trafic. Pour cette raison, dans le cas normal, les régulations servent simplement à traiter les datagrammes non conformes au mieux (et à les marquer si le marquage est mis en œuvre). Bien que cela protège contre le déni de service, il est vrai que la mauvaise TSpec peut causer une augmentation des délais de mise en file d'attente.

NOTE : Pour minimiser les problèmes de réarrangement des datagrammes, les points de reformatage peuvent souhaiter transmettre un datagramme au mieux depuis le front de la file d'attente de reformatage lorsque un nouveau datagramme arrive et que la mémoire tampon de reformatage est pleine.

Le lecteur observera que la reclassification des datagrammes dans la catégorie au mieux (plutôt que de les éliminer) rend aussi plus facile la prise en charge des flux élastiques. On peut réserver un baquet de jetons modeste et lorsque le trafic excède le baquet de jetons, le trafic excédentaire sera envoyé au mieux.

Une question qui s'y rapporte est que chez tous les éléments de réseau, les datagrammes plus gros que la MTU de l'élément de réseau DOIVENT être considérés comme non conformes et DEVRAIENT être classés au mieux (et seront alors soit fragmentés, soit éliminés, conformément au traitement du trafic au mieux de l'élément). Là encore si le marquage est disponible, ces datagrammes reclassés DEVRAIENT être marqués.]

8   Ordre et fusion

Les TSpec sont ordonnées selon les règles suivantes :

La TSpec A est un substitut ("aussi bon ou meilleur que") pour la TSpec B si (1) le débit de jetons r et la profondeur de baquet b pour la TSpec A sont tous deux supérieurs ou égaux à ceux de la TSpec B ; (2) le débit de crête p est au moins aussi grand dans la TSpec A qu'il l'est dans la TSpec B ; (3) l'unité régulée minimum m est au moins aussi petite pour la TSpec A qu'elle l'est pour la TSpec B ; et (4) la taille maximum de datagramme M est au moins aussi grande pour la TSpec A qu'elle l'est pour la TSpec B.

La TSpec A est "inférieure ou égale" à la TSpec B si (1) le débit de jetons r et la profondeur de baquet b pour la TSpec A sont tous deux inférieurs ou égaux à ceux de la TSpec B ; (2) le débit de crête pour la TSpec A est au moins aussi petit que le débit de crête dans la TSpec B ; (3) l'unité régulée minimum m est au moins aussi grande pour la TSpec A que pour la TSpec B ; et (4) la taille maximum de datagramme M est au moins aussi petite pour la TSpec A que pour la TSpec B.

Une TSpec fusionnée peut être calculée sur un ensemble de TSpec en prenant (1) le plus grand débit de remplissage de jetons, (2) la plus grande taille de baquet, (3) le plus grand débit de crête, (4) la plus petite unité minimum régulée, et (5) la plus petite taille maximum de datagramme de tous les membres de l'ensemble. Cette utilisation du mot "fusion" est similaire à celle du protocole RSVP [10] ; une TSpec fusionnée est celle qui est adéquate pour décrire le trafic provenant de toutes les TSpec constituantes.

Une TSpec cumulée peut être calculée sur un ensemble de TSpec en calculant :(1) la somme des débits de remplissage de jetons, (2) la somme des tailles de baquets, (3) la somme des débits de crête, (4) la plus petite unité minimum régulée, et (5) le paramètre taille maximum de datagramme.

Une TSpec commune minimale est celle qui est suffisante pour décrire le trafic de l'un quelconque des flux d'un ensemble de flux de trafic. Une TSpec commune minimale peut être calculée sur un ensemble de TSpec en calculant : (1) le plus grand taux de remplissage de jetons, (2) la plus grande taille de baquet, (3) le plus grand débit de crête, (4) la plus petite unité minimum régulée, et (5) la plus grande taille maximum de datagramme parmi tous les membres de l'ensemble.

Le minimum de deux TSpec diffère selon que les TSpec peuvent être ordonnées. Si une TSpec est inférieure à l'autre TSpec, la plus petite TSpec est le minimum. Autrement, la TSpec minimum de deux TSpec est déterminée en comparant les valeurs respectives dans les deux TSpec et en choisissant : (1) le plus petit taux de remplissage de jetons, (2) la plus grande taille de baquet de jetons, (3) le plus petit débit de crête, (4) la plus petite unité minimum régulée , et (5) la plus petite taille maximum de datagramme.

Les RSpec sont fusionnées de manière similaire à celle des TSpec, c'est à dire qu'un ensemble de RSpec est fusionné en une seule RSpec en prenant le plus grand taux R, et le plus petit terme de surlongueur S. Plus précisément, la RSpec A est un substitut pour la RSpec B si la valeur du taux de service réservé, R, dans la RSpec A est supérieure ou égale à cette valeur dans la RSpec B, et si la valeur du terme de surlongueur, S, dans la RSpec A est inférieure ou égale à celle de la RSpec B.

Chaque élément de réseau reçoit une demande de service de la forme (TSpec, RSpec), où la RSpec est de la forme (Rin, Sin). L'élément de réseau traite cette demande et effectue une des deux actions suivantes :

a.   il accepte la demande et retourne une nouvelle Rspec de la forme (Rout, Sout) ;

b.   il rejette la demande.

Les règles de traitement pour générer la nouvelle RSpec sont gouvernées par la contrainte de délai :

Sout + b/Rout + Ctoti/Rout ≤ Sin + b/Rin + Ctoti/Rin,

où Ctoti est la somme cumulée des termes d'erreur, C, pour tous les éléments de réseau qui sont en amont et y compris l'élément actuel, i. En d'autres termes, cet élément consomme (Sin - Sout) de surlongueur et peut l'utiliser pour réduire son niveau de réservation, pourvu que l'inégalité ci-dessus soit satisfaite. Rin et Rout DOIVENT aussi satisfaire la contrainte :

r ≤ Rout ≤ Rin.

Lorsque plusieurs RSpec, ayant chacune le taux Rj, j=1,2..., sont à fusionner à un point de partage, la valeur de Rout est le maximum de tous les taux Rj, et la valeur de Sout est le minimum de tous les termes de surlongueur Sj.

NOTE : Les diverses fonctions de TSpec décrites ci-dessus sont utilisées par des applications qui désirent combiner des TSpec. Il est important d'observer, cependant, que les propriétés de la réservation réelle sont déterminées en combinant la TSpec avec le taux de RSpec (R).

Parce que la réservation garantie exige à la fois la TSpec et le taux de RSpec, il existe certains problèmes difficiles pour les réservations partagées dans RSVP, en particulier lorsque deux sources de flux ou plus se rencontrent. En amont du point de rencontre, il serait souhaitable de réduire la TSpec et la RSpec pour utiliser seulement autant de bande passante et de mémoire tampon qu'exigé par le trafic de la source individuelle. (Bien sûr, cela peut être nécessaire si l'envoyeur émet sur une liaison à faible bande passante).

Cependant, le taux de la RSpec est réglé pour réaliser une limite de délai particulière (et n'est pas juste une fonction de la TSpec) de sorte que changer la RSpec peut causer l'échec de la réservation pour satisfaire les exigences de délai du receveur. En même temps, ne pas ajuster le taux de la RSpec signifie que les réservations RSVP "partagées" qui utilisent le service garanti vont échouer chaque fois que la bande passante disponible à une liaison particulière est inférieure au taux R demandé par le receveur, même si la bande passante est adéquate pour prendre en charge le nombre d'envoyeurs qui utilisent réellement la liaison. Pour le moment, cette limitation est un problème ouvert de l'utilisation du service garanti avec RSVP.

9   Lignes directrices pour la mise en œuvre

Cette section expose un certain nombre d'importants problèmes de mise en œuvre sans ordre particulier.

Il est important de noter que les sous-réseaux individuels sont des éléments de réseau et que les routeurs et les sous-réseaux DOIVENT tous deux prendre en charge le modèle de service garanti pour réaliser le service garanti. Comme les sous-réseaux ne sont normalement pas capables de négocier le service en utilisant les protocoles fondés sur IP, au titre de la fourniture du service garanti, les routeurs devront agir comme mandataires pour les sous-réseaux auxquels ils sont rattachés.

Dans certains cas, ce service de mandataire sera facile. Par exemple, sur des lignes louées gérées par un programmateur WFQ sur le nœud amont, le mandataire a simplement besoin de s'assurer que la somme des taux de toutes les RSpec ne dépasse pas la bande passante de la ligne, et d'annoncer les délais fondés sur le taux et ceux qui ne le sont pas pour la ligne comme valeurs de C et de D.

Dans d'autres cas, ce service de mandataire va être plus complexe. Dans un réseau ATM, par exemple, cela peut exiger d'établir un circuit virtuel ATM pour le flux et de calculer les termes C et D pour ce circuit virtuel. Le lecteur observera que le baquet de jetons et le taux de crête utilisés par le service garanti se transposent directement en paramètres Débit de cellule soutenu, Taille de salve, et débit de cellules de crête de QS de la Recommandation UIT-T Q.2931 de l'ATM pour le trafic à débit binaire variable.

L'assurance que les datagrammes ne seront pas perdus est obtenue en réglant l'espace de mémoire tampon B du routeur égal au baquet de jetons b plus un terme d'erreur (décrit ci-dessous).

Une autre question en rapport avec les sous-réseaux est que les taux de remplissage de jetons de la TSpec mesurent le trafic IP et ne tiennent pas compte (ils ne le peuvent pas) des en-têtes de niveau liaison. Aussi les éléments de réseau sous-réseaux DOIVENT ajuster le taux et éventuellement la taille de baquet pour tenir compte de l'ajout des en-têtes de niveau liaison. Les tunnels DOIVENT aussi tenir compte des en-têtes IP additionnels qu'ils ajoutent.

Pour les réseaux de datagrammes, le taux maximum d'en-tête peut habituellement être calculé en divisant les taux et tailles de baquet par l'unité minimum régulée. Pour les réseaux qui font la fragmentation interne, comme ATM, le calcul peut être plus complexe, car on DOIT tenir compte à la fois de la redondance par fragment et de tous "gaspillage" (octets de bourrage transmis) dus aux discordances entre tailles de datagrammes et de fragments. Par exemple, une estimation prudente du taux de données additionnel imposé par l'AAL5 plus la segmentation et le réassemblage ATM est

((r/48)*5)+((r/m)*(8+52))

qui représente le taux divisé en cellules de 48 octets multiplié par l'en-tête ATM de 5 octets, plus le taux maximum de datagrammes (r/m) multiplié par le coût de l'en-tête AAL5 de 8 octets, plus l'espace maximum qui peut être gaspillé par la segmentation ATM d'un datagramme (qui sont les 52 octets perdus dans une cellule qui contient un seul octet). Mais cette estimation va vraisemblablement être trop forte, spécialement si m est petit, car le gaspillage de l'ATM est normalement bien inférieur à 52 octets. (Les mises en œuvre d'ATM doivent savoir que le baquet de jetons peut aussi devoir être étalonné lors du réglage des paramètres de circuit virtuel pour l'établissement de l'appel et que cet exemple ne tient pas compte des redondances incombant aux encapsulations telles que celles spécifiées dans la RFC 1483).

Pour assurer l'absence de pertes, les éléments de réseau devront allouer de la mémoire tampon pour les salves. Si chaque bond met parfaitement en œuvre le modèle fluide, cette mise en mémoire tampon sera simplement b (la taille du baquet de jetons). Cependant, comme noté dans l'exposé sur le reformatage, la mise en œuvre est approximative et on s'attend à ce que le trafic devienne plus saccadé au fur et à mesure qu'il avance dans le réseau. Cependant, comme avec le formatage, la quantité de mémoire tampon requise pour traiter la sporadicité est bordée par b+Csum+Dsum*R. Si on tient compte du débit de crête, cela se réduit à

M + (b-M)(p-X)/(p-r) + (Csum/R + Dsum)X

où X est réglé à r si (b-M)/(p-r) est inférieur à Csum/R+Dsum et X est R si (b-M)/(p-r) est supérieur ou égal à Csum/R+Dsum et p>R ; autrement, X est réglé à p. Cette réduction vient du fait que le débit de crête limite le taux auquel la salve, b, peut être placée dans le réseau. À l'inverse, si un terme de surlongueur différent de zéro, Sout, est retourné par l'élément de réseau, les exigences de mémoire tampon sont augmentées par l'ajout de Sout à Dsum.

Alors que les applications envoyeuses sont encouragées à établir le paramètre de débit de crête et que les points de reformatage sont obligés de s'y conformer, il est toujours acceptable d'ignorer le débit de crête pour les besoins du calcul des exigences de mémoire tampon et des délais de bout en bout. Le résultat est simplement une surestimation de la mémoire tampon et du délai. Comme noté ci-dessus, si le débit de crête n'est pas connu (et donc potentiellement infini) la mémoire tampon requise est b+Csum+Dsum*R. Le délai de bout en bout sans le débit de crête est b/R+Ctot/R+Dtot.

Le paramètre D pour chaque élément de réseau DEVRAIT être réglé à la variation de délai de transfert de datagramme maximum (indépendamment du débit et de la taille du baquet) à travers l'élément de réseau. Par exemple, dans un simple routeur, on peut calculer la différence entre le pire cas et le meilleur cas de temps que met un datagramme pour passer de l'interface d'entrée au processeur, et l'ajouter à toute variation qui peut survenir dans le délai que prend de passer du processeur au programmateur de liaison de sortie (en supposant que les schémas de mise en file d'attente fonctionnent correctement).

Pour la mise en file d'attente à pondération équitable dans un environnement de datagrammes, D est réglé à la MTU de la liaison divisée par la bande passante de la liaison, pour tenir compte de la possibilité qu'un paquet arrive juste lorsque un paquet de taille maximum commence à être transmis, et que le paquet arrivant doive être expédié avant le paquet de taille maximum. Pour un système à créneaux fondé sur la trame, tel que la mise en file d'attente en arrêt-relance (Stop and Go), D est le nombre maximum de créneaux qu'un datagramme peut devoir attendre avant d'avoir une chance d'être transmis.

Noter que la diffusion groupée peut rendre la détermination de D plus difficile. Dans de nombreux sous-réseaux, ATM étant un exemple parmi d'autres, les propriétés du sous-réseau peuvent dépendre du chemin pris par l'envoyeur de diffusion groupé au receveur. Il y a un certain nombre d'approches possibles de ce problème. L'une d'elles est de choisir une latence représentative pour le sous-réseau global et de régler D à la différence (non négative) par rapport à cette latence. Une autre est d'estimer les propriétés du sous-réseau aux points de sortie du sous-réseau, car le point de sortie est vraisemblablement le mieux placé pour calculer les propriétés de son chemin à partir de la source.

NOTE : Il est important de noter qu'il n'y a pas d'ensemble fixe de règles sur la façon dont un sous-réseau détermine ses propriétés, et chaque technologie de sous-réseau devra développer son propre ensemble de procédures pour calculer précisément les valeurs de C, de D, et de surlongueur.

D est destiné à être distinct de la latence à travers l'élément de réseau. La latence est le délai minimum à travers l'appareil (le délai de la vitesse de la lumière dans une fibre pour le minimum absolu que va prendre le déplacement d'un paquet à travers un routeur), alors que le paramètre D est destiné à border la variabilité dans un délai non fondé sur le débit. En pratique, cette distinction est parfois arbitraire (la latence peut être minimale) – dans de tels cas, il est parfaitement raisonnable de combiner la latence avec D et d'annoncer toute latence comme zéro.

NOTE : Il est implicite dans ce schéma que pour obtenir une garantie complète du délai maximum qu'un paquet peut subir, un utilisateur de ce service aura besoin de connaître à la fois le délai de mise en file d'attente (fourni par C et D) et la latence. La latence n'est pas annoncée par ce service mais est un paramètre général de caractérisation (annoncé comme spécifié dans [8]).

Cependant, même si la latence n'est pas annoncée, ce service peut quand même être utilisé. La plus simple approche est de mesurer le délai subi par le premier paquet (ou le délai minimum des quelques premiers paquets) reçus et de traiter cette valeur de délai comme limite supérieure de la latence.

Le paramètre C est l'arriéré de données résultant des errements de la déviation d'une mise en œuvre spécifique par rapport à un service bit par bit. Ainsi, par exemple, pour la mise en file d'attente à pondération équitable de datagrammes, C est réglé à M pour tenir compte des effets de mise en paquets.

Si un élément de réseau utilise une certaine quantité de surlonguer, Si, pour réduire la quantité de ressources qu'il a réservées pour un flux particulier, i, la value Si DEVRAIT être mémorisée chez l'élément de réseau. Ultérieurement, si des rafraîchissements de la réservation sont reçus pour le flux i, l'élément de réseau DOIT utiliser la même surlongueur Si sans aucun autre calcul. Cela garantit la cohérence dans le processus de réservation.

Comme exemple d'utilisation du terme de surlongueur, considérons le cas où le délai exigé de bout en bout, Dreq, est supérieur au délai maximum du système de flux fluide. Dreq est obtenu en réglant R=r dans la formule du délai fluide (pour être stable, R ≤ r doit être vrai), et est donné par

b/r + Ctot/r + Dtot.

Dans ce cas, le terme de surlongueur est

S = Dreq - (b/r + Ctot/r + Dtot).

Le terme de surlongueur peut être utilisé par les éléments de réseau pour ajuster leurs réservations locales, de sorte qu'elles puissent admettre des flux qui autrement auraient été rejetés. Un élément de réseau à un élément de réseau intermédiaire qui peut différencier en interne entre les garanties de délai et de débit peut maintenant tirer parti de cette information pour diminuer la quantité de ressources allouées à ce flux. Par exemple, en prenant une quantité de surlongueur s ≤ S, un programmateur RCSD [5] peut augmenter la limite de délai local, d, alloué au flux, à d+s. Soit une RSpec, (Rin, Sin), il ferait cela en réglant Rout = Rin et Sout = Sin - s.

De même, un élément de réseau utilisant un programmateur WFQ peut diminuer sa réservation locale de Rin à Rout en utilisant une partie de la surlongueur dans la RSpec. Cela peut se faire en utilisant les règles de transformation données dans la section précédente, qui assurent que le niveau réduit de réservation ne va pas augmenter le délai global de bout en bout.

10   Critères d'évaluation

Les algorithmes de programmation et de contrôle d'admission de l'élément DOIVENT assurer que les limites de délai ne sont jamais violées et que les datagrammes ne sont jamais perdus, lorsque le trafic d'une source se conforme à la TSpec. De plus, l'élément DOIT s'assurer que les flux qui se comportent mal n'affectent pas le service fourni aux autres flux. Les fabricants sont invités à prouver formellement que leur mise en œuvre est une approximation du modèle fluide.

11   Exemples de mise en œuvre

Il existe plusieurs algorithmes et mises en œuvre qui approximent le modèle de fluide. Il y a parmi eux la mise en file d'attente à pondération équitable (WFQ, Weighted Fair Queueing) [2], Jitter- EDD [3], Virtual Clock [4] et un schéma proposé par IBM [5]. On trouvera une agréable présentation théorique qui intègre ces schémas dans une grande classe d'algorithmes dans [6].

12   Exemples d'utilisation

Considérons une application qui ne tolère ni la perte ni le retard d'un seul datagramme. Elle utilise les valeurs annoncées Ctot et Dtot et la TSpec du flux, pour calculer les limites de délai résultantes provenant d'une demande de service avec le taux R. En supposant que R < p, elle règle alors son point d'exécution à [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot.

13   Considérations pour la sécurité

Le présent mémoire expose comment ce service pourrait être détourné pour permettre des attaques de déni de service. Le service, tel qu'il est défini, ne permet pas de déni de service (bien que le service puisse se dégrader dans certaines circonstances).

Appendice 1   Utilisation du service garanti avec RSVP

L'utilisation du service garanti en conjonction avec le protocole RSVP d'établissement de réservations de ressources est spécifiée dans la RFC 2210 [9]. Le présent document donne le format des objets RSVP FLOWSPEC, SENDER_TSPEC, et ADSPEC nécessaires pour la prise en charge des applications qui désirent le service garanti et donne des informations sur la façon dont RSVP traite ces objets. Le protocole RSVP lui-même est spécifié dans la RFC 2205 [10].

Références

[1]   S. Shenker, J. Wroclawski, "Modèle de spécification de services d'élément de réseau", RFC2216, septembre 1997. (Information)

[2]   A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm," dans Internetworking: Research and Experience, Vol 1, n° 1, pp. 3-26.

[3]   L. Zhang, "Virtual Clock: A New Traffic Control Algorithm for Packet Switching Networks," dans Proc. ACM SIGCOMM '90, pp. 19-29.

[4]   D. Verma, H. Zhang, and D. Ferrari, "Guaranteeing Delay Jitter Bounds in Packet Switching Networks," dans Proc. Tricomm '91.

[5]   L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivarajan, "Efficient Network QoS Provisioning Based on per Node Traffic Shaping," IBM Research Report n° RC-20064.

[6]   P. Goyal, S.S. Lam and H.M. Vin, "Determining End-to-End Delay Bounds in Heterogeneous Networks," dans Proc. 5th Intl. Workshop on Network and Operating System Support for Digital Audio and Video, avril 1995.

[7]   A.K.J. Parekh, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks", MIT Laboratory for Information and Decision Systems, Report LIDS-TH-2089, février 1992.

[8]   S. Shenker, J. Wroclawski, "Paramètres généraux de caractérisation pour éléments de réseau à intégration de service", RFC2215, septembre 1997. (P.S.)

[9]   J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", RFC2210, septembre 1997. (P.S.)

[10]   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.)

Adresse des auteurs