Spécification du service d'élément de réseau à charge contrôlée

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 spécifie le comportement des éléments de réseau exigé pour la fourniture du service de charge contrôlée dans l'Internet. Le service de charge contrôlée fournit aux flux de données client une qualité de service proche de la QS que le même flux recevrait d'un élément de réseau sans charge, mais utilise le contrôle de capacité (admission) pour assurer que ce service est reçu même lorsque l'élément de réseau est surchargé.

1.   Introduction

Le présent document définit les exigences pour les éléments de réseau qui prennent en charge le service de charge contrôlée. Le présent mémoire fait partie d'une série de documents qui spécifient le comportement des éléments de réseau exigé 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.

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

2.   Comportement de bout en bout

Le comportement de bout en bout fourni à une application par une série d'éléments de réseau prenant en charge le service de charge contrôlée s'approche de près du comportement visible des applications qui reçoivent le service au mieux *dans des conditions sans charge* de la part de la même série d'éléments de réseau. En supposant que le réseau fonctionne correctement, ces applications peuvent supposer que :

-   Un pourcentage très élevé de paquets transmis sera livré avec succès par le réseau aux nœuds d'extrémité receveurs. (Le pourcentage de paquets non livrés avec succès doit s'approcher de près du taux d'erreur de base de paquet du support de transmission).

-   Le délai de transit rencontré par un très fort pourcentage de paquets livrés ne va pas excéder de beaucoup le délai minimum de transmission rencontré par un paquet livré avec succès. (Ce délai minimum de transit inclut le délai à la vitesse de la lumière plus le délai fixe de traitement dans les routeurs et autres appareils de communication le long du chemin.)

Pour s'assurer que ces conditions sont satisfaites, les clients qui demandent la service de charge contrôlée fournissent aux éléments de réseau intermédiaires une estimation du trafic de données qu'ils vont générer, la TSpec. En retour, le service assure que des ressources adéquates d'éléments de réseau pour traiter le trafic entrant dans cette enveloppe descriptive seront disponibles pour le client. Si les propriétés de génération du trafic du client devaient tomber en dehors de la région décrite par les paramètres TSpec, la QS fournie au client pourrait afficher des caractéristiques indicatives de surcharge, y compris un grand nombre de paquets retardés ou abandonnés. La définition du service n'exige pas que les caractéristiques précises de ce comportement de surcharge correspondent à celles qui seraient reçues par un flux de données au mieux traversant le même chemin dans des conditions de surcharge.

NOTE : Dans le présent mémoire, le terme "sans charge" est utilisé au sens de "pas lourdement chargé ou encombré" plutôt que dans le sens de "pas d'autre trafic réseau quel qu'il soit".

3.   Motivation

Le service de charge contrôlée est destiné à prendre en charge une large classe d'applications qui ont été développées pour une utilisation dans l'Internet d'aujourd'hui, mais sont très sensibles aux conditions de surcharge. Des membres importants de cette classe sont les "applications adaptatives en temps réel" actuellement offertes par un certain nombre de fabricants et chercheurs. Ces applications se sont révélées bien fonctionner sur des réseaux non surchargés, mais se dégrader rapidement dans des conditions de surcharge. Un service qui simule des réseaux non chargés sert bien ces applications.

Le service de charge contrôlée est intentionnellement minimal, en ce qu'il n'y a pas de fonctions ou capacités facultatives dans la spécification. Le service offre seulement une fonction, et les concepteurs de système et d'application peuvent supposer que toutes les mises en œuvre seront identiques sous cet angle.

En interne, le service de charge contrôlée convient pour une large gamme de mises en œuvre techniques, y compris des algorithmes évolutifs de programmation et de contrôle d'admission qui permettent aux mises en œuvre d'être très efficaces dans l'utilisation des ressources du réseau. Il est également sensible à des mises en œuvre extrêmement simples dans des circonstances où l'utilisation maximum des ressources du réseau n'est pas la seule préoccupation.

4.   Exigences pour le traitement des données d'élément de réseau

Chaque élément de réseau qui accepte une demande pour le service de charge contrôlée doit s'assurer que des ressources adéquates de bande passante et de traitement de paquet sont disponibles pour traiter le niveau de trafic demandé, comme indiqué par la TSpec du demandeur. Cela doit être réalisé par un contrôle d'admission actif. Toutes les ressources importantes pour le fonctionnement de l'élément de réseau doivent être considérées lors de l'admission d'une demande. Des exemples courants de telles ressources incluent la bande passante de la liaison, l'espace de mémoire tampon des routeurs ou accès de commutateur, et les capacités de calcul du moteur de transmission de paquets.

Le service de charge contrôlée n'accepte pas ni n'utilise de valeurs cibles spécifiques pour les paramètres de contrôle comme les délais ou les pertes. L'acceptation d'une demande du service de charge contrôlée est plutôt définie comme impliquant une obligation de la part de l'élément de réseau de fournir au demandeur un service étroitement équivalent à celui fourni au trafic non contrôlé (trafic au mieux) dans des conditions de charge légère.

La définition de "étroitement équivalent au service au mieux non chargé" est nécessairement imprécise. Il est très facile de définir cette qualité de service en décrivant les événements qui sont attendus comme *ne survenant pas*, à aucune fréquence. Un flux qui reçoit un service de charge contrôlée à un élément de réseau peut s'attendre à rencontrer :

