Modèle de spécification des services d'élément de réseau

Statut du présent mémoire

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

Résumé

Le présent document définit un cadre pour la spécification des services fournis par les éléments de réseau, disponibles pour les applications, dans un internet qui offre plusieurs qualités de service. Le document donne d'abord quelques indications nécessaires sur le contexte – y compris les définitions pertinentes et les formats de données suggérés – puis spécifie un "modèle" que devraient suivre les documents de spécification de service. Le modèle de spécification comporte des exigences par élément telles que le comportement de traitement de paquet du service, les paramètres requis et rendus disponibles par le service, les exigences de spécification et de régulation du trafic, et les relations d'ordre du trafic. Il comporte aussi des critères d'évaluation pour les éléments qui fournissent le service, et des exemples de la façon dont le service pourrait être mis en œuvre (par les éléments de réseau) et utilisé (par les applications).

1.   Introduction

Le présent document définit le cadre utilisé pour spécifier la fonctionnalité des composants du système inter réseau qui prennent en charge la capacité de fournir plusieurs qualités de service, à choix dynamique, aux applications qui utilisent un inter réseau. Le comportement des routeurs et sous-réseaux individuels est saisi comme un ensemble de "services", dont certains ou tous peuvent être offerts par chaque élément. L'enchaînement de ces services le long des chemins de données de bout en bout utilisés par une application donne le contrôle de la qualité de service globale.

La définition d'un service déclare ce qui est exigé de la part d'un routeur (ou, plus généralement, de tout élément de réseau ; un routeur, un commutateur, un sous réseau, etc.) qui fournit un service particulier. La définition de service spécifie aussi les paramètres utilisés pour invoquer le service, les relations entre ces paramètres et le service fourni, et le comportement de bout en bout obtenu par l'enchaînement de plusieurs instances du service.

Chaque définition de service spécifie aussi l'interface entre ce service et l'environnement. Cela inclut les paramètres nécessaires pour invoquer le service, les paramètres d'information que le service doit rendre disponibles par les mécanismes d'établissement, d'acheminement et de gestion, et les informations qui devraient être transportées entre les nœuds d'extrémité et les éléments de réseau par ces mécanismes afin de réaliser le comportement désiré de bout en bout. Cependant, une définition de service ne décrit pas les protocoles ou mécanismes spécifiques utilisés pour établir l'état dans les éléments de réseau pour les flux qui utilisent le service décrit.

Les services définis suivant les lignes directrices du présent document sont destinés à l'utilisation aussi bien dans l'Internet global que dans les réseaux IP privés. Dans certains cas, un enchaînement de services d'élément de réseau peut être utilisé pour fournir une gamme de comportements de bout en bout, certains convenant mieux à un internet décentralisé et certains autres plus appropriés à un réseau privé à gestion stricte. Le présent document indique les endroits où une telle distinction peut être appropriée.

Le présent document comporte trois parties. La première définit quelques termes utilisés à la fois dans le présent document et dans les divers documents de spécification de service. La seconde discute des formats et représentations de données. La troisième portion du document décrit les divers composants du modèle de spécification de service.

2.   Définitions

Les termes suivants sont utilisés tout au long du présent document. Les documents de spécification de service devraient employer les mêmes termes pour exprimer ces concepts.

o   Qualité de service (QS)

Dans le contexte du présent document, qualité de service se réfère à la nature du service de livraison de paquet fourni, comme décrit par des paramètres tels que la bande passant réalisée, le délai du paquet, et les taux de perte de paquet. Traditionnellement, l'Internet offrait une seule qualité de service, la livraison au mieux (best-effort delivery), avec des caractéristiques de bande passante disponible et de délai dépendantes de la charge instantanée. Le contrôle sur la qualité de service vue par les applications est exercé par le provisionnement adéquat des infrastructures du réseau. À l'opposé, un réseau avec une qualité de service contrôlable de façon dynamique permet aux sessions d'application individuelles de demander au réseau des caractéristiques de livraison de paquet conformes à leurs besoins tels qu'elles les perçoivent, et peut fournir différentes qualités de service aux différentes applications. On devrait comprendre qu'il y a une gamme de possibilités utiles entre les deux extrêmes qui sont de ne pas fournir du tout de QS dynamique et de fournir des paramètres extrêmement précis et justes de contrôle de la QS.

o   Élément de réseau

Un "élément de réseau" (ou la forme équivalente abrégée de "élément") est tout composant d'un inter réseau qui traite directement les paquets de données et est donc potentiellement capable d'exercer le contrôle de la QS sur les données qui s'écoulent à travers lui. Les éléments de réseau incluent les routeurs, les sous-réseaux, et les systèmes d'exploitation de nœud d'extrémité. Un élément de réseau capable de QS est celui qui offre un ou plusieurs des services définis conformément aux règles données dans le présent document. Noter que cette définition, par elle-même, exclut les éléments de réseau capables de QS qui satisfont les objectifs de performances seulement à travers un approvisionnement adéquat plutôt que par des mécanismes actifs de contrôle d'admission et de trafic. Un élément de réseau "à capacité de QS" est celui qui prend en charge les interfaces (décrites ci-dessous) exigées par les définitions de service. Et donc, un élément de réseau à capacité de QS n'a en fait pas besoin d'offrir un des services définis conformément au format du présent document ; il a simplement besoin de savoir comment refuser les demandes de service.

o   Flux

Pour les besoins du présent document, un flux est un ensemble de paquets traversant un élément de réseau dont tous sont couverts par la même demande de contrôle de la qualité de service. À un élément de réseau donné, un flux peut consister en paquets provenant d'une seule session d'application, ou il peut être un agrégat comprenant le trafic de données combinées provenant d'un certain nombre de sessions d'application.

NOTE : cette définition d'un flux est différente de celle utilisée dans IPv6, où un flux est défini comme les paquets qui ont la même adresse de source et le même identifiant de flux. Les mécanismes utilisés pour associer une demande de contrôle de qualité de service aux paquets couverts par cette demande sortent du domaine d'application du présent document.

