Paramètres généraux de caractérisation pour éléments de réseau à intégration de service

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éfinit un ensemble de paramètres de contrôle général et de caractérisation pour les éléments de réseau qui prennent en charge le cadre de contrôle de la qualité de service des services intégrés définis par l'IETF. Les paramètres généraux sont ceux qui ont des définitions partagées communes sur tous les services de contrôle de la QS.

1.   Introduction

Le présent mémoire définit l'ensemble des paramètres de contrôle général et de caractérisation utilisés par les éléments de réseau qui prennent en charge le cadre des services intégrés. "Général" signifie que le paramètre a une définition commune et une signification partagée entre tous les services de contrôle de la QS.

Les paramètres de contrôle sont utilisés par les applications pour fournir au réseau les informations qui se rapportent aux demandes de contrôle de la QS. Un exemple en est la spécification du trafic (TSpec) générée par les applications envoyeuses et receveuses.

Les paramètres de caractérisation sont utilisés pour découvrir ou caractériser l'environnement de gestion de la qualité de service le long du chemin d'un flux de paquets exigeant un contrôle actif de la QS de bout en bout. Ces caractérisations peuvent éventuellement être utilisées par l'application qui demande le contrôle de QS, ou par d'autres éléments de réseau le long du chemin. En sont des exemples les informations sur les services de contrôle de la QS disponibles le long d'un chemin de réseau et les estimations de bande passante disponible du chemin.

Les spécifications individuelles de service de contrôle de la QS peuvent se référer à ces définitions de paramètres aussi bien que définir des paramètres supplémentaires spécifiques des besoins de ce service.

Les paramètres reçoivent des identifiants orientés machine en utilisant la méthode décrite dans la [RFC2216] et résumée ici. Ces identifiants peuvent être utilisés au sein des messages de protocole (par exemple, comme décrit dans la [RFC2210]) ou des interfaces de gestion pour décrire les valeurs de paramètres présentes. Chaque identifiant de paramètre est composé à partir de deux champs numériques, un qui identifie le service associé au paramètre (le <numéro_de_service>), et l'autre (le <numéro_de_paramètre>) qui identifie le paramètre lui-même. Comme les définitions des paramètres de cette note sont communes à tous les services de contrôle de la QS, les valeurs de <numéro_de_paramètre> pour les paramètres qui sont définis ici sont allouées à partir de la gamme des "paramètres généraux" (1 à 127).

NOTE : les <numéro_de_paramètre> dans la gamme 128 - 254 désignent les paramètres qui ont des définitions spécifiques d'un service de contrôle de la QS particulier. À l'opposé des paramètres généraux décrits ici, il est nécessaire de considérer à la fois le <numéro_de_service> et le <numéro_de_paramètre> pour déterminer la signification du paramètre.

Le service numéro 1 est réservé pour les utilisations décrites à la Section 2 de la présente note. Les services numéros 2 à 254 seront alloués aux services individuels de contrôle de la QS. Actuellement, le numéro 2 a été alloué au service garanti [RFC2212], et le numéro 5 a été alloué au service de charge contrôlée [RFC2211].

Dans la présente note, la forme textuelle <numéro_de_service, numéro_de_paramètre> est utilisée pour écrire une paire numéro_de_service, numéro_de_paramètre. La gamme des valeurs de numéro_de_service et numéro_de_paramètre possibles spécifiée dans la [RFC2216] permet que l'identifiant de paramètre forme directement la portion de queue d'un identifiant d'objet de MIB représentant le paramètre. Cela simplifie la tâche de rendre les valeurs de paramètre disponibles pour les applications de gestion de réseau.

La définition de chaque paramètre utilisé pour caractériser un chemin à travers le réseau décrit deux types de valeurs ; locale et composée. Une valeur locale donne des informations sur un seul élément de réseau. Les valeurs composées reflètent la composition actuelle des valeurs locales le long d'un chemin, spécifiée par une règle de composition. Chaque définition de paramètre spécifie la règle de composition pour ce paramètre. La règle de composition dit comment combiner une valeur composée entrante (à partir de la portion du chemin déjà traversée) et la valeur locale, pour donner une nouvelle valeur composée qui est passée au prochain élément de réseau dans le chemin. Noter que la composition peut s'effectuer soit vers l'aval, en direction du ou des receveurs, soit vers l'amont, en direction de l'envoyeur. Chaque paramètre peut ne donner qu'une seule définition pour la valeur locale, mais peut éventuellement donner plus d'une définition pour les règles de composition et les valeurs composées. Cela parce qu'il peut être utile de composer la même valeur locale plusieurs fois suivant des règles de composition différentes.