-   Peu ou pas de délai moyen de mise en file d'attente de paquet sur toutes les échelles de temps significativement supérieures au "moment de salve". Le moment de salve est défini comme le temps nécessaire pour que la salve de taille maximum d'un flux soit transmise au taux de transmission demandé du flux, où la taille de salve et le taux sont donnés par la TSpec du flux, comme décrit ci-dessous.

-   Peu ou pas de perte due à l'encombrement à toutes les échelles de temps significativement supérieures au "moment de salve" défini ci-dessus. Dans ce contexte, la perte due à l'encombrement inclut les pertes de paquets dues à la pénurie de toute ressource de traitement nécessaire, telle que de l'espace de mémoire tampon ou de bande passante de liaison. Bien que des pertes dues à un encombrement occasionnel puissent survenir, toute perte substantielle durable représente un échec de l'algorithme de contrôle d'admission.

L'effet de base de ce langage est d'établir une attente sur la *durée* d'une interruption du service de livraison. Les événements de plus courte durée sont vus comme des effets statistiques qui peuvent survenir en fonctionnement normal. Les événements de plus longue durée sont des indications d'échec à allouer une capacité adéquate au flux à charge contrôlée.

Un élément de réseau peut employer des approches statistiques pour décider si une capacité adéquate est disponible pour accepter une demande de service. Par exemple, un élément de réseau qui traite un certain nombre de flux avec des caractéristiques à long terme prédites par des mesures du comportement passé peut être dans une certaine mesure capable de surallouer ses ressources sans réduire le niveau de service délivré aux flux.

Un élément de réseau peut employer tout moyen approprié de programmation pour s'assurer que les flux admis reçoivent le service approprié.

NOTE : La souplesse impliquée par le paragraphe ci-dessus existe dans des limites définies. Le lecteur devrait observer que l'exigence de délai et de comportement de perte de la spécification décrits ci-dessus impose des exigences concrètes aux mises en œuvre.

Peut-être que l'exigence la plus importante est que la mise en œuvre doive rendre la bande passante plus grande que le taux de jeton de TSpec disponible pour le flux dans certaines situations. L'exigence de disponibilité de bande passante supplémentaire peut se déduire du modèle de fluide de la programmation du trafic (par exemple, [7]). Si un flux reçoit exactement son taux de jetons promis à tout moment, la mise en file d'attente causée par une salve supérieure aux attentes qui arrive à l'élément de réseau peut ne jamais se libérer, causant l'accroissement permanent du délai de mise en file d'attente. Cela va arriver si le flux continue de générer du trafic au débit de jetons exact après l'émission de la salve.

Pour contrôler les effets à long terme des salves de trafic, une mise en œuvre de charge contrôlée a plusieurs options. Au minimum, un mécanisme doit être présent pour "emprunter" la bande passante nécessaire pour libérer les salves du réseau. Il y a un certain nombre de façons pour mettre en œuvre un tel mécanisme, qui vont de schémas d'emprunt explicites au sein du programmeur de trafic à des schémas implicites fondés sur le multiplexage statistique et sur le contrôle d'admission fondé sur des mesures. La présente spécification n'a pas de méthode préférée mais exige qu'un tel mécanisme existe bien.

De même, l'exigence de faibles pertes dues à l'encombrement pour le trafic dans les TSpec implique que la gestion des mémoires tampon ait une certaine souplesse. Comme le service de charge contrôlée ne reformate pas le trafic de ses paramètres de remplissage de jetons à chaque nœud, le trafic qui s'écoule à travers le réseau va subir des distorsions lorsque il traverse des points de mise en file d'attente. Cette distorsion va survenir avec une vraisemblance particulière durant les salves de trafic, précisément lorsque la mise en mémoire tampon est la plus lourdement utilisée. Dans ces circonstances, restreindre de façon rigide la capacité de mise en mémoire tampon à une taille égale à la taille de salve de la TSpec du flux peut conduire à des pertes dues à l'encombrement. Une mise en œuvre devrait être prête à mettre des capacités de mémoire tampon supplémentaires à la disposition des flux de salve. Une fois encore, cela peut se faire de différentes façons. Un choix évident est le multiplexage statistique d'un pôle de mémoires tampon partagées.

Les liaisons ne sont pas autorisées à fragmenter les paquets qui reçoivent le service de charge contrôlée. Les paquets qui dépassent la MTU de la liaison doivent être traités comme non conformes à la TSpec. Cela implique qu'ils soient transmis conformément aux règles décrites dans la section de régulation ci-dessous.

Les mises en œuvre de service de charge contrôlée ne sont pas obligées de fournir de contrôle de la gigue de délai de paquet à court terme au delà de ce qui est décrit ci-dessus. Cependant, l'utilisation des algorithmes de programmation de paquet qui fournissent davantage de contrôle de gigue ne sont pas interdits par la présente spécification.

Les pertes de paquets dues à des causes sans rapport avec l'encombrement, telles que des erreurs de liaison, ne sont pas couvertes par ce service.

5.   Informations d'invocation

Le service de charge contrôlée est invoqué en spécifiant les paramètres (TSpec) de trafic désirés du flux de données à l'élément de réseau. Les demandes concernant un nouveau flux seront acceptés si l'élément de réseau a la capacité de transmettre les paquets du flux comme décrit ci-dessus. Les demandes de changement de la TSpec pour un flux existant devraient être traitées comme une nouvelle invocation, au sens où le contrôle d'admission doit être appliqué à nouveau au flux. Les demandes qui réduisent la TSpec pour un flux existant (au sens où la nouvelle TSpec est strictement plus petite que l'ancienne TSpec conformément aux règles d'ordre données plus loin) ne devraient jamais se voir refuser le service.