o   Service

Les termes "service" ou "Service de contrôle de la QS" décrivent un ensemble désigné et coordonné de capacités de contrôle de la QS fournies par un seul élément de réseau. La définition d'un service inclut une spécification des fonctions à effectuer par l'élément de réseau, les informations requises par l'élément pour effectuer ces fonctions, et les informations rendues disponibles par l'élément aux autres éléments du système. Un service est mis en œuvre conceptuellement au sein du "module de service" contenu dans l'élément de réseau.

NOTE : Le texte ci-dessus définit une signification précise du mot "service". Service est un mot qui a des significations diverses dans la communauté de l'inter réseau ; la définition de "service" donnée ici se réfère précisément aux actions et réponses d'un seul élément de réseau tel qu'un routeur ou sous-réseau. Cela contraste avec la définition plus orientée bout en bout du même mot vu dans d'autres contextes de l'inter réseautage.

o   Comportement

Un "comportement" est la performance de bout en bout en rapport avec la QS vue par une session d'application. Ce comportement est le résultat final de la composition des services offerts par chaque élément de réseau le long du chemin du flux de données de l'application.

Lorsque chaque élément de réseau le long d'un chemin de flux de données offre le même service, il est fréquemment possible d'expliquer le comportement résultant de bout en bout de façon directe. Le comportement d'un chemin de flux de données comprenant des éléments qui utilisent des services différents est plus compliqué, et peut en fait être indéfini. Une future version du présent document pourrait imposer des exigences additionnelles à la spécification de service se rapportant à des enchaînements multiservices.

o   Caractérisation

Une caractérisation est une approximation calculée du comportement réel de bout en bout qui serait vu par un flux demandant des services spécifiques de QS au réseau. En fournissant des informations supplémentaires aux nœuds d'extrémité avant l'établissement d'un flux, les caractérisations assistent le choix par les nœuds d'extrémité des services à demander au réseau.

o   Paramètres de caractérisation

Les caractérisations sont calculées à partir d'un ensemble de paramètres de caractérisation fournis par chaque élément de réseau sur le chemin du flux, et d'une fonction de composition qui calcule la caractérisation de bout en bout à partir de ces paramètres. La fonction de composition peut en pratique être exécutée de façon répartie par le protocole d'établissement ou d'acheminement, ou les paramètres de caractérisation peuvent être rassemblés en un seul point et la caractérisation calculée en ce point.

Plusieurs caractérisations peuvent être calculées pour un seul flux de données candidat. À l'inverse, un service peut ne fournir aucune caractérisation, et sous certaines conditions aucune caractérisation n'être disponible pour les nœuds d'extrémité qui demandent des services de QS.

o   Fonction de composition

Une fonction de composition accepte des paramètres de caractérisation en entrée et calcule une caractérisation, comme décrit ci-dessus.

o   Spécification de trafic (TSpec)

Une spécification de trafic, ou TSpec, est une description du schéma du trafic pour lequel le service est demandé. En général, la TSpec forme un côté d'un "contrat" entre le flux de données et le service. Une fois qu'une demande de service est acceptée, le module de service a donné son accord pour fournir une QS spécifiée tant que continue le trafic de données du flux qui est précisément décrit par la TSpec.

Par exemple, cette spécification pourrait prendre la forme d'un filtre de baquet de jetons (défini ci-après) ou une limite supérieure d'un débit de crête. Noter que la spécification de trafic spécifie le schéma *admis* du trafic du flux, et non le schéma *réel* du trafic du flux. Le comportement d'un service lorsque le trafic réel d'un flux ne se conforme pas à la spécification de trafic doit être définie par le service (voir "Régulation" ci-dessous).

o   Spécification de demande de service (RSpec)

Une spécification de demande de service, ou RSpec, est une spécification de la qualité de service qu'un flux souhaite demander de la part d'un élément de réseau. Le contenu d'une spécification de demande de service est très spécifique d'un service particulier. Par exemple, ces spécifications pourraient contenir des informations sur la bande passante allouée au flux, au délai maximum, ou au taux de perte de paquet.

o   Protocole d'établissement

Un protocole d'établissement est utilisé pour porter les informations en rapport avec la QS depuis les nœuds d'extrémité qui demandent le contrôle de QS aux éléments de réseau qui doivent exercer ce contrôle, et pour installer et entretenir l'état de contrôle de la QS requis dans ces éléments de réseau. Un protocole d'établissement peut aussi être utilisé pour collecter des informations en rapport avec la QS auprès des éléments de réseau intérieurs le long du chemin du flux de données d'une application pour la livraison ultime aux nœuds d'extrémité. Des exemples de protocoles qui effectuent des fonctions d'établissement sont RSVP [RFC2205], ST-II [RFC1819], et la Recommandation UIT-T Q.2931.

Noter que d'autres mécanismes, tels que les protocoles de gestion de réseau, peuvent aussi effectuer cette fonction. L'expression "protocole d'établissement" se réfère par convention à un protocole dont cette fonction est le principal objet.

o   Baquet de jetons

Un baquet de jetons (token bucket) est une forme particulière de spécification de trafic consistant en un "débit de jeton" r et une "taille de baquet" b. Essentiellement, le paramètre r spécifie le débit de données soutenu en continu, alors que le paramètre b spécifie la mesure dans laquelle le débit de données peut dépasser le niveau soutenu pour de brèves périodes. Plus précisément, le trafic doit respecter la règle sur l'ensemble de toutes les périodes de temps, la quantité de données envoyées ne peut pas dépasser rT+b, où T est le temps.

Les baquets de jetons sont exposés plus en détails dans [PARTRIDGE].

o   Filtre de baquet de jetons

Un filtre de baquet de jetons est une fonction de filtrage ou régulation qui différencie ces paquets dans un flux de trafic qui se conforme à une spécification de baquet de jetons particulière des paquets qui ne le font pas. Le traitement spécifique accordé aux paquets non conformes n'est pas spécifié dans cette définition ; les actions courantes relèguent le paquet au service au mieux, éliminent le paquet, ou marquent le paquet d'une façon ou d'une autre.