Parce que les paramètres de caractérisation sont utilisés pour calculer les propriétés d'un chemin spécifique à travers l'Internet, toutes les définitions de paramètres de caractérisation sont par nature "par prochain bond", par opposition à "par interface" ou "par élément de réseau". Dans les cas où l'élément de réseau est (ou contrôle) un support partagé ou un grand nuage de sous-réseau, l'élément peut avoir besoin de fournir des valeurs différentes pour différents prochains bonds au sein du nuage. En pratique, il peut être approprié pour les fabricants de choisir et publier une gamme de tolérance, telle que si toutes les valeurs de prochain bond sont dans la gamme de tolérance, une seule valeur sera mémorisée et fournie.

Les valeurs locales et composées de paramètre de caractérisation ont des identifiants distincts de sorte qu'une entité de gestion de réseau peut examiner la valeur d'un paramètre de chemin aussi bien local que composé en tout point au sein du réseau.

Chaque définition de paramètre comporte une description des propriétés minimales, telles que la gamme et la précision, exigée de toute représentation des valeurs de ce paramètre pour le réseau. Chaque définition comporte aussi une description XDR [RFC1832] du paramètre, donnant une représentation appropriée externe (pour le réseau) des données pour les valeurs du paramètre. Cette définition duale est destinée à encourager un format de représentation commun sur le réseau chaque fois que possible, tout en permettant aussi d'autres représentations lorsque exigé par les circonstances spécifiques (par exemple, ASN.1 au sein de SNMP).

Les formats de message spécifiés dans la [RFC2210] pour être utilisés avec le protocole d'établissement RSVP utilisent les paramètres de représentation de données de l'XDR.

Tous les paramètres décrits dans la présente note sont obligatoires, en ce sens qu'un élément de réseau prétendant prendre en charge le service intégré doit reconnaître les valeurs qui arrivent dans les messages de protocole d'établissement et de gestion, les traiter correctement, et exporter en réponse une valeur raisonnable. Pour certains paramètres, la spécification exige que l'élément de réseau calcule et exporte une valeur locale *précise*. Pour d'autres paramètres, il est acceptable pour l'élément de réseau d'indiquer qu'il ne peut pas calculer et exporter une valeur locale précise. La définition de ces paramètres fournit une valeur réservée qui indique "indéterminé" ou "invalide". Cette valeur signale qu'un élément ne peut pas traiter convenablement le paramètre, et par conséquent que le résultat de la composition de bout en bout est aussi discutable.

NOTE (temporaire) : Les versions précédentes de ce document et de ceux d'utilisation de RSVP utilisaient à la fois l'approche de la valeur réservée et du fanion INVALID séparé pour enregistrer ce fait. Maintenant, l'approche de la valeur réservée est seule utilisée. De cette façon, tout protocole qui restitue une valeur de paramètre, y compris SNMP, peut porter l'indication invalide sans avoir besoin d'un fanion distinct. Le fanion INVALID reste dans le format de message RSVP mais est réservé uniquement pour une possible utilisation future dans le schéma de composition de service.

2.   Valeurs par défaut et spécifiques de service pour les paramètres généraux

Les paramètres généraux ont une *définition* commune à travers tous les services de contrôle de la QS. Fréquemment, la même *valeur* d'un paramètre général sera correcte pour tous les services de contrôle de la QS offerts par un élément de réseau. Dans ces circonstances, il n'est pas besoin d'exporter une copie séparée de la valeur pour chaque service de contrôle de la QS ; au lieu de cela, le nœud peut exporter un numéro qui s'applique à tous les services pris en charge.

Une valeur de paramètre général qui s'applique à tous les services pris en charge à un nœud de réseau s'appelle une valeur par défaut ou une valeur globale. Par exemple, si tous les services de contrôle de la QS fournis à un nœud prennent en charge la même taille de paquet maximum, le nœud peut exporter une seule valeur par défaut pour le paramètre PATH_MTU décrit à la Section 3, plutôt que de fournir une copie séparée de la valeur pour chaque service de contrôle de la QS. Dans le cas courant, cela réduit à la fois la taille des messages et la redondance de traitement pour le protocole d'établissement.

Un service individuel a occasionnellement besoin de rapporter une valeur différante de la valeur par défaut pour un paramètre général particulier. Par exemple, si la mise en œuvre du service garanti [RFC2212] à un routeur est restreinte par des considérations de programmateur, ou de matériel, à une taille maximum de paquet inférieure à celle prise en charge par le chemin de transmission au mieux du routeur, la mise en œuvre peut souhaiter exporter une valeur "spécifique de service" du paramètre PATH_MTU de telle sorte que les applications qui utilisent le service garanti fonctionnent correctement.