Le service de charge contrôlée utilise l'objet TOKEN_BUCKET_TSPEC défini sous la référence [RFC2215] pour décrire les paramètres de trafic d'un flux de données. Cette TSpec prend la forme d'une spécification de remplissage de jetons plus un taux de crête (p), une unité régulée minimum (m) et une taille maximum de paquet (M).

La spécification de remplissage de jetons comporte un débit de baquet r et une profondeur de baquet, b. r et b doivent tous deux être positifs. Le débit, r, est mesuré en octets de datagrammes IP par seconde. Les valeurs de ce paramètre peuvent aller de un octet par seconde à 40 téraoctets par seconde. Les éléments de réseau DOIVENT retourner une erreur pour les demandes qui contiennent des valeurs en-dehors de cette gamme. Les éléments de réseau DOIVENT retourner une erreur pour toute demande contenant une valeur dans cette gamme qui ne peut pas être prise en charge par l'élément. En pratique, seuls les quelques premiers chiffres du paramètre r sont significatifs, de sorte que l'utilisation de représentations en virgule flottante, précise à au moins 99,9 % est conseillée.

La profondeur de baquet, b, est mesurée en octets. Les valeurs de ce paramètre peuvent aller de 1 octet à 250 gigaoctets. Les éléments de réseau DOIVENT retourner une erreur pour les demandes qui contiennent des valeurs en-dehors de cette gamme. Les éléments de réseau DOIVENT retourner une erreur pour toute demande contenant une valeur dans cette gamme qui ne peut pas être prise en charge par l'élément. En pratique, seuls les quelques premiers chiffres du paramètre b sont significatifs, de sorte que l'utilisation de représentations en virgule flottante, précises à au moins 99,9 % est conseillée.

La gamme des valeurs admises pour ces paramètres est intentionnellement large pour permettre les technologies futures de réseau . Aucun élément de réseau n'est supposé prendre en charge la gamme complète des valeurs.

Le taux de crête, p, est mesuré en octets de datagrammes IP par seconde et a la même gamme et représentation suggérées que le débit de baquet. Le paramètre débit de crête existe dans la présente version de la spécification principalement pour la compatibilité de la TSpec avec les autres services de contrôle de la QS et le paramètre TOKEN_BUCKET_TSPEC partagé. Bien que certains algorithmes de contrôle d'admission et d'allocation de mémoire tampon puissent trouver la valeur de débit de crête utile, le champ peut toujours être ignoré par un service de charge contrôlée se conformant à cette version de la spécification. C'est à dire que le module de service chez un élément de réseau peut toujours supposer que le débit de crête de données arrivant à cet élément est le débit de ligne de l'interface entrante, et les critères d'évaluation du service n'exigent pas d'un élément de réseau qu'il prenne en compte la valeur du débit de crête. Une utilisation plus explicite du paramètre débit de crête par un module de service de charge contrôlée pourra être ajoutée à cette spécification à l'avenir.

L'unité régulée minimum, m, est un entier mesuré en octets. Tous les datagrammes IP inférieurs à la taille m seront comptés comme ayant la taille m par rapport au remplissage de jetons. La taille maximum de paquet, M, est le plus gros paquet qui va se conformer à la spécification de trafic ; elle est aussi mesurée en octets. Les éléments de réseau DOIVENT rejeter une demande de service si la taille maximum de paquet 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.

La représentation concrète préférée de la TSpec est celle de trois nombres à virgule flottante en précision simple en format IEEE suivis par deux entiers de 32 bits dans l'ordre des octets du réseau. La première valeur est le débit (r), la seconde valeur est la taille du baquet (b), la troisième est le débit de crête (p), la quatrième est l'unité régulée minimum (m), et la cinquième est la taille maximum de paquet (M). Pour les paramètres (r) et (b), seuls les schémas binaires qui représentent des nombres valides non négatifs à virgule flottante sont admis. Les nombres négatifs (y compris le "zéro négatif"), l'infini, et les NAN (pas un nombre) ne sont pas permis. Pour le paramètre (p) seuls les gabarits binaires qui représentent des nombres valides non négatifs à virgule flottante ou l'infini positif sont admis. L'infini positif est représenté par un exposant tout de uns (255) et un bit de signe et une mantisse toute de zéros. Les nombres négatifs (y compris le "zéro négatif"), l'infini négatif, et les NAN ne sont pas admis.

NOTE : Une mise en œuvre qui utilise un matériel d'utilisation générale ou un logiciel qui prend en charge la virgule flottante définie par l'IEEE peut souhaiter vérifier que les paramètres qui arrivent satisfont à cette exigence avant de les utiliser dans les calculs de virgule flottante, afin d'éviter des exceptions ou pièges inattendus

Le nom de service 5 est alloué au service de charge contrôlée.

Le paramètre TOKEN_BUCKET_TSPEC utilisé par le service de charge contrôlée a le numéro de paramètre général 127, comme indiqué dans [RFC2215].

6.   Informations exportées

Le service de charge contrôlée n'a pas de paramètres de caractérisation exigé. Les mises en œuvre individuelles peuvent exporter des mesures appropriées spécifiques de la mise en œuvre et des informations de surveillance.