o   Contrôle d'admission

Le contrôle d'admission est le processus qui décide si une nouvelle demande de service arrivant d'un élément de réseau peut être accordée. Cette action doit être effectuée par tout service qui souhaite offrir des limites quantitatives absolues aux performances globales. Il n'est pas nécessaire pour les services qui fournissent seulement des déclarations relatives sur les performances, tels que le service au mieux de l'Internet actuel. Les critères précis pour la prise de décision du contrôle d'admission sont spécifiques de chaque service particulier.

o   Régulation,

La régulation est l'ensemble des actions déclenchées lorsque les caractéristiques réelles du trafic de données d'un flux dépassent les valeurs attendues données dans la spécification de trafic du flux. Les services qui requièrent des fonctions de régulation pour fonctionner correctement doivent spécifier à le fois l'action à entreprendre lorsque survient une telle discordance et les localisations du réseau où ces discordances sont à détecter. Parmi les exemples de telles actions on citera la relégation du paquet au service au mieux, l'élimination des paquets, le reformatage du trafic, ou le marquage du trafic non conforme d'une façon ou d'une autre.

o   Interfaces

Le module de service interagit conceptuellement avec les autres portions de l'élément de réseau à travers un certain nombre d'interfaces. Le document de spécification de service devrait clairement définir les données spécifiques, y compris de formats, qui se déplacent à travers chaque interface conceptuelle, et s'assurer que la transposition entre interfaces conceptuelles et mécanismes spécifiques du service défini est claire.

3.   Format et représentation des données

Un module de service va importer et exporter diverses données selon les exigences spécifiques des services que prend en charge l'élément de réseau. Chaque définition de service DOIT spécifier le format de chacun de ces éléments de données d'une manière abstraite. Les informations spécifiées doivent être suffisantes pour que le concepteur d'un protocole d'établissement choisisse correctement un format approprié concret (un paquet) pour les variables qui contiennent ces données. Au minimum, les informations suivantes doivent être données:

-   Type : si la quantité est une énumération, une valeur numérique, etc.

-   Gamme : pour les quantités numériques, les valeurs minimum et maximum que la quantité doit être capable de représenter. Pour les quantités énumérées, une estimation du nombre maximum d'éléments qu'il peut être nécessaire d'énumérer à l'avenir, même si beaucoup des valeurs sont actuellement inutilisées.

-   Précision : la précision avec laquelle un quantité numérique doit être représentée, et si cette précision est absolue (demandant une quantité entière) ou un pourcentage de la valeur (permettant une quantité en virgule flottante).

La définition de service DEVRAIT de plus spécifier un format concret préféré pour chaque champ de données, dans le format usuel de représentation de paquet utilisé dans les documents actuels des normes de l'Internet ou dans un autre format accepté de spécification. Si la définition de service contient ces définitions concrètes, elles devraient être suffisamment complètes et détaillées pour permettre que la définition de service soit incorporée par référence dans les spécifications des protocoles d'acheminement et autres utilisateurs des données spécifiées.

NOTE : La formulation ci-dessus est destinée à encourager l'utilisation de formats de données communs par tous les protocoles qui portent des données se rapportant à un service spécifique, tout en ne rendant pas obligatoire ce format commun ou en n'entravant pas la liberté des créateurs de spécifications de protocoles de définir des représentations de données utilisant d'autres mécanismes tels que l'ASN.1 ou XDR.

4.   Désignation des services et éléments de données

Les nœuds d'extrémité, les éléments de réseau, les protocoles d'établissement, et les entités de gestion au sein d'un inter réseau à intégration de services ont besoin d'échanger des informations sur les services, les paramètres d'invocation des services, les paramètres de caractérisation, les variables intermédiaires et les résultats finaux des fonctions de composition. Pour répondre à cette exigence est établi un seul espace de noms uniforme pour les services et leurs paramètres.

L'espace de noms est une hiérarchie à deux niveaux : <nom_de_service>.<nom_de_paramètre>.

Chacun de ces éléments est une quantité numérique entière.

<nom_de_service> est un entier dans la gamme 1 à 254. L'espace numérique est divisé en trois régions.

Le service numéro 1 est utilisé pour indiquer que le paramètre associé est "générique", et n'est pas associé à un service spécifique. Cette utilisation de paramètres génériques est décrite plus complètement dans la [RFC2215].

La gamme de 2 à 127 est utilisée pour désigner les services définis par l'IETF. Les procédures d'allocation des numéros de service dans cette région seront établies par le groupe de travail INT-SERV de l'IETF et l'IANA. Les services désignés pour l'utilisation publique devraient obtenir un numéro de cet espace. L'exigence minimale pour ce faire est la publication d'une RFC conforme au format décrit dans la présente note.

Les numéros de service dans la région au dessus de 127 sont réservés pour des services expérimentaux ou privés. Les concepteurs de services peuvent allouer les numéros de cet espace à volonté pour des expériences locales. Une politique d'allocation globale mais temporaire de ces numéros pourra être établie à l'avenir si nécessaire.

La valeur 0 restera inutilisé pour permettre la transposition directe des noms de paramètres en noms d'objets de MIB, comme décrit ci-dessous.

La valeur 255 est réservée pour faciliter l'expansion future de l'espace des numéros de service, si nécessaire.

<nom_de_paramètre> est un numéro dans la gamme de 1 à 254, alloué service par service. Dans cette gamme, les valeurs 1 à 127 sont réservées pour être allouées aux paramètres qui ont une signification commune, partagée entre tous les services. Ces paramètres sont définis dans la [RFC2215].

Les numéros pour les paramètres spécifiques d'un service sont alloués dans la gamme de 128 à 254 par l'auteur du document de spécification de service.

La valeur 0 est laissée inutilisée pour permettre la transposition directe des noms de paramètre en noms d'objets de MIB, comme décrit ci-dessous.