Dans l'exemple ci-dessus, le routeur pourrait fournir une valeur de 1500 pour le paramètre PATH_MTU par défaut, et une valeur de 250 pour le paramètre PATH_MTU qui s'applique au service garanti. Dans ce cas, le protocole d'établissement qui fournit la caractérisation du chemin porte (et livre à l'application) à la fois une valeur pour le service garanti et une valeur pour les autres services.

La distinction entre des valeurs de paramètre par défaut et celles qui sont spécifiques du service n'a pas de sens pour les paramètres non généraux (ceux définis par un service de contrôle de la QS spécifique, et non pas par la présente note) parce que la définition et la valeur du paramètre sont toutes deux toujours spécifiques du service particulier.

La distinction entre les valeurs par défaut et celles spécifiques d'un service pour les paramètres généraux est reflétée dans l'espace de nom d'identifiant de paramètre. Cela permet aux nœuds de réseau, aux protocoles d'établissement, et aux outils de gestion de réseau de distinguer les valeurs par défaut de celles qui sont spécifiques d'un service, et de déterminer à quel service est associée une valeur de paramètre spécifique d'un service.

Le service numéro 1 est utilisé pour indiquer la valeur par défaut. Une valeur de paramètre identifiée par l'ID :

<1, numéro_de_paramètre>

est une valeur par défaut, qui s'applique à tous les services sauf si elle est outrepassée par une valeur spécifique d'un service pour le même paramètre.

Une valeur de paramètre identifiée par l'ID :

<numéro_de_service, numéro_de_paramètre>

où numéro_de_service n'est pas égal à 1, est une valeur spécifique d'un service. Elle ne s'applique qu'au service identifié parle numéro_de_service.

Ces valeurs spécifiques d'un service sont aussi appelées valeurs d'outrepassement. Cela parce que lorsque les valeurs par défaut et les valeurs spécifiques d'un service sont toutes deux présentes pour un paramètre, la valeur spécifique du service outrepasse la valeur par défaut (pour le service auquel elle s'applique). Les règles de composition des paramètres généraux spécifique de service et globaux prennent en charge cette capacité d'outrepassement. La règle de base est d'utiliser la valeur spécifique d'un service si elle existe, et autrement d'utiliser la valeur globale.

Un résumé complet du processus de composition des paramètres de caractérisation est donné ci-dessous. Dans ce résumé; la "valeur arrivante" est la valeur de paramètre incomplètement composée qui arrive d'un nœud voisin. La "valeur locale" est la valeur (globale ou spécifique du service) rendue disponible par le nœud local. Le "résultat" est la valeur nouvellement composée à envoyer au prochain nœud sur le chemin des données.

1.   Examinons la paire <numéro_de_service, numéro_de_paramètre> associée à la valeur arrivante. Cette information est convoyée par le protocole d'établissement avec la valeur arrivante.

2.   Si la valeur arrivante est pour un paramètre spécifique d'un seul service (ceci est vrai lorsque le numéro_de_paramètre est supérieur à 128), composer la valeur arrivante avec la valeur locale exportée par le service spécifié, et passer le résultat au prochain bond. Dans ce cas, il n'est pas besoin de considérer les valeurs globales, parce que le paramètre lui-même est spécifique d'un seul service.

3.   Si la valeur arrivante est une valeur spécifique d'un service pour un paramètre défini de façon générale (le numéro_de_paramètre est 127 ou moins, et le numéro_de_service est autre que 1) et si la mise en œuvre locale de ce service exporte aussi une valeur spécifique d'un service pour le paramètre, composer la valeur arrivante spécifique du service et la valeur locale spécifique du service du paramètre, et passer le résultat comme une valeur spécifique d'un service au nœud du prochain bond.

4.   Si la valeur arrivante est une valeur spécifique d'un service pour un paramètre général (le numéro_de_paramètre est 127 ou moins, et le numéro_de_service est autre que 1) et si la mise en œuvre locale de ce service n'exporte pas une valeur spécifique d'un service, composer la valeur arrivante spécifique du service avec la valeur globale pour ce paramètre exporté par le nœud local, et passer le résultat comme valeur spécifique d'un service au nœud de prochain bond.