7.   Régulation

Le service de charge contrôlée est fourni à un flux sur la base de la conformité du trafic de ce flux à une TSpec donnée au moment de l'établissement du flux. La présente section définit la signification de la conformité à la TSpec de charge contrôlée, décrit les circonstances dans lesquelles le trafic d'un flux de charge contrôlée pourrait "n'être pas" conforme à la TSpec, et spécifie l'action de l'élément de réseau dans ces circonstances.

Les modules du service de charge contrôlée fournissent le contrôle de la QS pour le trafic conforme à la TSpec donnée au moment de l'établissement. Les paramètres de remplissage de jetons de la TSpec exigent que le trafic obéisse à la règle que sur toute période de temps, la quantité de données n'excède pas rT+b, où r et b sont les paramètres de remplissage de jeton et T est la longueur de la période de temps. Pour les besoins de cette comptabilité, les liaisons doivent compter les paquets qui sont plus petits que l'unité de régulation minimale m comme étant de taille m. Les paquets qui arrivent sur un élément et causent une violation de la limite rT+b sont considérés comme non conformes.

De plus, les paquets plus gros que la MTU de liaison sortante sont considérés comme non conformes. Il est prévu que cette situation n'arrive à aucune fréquence, parce que les mécanismes d'établissement de flux sont censés notifier à l'application d'envoi la MTU de chemin appropriée.

En présence de l'arrivée de paquets non conformes pour un ou plusieurs flux de charge contrôlée, chaque élément de réseau doit s'assurer localement que les exigences suivantes sont satisfaites :

1)   L'élément de réseau DOIT continuer de fournir la qualité de service contractuelle à ceux des flux de charge contrôlée qui ne rencontrent pas de trafic excédentaire.

2)   L'élément de réseau DEVRAIT empêcher le trafic à charge contrôlée excédentaire d'impacter injustement le traitement d'arrivée du trafic au mieux. Cette exigence est exposée plus en détails à la Section 9 du présent document (Lignes directrices pour la mise en œuvre).

3)   En cohérence avec les points 1 et 2, l'élément de réseau DOIT essayer de transmettre le trafic excédentaire au mieux si des ressources suffisantes sont disponibles.

Les éléments de réseau ne doivent pas supposer que l'arrivée de trafic non conforme pour un flux spécifique à charge contrôlée sera inhabituelle, ou indicatrice d'erreur. Dans certaines circonstances (en particulier, de routeurs agissant comme "points de répartition" d'une arborescence de distribution de diffusion groupée pour la prise en charge d'une réservation partagée) un grand nombre de paquets vont échouer à l'essai de conformité *au titre du fonctionnement normal*.

Les éléments de réseau ne doivent pas supposer que les sources de données ou les éléments en amont ont pris des mesures pour "réguler" les flux de charge contrôlée en limitant leur trafic pour qu'il se conforme à la TSpec du flux. Chaque élément de réseau qui fournit le service de charge contrôlée DOIT s'assurer indépendamment que les exigences données ci-dessus sont satisfaites en présence de l'arrivée de trafic non conforme pour un ou plusieurs flux à charge contrôlée.

Les éléments de réseau peuvent utiliser tout mécanisme de mise en œuvre approprié pour satisfaire aux exigences données ci-dessus. Des exemples de ces mécanismes incluent des filtres de régulation de remplissage de jetons et des algorithmes de programmation flux par flux. Cependant, il est insuffisant de simplement placer tous les flux de charge contrôlée dans le même pôle de ressources partagées, sans d'abord s'assurer que les flux non conformes sont empêchés d'affamer les flux conformes des ressources de traitement nécessaires.

Un exposé complémentaire sur cette question se trouve à la Section 11 du présent document.

Au delà des exigences 2 et 3 ci-dessus, le service de charge contrôlée ne définit pas le comportement en matière de QS servi aux flux qui ont du trafic d'arrivée non conforme. Précisément, il est permis aussi bien de dégrader également le service fourni à tous les paquets du flux que de trier les paquets du flux entre ensemble conforme et ensemble non conforme et de fournir des niveaux de service différents aux deux ensembles. Ce point est discuté plus avant à la Section 9.

Lorsque des ressources sont disponibles, les éléments de réseau à des points à l'intérieur du réseau DEVRAIENT être prêts à s'accommoder des salves de paquets plus grandes que la TSpec réelle. Cette exigence découle de l'effet de distorsion du trafic décrit à la Section 4. Elle peut être satisfaite par des moyens explicites ou par le multiplexage statistique de ressources de mise en mémoire tampon partagées.

Lors du traitement d'un tel trafic, il est permis de retarder un peu un paquet si ce retard lui permet de passer la fonction de régulation. (En d'autres termes, de reformater le trafic). Cependant, l'exigence globale de limitation de la durée de toute distorsion de trafic de cette sorte doit être prise en compte. Le défi est de définir une fonction de reformatage viable.

Intuitivement, une approche plausible est de permettre un retard du maximum (en gros) de délai de mise en file d'attente rencontré par les paquets entièrement conformes avant de déclarer qu'un paquet a échoué à la fonction de régulation. Le mérite de cette approche, et la formulation précise de la spécification qui la décrit, requièrent un complément d'étude.

8.   Ordre et fusion

La TSpec de service de charge contrôlée est ordonnée conformément aux règles suivantes : La TSpec A est un substitut de ("aussi bonne ou meilleure que" ou"supérieure ou égale à") la TSpec B si et seulement si :