La valeur 255 est réservée pour faciliter l'expansion future de l'espace des numéros de paramètre, si nécessaire.

En plus de leurs utilisations au sein du cadre des services intégrés, ces paires de <numéro_de_service>.<numéro_de_paramètre> devraient être utilisées comme les deux derniers niveaux des noms de MIB lorsque les valeurs correspondantes seront disponibles pour les protocoles de gestion de réseau.

5.   Format de document de spécification

La présente section décrit la présentation et le contenu d'une spécification de service. Chaque document de spécification de service DOIT contenir les sections marquées [exigé] ci-dessous dans l'ordre indiqué. Chaque document DEVRAIT contenir chacune des sections de la liste ci-dessous, sauf si un argument irréfutable démontrait que la présence de la section est néfaste. Des éléments supplémentaires, y compris des références, devraient être inclus à la fin du document.

Certaines de ces sections sont normatives, en ce qu'elles décrivent des exigences spécifiques auxquelles les mises en œuvre conformes doivent adhérer. D'autres sections sont pour information par nature, en ce qu'elles décrivent le contexte nécessaire et des considérations techniques importantes pour la mise en œuvre d'un service. Les sections, et leur nature (exigé ou facultatif, et informative ou normative) sont énumérées ci-dessous.

Composants

Le corps d'un document de spécification de service incorpore les sections suivantes :

-   Comportement de bout en bout [exigé] [information]

-   Motivation [exigé] [information]

-   Exigences de traitement des données par l'élément de réseau [exigé] [normative]

-   Informations pour l'invocation [exigé] [normative]

-   Informations exportées [exigée] [normative]

-   Régulation [exigé] [normative]

-   Ordre et fusion [exigé] [normative]

-   Lignes directrices pour la mise en œuvre [facultatif] [information]

-   Critères d'évaluation [exigé] [information]

-   Exemples de mise en œuvre [facultatif] [information]

-   Exemples d'utilisation [facultatif] [information]

5.1   Comportement de bout en bout

C'est une description du comportement qui se produit si tous les éléments de réseau le long du chemin offrent le même service, invoqué avec un ensemble défini de paramètres.

Dans les réseaux privés, on aura en général que le comportement exigé de bout en bout est obtenu par l'enchaînement d'éléments de réseau utilisant le même service et faisant un usage significatif des caractérisations.

Dans l'Internet global, cela ne sera pas toujours vrai. Les comportements de bout en bout vont fréquemment être obtenus par un enchaînement d'éléments de réseau qui prennent en charge différents services, y compris dans certains cas des éléments qui n'exercent pas de contrôle de QS du tout . Les mécanismes pour caractériser le comportement de bout en bout dans ces circonstance ne sont pas pleinement établis pour l'instant. Des versions futures du présent document pourront imposer des exigences additionnelles aux spécifications de service pour faciliter la composition inter service.

Cette section est seulement pour information.

5.2   Motivation

Cette section expose pourquoi ce service est défini. Elle décrit les types d'applications qui pourraient faire usage de ce service, et pourquoi ce service pourrait être plus approprié pour ces applications que d'autres choix possibles. Cette section est seulement pour information.

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

Cette section contient une description des propriétés de QS vues par les paquets de données traités par un élément de réseau qui utilise ce service. La description doit clairement expliquer quelles variables sont contrôlées, le degré de contrôle exercé, et les aspects du modèle de traitement du service qui sont fixés ou supposés. Un exemples du degré d'informations de contrôle serait "cette propriété doit être vérifiée mathématiquement" ou "cette propriété devrait être satisfaite dans la plupart des conditions". Un exemple de déclaration d'hypothèse serait "ce service est supposé avoir un taux de perte de paquets extrêmement faible ; les objectifs de délai doivent être satisfaits en utilisant le contrôle d'admission plutôt que l'élimination des paquets en cas de surcharge".

Les exigences sur le traitement des paquets DEVRAIENT, chaque fois que possible, être exprimées comme des exigences de performances plutôt qu'en spécifiant un algorithme particulier de programmation de paquet. Les exigences de performances peuvent, par exemple, être une spécification des délais maximums des paquets ou la part minimale de bande passante donnée à un flux.

Cette section spécifie aussi les actions que le chemin de traitement des paquets est requis de prendre pour fournir un retour actif aux nœuds d'extrémité sur les conditions chez l'élément de réseau. De telles actions peuvent inclure des retours générés explicitement sur l'encombrement, indiqué soit comme des bits établis dans l'en-tête des paquets de données, soit comme l'envoi de messages de contrôle séparés.

Lors de la rédaction de cette section du document de spécification de service, le but des auteurs devrait être de spécifier le comportement demandé aussi précisément que nécessaire tout en laissant encore un espace suffisant pour les compromis appropriés de mise en œuvre et d'architecture pour les différentes circonstances et classes d'éléments de réseau. La réussite de cet équilibre peut demander une certaine attention.

5.4   Informations pour l'invocation

Cette section décrit l'ensemble des paramètres requis par un module de service pour invoquer le service, et une description de la façon dont les valeurs de paramètre sont utilisées par le module de service. Par exemple, un service hypothétique de "délai encadré" pourrait être décrit comme acceptant une demande qui indiquerait une cible de délai pour l'élément de réseau et l'ensemble des paquets soumis à ce délai cible, et le traitement des paquets dans l'ensemble donné avec le délai de la cible ou moins.

Les informations d'invocation nécessaires pour la plupart des services peuvent se répartir en deux classes, les spécifications de trafic (TSpec) et les spécifications de demande de service (RSpec). La TSpec donne les caractéristiques du trafic de données à traiter, alors que la Rspec spécifie les propriétés attendues du service. Par exemple, un service qui offre une limite mathématique sur le délai peut accepter une TSpec qui donne la bande passante du flux de trafic et la sporadicité spécifiée comme un baquet de jetons, et une RSpec donnant le délai maximum tolérable de mise en file d'attente.