5.   Si la valeur arrivante est une valeur globale pour un paramètre général (le numéro_de_paramètre est 127 ou moins, et le numéro_de_service est 1), et si la mise en œuvre locale de *tout* service exporte une valeur spécifique d'un service pour ce paramètre général, composer la valeur arrivante (globale) avec la valeur spécifique d'un service pour ce paramètre exporté par le service local, et passer le résultat comme valeur spécifique d'un service au nœud du prochain bond. Cela exigera d'ajouter un nouveau champ de données au message passé au prochain bond, pour contenir la valeur nouvellement générée spécifique d'un service. Répéter ce processus pour chaque service qui exporte une valeur spécifique d'un service pour le paramètre.

6.   Si la valeur arrivante est une valeur globale pour un paramètre général (le numéro_de_service est 1, et le numéro_de_paramètre est 127 ou moins) composer la valeur arrivante (globale) avec la valeur de paramètre global exportée par le nœud local, et passer le résultat comme valeur globale (service 1) au nœud de prochain bond. Cette étape est effectuée qu'une valeur spécifique d'un services soit générée et exportée ou non à l'étape 5.

3.   Définitions des paramètres généraux

3.1   Paramètre fanion NON-IS_HOP

Ce paramètre fournit des informations sur la présence d'éléments de réseau qui ne mettent pas en œuvre les services de contrôle de la QS le long du chemin des données.

La valeur locale du paramètre est 1 si l'élément de réseau ne met pas en œuvre le service de contrôle de la QS pertinent, ou sait qu'il y a une coupure dans la chaîne des éléments qui mettent en œuvre le service. Autrement, le paramètre local est 0. Le numéro_de_paramètre 1 est alloué au paramètre local.

La règle de composition pour ce paramètre est la fonction OU. Une valeur de paramètre composé de 1 arrivant au point d'extrémité d'un chemin indique qu'au moins un point le long du chemin n'offre pas le service de contrôle de la QS indiqué. Le numéro_de_paramètre pour la quantité composée est 2.

Le paramètre global de fanion NON_IS_HOP a donc l'identifiant ID<1,2>. Si ce fanion est mis, il indique qu'un ou plusieurs éléments de réseau le long du chemin des données de l'application ne prennent pas du tout en charge le cadre des services intégrés. Un exemple d'un tel élément serait un routeur IP offrant seulement une livraison de paquets au mieux et ne prenant en charge aucune demande de réservation de ressource.

Évidemment, un élément de réseau qui ne prend pas en charge la présente spécification ne saura pas établir ce fanion. La responsabilité réelle de la détermination qu'un nœud de réseau ne prend pas en charge les services intégrés peut incomber à l'élément de réseau, au protocole d'établissement, ou à une opération de configuration manuelle et dépend de la mise en œuvre et de l'usage. Ce calcul doit être prudent. Par exemple, un routeur qui envoie des paquets dans un tunnel IP doit supposer que les paquets tunnelés ne vont pas recevoir les services de contrôle de la QS sauf si lui ou le protocole d'établissement peut prouver le contraire.

Les versions spécifiques du service du fanion NON_IS_HOP indiquent que un ou plusieurs éléments de réseau le long d'un chemin ne prennent pas en charge le service particulier. Par exemple, le paramètre de fanion identifié par l'ID <2,2> établi (à 1) indique que certains éléments de réseau le long du chemin ne prennent pas en charge le service garanti, bien qu'ils puissent prendre en charge un autre service tel que la charge contrôlée.

Si le fanion global NON_IS_HOP <1,2> est mis pour un chemin, le receveur (élément de réseau ou application) devrait considérer les valeurs de tous les autres paramètres définis dans la présente spécification, y compris les fanions NON_IS_HOP spécifiques du service, comme éventuellement inappropriés. Si un fanion NON_IS_HOP spécifique de service est établi pour un chemin, le receveur devrait considérer les valeurs de tous les autres paramètres associés à ce service comme pouvant être inappropriés.

