Groupe de travail Réseau |
J. Wroclawski, MIT LCS |
Request for Comments : 2210 |
septembre 1997 |
Catégorie : En cours de normalisation |
Traduction Claude Brière de L'Isle |
Utilisation de RSVP avec les services intégrés de l'IETF
Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
Résumé
Le présent mémoire décrit l'utilisation du protocole de réservation de ressource (RSVP, reservationresource protocol) avec les services de charge contrôlée et de contrôle de qualité de service garantie. Le protocole RSVP définit plusieurs objets de données qui portent des informations de réservation de ressource mais sont opaques à RSVP lui-même. L'usage et le format de données de ces objets sont décrits dans ce document.
1. Introduction
Le cadre des services intégrés de l'Internet donne aux applications la capacité de choisir parmi plusieurs niveaux de contrôle de service de livraison pour leurs paquets de données. Deux choses sont exigées pour la prise en charge de cette capacité :
- Les éléments de réseau individuels (sous-réseaux et routeurs IP) le long du chemin suivi par les paquets de données d'une application doivent prendre en charge les mécanismes de contrôle de la qualité de service délivrée à ces paquets.
- Une façon de communiquer les exigences de l'application aux éléments de réseau le long du chemin et de convoyer les informations de gestion de la QS entre les éléments de réseau et l'application doit être fournie.
Dans le cadres des services intégrés, la première fonction est fournie par les services de contrôle de la QS tels que la charge contrôlée de la [RFC2211] et de garantie de service de la [RFC2212]. La seconde fonction peut être fournie d'un certain nombre de façons, mais elle est fréquemment mise en œuvre par un protocole d'établissement de réservation de ressources tel que RSVP [RFC2205].
Parce que RSVP est conçu pour être utilisé avec divers services de contrôle de la QS, et parce que les services de contrôle de la QS sont conçus pour être utilisés avec divers mécanismes d'établissement, il existe une séparation logique entre les deux spécifications. La spécification RSVP ne définit pas le format interne de ces champs du protocole RSVP, ou objets, qui se rapportent à l'invocation des services de contrôle de la QS. RSVP traite plutôt ces objets comme opaques. Les objets peuvent porter différentes informations pour satisfaire des exigences différentes d'application et de service de contrôle de la QS.
De même, les interfaces avec les services de contrôle de la QS sont définis dans un format général, de sorte que les services peuvent être utilisés avec divers mécanismes d'établissement.
La présente RFC fournit les informations requises pour l'utilisation de RSVP et des services de contrôle de la QS du cadre de service intégré. Elle définit l'usage et le contenu de ces objets du protocole RSVP, la FLOWSPEC, ADSPEC, et SENDER_TSPEC, dans un environnement qui prend en charge les services de contrôle de QS de charge contrôlée et de service garanti. Si de nouveaux services ou capacités sont ajoutés au cadre des services intégrés, cette note sera révisée en tant que de besoin.
2. Utilisation de RSVP
Plusieurs types de données doivent être transportés entre les applications et les éléments de réseau pour invoquer correctement les services de contrôle de la QS.
NOTE : En plus des données utilisées pour invoquer directement les services de contrôle de la QS, RSVP porte des informations d'authentification, de comptabilité et de politique nécessaires pour gérer l'utilisation de ces services. La présente note ne concerne que les objets RSVP nécessaires pour invoquer effectivement les services de contrôle de la QS, et ne traite pas des objets de comptabilité ou de politique.
Ces données incluent :
- Les informations générées par chaque receveur qui décrivent le service de contrôle de la QS désiré, une description des flux de trafic auxquels la réservation de ressource devrait s'appliquer (la TSpec de receveur), et tous paramètres nécessaires pour invoquer le service (la RSpec de receveur). Ces informations sont portées des receveurs aux éléments de réseau intermédiaires et à ou aux envoyeurs par les objets RSVP FLOWSPEC. Les informations portées dans un objet FLOWSPEC peuvent changer à des points intermédiaires dans le réseau à cause de fusions de réservations et d'autres facteurs.
- Les informations générées chez chaque envoyeur qui décrivent le trafic de données généré par cet envoyeur (la TSpec d'envoyeur). Ces informations sont portées de l'envoyeur aux éléments de réseau intermédiaires et au ou aux receveurs par RSVP, mais ne sont jamais modifiées par des éléments intermédiaires au sein du réseau. Ces informations sont portées dans les objets RSVP SENDER_TSPEC.
- Les informations générées ou modifiées au sein du réseau et utilisées chez les receveurs pour prendre les décisions de réservation. Ces information peuvent inclure les services disponibles, les estimations de délai et de bande passante, et les paramètres de fonctionnement utilisés par des services spécifiques de contrôle de la QS. Ces informations sont collectées à partir des éléments de réseau et portés vers les receveurs dans des objets RSVP ADSPEC. Plutôt que de porter les informations séparément de chaque nœud intermédiaire aux receveurs, les informations de l'ADSPEC représentent un résumé, calculé lorsque l'ADSPEC passe chaque bond. La taille de ce résumé reste (en gros) constante lorsque l'ADSPEC s'écoule à travers le réseau, donnant de bonnes propriétés d'échelonnage.
Du point de vue des objets RSVP, le départage se fait comme suit :
- L'objet RSVP SENDER_TSPEC porte la spécification du trafic (TSpec d'envoyeur) généré par chaque source de données au sein d'une session RSVP. Il est transporté inchangé à travers le réseau, et livré aux nœuds intermédiaires ainsi qu'aux applications receveuses.
- L'objet RSVP ADSPEC porte les information qui sont générées aux sources de données ou aux éléments de réseau intermédiaires, et s'écoule en aval vers les receveurs, et peut être utilisé et mis à jour au sein du réseau avant d'être livré aux applications receveuses. Ces informations incluent à la fois les paramètres qui décrivent les propriétés du chemin des données, y compris la disponibilité de services spécifiques de contrôle de la QS, et les paramètres requis par des services spécifiques de contrôle de la QS pour fonctionner correctement.
- L'objet RSVP FLOWSPEC porte les informations de demande de réservation (Receiver_TSpec et RSpec) générées par les receveurs des données. Les informations dans la FLOWSPEC s'écoulent vers l'amont vers les sources de données. Il peut être utilisé ou mis à jour à des éléments de réseau intermédiaires avant d'arriver à l'application d'envoi.
NOTE : L'existence des deux objets RSVP SENDER_TSPEC et ADSPEC est quelque peu historique. En utilisant le format de message décrit dans la présente note, il serait possible de placer toutes les informations de contrôle de service portées "en aval" par RSVP dans le même objet. Cependant, la distinction entre les données n'est pas mise à jour au sein du réseau (dans l'objet SENDER_TSPEC) et les données qui sont mises à jour dans le réseau (dans l'objet ADSPEC) peuvent être utiles en pratique à une mise en œuvre, et elles sont donc conservées.
2.1 Résumé du fonctionnement
Le fonctionnement se déroule comme suit :
Une instance d'application qui participe à une session RSVP comme envoyeur de données s'enregistre auprès de RSVP. Un élément des informations fournies par l'instance d'application est la TSpec d'envoyeur qui décrit le trafic que l'application s'attend à générer. Ces informations sont utilisées pour construire un objet RSVP SENDER_TSPEC, qui est inclus dans les messages RSVP PATH générés pour l'application.
L'application envoyeuse construit aussi un objet RSVP ADSPEC initial. Cette adspec porte les informations sur les capacités de contrôle de la QS et les exigences de l'application d'envoi elle-même, et forme le point de départ pour l'accumulation de propriétés de chemin décrites ci-dessous. L'ADSPEC est ajouté au message RSVP PATH créé chez l'envoyeur.
NOTE : Pour les besoins des programmeurs d'applications, une mise en œuvre d'hôte RSVP peut permettre que l'application d'envoi ne fournisse pas une adspec initiale, fournissant à la place la sienne propre par défaut. Cet usage a des chances de se produire lorsque l'application d'envoi ne participe pas elle-même au processus de contrôle de la QS de bout en bout (en programmant activement l'usage de la CPU et des moyens similaires) et ne se soucie pas elle-même du service de contrôle de la QS qui est choisi par les receveurs.
Normalement l'ADSPEC par défaut fournie dans ce cas par l'hôte RSVP va prendre en charge tous les services de contrôle de la QS connues de l'hôte. Cependant, le comportement exact de ce mécanisme dépend de la mise en œuvre.
L'ADSPEC est modifiée par les éléments de réseau suivants à mesure que le message RSVP PATH se déplace de l'envoyeur aux receveurs. À chaque élément de réseau, l'ADSPEC est passée de RSVP au module de contrôle du trafic. Le module de contrôle du trafic met à jour l'ADSPEC, qui peut contenir des données pour plusieurs services de contrôle de la QS, en identifiant les services mentionnés dans l'ADSPEC et en invitant chacun de ces services à mettre à jour sa portion de l'ADSPEC. Si le module de contrôle du trafic découvre qu'un service de contrôle de la QS mentionné dans l'ADSPEC n'est pas mis en œuvre par l'élément de réseau, il établit un fanion pour en faire rapport au receveur. L'ADSPEC mise à jour est alors retournée à RSVP pour livraison au prochain bond sur le chemin.
À l'arrivée du message PATH chez une application receveuse, les données dans les objets SENDER_TSPEC et ADSPEC sont passés à travers l'API RSVP à l'application. L'application (peut-être avec l'aide d'une bibliothèque de fonctions communes de réservation de ressource) interprète les données arrivantes, et les utilise pour guider le choix des paramètres de réservation de ressource. Parmi les exemples de cela on trouve l'utilisation du paramètre de caractérisation composé "PATH_MTU" en arrivée [RFC2215] pour déterminer le paramètre de taille maximum de paquet dans la demande de réservation, et l'utilisation des paramètres"C" et "D"du service garanti en arrivée [RFC2212] pour calculer une limite mathématique au délai de livraison des paquets lors de l'utilisation du service garanti.
Une application receveuse qui souhaite faire une réservation de ressource fournit à son RSVP local les paramètres de réservation nécessaires. Parmi eux se trouvent le service de contrôle de la QS désiré (Garanti ou Charge contrôlée), le spécificateur de trafic (TSpec) qui décrit le niveau de trafic pour lequel des ressources devraient être réservée, et, si nécessaire pour le service de contrôle de la QS choisi, une RSpec qui décrit le niveau de service désiré. Ces paramètres sont composés en un objet RSVP FLOWSPEC et transmis vers l'amont par RSVP.
À chaque point à capacité RSVP dans le réseau, les SENDER_TSPEC qui arrivent dans les messages PATH et les FLOWSPEC qui arrivent dans les messages RESV sont utilisés pour demander une réservation de ressource appropriée au service de contrôle de la QS désiré. La fusion d'état, la transmission de message, et le traitement d'erreur se font selon les règles du protocole RSVP.
Finalement, l'objet FLOWSPEC fusionné arrivant à chacun des envoyeurs de données d'une session RSVP est livré à l'application pour informer chaque envoyeur de la demande de réservation fusionnée et des propriétés du chemin des données.
2.2 Prise en charge RSVP de plusieurs services de contrôle de la QS
La conception décrite dans la présente note prend en charge des sessions RSVP dans lesquelles les receveurs choisissent un service de contrôle de la QS au démarrage.
Pour que cela soit possible, un receveur doit avoir toutes les informations nécessaires pour choisir un service particulier avant de faire ce choix. Cela signifie que les objets RSVP SENDER_TSPEC et ADSPEC doivent fournir aux receveurs les informations sur tous les services qui peuvent être choisis.
La TSpec d'envoyeur utilisée par les deux services de contrôle de la QS actuellement définis est identique. Cela simplifie l'objet RSVP SENDER_TSPEC, qui a seulement besoin de porter une seule structure de données de TSpec dans ce format partagé. Cette SENDER_TSPEC commune peut être utilisée avec l'un et l'autre service Garanti ou Charge contrôlée.
L'ADSPEC RSVP porte les informations dont les receveurs ont besoin pour choisir un service et déterminer les paramètres de réservation. Cela inclut :
- Si il y a ou non un bond non RSVP le long du chemin. Si il y a un bond non RSVP, le trafic de l'application va recevoir un service sans réservation au mieux à au moins un point sur le chemin.
- Si un service spécifique de contrôle de la QS est mis en œuvre ou non à chaque bond le long du chemin. Par exemple, un receveur peut apprendre qu'au moins un bond à capacité de service intégré le long du chemin prend en charge le service de charge contrôlée mais pas le service garanti.
- Les valeurs globales ou par défaut pour les paramètres de caractérisation générale décrits dans la [RFC2215]. Ces valeurs décrivent les propriétés du chemin lui-même, sans considération du service de contrôle de la QS choisi. Une valeur rapportée dans cette section de l'ADSPEC s'applique à tous les services sauf si une valeur différente, spécifique du service, est aussi présente dans l'ADSPEC.
- Une valeur spécifique du service pour un ou plusieurs des paramètres de caractérisation générale, si la valeur spécifique du service diffère de la valeur par défaut.
- Les valeurs des paramètres de caractérisation par service définies par chaque service.
Les données dans l'ADSPEC sont divisées en blocs ou fragments, dont chacun est associé à un service spécifique. Cela permet que l'adspec porte des informations sur plusieurs services, que de nouveaux services soient déployés à l'avenir sans immédiatement devoir mettre à jour le code existant, et qu'une application qui n'utilisera jamais un service particulier omette les données d'ADSPEC pour ce service. La structure de l'ADSPEC est décrite en détail au paragraphe 3.3.
Un envoyeur peut indiquer qu'un service de contrôle de la QS spécifique ne devrait pas être utilisé par les receveurs dans une session RSVP. Cela est fait en omettant toute mention de ce service dans l'ADSPEC, comme décrit au paragraphe 3.3. À l'arrivée chez un receveur, l'absence complète d'un fragment ADSPEC pour un service spécifique indique aux receveurs que le service ne devrait pas être utilisé.
NOTE : Dans RSVP version 1, tous les receveurs au sein d'une session sont obligés de choisir le même service de contrôle de la QS. Cette restriction est imposée par la difficulté de fusionner les réservations qui demandent des services de contrôle de la QS différents, et par le manque actuel d'un mécanisme général de remplacement de service. La restriction pourra être éliminée à l'avenir.
Considérant cette restriction, il peut être utile de coordonner le choix par les receveurs d'un service de contrôle de la QS en faisant que le ou les envoyeurs n'offrent qu'un choix, en utilisant le mécanisme d'ADSPEC mentionné ci-dessus. Tous les receveurs doivent alors choisir le même service. Autrement, la coordination peut être réalisée par l'utilisation d'un mécanisme d'annonce et d'établissement de session de niveau supérieur pour informer les receveurs du service de contrôle de la QS utilisé, par configuration manuelle des receveurs, ou par un protocole d'accord fonctionnant entre les receveurs de la session eux-mêmes.
Comme avec l'ADSPEC, les formats d'objets FLOWSPEC et SENDER_TSPEC décrits à la Section 3 sont capables de porter les TSpec et les RSpec pour plus d'un service de contrôle de la QS dans des fragments de données séparés. Actuellement, l'utilisation d'une FLOWSPEC ou SENDER_TSPEC contenant des fragments pour plus d'un service de contrôle de la QS n'est pas acceptée. À l'avenir, cette capacité pourra être utilisée pour mettre en œuvre un schéma plus souple de demande et de remplacement de service, permettant aux applications d'obtenir un contrôle utile de la qualité de service de bout en bout quand tous les nœuds intermédiaires ne prennent pas en charge le même ensemble de services de QS. Les API d'application RSVP devraient être conçues de façon à prendre en charge les objets SENDER_TSPEC, FLOWSPEC, et ADSPEC passants de taille variable et contenant des informations sur plusieurs services de contrôle de la QS entre RSVP et ses clients.
2.3 Utilisation des informations de l'ADSPEC
Ce paragraphe donne des précisions sur les paramètres de réservation et sur l'utilisation des informations portées par l'objet RSVP ADSPEC.
L'objet RSVP ADSPEC porte des bits fanions qui disent aux applications receveuses si un chemin à capacité complète de réservation existe ou non entre chaque envoyeur et le receveur. Ces bits sont appelés "bits de coupure", parce qu'ils indiquent les coupures dans le contrôle de QS le long d'un chemin de réseau. Les bits de coupure sont portés au sein de l'en-tête qui commence chaque fragment de données par service d'un objet RSVP ADSPEC.
Le service numéro 1 est utilisé au sein de l'ADSPEC pour identifier un fragment qui porte des informations sur les valeurs globales de paramètres qui s'appliquent à tous les services (voir la [RFC2215] pour les détails). Le bit de coupure dans le l'en-tête par service du service 1 est utilisé pour dire au ou aux receveurs si tous les éléments de réseau le long di chemin de l'envoyeur au receveur prennent en charge RSVP et les services intégrés. Si un receveur trouve ce bit établi, au moins un élément de réseau le long du chemin de transmission des données entre l'envoyeur de l'ADSPEC et le receveur ne peut pas fournir de services de contrôle de la QS du tout. Ce bit correspond au paramètre de caractérisation globale NON_IS_HOP (bond non à intégration de service) défini dans la [RFC2215].
NOTE : Si ce bit est établi, les valeurs de tous les autres paramètres dans l'ADSPEC sont non fiables. Le bit établi indique qu'au moins un nœud le long du chemin de l'envoyeur au receveur n'a pas traité complètement l'ADSPEC.
Les bits de coupure spécifique d'un service disent au ou aux receveurs si tous les éléments de réseau le long du chemin de l'envoyeur au receveur prennent en charge un service de contrôle de la QS particulier. Le bit de coupure pour chaque service est porté au sein de l'en-tête ADSPEC par service pour ce service. Si un bit est établi chez le receveur, au moins un élément de réseau le long du chemin de transmission des données prend en charge RSVP mais ne prend pas en charge le service de contrôle de la QS correspondant à l'en-tête par service. Ces bits correspondent aux paramètres de caractérisation spécifiques du service NON_IS_HOP définis dans la [RFC2215].
La Section 3 donne plus d'informations sur les bits de coupure.
Les deux services de contrôle de la QS Garanti et Charge contrôlée placent une limite supérieure à la taille des paquets, et exigent que l'application limite la taille maximum des paquets sujets à la réservation de ressource. Pour les deux services, la taille maximum de paquet désirée est un paramètre de la demande de réservation, et le service va rejeter (avec une erreur de contrôle d'admission ) les demandes de réservation qui spécifient une taille de paquet supérieure à celle acceptée par le service.
Comme les demandes de réservation RSVP sont faites par les receveurs, cela implique que les *receveurs* dans une session RSVP, aussi bien que les envoyeurs, ont besoin de savoir quelle est la MTU acceptée par les services de contrôle de la QS le long d'un chemin de données. De plus, dans certains cas inhabituels, la MTU acceptée par un service de contrôle de la QS peut différer de celle acceptée par le même routeur lorsqu'il fournit un service au mieux.
Une forme modulable de négociation de MTU est utilisée pour régler ces problèmes. La négociation de la MTU dans un système RSVP fonctionne comme suit :
- Chaque application envoyeuse qui se joint à une session RSVP remplit le paramètre M (taille maximum de paquet) dans la Sender_TSpec qu'elle génère (portée des envoyeurs aux receveurs dans un objet SENDER_TSPEC) avec la taille maximum de paquet qu'elle souhaite envoyer pour les réservations de ressource couvertes.
- Chaque message RSVP PATH d'une application envoyeuse porte aussi un objet ADSPEC qui contient au moins un paramètre de caractérisation PATH_MTU. Lorsque il arrive chez le receveur, ce paramètre donne la MTU minimum en tout point le long du chemin de l'envoyeur au receveur. Généralement, seul le paramètre "global" PATH_MTU (service 1, paramètre 9) sera présent, auquel cas sa valeur est une MTU légale pour toutes les demandes de réservation. Si un paramètre PATH_MTU spécifique du service est présent, sa valeur sera inférieure à celle du paramètre global, et devrait être utilisée pour les demandes de réservation pour ce service.
- Chaque receveur prend le minimum de toutes les valeurs de PATH_MTU (pour le service de contrôle de la QS désiré) qui arrive dans les messages ADSPEC provenant des différents envoyeurs et utilise cette valeur comme la MTU dans ses demandes de réservation. Cette valeur est utilisée pour remplir le paramètre M de la TSpec créée chez le receveur. Dans le cas d'une réservation de style FF, un receveur peut aussi choisir d'utiliser la MTU déduite de l'ADSPEC de chaque envoyeur dans la FLOWSPEC générée pour cet envoyeur, si le receveur est concerné par l'obtention de la MTU maximum sur chaque chemin de données. Pour s'accommoder des changements dans le chemin des données, le receveur peut continuer à observer les ADSPEC qui arrivent, et modifier la réservation si une ADSPEC nouvellement arrivée indique une plus petite MTU que celle actuellement utilisée.
- Comme les demandes de réservation (messages RESV) se déplacent des receveurs aux envoyeurs, les paramètres de réservation sont fusionnés aux nœuds intermédiaires. Au titre de cette fusion, le plus petit des deux paramètres M arrivant à un point de fusion sera transmis dans le message RESV vers l'amont.
- Comme les demandes de réservation arrivent aux RSVP intermédiaires, on prend le minimum des TSpec demandées des receveurs et la somme des TSpec d'envoyeur, et on fait une réservation pour la TSpec qui en résulte. La réservation va utiliser la plus petite des valeurs réelles de MTU de chemin calculée par les receveurs et la plus grande taille maximum de paquet déclarée par le ou les envoyeurs . (Le paramètre M résultant de la fonction TSpec sum() est le maximum de la somme des paramètres M des TSpec additionnées).
- Lorsque le message RESV complètement fusionné arrive chez chaque envoyeur, la valeur de la MTU (le paramètre M) dans l'objet FLOWSPEC fusionné aura été réglé à la plus petite MTU acceptable des chemins de données de cet envoyeur à tout receveur de la session. Cette MTU devrait être utilisée par l'application envoyeuse pour dimensionner ses paquets. Tout paquet d'une taille supérieure à cette MTU peut être livré au mieux plutôt que d'être couvert par la réservation de ressource de la session.
Noter que les envoyeurs n'ajustent pas la valeur du champ M de leur Sender_TSpec pour correspondre à la taille réelle de paquet choisie à cette étape. La valeur de M représente le plus grand paquet que l'envoyeur peut envoyer, et non le plus grand paquet qu'il envoie actuellement.
Noter que le schéma ci-dessus va permettre à chaque envoyeur dans une session d'utiliser la plus grande MTU appropriée pour cet envoyeur, dans les cas où des chemins de données ou des receveurs différents ont des MTU acceptables différentes.
3. Format des objets RSVP
Cette section spécifie le contenu détaillé et le format de transmission sur le réseau des objets RSVP SENDER_TSPEC, ADSPEC, et FLOWSPEC à utiliser avec les services de contrôle de la QS Garanti et Charge contrôlée. Les formats d'objet spécifiés ici se fondent sur les règles générales de construction de message données à l'Appendice 1.
3.1 Objet RSVP SENDER_TSPEC
L'objet RSVP SENDER_TSPEC porte les informations sur le trafic généré par la source des données. L'objet RSVP SENDER_TSPEC contient un paramètre Token_Bucket_TSpec global (numéro de service 1, paramètre 127, comme défini dans la [RFC2215]). Cette TSpec porte des informations de trafic utilisables par l'un ou l'autre des services de contrôle de la QS Garanti ou Charge contrôlée.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | réservé | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |0| réservé | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Débit de rempliss. de jeton [r] (nbr 32 bits IEEE virg. flot.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Taille rempliss. de jetons [b] (nbr 32 bits IEEE virg. flot.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 |Débit données de crête [p] (nbr 32 bits IEEE virgule flottante)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Unité régulée minimum [m] (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Taille de paquet maximum [M] (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – Numéro de version de format de message (0)
(b) – Longueur totale (7 mots en-tête non inclus)
(c) – En-tête de service, service numéro 1 (informations par défaut/globales)
(d) – Longueur des données du service 1, 6 mots en-tête non inclus
(e) – Identifiant de paramètre, paramètre 127 (Token_Bucket_TSpec)
(f) – Fanions de paramètre 127 (aucun n'est établi)
(g) – Longueur du paramètre 127, 5 mots en-tête non inclus
Dans cette TSpec, les paramètres [r] et [b] sont réglés de façon à refléter la vision du trafic généré par l'envoyeur. Le paramètre trafic de crête [p] peut être réglé au taux de crête de génération de trafic de l'envoyeur (si il est connu et contrôlé), le taux de ligne d'interface physique (si il est connu), ou un infini positif (si aucune meilleur valeur n'est disponible). L'infini positif est représenté par un nombre à virgule flottante à précision simple défini par l'IEEE avec un exposant tout de uns (255) et un signe et une mantisse tout de zéros. Le format des nombres à virgule flottante définis par l'IEEE est récapitulé plus en détails dans la [RFC1832].
Le paramètre unité minimum régulée [m] devrait généralement être réglé égal à la taille du plus petit paquet généré par l'application. Cette taille de paquet inclut les données d'application et tous les en-têtes de protocole au niveau IP ou au-dessus (IP, TCP, UDP, RTP, etc.). La taille donnée n'inclut aucun en-tête de niveau couche de liaison, parce que ces en-têtes vont changer alors que le paquet traverse différentes portions de l'inter réseau.
Le paramètre [m] est utilisé par les nœuds au sein du réseau pour calculer la redondance de bande passante maximum nécessaire pour porter les paquets d'un flux sur la technologie de couche liaison particulière, sur la base du rapport de [m] à la taille de l'en-tête de couche liaison. Cela permet qu'une quantité correcte de bande passante soit allouée au flux à chaque point du réseau. Noter que de plus petites valeurs de ce paramètre conduisent à une augmentation de l'estimation de la redondance et donc à l'augmentation de la probabilité de rejet d'une demande de réservation par le nœud. Dans certains cas, une application qui transmet un faible pourcentage de très petits paquets peut donc choisir de régler cette valeur de [m] supérieure à la taille réelle minimum de paquet transmis. Cela va augmenter la probabilité de réussite de la réservation, aux dépends de la régulation des paquets de taille inférieure à [m] comme si leur taille était [m].
Noter qu'une valeur [m] de zéro est illégale. Une valeur de zéro indiquerait qu'aucune donnée, ou en-tête IP, n'est présente, et donnerait une quantité infinie de redondance de couche liaison.
Le paramètre taille maximum de paquet [M] devrait être réglés à la taille du plus gros paquet que l'application peut souhaiter générer, comme décrit au paragraphe 2.3.2. Cette valeur doit, par définition, être égale ou supérieure à la valeur de [m].
3.2 Objet RSVP FLOWSPEC
L'objet RSVP FLOWSPEC porte les informations nécessaires pour faire des demandes de réservation du ou des receveurs sur le réseau. Il comporte l'indication du service de contrôle de la QS qui est demandé, et les paramètres nécessaires pour ce service.
Le service de contrôle de la QS demandé est indiqué par le numéro de service dans l'en-tête par service de la FLOWSPEC.
Le format d'un objet RSVP FLOWSPEC généré par un receveur qui demande le service à charge contrôlé est indiqué ci-dessous. Chacun des champs de la TSpec est représenté en utilisant la représentation concrète préférée spécifiée dans la section "Informations d'invocation " de la [RFC2211]. La valeur de 5 dans l'en-tête par service (champ (c) ci-dessous) indique que le service de charge contrôlée est demandé.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | réservé | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 5 (c) |0| réservé | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Débit de rempl. de jeton [r] (nbr 32 bits IEEE à virg.flott.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Taille de rempl. de jeton [b] (nbr 32 bits IEEE à virg. flot.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Débit de crête de données [p] (nbr 32 bits IEEE à virg. flot.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Unité régulée minimum [m] (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Taille maximum de paquet [M] (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – Numéro de version de format de message (0)
(b) – Longueur totale (7 mots en-tête non inclus)
(c) – En-tête de service, numéro de service 5 (Charge contrôlée)
(d) - Longueur des données de charge contrôlée , 6 mots non inclus l'en-tête par service
(e) – Identifiant de paramètre, paramètre 127 (TSpec de remplissage de jetons)
(f) – Fanions de paramètre 127 (aucun n'est établi)
(g) – Longueur de paramètre 127, 5 mots non inclus l'en-tête par service
Dans cet objet, les paramètres de TSpec [r], [b], et [p] sont réglés pour refléter les paramètres de trafic de la réservation désirée par le receveur (la TSpec de réservation). La signification de ces champs est exposée en détail dans la [RFC2211]. Noter que si le terme [p] est plus petit que le terme [r] la demande n'a aucun sens.
Le paramètre Taille maximum de paquet [M] devrait être réglé à la valeur de la plus petite MTU de chemin, que le receveur apprend des informations contenues dans les objets RSVP ADSPEC qui arrivent. Autrement, si l'application receveuse a une connaissance incorporée de la taille maximum de paquet utilisée dans la session RSVP, et si cette valeur est plus petite que la plus petite MTU de chemin, [M] peut être réglé à cette valeur. Noter que demander une valeur de [M] supérieurs à ce que les modules de service le long du chemin peuvent accepter va causer l'échec de la réservation. Voir au paragraphe 2.3.2 des précisions sur la valeur de la MTU.
La valeur de [m] peut être choisie de plusieurs façons. Rappelons que lorsque une réservation de ressource est installée à chaque nœud intermédiaire, la valeur utilisée pour [m] est la plus petite des demandes du receveur et des valeurs dans chaque SENDER_TSPEC de l'envoyeur.
Si l'application a une taille minimum de paquet fixe connue, cette valeur devrait alors être utilisée pour [m]. C'est le cas le plus souhaitable.
Pour une réservation de style partagé, le receveur peut choisir entre deux options, soit prendre un point intermédiaire entre elles.
- Si le receveur choisit une grande valeur pour [m], la réservation va alors allouer moins de redondance pour les en-têtes de niveau liaison. Cependant, si un nouvel envoyeur avec une SENDER_TSPEC [m] plus petite se joint à la session ultérieurement, une réservation déjà installée peut échouer à ce moment.
- Si le receveur choisit une valeur de [m] égale à la plus petite valeur qui pourrait être utilisée par un envoyeur, la réservation sera alors forcée d'allouer plus de redondance pour les en-têtes de niveau liaison. Cependant, elle n'échouera pas ultérieurement si un nouvel envoyeur avec une plus petite SENDER_TSPEC [m] rejoint la session.
Pour une réservation de style FF, si aucune valeur spécifique de l'application n'est connue, le receveur devrait simplement utiliser la valeur de [m] arrivant dans chaque SENDER_TSPEC d'envoyeur pour sa demande de réservation à cet envoyeur.
Le format d'un objet RSVP FLOWSPEC généré chez un receveur qui demande le service garanti est montré ci-dessous. L'objet flowspec utilisé pour demander le service garanti porte une TSpec et une RSpec qui spécifient les paramètres de trafic du flux désiré par le receveur.
Chacun des champs TSpec et RSpec est représenté en utilisant la représentation concrète préférée spécifiée au paragraphe "Informations d'invocation" de la [RFC2212]. La valeur de 2 pour l'identifiant d'en-tête de service (champ (c) dans la figure ci-dessous) indique que c'est le service garanti qui est demandé.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Non utilisé | 10 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 2 (c) |0| réservé | 9 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Débit de rempl. de jeton [r] (nbr 32 bits IEEE à virg.flott.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Taille de rempl. de jeton [b] (nbr 32 bits IEEE à virg. flot.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Débit de crête de données [p] (nbr 32 bits IEEE à virg. flot.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Unité régulée minimum [m] (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Taille maximum de paquet [M] (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 130 (h) | 0 (i) | 2 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Débit [R] (nombre à virgule flottante de 32 bits de l'IEEE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Terme de surlongueur [S] (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – Numéro de version de format de message (0)
(b) – Longueur totale (9 mots en-tête non inclus)
(c) – En-tête de service, numéro de service 2 (Garanti)
(d) – Longueur des données par service , 9 mots en-tête par service non inclus
(e) – Identifiant de paramètre, paramètre 127 (TSpec de remplissage de jetons)
(f) – Fanions de paramètre 127 (aucun n'est établi)
(g) – Longueur de paramètre 127, 5 mots non inclus l'en-tête de paramètre
(h) – Identifiant de paramètre, paramètre 130 (RSpec de service garanti)
(i) – Fanions de paramètre 130 (aucun n'est établi)
(j) – Longueur de paramètre 130, 2 mots non inclus l'en-tête de paramètre
Dans cet objet, les paramètres de TSpec [r], [b], et [p] sont réglés de façon à refléter les paramètres de trafic de la réservation désirée par le receveur (la TSpec de réservation). La signification de ces champs est pleinement exposée dans la [RFC2212]. Noter que cela n'a pas de sens de régler le terme [p] plus petit que le terme [r].
Les termes [R] et [S] de la Pspec sont choisis de façon à obtenir la bande passante désirée et les garanties de délai. Ce choix est décrit dans la [RFC2212].
Les paramètres [m] et [M] sont réglés identiques à ceux de la FLOWSPEC du service de charge contrôlée, décrit au paragraphe précédent.
3.3 Objet RSVP ADSPEC
Un objet RSVP ADSPEC est construit à partir des fragments de données apportés par chaque service qui peut être utilisé par l'application. L'ADSPEC commence par un en-tête global de message, suivi par un fragment pour les paramètres généraux par défaut, suivi par les fragments pour chaque service de contrôle de la QS qui peut être choisi par les applications receveuses. La taille de l'ADSPEC varie selon le nombre et la taille des fragments de données par service présents et la présence de paramètres généraux spécifiés (qui sont décrits au paragraphe 3.3.5).
L'absence complète d'un fragment de données pour un service particulier signifie que l'application envoyeuse ne sait pas ou ne se soucie pas du service, et c'est un signal aux nœuds intermédiaires de ne pas ajouter ou mettre à jour les informations sur ce service dans l'ADSPEC. C'est aussi un signal aux applications receveuses qu'elles ne devraient pas choisir ce service lorsqu'elles font leurs réservations.
Chaque fragment présent est identifié par un en-tête de données par service. Chaque en-tête contient un champ qui identifie le service, un bit de coupure, et un champ de longueur.
Le champ Longueur permet aux informations de l'ADSPEC pour un service d'être sautées par un éléments de réseau qui ne les reconnaît pas ou ne met pas le service en œuvre. Lorsque un élément fait cela, il établit le bit de coupure, indiquant que les données ADSPEC du service n'ont pas été mises à jour au dernier bond. Noter que le bit de coupure d'un service peut être établi sans que par ailleurs le service soit pris en charge d'aucune façon. Dans tous les cas, un élément de réseau qui rencontre un en-tête de données par service qu'il ne comprend pas établit simplement le bit 23 pour rapporter que le service n'est pas pris en charge, puis saute le reste du fragment.
Les fragments de données doivent toujours apparaître dans l'ADSPEC dans l'ordre du numéro de service. En particulier, le fragment de paramètres généraux par défaut (numéro de service 1) vient toujours en premier.
Au sein d'un fragment de données, les données spécifiques du service doivent toujours venir en premier, suivies par tous paramètres généraux qui ne sont pas par défaut qui pourraient être présents, ordonnés par numéro de paramètre. La taille et la structure des données spécifiques du service sont fixées par la définition du service, et n'exigent pas d'analyse au démarrage. Le reste du fragment, qui porte les paramètres généraux qui ne sont pas par défaut, varie en taille et en structure selon les paramètres, s'il en est, qui sont présents. Cette partie du fragment doit être analysée en examinant les en-têtes par paramètre.
Comme la taille globale de chaque fragment de données est variable, il est toujours nécessaire d'examiner le champ Longueur pour trouver la fin du fragment, plutôt que de supposer une structure de taille fixe.
Le format de base de l'ADSPEC est indiqué ci-dessous. L'en-tête de message et les fragments de paramètres généraux par défaut sont aussi présents. Les fragments pour le service garanti ou la charge contrôlée peuvent être omis si le service n'est pas utilisé par la session RSVP. Des fragments de données supplémentaires seront ajoutés si de nouveaux services sont définis.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (a) | réservé | Longueur de message - 1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Fragment de paramètres généraux par défaut (Service 1) (c) |
| (toujours présent) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Fragment service garanti (Service 2) (d) |
| (présent si l'application peut utiliser le service garanti) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Fragment de service Charge contrôlée (Service 5) (e) |
|(présent si l'appli. peut utiliser le service Charge contrôlée)|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – Numéro de version de format de message (0)
(b) – Longueur globale du message mot d'en-tête non inclus
(c, d, e) – Fragments de données
Toutes les ADSPEC RSVP portent les paramètres de caractérisation générale définis dans la [RFC2215]. Les valeurs pour les paramètres généraux globaux ou par défaut (valeurs qui s'appliquent à tous les services ou au chemin lui-même) sont portées dans le fragment de données par service pour le service numéro 1, comme montré sur la figure ci-dessus. Ce fragment est toujours présent, et toujours le premier du message.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 1 (c) |x| réservé | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 4 (e) | (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | compte de bond IS (entier non signé de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 |Estim. bande passante du chemin (nbr 32 bits virg. flot. IEEE )|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Latence minimum du chemin (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | MTU composée (entier non signé de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(c) – En-tête par service, service numéro 1 (paramètres généraux par défaut)
(d) – Bit de coupure global ([RFC2215], paramètre 2) (marqué x) et longueur du bloc de données des paramètres généraux.
(e) – Identifiant de paramètre, paramètre 4 (paramètre nombre de bonds IS de la [RFC2215])
(f) – Octet fanion de paramètre 4
(g) – Longueur du paramètre 4, 1 mot en-tête non inclus
(h) – Identifiant de paramètre, paramètre 6 (paramètre Bande passante du chemin de la [RFC2215])
(i) – Octet fanion de paramètre 6
(j) – Longueur du paramètre 6, 1 mot en-tête non inclus
(k) – Identifiant de paramètre, paramètre 8 (latence minimum du chemin de la [RFC2215])
(l) – Octet fanion de paramètre 8
(m) – Longueur du paramètre 8, 1 mot en-tête non inclus
(n) – Identifiant de paramètre, paramètre 10 (MTU composée du chemin de la [RFC 2215])
(o) – Octet fanion de paramètre 10
(p) – Longueur du paramètre 10, 1 mot en-tête non inclus
Les règles de composition des paramètres généraux figurent dans la [RFC2215].
Dans le fragment ci-dessus, le bit de coupure général (bit 23 du mot 1, marqué d'un (x) sur la figure) est utilisé pour indiquer l'existence d'un élément de réseau qui ne prend pas en charge les services de contrôle de la QS quelque part dans le chemin des données. Ce bit est à zéro à la création de l'ADSPEC, et mis à un si un élément de réseau qui ne prend pas en charge RSVP ou les services intégrés est rencontré. Une ADSPEC qui arrive chez un receveur avec ce bit établi indique que tous les autres paramètres dans l'ADSPEC peuvent être invalides, car tous les éléments de réseau le long du chemin ne prennent pas en charge la mise à jour de l'ADSPEC.
Les paramètres généraux sont mis à jour à chaque nœud de réseau qui prend en charge RSVP :
- Lorsque une ADSPEC de message PATH rencontre un élément de réseau qui met en œuvre les services intégrés, la portion de l'ADSPEC associée au service numéro 1 est passée au module qui met en œuvre les paramètres généraux. Ce module met à jour les paramètres généraux globaux.
- Lorsque une ADSPEC de message PATH rencontre un élément de réseau qui ne met pas en œuvre RSVP ou les services intégrés, le bit de coupure doit être établi dans l'en-tête de service de paramètres généraux. En pratique, ce bit sera établi habituellement par un autre élément de réseau qui prend en charge RSVP, mais est averti du trou dans la couverture des services intégrés.
- Dans l'un et l'autre cas, l'ADSPEC est repassée à RSVP pour livraison au prochain bond le long du chemin.
Le service garanti utilise l'ADSPEC RSVP pour porter les données nécessaires au calcul des termes C et D passés du réseau à l'application. La taille minimum d'un fragment de données de service non vide est de 8 mots de 32 bits. Le fragment ADSPEC pour le service garanti a le format suivant :
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |x| réservé | N-1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 133 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 |Valeur composée de bout en bout pour C [Ctot] (entier 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 134 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 |Valeur composée de bout en bout pour D [Dtot] (entier 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 135 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 |Point composé C depuis dernier reformat [Csum] (entier 32 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 136 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 |Point composé D depuis dernier reformat [Dsum] (entier 32 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 |En-têtes/valeurs de param. généraux specif. de svce, si présent|
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – En-tête par service, service numéro 2 (Garanti)
(b) – Bit de coupure et longueur des données par service en mots de 32 bits, mot d'en-tête non inclus.
(c) – Identifiant de paramètre, paramètre 133 (Ctot composé)
(d) – Octet de fanion de paramètre 133
(e) – Longueur du paramètre 133, 1 mot d'en-tête non inclus
(f) – Identifiant de paramètre, paramètre 134 (Dtot composé)
(g) – Octet de fanion de paramètre 134
(h) – Longueur du paramètre 134, 1 mot d'en-tête non inclus
(i) – Identifiant de paramètre, paramètre 135 (Csum composée).
(j) – Octet de fanion de paramètre 135
(k) – Longueur du paramètre 135, 1 mot d'en-tête non inclus
(l) – Identifiant de paramètre, paramètre 136 (Dsum composée).
(m) – Octet de fanion de paramètre 136
(n) – Longueur du paramètre 136, 1 mot d'en-tête non inclus
Lorsque un nœud qui met effectivement en œuvre le service garanti crée le fragment adspec de service garanti, les valeurs des paramètres sont réglées aux valeurs locales pour chaque paramètre. Lorsque une application ou élément de réseau qui ne met pas lui-même en œuvre le service garanti crée un fragment d'adspec de service garanti, il devrait régler les valeurs de chaque paramètre à zéro, et établir le bit de coupure pour indiquer que le service n'est en fait pas mis en œuvre à ce nœud.
Une application ou hôte RSVP qui crée un fragment adspec de service garanti mais ne met pas lui-même en œuvre le service garanti peut créer un fragment adspec de service garanti tronqué "vide" consistant en seulement un mot d'en-tête:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |1| (b) | 0 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – En-tête par service, service numéro 2 (Garanti)
(b) – Bit de coupure (établi, le service n'est pas mis en œuvre)
(c) – Longueur des données par service en mots de 32 bits, mot d'en-tête non inclus.
Cela peut arriver si l'application ou hôte d'envoi qui ne fait pas lui-même de réservation de ressource, veut quand même que le réseau le fasse. Noter que dans ce cas; le bit de coupure sera toujours établi, car le créateur du fragment adspec ne met pas lui-même en œuvre le service garanti.
Lorsque une ADSPEC de message PATH contenant un en-tête par service pour le service garanti rencontre un élément de réseau qui met en œuvre le service garanti, le fragment de données de service garanti est mis à jour :
- Si le bloc de données dans l'ADSPEC est un bloc vide (seulement un en-tête) le fragment d'en-tête seul doit d'abord être développé en fragment de données complet comme décrit ci-dessus, avec les valeurs initiales de Ctot, Dtot, Csum, et Dsum réglées à zéro. Un fragment vide se reconnaît rapidement en vérifiant un champ de taille de zéro. La valeur du bit de coupure dans l'en-tête est préservée quand les données supplémentaires de service garanti sont ajoutées. La longueur globale du message et la taille du fragment de données du service garanti (champ (b) dans la figure ci-dessus) sont changées pour refléter l'augmentation de longueur du message.
Les valeurs de Ctot, Csum, Dtot, et Dsum dans le fragment de données ADSPEC sont alors composées avec les valeurs locales exportées par l'élément de réseau conformément à la fonction de composition définie dans la [RFC2212].
- Lorsque une ADSPEC de message PATH avec un en-tête de service garanti rencontre un élément de réseau qui prend en charge mais ne met pas en œuvre le service garanti, l'élément de réseau établit le bit de coupure dans l'en-tête de service garanti.
- Les nouvelles valeurs sont placées dans les champs corrects de l'ADSPEC, et celle-ci est repassée à RSVP pour livraison au prochain bond sur le chemin.
Lorsque une ADSPEC de message PATH contenant un fragment de données de service garanti rencontre un élément de réseau qui prend en charge RSVP mais ne met pas en œuvre le service garanti, l'élément de réseau établit le bit de coupure dans l'en-tête de service garanti.
Lorsque une ADSPEC de message PATH sans en-tête de service garanti rencontre un élément de réseau qui met en œuvre le service garanti, le module de service garanti de l'élément de réseau laisse l'ADSPEC inchangée. L'absence d'en-tête de service garanti par service dans l'ADSPEC indique que l'application ne se soucie pas du service garanti.
À la différence du service garanti, le service de charge contrôlée n'exige pas de données d'ADSPEC supplémentaires pour fonctionner correctement. Les seules données d'ADSPEC spécifiques du service de charge contrôlée sont le bit de coupure de charge contrôlée. Le bloc de données usuel du service de charge contrôlée ne contient donc pas d'informations supplémentaires. La taille minimum du fragment de données du service de charge contrôlée est un mot de 32 bits.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | N-1 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | En-têtes/valeurs de param général spécif du serv., si présent |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – En-tête par service, service numéro 5 (charge contrôlée)
(b) – Bit de coupure
(c) – Longueur des données par service en mots de 32 bits, mot d'en-tête non inclus.
La portion charge contrôlée de l'ADSPEC est traitée conformément aux règles suivantes :
- Lorsque une ADSPEC de message PATH avec un en-tête de service de charge contrôlée rencontre un élément de réseau qui met en œuvre un service de charge contrôlée, l'élément de réseau ne fait aucun changement à l'en-tête de service.
- Lorsque une ADSPEC de message PATH avec un en-tête de service de charge contrôlée rencontre un élément de réseau qui prend en charge RSVP mais ne met pas en œuvre le service de charge contrôlée, l'élément de réseau établit le bit de coupure dans l'en-tête de service de charge contrôlée.
- Dans l'un et l'autre cas, l'ADSPEC est repassée à RSVP pour livraison au prochain bond sur le chemin.
Dans certains cas, les valeurs par défaut pour les paramètres généraux ne sont pas correctes pour un service particulier. Par exemple, une mise en œuvre de service garanti peut n'accepter les paquets qu'avec une taille maximum inférieure à celle de la MTU de liaison, ou que le pourcentage de bande passante de liaison sortante rendu disponible pour le service de charge contrôlée à un élément de réseau puisse être administrativement limité à un montant inférieur à la bande passante globale.
Dans ces cas, une valeur spécifique du service, ainsi que la valeur par défaut, est rapportée au receveur de l'ADSPEC. Les informations spécifiques du service qui outrepassent les informations générales sont portées par un paramètre de même nom que le paramètre général, placé au sein du fragment de données du service de contrôle de la QS auquel il s'applique. Ces valeurs spécifiques du service sont appelées des paramètres d'outrepassement ou des paramètres généraux spécifiques du service.
Par exemple, le fragment suivant d'ADSPEC de charge contrôlée porte des informations qui outrepassent l'estimation global de bande passante du chemin avec une valeur différente :
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | 2 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (d) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 |Estim. de Bde pass. pour service CC (Nbr 32 b à virg. fl. IEEE)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) – En-tête par service, service numéro 5 (charge contrôlée)
(b) – Bit de coupure
(c) – Longueur des données par service, deux mots en-tête non inclus
(c) – Identifiant de paramètre, paramètre 6 (paramètre général AVAILABLE_PATH_BANDWIDTH de la [RFC2215])
(d) – Fanions de paramètre 6 (aucun n'est établi)
(e) – Longueur de paramètre 6, un mot d'en-tête non inclus
La présence de paramètres d'outrepassement dans un fragment de données peut être détectée rapidement par l'examen du champ Longueur du fragment, qui va être plus grand que la longueur "standard" pour le fragment. Les paramètres spécifiques d'outrepassement peuvent facilement être identifiés pas l'examen des en-têtes de paramètre, parce qu'ils ont les numéros de paramètre provenant de la portion générale de paramètre dans l'espace numérique (1-127), mais se trouvent dans les blocs de données spécifiques de service (ceux dont les numéros de service sont entre 2 et 254 dans le champ d'en-tête par service).
La présence de paramètres d'outrepassement dans un fragment de données est facultative. Une paire en-tête/valeur de paramètre n'est ajoutée que lorsque une application ou service de contrôle de la QS particulier souhaite outrepasser la valeur globale d'un paramètre général avec une valeur spécifique d'un service.
Comme avec les options IP, c'est seulement l'utilisation des ces paramètres d'outrepassement qui est facultative. Toutes les mises en œuvre doivent être prêtes à recevoir et traiter les paramètres d'outrepassement.
Les principes de base pour le traitement des paramètre d'outrepassement sont d'utiliser la valeur spécifique (locale ou adspec) si elle existe, et d'utiliser autrement la valeur par défaut. Si un nœud local exporte une valeur d'outrepassement pour un paramètre général, mais qu'il n'y a pas de valeur d'outrepassement da,s l'adspec arrivante, le nœud local l'ajoute. Le fragment de pseudo-code suivant donne des précisions.
/* Règles de traitement de paramètre Adspec *
<on a une ADSPEC qui arrive de RSVP>
pour ( <chaque service numéro N avec un fragment dans l'ADSPEC> ) {
si ( <le nœud local ne prend pas en charge le service> ) {
<établir le bit de coupure dans l'en-tête de service>
} autrement {
pour ( <chaque paramètre dans le fragment de données pour le service N> ) {
si ( < le service local N fournit une valeur pour le paramètre> ) {
<composer les valeurs arrivantes et mettre l'adspec à jour>
} autrement {
/* Doit être un paramètre général, ou le service N aurait fourni une valeur.. */
<composer la valeur arrivante avec la valeur locale par défaut et mettre à jour l'adspec>
}
}
pour ( <tout paramètre fourni par la mise en œuvre du service local N mais non trouvé dans l'adspec> ) {
/* Doit être une valeur d'outrepassement pour un paramètre général, ou l'adspec aurait contenu une valeur.. */
<composer la valeur d'outrepassement locale avec la valeur arrivante par défaut (d'après le fragment de données de service 1) et ajouter le paramètre au fragment de service N de l'adspec dans l'ordre des numéros de paramètre>
}
}
}
<repasser l'ADSPEC mise à jour à RSVP>
En pratique, les deux boucles "pour" peuvent être combinées. Comme les paramètres d'outrepassement au sein d'un fragment de service sont transmis dans l'ordre numérique, il est possible de déterminer si un paramètre est présent sans examiner le fragment entier. Aussi, comme les fragments de données sont ordonnés par numéro de service, les valeurs par défaut pour les paramètres généraux vont toujours être lues avant qu'il soit nécessaire de mettre à jour les valeurs locales d'outrepassement dans la seconde boucle "pour".
La figure ci-dessous montre l'adspec complète pour une application qui peut utiliser l'un et l'autre des services à charge contrôlée ou garanti. Dans l'exemple, les fragments de données sont présents pour les paramètres généraux des services garanti et charge contrôlée. Tous les fragments sont de taille standard, et aucun paramètre d'outrepassement n'est présent.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Non utilisé | 19 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| réservé (d) | 8 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | extension zéro de ... compte de bond IS (16 bits non signé) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Estim. de bande passante (nbr à virg. flot. IEEE de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Latence minimum de chemin (entier de 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (o) | (p) | 1 (q) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | extension zéro de .. MTU composée (16 bits non signé) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 2 (r) |x| réservé (s) | 8 (t) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 133 (u) | (v) | 1 (w) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13 | Valeur de bout en bout composée pour C [Ctot] (entier 32 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14 | 134 (x) | (y) | 1 (z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15 | Valeur de bout en bout composée pour D [Dtot] (entier 32 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 135 (aa | (bb | 1 (cc) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 |Point composé C depuis dernier reformat.[Csum] (entier 32 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18 | 136 (dd) | (ee) | 1 (ff) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19 |Point composé D depuis dernier reformat [Dsum] (entier 32 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 5 (gg | x 0 (hh) | 0 (ii) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mot 1 : En-tête de message:
(a) – En-tête de message et numéro de version
(b) – Longueur de message - 19 mots en-tête non inclus
Mots 2 à 7 : Paramètres de caractérisation généraux par défaut
(c) – En-tête par service, service numéro 1 (Paramètres généraux par défaut)
(d) – Bit de coupure global (paramètre général NON_IS_HOP 2) (marqué x)
(e) – Longueur du bloc de données des paramètres généraux (8 mots)
(f) – Identifiant de paramètre, paramètre 4 (paramètre général NUMBER_OF_IS_HOPS)
(g) – Octet de fanion de paramètre 4
(h) – Longueur du paramètre 4, 1 mot en-tête non inclus
(i) – Identifiant de paramètre, paramètre 6 (paramètre général AVAILABLE_PATH_BANDWIDTH)
(j) – Octet de fanion de paramètre 6
(k) – Longueur du paramètre 6, 1 mot en-tête non inclus
(l) – Identifiant de paramètre, paramètre 8 (paramètre général MINIMUM_PATH_LATENCY)
(m) – Octet de fanion de paramètre 8
(n) – Longueur du paramètre 8, 1 mot en-tête non inclus
(o) – Identifiant de paramètre, paramètre 10 (paramètre général PATH_MTU)
(p) – Octet de fanion de paramètre 10
(q) – Longueur du paramètre 10, 1 mot en-tête non inclus
Mots 11-19 : Paramètres du service garanti
(r) – En-tête par service, service numéro 2 (Garanti)
(s) – Bit de coupure
(t) – Longueur des données par service , 8 mots en-tête non inclus
(u) – Identifiant de paramètre, paramètre 133 (Ctot composé)
(v) – Octet de fanion composé Ctot
(w) – Longueur de Ctot composé, 1 mot en-tête non inclus
(x) – Identifiant de paramètre, paramètre 134 (Dtot composé)
(y) – Octet de fanion composé Dtot
(z) – Longueur de Dtot composé, 1 mot en-tête non inclus
(aa)– Identifiant de paramètre, paramètre 135 (Csum composée).
(bb)– Octet de fanion Csum composée
(cc)– Longueur de Csum composée, 1 mot en-tête non inclus
(dd)– Identifiant de paramètre, paramètre 136 (Dsum composée).
(ee)– Octet de fanion Dsum composée
(ff)– Longueur de Dsum composée, 1 mot en-tête non inclus
Mot 20 : Paramètres de charge contrôlée
(gg – En-tête par service, service numéro 5 (charge contrôlée)
(hh)–Bit de coupure
(ii)– Longueur de données de charge contrôlée, 0 mot en-tête non inclus
4. Considérations pour la sécurité
Les règles de format de message et d'usage décrites dans la présente note ne soulèvent pas de problème de sécurité. L'usage global de ces règles pour mettre en œuvre plusieurs qualités de service utilisant RSVP et les modules de programmation des services intégrés introduit une nouvelle exigence de sécurité ; la nécessité de contrôler et d'authentifier l'accès aux qualités de service améliorées. Cette exigence est exposée plus en détails dans les [RFC2205], [RFC2212], et [RFC2211]. La [RFC2747] décrit le mécanisme utilisé pour protéger l'intégrité des messages RSVP qui portent les informations décrites ici.
Appendice 1 Règles de construction des messages
Cette section donne les règles utilisées pour générer les formats d'objet de la Section 3. C'est un format général du réseau pour le codage des objets de données des services intégrés au sein des messages d'établissement et de gestion du protocole. Le format a une structure à trois niveaux :
- Un en-tête global de message porte un numéro de version et la longueur de message. Fournir cet en-tête dans un format standard permet à la même bibliothèque de codes de traiter les objets de données portés par plusieurs protocoles d'établissement.
- Le fragments par service portent les informations sur un service de contrôle de la QS spécifique, tels que le service garanti de la [RFC2212] ou de charge contrôlée de la [RFC2211]. Chaque fragment par service porte un ou plusieurs paramètres. L'ensemble des paramètres présents dans un fragment est déterminé par les besoins du protocole utilisé. Des exemples sont donnés dans la Section 2.
- Les paramètres sont les données réelles utilisées pour contrôler ou surveiller un service. Un paramètre peut être une seule quantité telle qu'un entier, ou une structure de données composite telle qu'une TSpec. Les paramètres spécifiques d'un service sont définis par la spécification de service. Le paramètres généraux disponibles, avec les définitions partagées par de nombreux services, figurent dans la [RFC2215].
A.1 En-tête de message
L'en-tête de message de 32 bits spécifie le numéro de version du format de message et la longueur totale du message. Le message global doit être aligné sur une limite de 32 bits au sein d'un paquet de données de protocole de transport. La longueur du message est mesurée en mots de 32 bits *non inclus le mot qui contient l'en-tête*. Ceci diminue la probabilité d'un mot éliminé accidentellement résultant en une boucle infinie dans l'analyseur de message.
L'en-tête de message est représenté en gabarit binaire de 32 bits comme indiqué ci-dessous qui est codé comme un entier XDR non signé. Le codage comme entier XDR non signé est équivalent à convertir le champ binaire du format natif de la machine en ordre gros boutien des octets du réseau.
En-tête de message
MSB LSB
31 28 27 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Non utilisé | LONGUEUR GLOBALE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V - Version du format de message ; actuellement 0
LONGUEUR GLOBALE - Longueur du message en mots de 32 bits, en-tête non inclus
A.2 En-tête de données par service
L'en-tête de message est suivi par un ou plusieurs blocs de données spécifiques du service, contenant chacun les données associées à un service de contrôle de la QS spécifique. Chaque bloc de données spécifique du service commence par un en-tête d'identification. Cet en-tête de 32 bits contient le numéro du service, un fanion d'un bit (le "bit de coupure", parce qu'il indique une coupure dans le chemin de contrôle de la QS) et un champ de longueur. Le champ de longueur spécifie le nombre de mots de 32 bits utilisés pour contenir les données spécifiques de ce service comme un compte de mots de 32 bits *non inclus le mot contenant l'en-tête*.
Le bit de coupure établi indique que le service spécifié par les en-têtes n'était pas pris en charge ou non reconnu à certains points du chemin du message à travers le réseau. Ce bit correspond au paramètre général NON_IS_HOP défini dans la [RFC2215]. Il est mis à zéro quand un message est généré, et établi chaque fois que le message passe à travers un élément qui ne reconnaît pas le numéro de service dans l'en-tête par service.
L'en-tête de données par service est représenté par un gabarit binaire de 32 bits indiqué ci-dessous puis codé comme un entier XDR non signé.
En-tête de données par service
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SVC_NUMÉRO |B| Réservé | SVC_LONGUEUR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SVC_NUMÉRO - Numéro d'identifiant de service (défini dans la spécification du service).
B - Bit de coupure - service non pris en charge/coupure dans le chemin.
SVC_LONGUEUR - Longueur des données spécifiques du service en mots de 32 bits, en-tête non inclus.
A.3 En-tête de paramètre
L'en-tête par service est suivi par un ou plusieurs blocs de paramètres de service, identifiés chacun par un en-tête de paramètre. Cet en-tête contient l'identifiant de paramètre (numéro de paramètre), la longueur des données portant la valeur du paramètre, et un champ de fanions. Le ou les champs de données des paramètres suivent. Le numéro de paramètre, ainsi que la signification et le format des mots de données suivant l'en-tête sont donnés par la spécification qui définit le paramètre.
L'en-tête de paramètre est représenté par un gabarit binaire de 32 bits comme indiqué ci-dessous puis codé comme un entier XDR non signé.
En-tête de paramètre
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PARAM_NUM |I FANIONS | PARAM_LONGUEUR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PARAM_NUM - Numéro de paramètre (défini dans la spécification du service)
FANIONS - Fanions pour le paramètre
PARAM_LONGUEUR - Longueur des données pour le paramètre en mots de 32 bits, non inclus le mot d'en-tête.
Les fanions suivants sont actuellement définis dans le champ FANIONS :
I (bit 23) - INVALIDE
Ce fanion indique que la valeur du paramètre n'a pas été traitée correctement chez un ou plusieurs éléments de réseau le long d'un chemin de données. Il est destiné à être utilisé dans un possible schéma de composition de service futur.
Les autres bits dans le champ FANIONS de l'en-tête de paramètre sont actuellement réservés, et devraient être mis à zéro.
A.4 Données de paramètre
Après l'en-tête de paramètre sont les données réelles représentant la valeur du paramètre. Les valeurs de paramètre sont codées en un ou plusieurs mots de 32 bits en utilisant la représentation XDR de données externes décrite dans la [RFC1832], et les mots résultants sont placés dans le message.
Le document définissant un paramètre devrait fournir une description XDR des champs de données du paramètre. Si il ne le fait pas, une description devrait être fournie dans cette note.
Références
(Les liens sur les numéros pointent sur le texte original, ceux des titres sur la traduction française)
[RFC1832] R. Srinivasan, "XDR : norme de représentation des données externes", août 1995. (Obsolète, voirRFC4506) (D.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.)
[RFC2211] J. Wroclawski, "Spécification du service d'élément de réseau à charge contrôlée", septembre 1997. (P.S.)
[RFC2212] S. Shenker, C. Partridge, R. Guerin, "Spécification de la qualité de service garantie", septembre 1997. (P.S.)
[RFC2215] S. Shenker, J. Wroclawski, "Paramètres généraux de caractérisation pour éléments de réseau à intégration de service", septembre 1997. (P.S.)
[RFC2216] S. Shenker, J. Wroclawski, "Modèle de spécification de services d'élément de réseau", septembre 1997. (Information)
[RFC2747] F. Baker, B. Lindell, M. Talwar, "Authentification cryptographique RSVP", janvier 2000. (MàJ parRFC3097) (P.S.)
Adresse de l'auteur
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
USA
téléphone : 617-253-7885
fax : 617-253-2673 (FAX)
mél : jtw@lcs.mit.edu