Un service qui accepte une demande d'invocation peut être vu comme l'entrée dans un "contrat" de fourniture du service décrit par la RSpec pour autant que le trafic du flux continue d'être décrit par la TSpec. Si le schéma de trafic du flux tombe en dehors des limites de la TSpec, la QS fournie au flux peut changer. La nature précise de ce changement est aussi décrite par la spécification de service (voir la section 5.6 "Régulation" ci-dessous).

Les composantes RSpec et TSpec des informations d'invocation devraient être spécifiées séparément et indépendamment, car elles seront souvent générées par des éléments différents de l'inter réseau.

Toutes les spécifications d'informations quantitatives dans cette section devraient suivre les lignes directrices données dans la section 3, "Formats de données", ci-dessus.

5.5   Information exportées et paramètres de caractérisation

Cette section décrit les informations qui doivent être collectées et exportées par le module de service. Les informations exportées sont disponibles pour les autres modules de l'élément de réseau, et par extension aux protocoles d'établissement, aux protocoles d'acheminement, aux outils de gestion du réseau, et autres de cette sorte.

Les informations exportées par les modules de service peuvent être utilisées de plusieurs façons. Par exemple, des quantités telles que la quantité de bande passante de liaison dédiée au service et l'ensemble des flux de données qui reçoivent actuellement le service sont des éléments d'information appropriés à mettre à disposition comme variables de gestion de réseau.

Une définition de service peut identifier un sous ensemble particulier des informations exportées par un module de service comme paramètres de caractérisation. Ces paramètres de caractérisation peuvent être utilisés pour calculer ou estimer le comportement de bout en bout d'un flux de données qui traverse un enchaînement d'éléments de service de réseau. Ils peuvent également être utilisés pour caractériser des portions du chemin à l'usage des éléments de réseau (par exemple, pour calculer la mémoire tampon nécessaire, un élément peut avoir besoin de savoir quelque chose des caractéristiques de service de la portion amont du chemin). Un service qui définit les paramètres de caractérisation spécifie aussi les caractérisations qui sont utilisées pour les générer et la fonction de compositions utilisée pour générer les caractérisations.

NOTE : Les paramètres de caractérisations sont identifiés comme tels par le fait qu'ils sont les entrées des fonctions de composition définies du service. Parce que les paramètres de caractérisations font partie de l'ensemble global des données exportées d'un service, ils sont aussi disponibles aux autres fonctions, comme celles de gestion de réseau. L'exposé ci-dessous se rapporte seulement à leur utilisation comme paramètres de caractérisations, et n'est pas destiné à limiter les autres usages.

Les paramètres de caractérisations peuvent être des quantités relativement statiques, comme la bande passante disponible sur une liaison spécifique, ou des quantités relativement dynamiques, comme une estimation instantanée du délai de paquet en cours.

La prise en charge des paramètres de caractérisations définis d'un service est obligatoire. Tout élément de réseau qui offre ce service doit être capable de mesurer, calculer, ou, si c'est admis par la spécification, estimer les paramètres de caractérisations du service. Les concepteurs de service sont invités à comprendre les implications de la spécification des paramètres de caractérisations pour un service, en particulier en ne restreignant pas indûment les choix des architectures de matériels et logiciels utilisés pour mettre en œuvre l'élément de réseau.

Les paramètres de caractérisations sont utilisés en composant les valeurs exportées par chaque élément de réseau le long d'un chemin de flux de données conformément à une règle de composition. Pour chaque paramètre ou ensemble de paramètres utilisé pour développer une caractérisation, la spécification de service doit spécifier la règle de composition à utiliser. Ces règles de composition devraient résulter en caractérisations qui sont indépendantes de l'ordre dans lequel l'élément est composé ; la commutativité et l'associativité sont des conditions suffisantes mais pas nécessaires pour cela.

Les paramètres de caractérisations sont disponibles à travers une interface générale, et sont fournis en réponse à une demande provenant de quelque autre module, tel qu'un protocole d'établissement ou le protocole d'acheminement. La question de savoir exactement comment, ou si, un protocole spécifique (par exemple, RSVP) utilise des paramètres de caractérisation pour générer les caractérisations est décrite dans la spécification de ce protocole spécifique.

L'utilisation correcte des paramètres de caractérisation fournis par les modules de service est une fonction du protocole d'établissement, d'acheminement, ou de gestion qui contrôle le module. Il n'y a pas de garantie absolue que ces caractérisations seront disponibles aux nœuds d'extrémité qui désirent utiliser un service de contrôle de la QS. Les concepteurs de services qui ciblent des services pour l'Internet global peuvent souhaiter s'assurer qu'un service est utile même en l'absence de caractérisations, et monter de telles utilisations dans les sections "Exemples" des documents de description de service.

À l'inverse, la disponibilité des caractérisations peut être obligatoire dans certaines circonstances, en particulier pour les réseaux IP privés qui fournissent des qualités de service étroitement contrôlées pour des applications spécifiques. Les concepteurs de services qui visent cet environnement devraient particulièrement s'assurer que le service fournit des paramètres de caractérisation et des fonctions de composition adéquats pour satisfaire aux besoins du public visé. Il peut être approprié de spécifier le même service de base avec des caractérisations supplémentaires pour satisfaire des exigences spécifiques au delà de celles de l'Internet global.

Certains paramètres de caractérisation "généraux" utiles et les règles de composition correspondantes ne sont associés à aucun service spécifique. Cela inclut la latence de la vitesse de la lumière des liaisons de communication et la bande passante disponible de liaison. Ces paramètres de caractérisation généraux sont définis dans la [RFC2215].