Le paramètre NON_IS_HOP peut être représenté sous toute forme qui peut exprimer le vrai et faux booléen. Cependant, noter qu'un élément de réseau doit régler ce fanion avec précision lorsque il ne comprend pas pleinement le format ou la représentation des données d'un message de protocole arrivant (parce qu'il ne prend pas en charge le service spécifié). Donc, la représentation des données utilisée pour ce paramètre par les protocoles d'établissement et de gestion doit permettre que la valeur du paramètre soit lue et établie même si l'élément de réseau ne peut pas par ailleurs analyser le message de protocole.

Une description XDR appropriée de ce paramètre est : bool NON_IS_HOP;

Cependant, le codage XDR standard des données pour cette description ne va pas satisfaire aux exigences décrites ci-dessus sauf si d'autres restrictions sont apportées aux formats de message. Une autre représentation de données peut être plus appropriée.

NOTE : Le format de message décrit pour RSVP dans la [RFC2210] porte ce paramètre comme un fanion d'un seul bit, désigné comme "bit de coupure".

3.2   Paramètre NUMBER_OF_IS_HOPS

IS signifie "à capacité de services intégrés". Un élément de réseau à capacité de services intégrés est celui qui se conforme aux diverses exigences décrites dans le présent document et ceux qui sont référencés. L'élément de réseau n'a pas besoin d'offrir un service spécifique, mais si il le fait, il doit prendre en charge et caractériser le service en conformité avec la spécification pertinente, et si il ne le fait pas, il doit régler correctement le paramètre fanion NON_IS_HOP pour le service. Pour être complet, le paramètre local a le numéro_de_paramètre 3.

La règle de composition pour ce paramètre est d'incrémenter le compteur de un à chaque bond à capacité IS. Cette quantité, lorsque elle est composée de bout en bout, informe le point d'extrémité du nombre d'éléments de réseau à capacité de services intégrés traversés le long du chemin. Le numéro_de_paramètre pour ce paramètre composé est 4.

Les valeurs du paramètre composé vont de 1 à 255, limitées par les limites du compte de bonds IP.

La représentation XDR de ce paramètre est : entier non signé NUMBER_OF_IS_HOPS;

3.3   Paramètre AVAILABLE_PATH_BANDWIDTH

Ce paramètre fournit des informations sur la bande passante disponible le long du chemin suivi par un flux de données. Le paramètre local est une estimation de la bande passante que l'élément de réseau a disponible pour les paquets qui suivent le chemin. Le calcul de la valeur de ce paramètre devrait tenir compte de toutes les informations disponibles à l'élément de réseau sur le chemin, en prenant en considération les contrôles administratifs et politiques sur la bande passante, ainsi que les ressources physiques.

NOTE : Ce paramètre devrait refléter, d'aussi près que possible, la bande passante disponible réelle pour les paquets qui suivent un chemin. Cependant, la bande passante disponible peut dépendre d'un certain nombre de facteurs inconnus de l'élément de réseau jusqu'à ce qu'une demande de QS spécifique soit en place, telles que la ou les destinations du flux de paquets, le service à demander pour le flux, ou des informations de politique externes associées à une demande de réservation. Comme le paramètre doit en fait être fourni avant que toute demande spécifique de QS ne soit faite, il est souvent difficile de fournir précisément le paramètre. Dans les circonstances où le paramètre ne peut pas être fourni avec précision, l'élément de réseau devrait essayer au mieux, mais il est acceptable de surestimer la bande passante disponible d'une façon significative.

Le numéro_de_paramètre pour AVAILABLE_PATH_BANDWIDTH est 5. Le paramètre global <1, 5> est une estimation de la bande passante disponible pour tout paquet qui suit le chemin, sans considération du service de contrôle de la QS (s'il en est) auquel les paquets peuvent être soumis.

Dans les cas où un service particulier est restreint administrativement ou techniquement à une portion limitée de la bande passante disponible globale, le module de service peut souhaiter exporter un paramètre d'outrepassement qui spécifie cette plus petite valeur de bande passante.

La règle de composition pour ce paramètre est la fonction MIN. La valeur composée est le minimum de la valeur de l'élément de réseau et de la valeur précédemment composée. Cette quantité, lorsque elle est composée de bout en bout, informe le point d'extrémité de la bande passante minimale de liaison le long du chemin de l'envoyeur au receveur. Le numéro_de_paramètre pour la bande passante composée minimale le long du chemin est 6.

Les valeurs de ce paramètre sont mesurées en octets par seconde. La représentation doit être capable d'exprimer des valeurs allant de 1 octet par seconde à 40 téraoctets par seconde, ce qui est estimé être environ la bande passante maximum théorique d'un simple brin de fibre.

Particulièrement pour les grandes bandes passantes, seuls les quelques premiers chiffres sont significatifs, de sorte que l'utilisation d'une représentation en virgule flottante, précise au moins à 99,9 %, est conseillée.

La représentation XDR de ce paramètre est : flottante AVAILABLE_PATH_BANDWIDTH;

Pour les valeurs de ce paramètre, seuls des nombres non négatifs valides en virgule flottante sont admis. Les nombres négatifs (y compris le "zéro négatif"), les infinis, et les NAN (pas un nombre) ne sont pas admis.

NOTE : Une mise en œuvre qui utilise un matériel ou logiciel d'usage général qui prend en charge la virgule flottante définie par l'IEEE peuvent souhaiter vérifier que les valeurs arrivantes de paramètre satisfont à ces exigences avant d'utiliser les valeurs dans des calculs en virgule flottante, afin d'éviter des exceptions ou pièges inattendus.

Si l'élément de réseau ne peut pas fournir ou choisit de ne pas fournir une estimation de la bande passante du chemin, il peut exporter une valeur locale de zéro pour ce paramètre. Un élément de réseau ou application qui reçoit une valeur composée de zéro pour ce paramètre doit supposer que la bande passante disponible réelle est inconnue.

3.4   Paramètre MINIMUM_PATH_LATENCY

Le paramètre local est la latence du processus de transmission de paquet associée à l'élément de réseau, où la latence est définie comme étant *le plus petit* délai de paquet possible ajouté par l'élément de réseau. Ce délai résulte du délai de propagation à la vitesse de la lumière, des limitations du traitement du paquet, ou des deux. Il n'inclut aucun délai variable de mise en file d'attente qui pourrait être présent.

L'objet de ce paramètre est de fournir une latence de chemin minimum de base à utiliser avec les services qui fournissent des estimations ou des limites au délai supplémentaire de chemin, tels que le service garanti [RFC2212]. Avec la limite de délai de mise en file d'attente offerte par le service garanti et les services similaires, ce paramètre donne à l'application la connaissance des deux délais minimum et maximum de livraison de paquet. Connaître à la fois la latence minimum et maximum subie par les paquets de données permet à l'application receveuse de calculer précisément ses exigences de mémoire tampon de "dégiguage".

Noter que la quantité caractérisée par ce paramètre est la valeur absolue la plus petite possible pour la latence de traitement et transmission du paquet de l'élément de réseau. Cette valeur est la quantité requise pour fournir aux hôtes d'extrémité les limites de gigue. Le paramètre ne fournit pas une estimation de la limite supérieure de la latence minimum, qui peut intéresser le trafic au mieux et les services de contrôle de la QS qui n'offrent pas explicitement de limites de délai. En d'autre termes, le paramètre va toujours sous-estimer, plutôt que surestimer, la latence, en particulier dans les situations de diffusion groupée et les grands nuages.

Lorsque des paquets qui traversent un élément de réseau subissent des latences minimales différentes sur des chemins différents, ce paramètre devrait, si possible, rapporter une valeur de latence précise pour chaque chemin. Par exemple, lorsque un circuit virtuel ATM en point-multipoint est utilisé pour mettre en œuvre la diffusion groupée IP, le mécanisme qui met en œuvre ce paramètre pour le nuage ATM devrait idéalement calculer une valeur distincte pour chaque destination. Faire cela peut exiger une coopération entre les éléments d'entrée et de sortie bordant le nuage de communication multi accès. La méthode par laquelle cette coopération est réalisée, et le choix de l'élément de réseau de niveau IP qui fournit réellement et compose la valeur dépend de la technologie.

Un autre choix est de fournir la même valeur de ce paramètre pour tous les chemins à travers le nuage. La valeur rapportée doit être la plus petite latence pour tout chemin possible. Noter que dans cette situation, les services de contrôle de la QS (par exemple, le service garanti) qui fournissent une limite supérieure de la latence ne peuvent pas simplement ajouter le délai de mise en file d'attente à la valeur calculée par ce paramètre ; ils doivent aussi compenser les délais de chemin au dessus du minimum. Dans ce cas, la plage entre le délai de paquet minimum et maximum rapportée à l'application peut être supérieure à celle qui se produit réellement parce que l'application sera informée du délai minimum le long du plus court chemin et du délai maximum le long du chemin réel. Cela est acceptable dans la plupart des situations.

Une troisième solution est de rapporter la valeur "indéterminée", comme spécifié ci-dessous. Dans cette circonstance, l'application cliente peut déduire une latence minimum de chemin par des mesures, ou supposer une valeur de zéro.

La règle de composition pour ce paramètre est une somme avec un maximum de (2**32 - 1). Cette quantité, lorsque elle est composée de bout en bout, informe le point d'extrémité du délai minimal de paquet le long du chemin de l'envoyeur au receveur. Le numéro_de_paramètre pour la latence de la liaison de l'élément de réseau est 7. Le numéro_de_paramètre pour la latence cumulative le long du chemin est 8.

Les latences sont rapportées en unités de une microseconde. Un élément individuel peut annoncer une valeur de latence entre 1 et 2**28 (de l'ordre de deux minutes) et la latence totale ajoutée sur tous les éléments peut aller jusqu'à (2**32)-2. Si la somme des délais des différents éléments excède (2**32)-2, le délai annoncé de bout en bout devrait être rapporté comme indéterminé. Ceci est décrit ci-dessous.

Noter qu'alors que la granularité des mesures est en microsecondes, un élément conforme (à la présente spécification) est libre de mesurer en fait les délais de façon plus lâche. L'exigence minimum est que l'élément estime son délai avec précision à une granularité de 100 microsecondes. Les éléments qui peuvent mesurer plus précisément sont, bien sûr, encouragés à le faire.

NOTE : Mesurer en millisecondes n'est pas acceptable, parce que si la valeur minimum de délai est une milliseconde, un chemin avec plusieurs bonds va conduire à un délai composé d'au moins plusieurs millisecondes, ce qui a des chances d'être trompeur.

La description XDR de ce paramètre est : entier non signé MINIMUM_PATH_LATENCY;

La valeur distinctive (2**32)-1 est destinée à signifier "latence indéterminée". Un élément de réseau qui ne peut pas prédire avec précision la latence des paquets qu'il traite devrait régler son paramètre local à cette valeur. Comme la fonction de composition limite la somme composée à cette valeur, la réception de cette valeur à un élément de réseau ou application indique que la vraie latence du chemin est inconnue. Cela peut arriver parce que un ou plusieurs éléments de réseau n'ont pas pu fournir une valeur, ou parce que la gamme de calcul de la composition a été dépassée.

3.5   Paramètre PATH_MTU

Ce paramètre calcule l'unité de transmission maximum (MTU) pour les paquets qui suivent un chemin de données. Cette valeur est nécessaire pour invoquer les services de contrôle de la QS qui exigent que la taille du paquet IP soit strictement limitée à une MTU spécifique. Les mécanismes existants de découverte de la MTU ne peuvent pas être utilisés parce qu'ils ne fournissent d'informations qu'à l'envoyeur et qu'il ne permettent pas directement aux services de contrôle de la QS de spécifier des MTU plus petites que la MTU physique.

Le paramètre local de caractérisation est la MTU IP, où la MTU d'un élément de réseau est définie comme étant l'unité de transmission maximum dont l'élément de réseau peut s'accommoder sans fragmentation, y compris les en –tête de protocole IP et de couche supérieure mais non inclus les en-têtes de niveau liaison. La règle de composition est de prendre le minimum de la MTU de l'élément de réseau et de la valeur composée précédente. Cette quantité, lorsque composée de bout en bout, informe le point d'extrémité de l'unité de transmission maximum qui peut traverser le chemin de l'envoyeur au receveur sans fragmentation. Le numéro_de_paramètre pour la MTU de la liaison de l'élément de réseau est 9. Le numéro_de_paramètre pour la MTU composée le long du chemin est 10.

Une valeur correcte et valide de ce paramètre doit être fournie par tous les éléments de réseau à capacité IS.

Un module de service spécifique peut spécifier une MTU plus petite que celle globale de l'élément de réseau en outrepassant ce paramètre avec la valeur de la MTU du service. Un module de service peut ne pas spécifier de valeur de MTU plus grande que celle donnée par le paramètre global.

Les valeurs de ce paramètre sont mesurées en octets. La représentation doit être capable d'exprimer des valeurs allant de 1 octet à 2**32-1 octets.

La description XDR de ce paramètre est : entier non signé PATH_MTU;

3.6   Paramètre TOKEN_BUCKET_TSPEC

Ce paramètre est utilisé pour décrire les paramètres de trafic de données en utilisant un simple filtre de baquet de jetons. Ce paramètre est utilisé par les envoyeurs de données pour décrire les paramètres de trafic du trafic qu'il s'attend à générer, et par les services de contrôle de la QS pour décrire les paramètres du trafic auquel la réservation devrait s'appliquer. Il est défini comme général plutôt que comme spécifique du service parce que la même description de trafic peut être utilisée par plusieurs services de contrôle de la QS dans certaines situations.

NOTE : Toutes les définitions précédentes dans cette note ont décrit des "paramètres de caractérisation", avec des valeurs locales réglées par les éléments de réseau pour caractériser leur comportement et règles de composition pour donner le comportement résultant de bout en bout. Le paramètre TOKEN_BUCKET_TSPEC n'est pas un paramètre de caractérisation, parce que les nœuds intermédiaires au sein du réseau n'exportent pas les valeurs locales pour les TOKEN_BUCKET_TSPEC. Le paramètre TOKEN_BUCKET_TSPEC est simplement une définition de structure de données présentée ici parce qu'elle est commune à plus d'un service de contrôle de la QS.

Le numéro_de_paramètre 127 est alloué au paramètre TOKEN_BUCKET_TSPEC.

TOKEN_BUCKET_TSPEC prend la forme d'une spécification de baquet de jetons plus un débit de crête [p], une unité régulée minimum [m], et une taille maximum de paquet [M].

La spécification du baquet de jetons comporte une moyenne ou débit de jetons [r] et une profondeur de baquet [b]. [r] et [b] doivent toutes deux être positives.

Le débit de jetons [r] est mesuré en octets de datagrammes IP par seconde. Les valeurs de ce paramètre peuvent aller de 1 octet par seconde à 40 téraoctets par seconde. En pratique, seuls les quelques premiers chiffres des paramètres [r] et [p] sont significatifs, de sorte que l'utilisation de représentations en virgule flottante, précises 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 un octet à 250 gigaoctets. En pratique, seuls les 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.

Le taux de trafic de crête [p] est mesuré en octets de datagrammes IP par seconde. Les valeurs de ce paramètre peuvent aller de 1 octet par seconde à 40 téraoctets par seconde. En pratique, seuls les quelques premiers chiffres des paramètres [r] et [p] sont significatifs, de sorte que l'utilisation de représentations en virgule flottante, précises à au moins 99,9 % est conseillée. La valeur de taux de crête peut être réglée à l'infini positif, indiquant qu'elle est inconnue ou non spécifiée.

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

L'unité régulée minimum [m], est un entier mesuré en octets. La taille inclut les données d'application et tous les en-têtes de protocole au niveau IP et au-dessus (IP, TCP, UDP, RTP, etc.). Elle n'inclut pas la taille de l'en-tête de niveau liaison, parce que ces en-têtes vont changer de taille lorsque le paquet traverse les différentes portions de l'Internet.

Tous les datagrammes IP de taille inférieure à [m] sont traités comme étant de taille m pour les besoins de l'allocation et la régulation des ressource. L'objet de ce paramètre est de permettre une estimation raisonnable des ressources par paquet nécessaires pour traiter les paquets d'un flux (le débit maximum de paquet peut être calculé à partir des termes [b] et [m]) et de border raisonnablement la redondance de bande passante consommée par les en-têtes de paquet de niveau liaison du flux. La redondance maximum de bande passante consommée par les en-têtes de niveau liaison lors du transport des paquets d'un flux est bordée par le ratio de la taille d'en-tête de niveau liaison à [m]. Sans le terme [m], il serait nécessaire de calculer cette redondance de bande passante en supposant que chaque flux a toujours envoyé des paquets de la taille minimum, ce qui n'est pas acceptable.

La taille maximum du paquet, [M], est le plus gros paquet qui va se conformer à la spécification de trafic ; elle est aussi mesurée en octets. Tout paquets de taille supérieure envoyé dans le réseau ne peut pas recevoir le service de contrôle de la qualité de service car il sont considérés ne pas satisfaire à la spécification du trafic.

[m] et [M] doivent tous deux être positifs, et [m] doit être inférieur ou égal à [M].

La description XDR de ce paramètre est :

struct { flottant r; flottant b; flottant p; non signé m; non signé M; } TOKEN_BUCKET_TSPEC;

Pour les champs [r] et [b], seuls des nombres valides non négatifs à virgule flottante sont admis. Les nombres négatifs (y compris le "zéro négatif), les infinis, et les NAN ne sont pas admis.

Pour le champ [p], seuls des nombres valides non négatifs à virgule flottante ou l'infini positif sont admis. Les nombres négatifs (y compris le "zéro négatif), les infinis négatifs, et les NAN ne sont pas admis.

NOTE : Une mise en œuvre qui utilise un matériel ou logiciel d'usage général qui prend en charge la virgule flottante définie par l'IEEE peut souhaiter vérifier que les valeurs arrivantes de paramètre satisfont à ces exigences avant d'utiliser les valeurs dans des calculs en virgule flottante, afin d'éviter des exceptions ou pièges inattendus.

4.   Considérations pour la sécurité

La mise en œuvre des paramètres de caractérisation décrits dans le présent mémoire ne crée aucune possibilité nouvelle pour des attaques malveillantes contre les infrastructures de réseau. La mise en œuvre de ces paramètres de caractérisation révèle, par nécessité, des informations supplémentaires sur les performance d'un réseau, qui dans des circonstances extrêmement rares pourraient être vues comme une question de sécurité par un fournisseur de réseau.

5.   Références

(Les liens sur les numéros pointent sur la version originale, ceux dans les titres sur la traduction française.)

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

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

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

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

[RFC1832]   R. Srinivasan, "XDR : norme de représentation des données externes", août 1995. (Obsolète, voirRFC4506) (D.S.)

Adresse des auteurs