(1)   le débit de remplissage de jetons r pour la TSpec A est supérieur ou égal à celui de la TSpec B,

(2)   la profondeur du baquet de jetons b de la TSpec A est supérieure ou égale à celle de la TSpec B,

(3)   le débit de crête p pour la TSpec A est supérieur ou égal à celui de la TSpec B,

(4)   l'unité de régulation minimum m pour la TSpec A est inférieure ou égale à celle de la TSpec B,

(5)   la taille maximum de paquet M de la TSpec A est supérieure ou égale à celle de la TSpec B.

Noter que toutes les TSpec ne peuvent pas être ordonnées les unes par rapport aux autres. Si deux TSpec diffèrent mais que les cinq points ci-dessus ne sont pas tous vrais, les TSpec ne sont alors pas ordonnées.

Une TSpec fusionnée est la TSpec utilisée par le protocole RSVP lors de la fusion d'un ensemble de TSpec pour créer une réservation "fusionnée". La fusion des TSpec est décrite plus avant dans les [RFC2210] et [RFC2205]. L'opération de fusion de TSpec vise deux exigences :

-   Les paramètres de TSpec "fusionnée" sont utilisés comme TSpec du flux de trafic au nœud local.

-   Les paramètres fusionnés sont passés en amont à la ou aux sources du trafic pour décrire les caractéristiques de la réservation réellement installée le long du chemin des données.

Pour le service de charge contrôlée, 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 r ;

(2)   la plus grande taille de baquet de jetons b ;

(3)   le plus grand débit de crête p ;

(4)   la plus petite unité minimale régulée m ;

(5)   la plus *petite* taille maximum de paquet M ;

entre tous les membres de l'ensemble.

La plus petite TSpec commune est une TSpec adéquate pour décrire le trafic provenant de n'importe lequel d'un certain nombre de flux de trafic. La plus petite TSpec commune peut être utile lors de la création d'une réservation partagée pour un certain nombre de flux en utilisant SNMP ou un autre protocole de gestion. Cela diffère de la TSpec fusionnée décrite ci-dessus en ce que les paramètres calculés ne sont pas passés en amont aux sources du trafic.

Pour le service de charge contrôlée, la plus petite TSpec commune peut se calculer sur un ensemble de TSpec en prenant :

(1)   le plus grand débit de remplissage de jetons r ;

(2)   la plus grande taille de baquet de jetons b ;

(3)   le plus grand débit de crête p ;

(4)   la plus petite unité minimale régulée m ;

(5)   la plus grande taille maximum de paquet M ;

entre tous les membres de l'ensemble.

La somme de n TSpec de service de charge contrôlée est utilisée lors du calcul de la TSpec pour une réservation partagée de n flux. Elle est calculée en prenant :

-   La somme sur toutes les TSpec du paramètre r de débit de remplissage de jetons.

-   La somme sur toutes les TSpec du paramètre b taille du baquet de jetons.

-   La somme sur toutes les TSpec du paramètre p débit de crête.

-   Le minimum sur toutes les TSpec du paramètre m unité minimum régulée.

-   Le maximum sur toutes les TSpec du paramètre M taille maximum de paquet.

Le minimum de deux TSpec diffère selon que les TSpec peuvent être ordonnées conformément à la règle "supérieure ou égale" mentionnée ci-dessus. Si une TSpec est inférieure à l'autre TSpec, la plus petite TSpec est le minimum. Pour les TSpec non ordonnées, une règle différente est utilisée. Le minimum de deux TSpec non ordonnées est déterminé par la comparaison de leurs valeurs respectives en choisissant :

(1)   le plus petit débit de remplissage de jetons r ;

(2)   la *plus grande* taille de baquet de jetons b ;

(3)   le plus faible débit de crête p ;

(4)   la *plus petite* unité régulée minimum m ;

(5)   la plus petite taille maximum de paquet M;

9.   Lignes directrices pour la mise en œuvre

Exigences pour l'algorithme de contrôle d'admission : L'intention de cette spécification de service est que les éléments de réseau délivrent un niveau de service s'approchant étroitement du service au mieux dans des conditions non chargées. Comme avec le service au mieux dans ces conditions, il n'est pas exigé que chaque paquet individuel soit bien livré avec un délai de zéro mise en file d'attente. Les éléments de réseau qui fournissent le service de charge contrôlée peuvent sur souscrire les ressources disponibles sans une certaine mesure, en ce sens que les exigences de bande passante et de mémoire tampon indiquées par l'addition des taux de remplissage de jetons de TSpec de tous les flux de charge contrôlée peut excéder les capacités maximum de l'élément de réseau. Cependant, cette sursouscription ne peut être effectuée que dans les cas où l'élément est assez sûr que l'utilisation réelle sera inférieure à la somme que suggèrerait les baquets de jetons, de sorte que l'objectif de performances de la mise en œuvre sera atteint. Ces informations peuvent venir de mesures du flux de trafic agrégé, d'une connaissance spécifique des statistiques de trafic de l'application, ou d'autres moyens. L'approche la plus prudente, le rejet des nouveaux flux chaque fois que l'addition de leur trafic causerait le dépassement par la somme stricte des baquets de jetons de la capacité de l'élément de réseau (y compris la considération des ressources nécessaires pour maintenir les caractéristiques de délai et de perte spécifiées par le service) peut être appropriée dans d'autres circonstances.