Bien que toute mise en œuvre conforme d'un service soit obligée de fournir les paramètres de caractérisation de ce service, il est encore possible que les paramètres de caractérisation désirés ne soient pas disponibles pour la composition de tous les éléments de réseau dans un chemin. Cette situation peut survenir lorsque différents services d'élément de réseau sont utilisés à des points différents dans le chemin de bout en bout, comme cela peut être exigé dans un environnement hétérogène d'inter réseaux. Pour cette raison, les paramètres de caractérisation et les résultats de fonction de composition incluent conceptuellement un "fanion de validité". Un élément de réseau qui n'est pas capable de fournir le paramètre de caractérisation doit établir ce fanion, et autrement laisser le paramètre ou valeur composée inchangé. Une fois établi, le fanion est préservé par la fonction de composition, et sert d'indicateur de la validité des données lorsque le résultat composé final est livré à sa destination.

Les protocoles qui transportent des paramètres de caractérisation et des données de composition doivent définir et prendre en charge une représentation concrète pour ce fanion de validité, ainsi que pour les paramètres de caractérisation eux-mêmes.

NOTE : Ce modèle de spécification de service ne permet pas à une définition de service *d'exiger* qu'un mécanisme d'établissement ou d'invocation utilisé avec le service effectue de fonction autre que le transport de paramètres d'invocation aux éléments de réseau et que la signalisation d'erreurs générée par les éléments de réseau aux nœuds d'extrémité. Un exemple notable en est que les documents de spécification de service ne peuvent pas exiger ou supposer que les caractérisations définies dans la spécification sont réellement calculées ou présentées aux nœuds d'extrémité.

Malgré ce point, l'utilité pratique d'un service spécifique peut fortement dépendre de la présence d'un comportement supplémentaire dans le système de réseau, tel que le calcul et la présentation de caractérisations aux nœud d'extrémité ou l'assurance fiable que tout élément de réseau dans le chemin de l'envoyeur aux receveurs prend en charge le service donné. Les auteurs de spécification de service sont vivement encouragés à expliquer clairement la situation de leur service à cet égard. Des déclarations telles que : "Les caractérisations définies par ce service servent de conseils utiles à l'application. Cependant, le service est spécifiquement destiné à être utile même si les caractérisations ne sont pas disponibles.", ou "L'utilité de ce service dépend fortement de la livraison des caractérisations et de la connaissance que tous les éléments de réseau sur le chemin prennent en charge de service. Les demandes du service lorsque les caractérisations ne sont pas disponibles vont vraisemblablement conduire à des résultats incorrects ou trompeurs." sont appropriées. Il peut aussi être utile de considérer ce point au paragraphe 5.11 "Exemples d'utilisation".

NOTE : La possibilité de modifier l'architecture globale pour fournir des informations sur le protocole d'invocation dans une demande de service, et de permettre à un service d'exiger que le protocole d'invocation prenne en charge des fonctionnalités supplémentaires spécifiques fait l'objet d'études actives.

5.6   Régulation

Cette portion de la description de service décrit la nature de la régulation utilisée pour mettre en application l'adhésion à la spécification de trafic d'un flux. Le document de spécification doit spécifier les points suivants :

-   Action de régulation attendue. C'est l'action entreprise lorsque des paquets non conformes à la TSpec sont détectés. Les exemples d'actions incluent de reléguer les paquets non conformes au service au mieux, d'éliminer immédiatement les paquets non conformes, de retarder ces paquets jusqu'à ce qu'ils soient à nouveau adaptés à la TSpec, ou de "marquer" les paquets non conformes d'une façon ou d'une autre.

-   Légalité des actions de régulation de remplacement. La section doit spécifier si des actions non spécifiquement mentionnées dans la description du comportement de régulation de la spécification sont légales. Par exemple, une description de service qui spécifie que les paquets non conformes sont à éliminer devrait déclarer si une autre action, comme de retarder ces paquets, est acceptable.

-   Localisation des actions de régulation dans l'inter réseau. La description de la régulation doit spécifier où est effectuée cette régulation. Les possibilités sont "seulement aux bordures du réseau", "à chaque bond", "aux points de branches hétérogènes" (points où les branches d'une arborescence de diffusion groupée convergent et ont différentes TSpec réservées vers l'aval), et "aux points de fusion de source" (les points où plusieurs flux de données couverts par une seule réservation de ressource convergent). La spécification devrait clairement déclarer les exigences sur les informations de topologie (par exemple "ceci est un nœud de bordure" ou "ceci est un point de fusion de source") qui doivent être disponibles de la part du protocole d'établissement ou d'une autre source.

Dans cette section, la spécification devrait aussi préciser la légalité de la régulation à des points supplémentaires du réseau, au delà de ceux énumérés ci-dessus. Cela est important du fait des effets techniques tels que ceux décrits au prochain paragraphe.

Considération techniques supplémentaires applicables. Si la régulation des flux de données est exigée ou légale à des points autres que la première entrée du flux dans le réseau, la définition de service devrait décrire toutes les considérations techniques supplémentaires qui affectent la conception d'une telle régulation. Par exemple, de nombreux services potentiels vont permettre qu'un flux de données devienne plus saccadé à mesure qu'il progresse à travers le réseau. Si un tel service permet la régulation à des points autres que les bords du réseau, la spécification de trafic qui décrit le flux devra être modifiée à partir du point donné par l'application au réseau pour tenir compte de cette sporadicité croissante. Autrement, il est vraisemblable que le flux sera "sur régulé", avec des paquets qui seront pénalisés inutilement.

5.7   Ordre et fusion

Ordre et fusion entrent en jeu lorsque un élément de réseau reçoit plusieurs demandes d'invocation qui couvrent le même flux de données. Par exemple, cela pourrait arriver si plusieurs receveurs d'un flux de données en diffusion groupée ont demandé des services de QS pour ce flux en utilisant le protocole d'établissement RSVP, ou si un flux était soumis à la fois à une demande d'invocation permanente installée de façon statique et à une demande dynamique de la par d'un protocole d'établissement de ressource.