Les questions spécifiques de ce sujet sont exposées dans les sections "Critères d'évaluation" et "Exemples de mise en œuvre" ci-dessous.

Interaction avec le trafic au mieux : Une mise en œuvre de ce service devrait clairement comprendre que dans certaines circonstances (routeurs agissant comme "points de répartition" d'une arborescence de distribution de diffusion groupée qui prend en charge une réservation partagée ) de grands nombres de paquets d'un flux peuvent échouer à l'essai de conformité à la TSpec *au titre du fonctionnement normal*. Conformément aux exigences de la Section 7, ces paquets devraient être transmis sur une base au mieux si les ressources le permettent.

Si l'algorithme de mise en file d'attente au mieux de l'élément de réseau ne fait pas la distinction entre ces paquets et ceux du trafic au mieux élastique tels que ceux de flux TCP, les paquets de charge contrôlée en excès vont "réduire" le trafic élastique et dominer l'utilisation de la bande passante au mieux. Le cadre des services intégrés ne règle actuellement pas cette question. Cependant, plusieurs solutions possibles sont connues à ce problème [RFC2309]. Les éléments de réseau qui prennent en charge le service de charge contrôlée devrait mettre en œuvre quelque mécanisme dans leur chemin de mise en file d'attente au mieux pour faire une discrimination entre classes de trafic au mieux et pour fournir au trafic élastique une protection contre les flux au mieux inélastiques.

Deux approches de base sont disponibles pour satisfaire à cette exigence. L'élément de réseau peut entretenir des allocations de ressource séparées pour les différentes classes de trafic au mieux, de sorte qu'aucune classe ne domine excessivement la charge du mélange au mieux. Autrement, un élément peut traiter le trafic à charge contrôlée en excès à une priorité quelque peu inférieure à celle du trafic élastique au mieux, de façon à éviter complètement l'effet de réduction mentionné plus haut.

Si tout ou la plupart du trafic à charge contrôlée provient d'applications en temps réel à débit non adaptatif, l'utilisation d'un mécanisme de priorité peut être souhaitable. Si la plus grande partie du trafic à charge contrôlée provient d'applications en temps réel à débit adaptatif ou élastique qui tentent d'établir un niveau minimum de service encadré, l'utilisation de classes de ressource distinctes peut être préférable. Cependant, ceci n'est pas une ligne directrice impérative. En pratique, le choix du mécanisme par le concepteur de l'élément de réseau va dépendre en grande partie à la fois des objectifs de conception et des techniques de mise en œuvre appropriés à la plate-forme du concepteur. Cette version de la spécification de service ne spécifie aucun de ces comportements, mais laisse le choix aux développeurs.

Comportement de transmission en présence de trafic non conforme : Comme indiqué à la Section 7, le service de charge contrôlée ne définit pas le comportement en matière de QS délivrée aux flux qui arrivent avec du trafic non conforme. Il est permis aussi bien de dégrader également le service fourni à tous les paquets du flux que de trier les paquets du flux en des ensembles conformes et non conformes et de fournir des niveaux de service différents à chacun des ensembles.

Dans le premier cas, le délai de mise en file d'attente espéré et la probabilité de perte de paquet vont augmenter pour tous les paquets du flux, mais le réarrangement de l'ordre de livraison des paquets va en général rester à de faibles niveaux. Ce comportement est préférable pour les applications ou protocoles de transport qui sont sensibles à des réarrangements de paquet excessifs. Un exemple possible est celui d'une connexion TCP non modifiée, qui verrait des réarrangements ainsi que des pertes de paquet, ce qui déclancherait des duplications d'accusés de réception et donc des retransmissions excessives.

Dans le second cas, un sous ensemble des paquets du flux sera livré avec de faibles pertes et retards, alors que certains autres sous ensembles seront livrés avec de plus fortes pertes et des délais potentiellement plus élevés. Les paquets retardés vont apparaître au receveur comme ayant été réarrangés dans le réseau, alors que les paquets non retardés vont, en moyenne, arriver à temps, plus que si tous les paquets avaient été traités de façon égale. Cela peut être préférable pour les applications qui sont très sensibles au temps, telles que les outils de conférences interactives.

10.   Critères d'évaluation

L'exigence de base pour une mise en œuvre de service de charge contrôlée est que dans toutes conditions, elle fournisse des flux de données acceptés avec un service étroitement similaire à celui que le même flux aurait reçu en utilisant le service au mieux dans des conditions non chargées.

Cela suggère une stratégie simple d'évaluation en deux étapes. L'étape une est de comparer le service fourni à un trafic au mieux avec le trafic à charge contrôlée dans des conditions non chargées.

-   Mesurer le taux de perte de paquet et les caractéristiques de délai d'un flux d'essai en utilisant le service au mieux sans charge sur l'élément de réseau.

-   Comparer ces mesures avec celles du même flux recevant un service de charge contrôlée sans charge sur l'élément de réseau.

Des mesures proches indiquent des taux d'évaluation élevés. Une différence substantielle dans les caractéristiques de délai, telle que le lissage qu'on verrait dans une mise en œuvre qui a programmé le flux à charge contrôlée en utilisant un algorithme à débit binaire fixé constant devrait résulter en un taux un peu moins élevé.

L'étape deux est d'observer les changements de service reçus par un flux à charge contrôlée lorsque la charge augmente.

-   Augmenter la charge du trafic local d'arrière plan sur l'élément de réseau, tout en continuant de mesurer les caractéristiques de perte et de délai du flux à charge contrôlée. Les caractéristiques qui restent essentiellement constantes lorsque l'élément est conduit à la surcharge indiquent un fort taux d'évaluation. Des changements mineurs de la distribution des délais indiquent un taux un peu plus faible. Une augmentation significative du délai ou des pertes indiquent un faible taux d'évaluation.

Ce modèle simple n'est pas adéquat pour évaluer pleinement les performances du service à charge contrôlée. Trois variables supplémentaires affectent l'évaluation. La première est la sporadicité à court terme des flux de trafic utilisés pour effectuer les essais mentionnés ci-dessus. La seconde est le degré de changement à long terme du trafic à charge contrôlée au sein des limites de sa TSpec. (Les changements de ses caractéristiques auront un grand effet sur l'efficacité de certains algorithmes de contrôle d'admission.) La troisième est le rapport du trafic à charge contrôlée avec les autres trafics sur l'élément de réseau (trafic au mieux ou d'autres services contrôlés).