Dans cette situation, le module de service doit être capable de répondre aux questions sur l'ordre entre les différentes demandes d'invocation, et doit être capable de générer une seule nouvelle demande d'invocation qui satisfasse à la sémantique du protocole d'établissement et aux exigences de tous les demandeurs d'origine. Du point de vue du fonctionnement, ceci est réalisé en ayant le protocole invocateur qui demande au module de service, étant donné un ensemble de demandes d'invocation I1...In, de calculer une nouvelle demande qui a pour résultat le comportement désiré.

Cinq opérations doivent être définies dans cette section. Ce sont :

-   Ordre. La section doit définir une relation d'ordre entre les TSpec et RSpec du service. Cela peut être un ordre partiel, en ce que certaines TSpec ou RSpec peuvent être non ordonnées les unes par rapport aux autres.

-   Sommation. Cette fonction calcule une demande d'invocation qui représente la somme de N entrées de demandes d'invocation. Normalement, cette fonction est utilisée pour calculer la taille d'une demande de service adéquate pour une réservation partagée pour N flux différents. Il est souhaitable mais non exigé que cette fonction calcule la "moindre somme possible".

-   Minimum. Cette fonction calcule le minimum de deux TSpec. Normalement, cette fonction est utilisée pour calculer la TSpec pour une invocation de service réelle étant donnée une TSpec cible pour la demande de service et une TSpec pour le schéma de trafic réel du flux. La fonction minimum doit calculer la plus petite TSpec adéquate pour décrire le minimum de la TSpec demandée et du trafic réel du flux.

-   Fonction Fusion de RSVP. Cette fonction calcule la demande d'invocation utilisée pour demander le service à un point de fusion RSVP [RFC2205]. La fonction doit a) calculer une demande d'invocation appropriée pour un ensemble de réservations vers l'aval qui doivent être fusionnées, et b) générer les paramètres de réservation appropriés à passer vers l'amont par RSVP. Cette fonction est décrite plus précisément ci-dessous et dans la [RFC2210].

-   Fonction Moindre demande commune. Cette fonction calcule une demande d'invocation suffisante pour fournir un service au moins équivalent à celui de toute demande d'origine passée à la fonction. Cette fonction diffère de la fonction Fusion RSVP en ce qu'elle calcule simplement une limite supérieure. Elle n'a pas besoin de calculer de nouveaux paramètres d'invocation à passer en amont par RSVP et ne peut pas utiliser la seconde option discutée dans les "Notes sur la fusion RSVP" ci-dessous.

o   Notes sur l'ordre

Normalement, la relation d'ordre va être décrite séparément pour la TSpec et la RSpec du service. Une demande d'invocation est ordonnée par rapport à une autre si et seulement si sa TSpec et sa RSpec sont toutes deux similairement ordonnées l'une par rapport à l'autre.

Pour les TSpec, la relation d'ordre de base est bien définie. La TSpec A est substituable à la TSpec B si et seulement si tout flux conforme à la TSpec B est aussi conforme à la TSpec A. La spécification de service doit expliquer comment comparer deux TSpec pour déterminer si cela est vrai.

Pour les RSpec, la relation d'ordre dépend du service. La RSpec A est substituable à la RSpec B si la qualité de service invoquée par la RSpec A est au moins aussi bonne que la qualité de service invoquée par la RSpec B. Comme il n'y a pas de description mathématique précise de la "bonté" de la qualité de service, ces relations d'ordre doivent être expliquées de façon précise dans la description de service.

o   Notes sur la fusion RSVP

L'objet de la fonction de fusion RSVP est de calculer une demande d'invocation qui va fournir au flux fusionné un service au moins équivalent à celui que toute demande d'origine aurait obtenu pour son flux correspondant non fusionné. Cette équivalence peut être obtenue de deux façons :

1)   La demande fusionnée peut être calculée comme limite supérieure de l'ensemble original (non fusionné) des demandes d'invocation. Dans ce cas, par définition, le service offert par la demande fusionnée sur tout flux particulier est identique à celui offert par la plus grande demande non fusionnée.

2)   Le demande fusionnée peut être calculée comme une valeur plus petite que la limite supérieure de l'ensemble des demandes d'origine, mais le résultat passé en amont peut restreindre les sources de trafic à des comportements qui rendent identiques les comportements des demandes fusionnées et non fusionnées.

Noter que les règles de fusion pour un service particulier peuvent appliquer l'option 1 ou l'option 2 aux différents composants d'une TSpec, selon le cas approprié. La décision est normalement prise comme suit :

Lorsque une instance de module de service amont peut tolérer un flux qui excède le paramètre, la limite supérieure devrait être utilisée. Par exemple, si le service accepte la régulation pour se protéger contre l'excès de trafic, le taux de trafic pris en charge par une réservation fusionnée pourrait être une limite supérieure parmi les taux de trafic acceptés par chaque réservation non fusionnée. Les effet en seront d'installer la réservation fusionnée au nœud local et d'informer chaque source de trafic du plus fort taux de trafic protégé par réservation le long de tout chemin de distribution *un* de la source à un receveur.

Lorsque une instance de module de service aval ne va pas fonctionner correctement si le paramètre est dépassé, la fonction fusionnée devrait choisir la valeur la moins agressive du paramètre pour l'installer et la passer en amont. Dans ce cas, les sources de trafic seront informées d'une valeur de paramètre qui est appropriée pour *tous* les chemins de distribution traversés par le flux de trafic. Par exemple, les services qui peuvent seulement traiter des paquets de taille limitée peuvent incorporer la taille de paquet dans la TSpec, et traiter le paramètre comme décrit dans l'option 2. L'effet en sera de limiter les tailles de paquets dans le flux à celles qui peuvent être traitées par chaque instance de service le long du chemin de ce flux.

Ce calcul de fusion doit être effectué par le module de service parce qu'il est spécifique d'un service particulier.

o   Notes sur le calcul des limites supérieures

Les fonction Fusion RSVP et Moindre demande commune peuvent toutes deux être utilisées pour calculer des limites supérieures sur les paramètres de TSpec et RSpec.