La troisième variable devrait être évaluée de façon spécifique en utilisant la procédure suivante.

Aucun flux à charge contrôlée n'étant en place, surcharger l'élément de réseau avec du trafic au mieux (comme indiqué par une perte de paquets substantielle et des délais de mise en file d'attente).

Exécuter les demandes de service de charge contrôlée qui donnent des TSpec avec des taux et des paramètres de salve croissants. Si la demande est acceptée, vérifier que le trafic qui satisfait à la TSpec est en fait traité avec des caractéristiques approchant étroitement les mesures en condition non chargée prises auparavant.

Répéter ces expériences pour déterminer la gamme de valeurs de paramètres de trafic (débit, taille de salves) traitées avec succès par l'élément de réseau. La gamme utile de chaque paramètre doit être déterminée pour plusieurs réglages des autres paramètres, pour cartographier une "région" bidimensionnelle de TSpec traitées avec succès. En comparant avec les éléments de réseau fournissant des capacités similaires, cette région indique la capacité relative des éléments à fournir le service de charge contrôlée sous des charges élevées. Une plus grande région indique une taux d'évaluation plus fort.

11.   Exemples de mise en œuvre

Une mise en œuvre possible du service à charge contrôlée est de fournir un mécanisme de mise en file d'attente avec deux niveaux de priorité ; un niveau de haute priorité pour la charge contrôlée et une priorité inférieure pour le service au mieux. Un algorithme de contrôle d'admission est utilisé pour limiter la quantité du trafic placé dans la file d'attente de priorité élevée. Cet algorithme peut se fonder sur les caractéristiques spécifiées des flux de haute priorité (en utilisant les informations fournies par les TSpec) ou sur les caractéristiques mesurées des flux à haute priorité existants et de la TSpec de la nouvelle demande.

Une autre mise en œuvre possible du service de charge contrôlée se fonde sur les capacités existantes des éléments de réseau qui prennent en charge les "classes de trafic" fondées sur des mécanismes tels que la mise en file d'attente à pondération équitable (WFQ, Weighted Fair Queueing) ou la mise en file d'attente fondée sur la classe [6]. Dans ce cas, il est suffisant de transposer les flux de données acceptés pour le service de charge contrôlée dans une classe de trafic existante avec une capacité adéquate pour éviter la surcharge. Cette exigence est mise en application par un algorithme de contrôle d'admission qui prend en considération les caractéristiques de la classe de trafic, les caractéristiques du trafic déjà admis dans la classe, et la TSpec du nouveau flux qui demande le service. Là encore, l'algorithme de contrôle d'admission peut se fonder sur les caractéristiques spécifiées dans la TSpec ou dans celles mesurées sur le trafic existant.

Un cas particulier de l'approche ci-dessus est d'employer un programmeur qui met en œuvre la mise en file d'attente à pondération équitable ou un schéma de gestion de charge similaire, qui alloue une programmation distincte de mise en file d'attente avec des pondérations correctement choisies pour chaque flux à charge contrôlée individuel. Dans ces circonstances, le programmeur de trafic joue aussi le rôle de fonction de régulation, en s'assurant que le trafic non conforme qui arrive pour un flux à charge contrôlée n'affecte ni d'autres flux à charge contrôlée ni le trafic au mieux. Ce mécanisme d'élimination présente l'inconvénient de ne pas tirer parti des gains de performances ou d'utilisation de ressource résultants de l'agrégation statistique de plusieurs flux en une seule classe de mise en file d'attente.

Les algorithmes de contrôle d'admission fondés sur les caractéristiques spécifiées seront vraisemblablement appropriés lorsque le nombre de flux est faible dans la classe à priorité élevée, ou que les caractéristiques du trafic des flux apparaissent comme très variables. Dans ces situations, le comportement mesuré des flux de trafic agrégés à charge contrôlée peut ne pas pouvoir servir de moyen de prévision efficace du trafic futur, ce qui fait que l'algorithme de contrôle d'admission fondé sur les mesures produit des résultats incorrects. À l'inverse, dans les situations où le comportement passé du trafic à charge contrôlée agrégé *est* un bon moyen de prévision du comportement futur, un algorithme de contrôle d'admission fondé sur les mesures peut permettre que plus de trafic soit admis dans la classe du service à charge contrôlée sans dégradation des performances. Une mise en œuvre peut choisir de commuter de l'une à l'autre de ces deux approches selon la nature des flux de trafic à un moment donné.

Diverses techniques peuvent être utilisées pour fournir l'isolement souhaité entre le trafic à charge contrôlée excédentaire (non conforme) et le trafic au mieux. L'utilisation d'une file d'attente à faible priorité pour le trafic à charge contrôlée non conforme est simple, mais d'autres approches peuvent fournir un meilleur service ou mieux convenir dans les architectures existantes. Des variantes de la mise en file d'attente équitable ou de la mise en file d'attente à pondération équitable peuvent être utilisées pour allouer un pourcentage des ressources disponibles aux différentes classes de trafic au mieux. Une approche serait d'allouer à chaque flux à charge contrôlée un pourcentage 1/N "équitable" de la bande passante disponible au mieux pour son trafic excédentaire. Une autre approche serait de fournir une seule classe de ressources WFQ pour tout le trafic à charge contrôlée excédentaire. Finalement, des mécanismes de remplacement tels que RED (Random Early Detection, détection précoce aléatoire) [RFC2309] peuvent être utilisés pour fournir la même fonction globale.

12.   Exemples d'utilisation

Le service de charge contrôlée peut être utilisé par toute application qui peut faire usage du service au mieux, mais convient mieux aux applications qui peuvent utilement caractériser leurs exigences de trafic. Les applications qui se fondent sur le transport de données "à support continu", telles que de l'audio ou de la vidéo numérisés, sont un exemple important de cette classe.

Le service à charge contrôlée n'est pas isochrone et ne fournit aucune information explicite sur les délais de transmission. Pour cette raison, les applications qui ont des exigences temporelles de bout en bout, y compris celle de la classe à support continu mentionnée ci-dessus, fournissent un mécanisme de récupération du rythme spécifique de l'application, similaire ou identique aux mécanismes requis lorsque ces applications utilisent le service au mieux. Un protocole utile pour les applications qui exigent cette capacité est le protocole de transport en temps réel de l'IETF [RFC1889].

Les applications sensibles à l'encombrement peuvent choisir de demander le service de charge contrôlée chaque fois qu'elles sont lancées. Autrement, ces applications peuvent surveiller leurs propres performances et ne demander le service de charge contrôlée au réseau que lorsque le service au mieux ne fournit pas de performances acceptables. La première tactique donne une meilleure assurance que le niveau de qualité fournie à l'utilisateur ne va pas changer pendant la durée de vie de la session de l'application. La seconde tactique donne une plus grande souplesse et permet des économies de coûts dans des environnements où les niveaux de service au dessus de au mieux entraînent des charges.

13.   Considérations pour la sécurité

Un élément de réseau qui met en œuvre le service décrit ici est intentionnellement et explicitement supposé donner un traitement préférentiel au trafic des paquets sélectionnées. Le présent mémoire ne décrit pas le mécanisme utilisé pour indiquer quel trafic doit recevoir le traitement préférentiel — le service de charge contrôlée décrit ici peut plutôt être invoqué par un certain nombre de mécanismes, y compris RSVP, le logiciel de gestion de réseau SNMP, ou des logiciels de contrôle brevetés. Cependant, tout mécanisme utilisé pour invoquer le service à charge contrôlé doit fournir une sécurité suffisante pour se garder contre l'utilisation de cette capacité de traitement préférentiel par du trafic indésirable ou non autorisé. Une mise en œuvre correcte du service de charge contrôlée *n'est pas* susceptible d'une attaque de déni de service fondée sur une demande malveillante d'une très petite allocation de ressource pour le flux de trafic attaqué. Cela parce que la spécification de service exige que le trafic excédentaire du niveau demandé soit transporté au mieux, plutôt que d'être éliminé. Cette exigence est exposée plus en détails à la section 7 du présent mémoire.

Par nécessité, donner un service préférentiel à certains flux de trafic implique de donner moins de service aux autres flux de trafic. Il est donc possible de mener une attaque de déni de service par une reconfiguration malveillante de l'algorithme de contrôle d'admission de contrôle de charge pour admettre la sur allocation de la bande passante disponible ou des autres ressources de transmission, affamant ainsi les flux sans contrôle de charge. En général, cala n'est pas susceptible d'augmenter la vulnérabilité du réseau aux attaques, parce que de nombreuses autres reconfigurations d'un routeur ou hôte peuvent causer un déni de service. Il est raisonnable de supposer que quel que soit le moyen utilisé pour se protéger contre les attaques par reconfiguration, il sera aussi adéquat pour se protéger aussi contre celle-la.

Appendice 1   Utilisation du service de charge contrôlée avec RSVP

L'utilisation du service de charge contrôlée en conjonction avec le protocole d'établissement de réservation de ressource RSVP est spécifiée dans la [RFC2210]. Le présent document donne le format des objets RSVP FLOWSPEC, SENDER_TSPEC, et ADSPEC nécessaires à la prise en charge des applications qui désirent le service de charge contrôlée et donne des informations sur la façon du RSVP traite ces objets. Le protocole RSVP lui-même est spécifié dans la [RFC2205].

Références

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

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

[RFC1889]   H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voirRFC3550 STD64)

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

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

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

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

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

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

Adresse de l'auteur

John Wroclawski

MIT Laboratory for Computer Science

545 Technology Sq.

Cambridge, MA 02139

USA

téléphone : 617-253-7885

fax : 617-253-2673 (FAX)

mél : jtw@lcs.mit.edu