La limite supérieure calculée n'a pas besoin d'être une limite supérieure inférieure (ou moindre limite supérieure) , pas plus que les divers éléments de réseau le long du chemin n'ont besoin de tous utiliser le même choix de limite supérieure. Tout choix de paramètre d'invocation Iu est conforme pour autant qu'il soit substituable à chacun des paramètres I1...In à partir desquels il est calculé. Intuitivement, un ensemble de paramètres est substituable à un autre si la qualité de service résultante est au moins aussi désirable pour toutes les applications. Une définition précise de cette fonction "substituable à", la relation d'ordre, doit être spécifiée dans la définition de service. (Elle peut être spécifiée comme l'ensemble vide, auquel cas la fusion de demandes dissemblables ne sera pas admis). Si la fonction d'ordre spécifiée dans cette section donne un ordre partiel (si il est possible que deux RSpec ou TSpec ne soient pas ordonnées) un calcul de limite supérieure distincte doit alors aussi être donné pour le paramètre.

o   Notes sur la substitution de service

Cette portion de la description de service peut aussi noter toutes les relations avec d'autres services qui sont strictement ordonnés par rapport au service défini. Deux services A et B sont strictement ordonnés si il est toujours possible de substituer le service B au service A étant donné un ensemble de paramètres d'invocation pour le service A. Ces informations d'ordre peuvent être utilisées pour permettre des éléments de réseau qui fournissent le service B pour répondre aux demandes pour le service A, même si l'élément ne fournit pas directement le service A. Si la spécification du service décrit un tel ordre inter service, elle DOIT aussi inclure une description de la fonction de transposition de paramètre d'invocation pour cet ordre.

La substitution d'un service à un autre dans les cas où ils ne sont pas strictement ordonnés n'est actuellement pas prise en charge. Une future version du présent document pourra compléter le format de spécification de service pour prendre en charge cette capacité.

5.8   Lignes directrices pour la mise en œuvre

De nombreux services peuvent être définis d'une manière qui permette que la gamme des comportements d'un élément de réseau conforme soit assez large. Cette section devrait donner des indications sur les gammes de comportements que l'auteur de la spécification de service pense être désirés par la communauté de l'Internet dans ses mises en œuvre. Comme ces lignes directrices dépendent de notions imprécises et indéfinissables comme celle de "charge normale", ces lignes directrices ne peuvent pas être incorporées au titre d'un essai de conformité strict. Elles sont donc purement pour information.

5.9   Critères d'évaluation

Les comportements fonctionnels spécifiques exigés par une mise en œuvre pour la conformité à une spécification de service sont détaillées dans les sections précédentes. Cependant, les spécifications de service sont destinées à permettre une large gamme de mises en œuvre, et ces mises en œuvre vont avoir des performances différentes. Cette section décrit les essais qui peuvent être utilisés pour évaluer la mise en œuvre d'un service donné par un élément de réseau.

Les développeurs de modules de service sont confrontés à un certain nombre de compromis, et il est peu vraisemblable qu'une seule mise en œuvre soit considérée comme "la meilleure" en toutes circonstances. Par exemple, sur la même spécification de service, une mise en œuvre appropriée pour une liaison à base vitesse peut viser une utilisation de liaison extrêmement élevée, alors qu'une mise en œuvre différente pourra essayer de réduire le délai de transmission de paquets non chargés au minimum au dépens d'une utilisation un peu plus faible de la liaison. L'intention des essais spécifiés dans cette section devrait être de mettre à l'épreuve les compromis fait par le concepteur de la mise en œuvre, et de fournir des métriques utiles pour guider le choix de l'utilisateur vers une mise en œuvre appropriée à ses besoins.

Les essais spécifiés dans cette section devraient être conçus pour fonctionner sur un seul élément de réseau isolément. Cela permet de les utiliser dans un système comparatif pour les éléments de réseau à capacité de QS. Dans les réseaux de production, les utilisateurs seront plus concernés par le comportement de bout en bout obtenu, qui va dépendre non seulement des éléments de réseau particuliers choisis, mais aussi d'autres facteurs tels que le protocole d'établissement et la bande passante des liaisons. Certains facteurs de performances pertinents pour l'utilisateur sont le taux de rejets au contrôle d'admission, la gamme des services offerts, le délai de paquet et le taux d'abandon dans les diverses classes de service. La forme de tous les outils de métrique et de mesure standardisés de bout en bout pour l'inter réseau à intégration de services n'est pas spécifiée par le présent document ou par les document de spécification de service qui suivent le format donné ici.

Cette section est seulement pour information.

5.10   Exemples de mise en œuvre

Cette section décrit les exemples d'instances de service. Ce seront souvent de simples références à la littérature, ou de brefs aperçus de la façon dont le service pourrait être mis en œuvre. L'objet de la section est de donner un sens plus concret au service spécifié et de fournir des pointeurs et indications pour aider celui qui met en œuvre. Cependant, les descriptions dans cette section ne sont spécifiquement pas destinées à exclure les autres stratégies de mise en œuvre.

Cette section est seulement pour information.

5.11   Exemples d'utilisation

Afin de donner un sens plus concret de l'utilisation possible de ce service, cette section décrit des exemple d'utilisation du service, dans un but d'information uniquement. Les exemples n'ont aucun caractère d'exhaustivité, et n'excluent d'aucune façon les autres utilisations du service.

Cette section est seulement pour information.

6.   Considérations pour la sécurité

Les considérations pour la sécurité ne sont pas discutées dans le présent mémoire.

7.   Références

[PARTRIDGE]   C. Partridge, "Gigabit Networking", Addison Wesley Publishers (1994).

[RFC2215]   S. Shenker, J. Wroclawski, "Paramètreshttp://abcdrfc.free.fr/rfc-vf/rfc2215.html généraux de caractérisation pour éléments de réseau à intégration de service", septembre 1997. (P.S.)

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

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

[RFC1819]   L. Delgrossi et L. Berger, éditeurs, "Spécification du protocole de flux Internet version 2 (ST2) - Version ST2+", août 1995.

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

8.   Adresse des auteurs