Groupe de travail Réseau	F. Baker, Cisco Systems	
Request for Comments : 3175	C. Iturralde, Cisco Systems	
Catégorie : En cours de normalisation	F. Le Faucheur, Cisco Systems	
	B. Davie, Cisco Systems	
Traduction Claude Brière de L'Isle	septembre 2001	

Agrégation de RSVP pour réservations IPv4 et IPv6

Statut du présent Mémo
La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est soumise à aucune restriction.

Déclaration de Copyright
Copyright (C) The Internet Society (2001). Tous droits réservés.

Résumé
Le présent document décrit l'utilisation d'une seule réservation RSVP (protocole de réservation de ressource) pour agréger d'autres réservations RSVP à travers une région d'acheminement de transit, d'une façon conceptuellement similaire à l'utilisation des chemins virtuels dans un réseau ATM (mode de transfert asynchrone). Il propose une création dynamique des réservations agrégées, une classification du trafic pour lequel s'applique la réservation agrégée, une détermination de la quantité de bande passante nécessaire pour satisfaire l'exigence, et la récupération de la bande passante lorsque les sous-réservations ne sont plus nécessaires. Il contient aussi des recommandations concernant les algorithmes et politiques pour la prédiction des réservations.

Table des Matières
1.	Introduction
1.1	Position du problème : agrégation de réservations de bout en bout (E2E)
1.2	Solution proposée
1.3	Définitions
1.4	Aspects détaillés de la solution proposée
2.	Éléments de procédure
2.1	Réception du message Path E2E par un routeur d'agrégation
2.2	Traitement du message Path E2E par des routeurs intérieurs
2.3	Réception du message Path E2E par un routeur de désagrégation
2.4	Initiation d'un nouveau message de chemin agrégé par un routeur d'agrégation
2.5	Traitement d'un message de réservation E2E par un routeur désagrégateur
2.6	Initiation d'un nouveau message de réservation agrégée par un routeur de désagrégation
2.7	Traitement de message de réservation agrégé par les routeurs intérieurs
2.8	Traitement de message de réservation E2E par un routeur d'agrégation
2.9	Retrait de réservation E2E
2.10	Retrait de réservation agrégée
2.11	Traitement des données sur un flux E2E réservé par un routeur d'agrégation
2.12	Procédures pour les sessions en diffusion groupée
3.	Éléments de protocole
3.1	RSVP-E2E-IGNORE du protocole IP
3.2	Code d'erreur de chemin
3.3	Objet SESSION
3.4	Objet SENDER_TEMPLATE
3.5	Objet FILTER_SPEC
4.	Politiques et algorithmes de gestion prévisionnelle des blocs de bande passante
5.	Considérations pour la sécurité
6.	Considérations relatives à l'IANA
7.	Remerciements
Appendice 1	Exemple de flux de signalisation pour un premier flux E2E
Appendice 2	Exemple de flux de signalisation pour flux E2E suivants sans redimensionnement de réservation
Appendice 3	Exemple de flux de signalisation pour flux E2E suivant avec redimensionnement de réservation
Références

1.	Introduction

Un problème clé de la conception de RSVP version 1 [RFC2205] est, comme noté dans sa déclaration d'applicabilité, que la faculté d'agrégation de sessions réservées individuellement dans une classe commune lui fait défaut. L'utilisation d'une telle agrégation est recommandée dans [CSZ], et exigée pour le redimensionnement.

Le problème de l'agrégation peut être traité de diverses façons. Par exemple, il peut parfois être suffisant de simplement marquer le trafic réservé avec un message DSCP convenable (par exemple, EF), permettant ainsi l'agrégation de programmation et d'état de classification. Il peut aussi être souhaitable d'installer une ou plusieurs réservations agrégées d'entrée à sortie d'une "région d'agrégation" (définie ci-dessous) où chaque réservation agrégée porte des paquets marqués de façon similaire à partir d'un grand nombre de flux. Ceci fournit un niveau d'assurance élevé que les exigences de bout en bout des flux réservés seront satisfaites, tout en permettant en même temps d'agréger l'état de réservation.

Tout au long du présent document, nous parlons "d'agrégateur" et de "désagrégateur", nous référant aux routeurs qui sont à la bordure d'entrée et de sortie d'une région d'agrégation. Nous décrivons ci-dessous comment exactement un routeur détermine si il devrait jouer le rôle d'agrégateur ou de désagrégateur.

Nous nous réfèrerons aux sessions réservées individuelles (les sessions que nous tentons d'agréger) comme réservations de "bout en bout" (abrégé en "E2E" pour "end-to-end"), et à leurs messages Path/Resv respectifs comme messages E2E Path/Resv. Nous appelons la plus grande réservation (celle qui représente de nombreuses réservations E2E) une réservation "agrégée", et ses messages Path/Resv des messages "Path/Resv agrégés".

1.1	Position du problème : agrégation de réservations de bout en bout (E2E)
Le problème de nombreuses petites réservations a été largement discuté, et peut être résumé dans l'observation que chaque réservation exige une quantité non triviale d'échanges de messages, de calcul et de ressources mémoire dans chaque routeur le long du chemin. Il serait agréable de réduire cela à un niveau plus gérable, là où la charge est la plus lourde et où l'agrégation est possible.

L'agrégation apporte cependant son propre défi. En particulier, elle réduit le niveau d'isolation entre les flux individuels, ce qui implique qu'un flux peut subir des retards du fait des salves d'un autre. La synchronisation des salves provenant de flux différents peut survenir. Cependant, il est évident [CSZ] de suggérer que l'agrégation de flux n'a pas d'effet négatif sur le délai moyen des flux, et conduit en fait à une réduction du délai dans la "queue" de la distribution  du délai (par exemple, le délai du percentile à 99 %) des flux. Ces avantages de l'agrégation compensent dans une certaine mesure la perte d'une isolation stricte.

1.2	Solution proposée
La solution que nous proposons implique l'agrégation de plusieurs réservations de bout en bout qui traversent une "région d'agrégation" et partagent des routeurs d'entrée et sortie communs sur une plus grande réservation de l'entrée à la sortie. Nous définissons une "région d'agrégation" comme un ensemble contigu de systèmes capables d'effectuer l'agrégation RSVP (comme définie ci-dessous) le long de tout chemin possible à travers cet ensemble contigu.

Les interfaces de communication entrent dans deux catégories par rapport à une région d'agrégation ; elles sont "extérieures" à une région d'agrégation, ou elles lui sont "intérieures". Les routeurs qui ont au moins une interface dans la région entrent dans une de trois catégories par rapport à une session RSVP donnée ; ils agrègent, ils désagrègent, ou ils sont entre un agrégateur et un désagrégateur.

L'agrégation dépend de si on est capable de cacher les messages E2E RSVP aux routeurs à capacité RSVP à l'intérieur de la région d'agrégation. À cette fin, le numéro de protocole IP dans les messages Path, PathTear, et ResvConf de la réservation E2E est changé de RSVP (46) à RSVP-E2E-IGNORE (134) en entrant dans la région d'agrégation, et restauré en RSVP au point de désagrégation. Ces messages sont ignorés (aucun état n'est mémorisé et le message est transmis comme un datagramme IP normal) par chaque routeur au sein de la région d'agrégation chaque fois qu'il est transmis à une interface intérieure. Comme le routeur de désagrégation perçoit le bond RSVP précédent sur de tels messages comme étant le routeur agrégateur, Resv et les autres messages n'exigent pas cette modification ; ils sont de toute façon en envoi individuel de bond RSVP en bond RSVP.

Les baquets de jetons (SENDER_TSPEC et FLOWSPEC) de réservations E2E sont ajoutés dans les éléments d'information correspondants dans les messages agrégés Path et Resv. Les messages de chemin agrégé sont envoyés de l'agrégateur aux désagrégateurs en utilisant le numéro de protocole IP normal de RSVP. Les messages Resv agrégés sont renvoyés du désagrégateur à l'agrégateur, établissant donc une réservation agrégée au nom de l'ensemble de flux E2E qui utilisent cet agrégateur et désagrégateur.

Un tel établissement d'un plus petit nombre de réservations agrégées au nom d'un plus grand nombre de réservations E2E donne la réduction correspondante de la quantité d'états à mémoriser et de la quantité de messages de signalisation échangés dans la région d'agrégation.

En utilisant les mécanismes de services différenciés pour le classement et la programmation du trafic pris en charge par les réservations agrégées (plutôt que d'effectuer un classement et une programmation par réservation agrégée) la quantité d'états de classement et de programmation dans la région d'agrégation est encore plus réduite. Elle est non seulement indépendante du nombre de réservations E2E, mais elle est aussi indépendante du nombre de réservations agrégées dans la région d'agrégation. Un ou plusieurs DSCP Diff-Serv sont utilisés pour identifier le trafic couvert par les réservations agrégées et un ou plusieurs PHB Diff-Serv sont utilisés pour offrir le traitement de transmission requis à ce trafic. Il peut y avoir plus d'une réservation agrégée entre la même paire de routeurs, chacune représentant des classes de trafic différentes et chacune utilisant un DSCP et un PHB différent.

1.3	Définitions
On définit une "région d'agrégation" comme un ensemble de routeurs à capacité RSVP pour lesquels les messages RSVP E2E qui arrivent sur une interface extérieure d'un routeur dans l'ensemble vont traverser une ou plusieurs interfaces intérieures (de ce routeur et éventuellement d'autres routeurs de l'ensemble) avant de traverser finalement une interface extérieure.

Un tel message RSVP E2E est dit avoir traversé la région d'agrégation.

On définit le routeur "agrégateur" pour ce flux E2E comme le premier routeur qui traite le message E2E Path lorsque il entre dans la région d'agrégation (c'est à dire, celui qui transmet le message d'une interface extérieure à une interface intérieure).

On définit le routeur "désagrégateur" pour ce flux E2E comme le dernier routeur à traiter le message Path E2E lorsque il quitte la région d'agrégation (c'est à dire, celui qui transmet le message d'une interface intérieure à une interface extérieure).

On définit un routeur "intérieur" pour ce flux E2E comme tout routeur dans la région d'agrégation qui reçoit ce message sur une interface intérieure et le transmet à une autre interface intérieure. Les routeurs intérieurs n'effectuent ni agrégation ni désagrégation pour ce flux.

Noter que par ces définitions un seul routeur avec un mélange d'interfaces intérieures et extérieures peut avoir la capacité d'agir comme agrégateur sur des flux E2E, comme désagrégateur sur d'autres flux E2E, et comme routeur intérieur sur encore d'autres flux.

1.4	Aspects détaillés de la solution proposée
Un certain nombre de questions viennent à l'esprit en considérant ce modèle.

1.4.1	Classification du trafic au sein de la région d'agrégation
Une des raisons pour laquelle RSVP version 1 n'identifiait  pas de moyen pour agréger des sessions était qu'il n'y avait pas un moyen clair de classer les agrégats. Avec le développement de l'architecture de services différenciés, ce problème est au moins partiellement résolu ; le trafic d'une classe particulière peut être marqué avec un DSCP donné et ainsi classé. On prend quelques libertés avec ce modèle.

On suppose que sur chaque liaison sur le chemin, une file d'attente, de couleur WDM, ou un composant de gestion similaire est mis de côté pour tout le trafic agrégé de la même classe, et que de la bande passante en quantité suffisante est rendue disponible pour porter le trafic qui lui a été alloué. Cette bande passante peut être ajustée sur la base de la quantité totale de trafic de réservation agrégé affecté à la même classe.

Il y a de nombreuses options pour savoir exactement quels PHB Diff-serv pourraient être utilisés pour différentes classes de trafic lorsqu'il traverse la région d'agrégation. C'est le problème de la "transposition de service" décrit dans la [RFC2998], et il est applicable à des situations plus larges que celles décrites dans ce document. Des arguments existent pour utiliser EF ou un ou plusieurs PHB AF pour le trafic agrégé. Par exemple, comme la charge contrôlée exige que le trafic non conforme à TSpec (régulé) soit transmis comme trafic au mieux plutôt qu'abandonné, il peut être approprié d'utiliser une classe AF pour la charge contrôlée, utilisant la préférence d'abandon la plus élevée pour les paquets non conformes.

Dans les opérations RSVP conventionnelles (non agrégées), une session est identifiée par une adresse de destination et facultativement un accès de protocole. Comme les données qui appartiennent à une réservation agrégée sont identifiées par un DSCP, la session est définie par l'adresse de destination et le DSCP. Pour les cas où deux DSCP sont utilisés (pour les paquets conformes et pour les paquets non conformes, comme noté plus haut) la session est identifiée par le DSCP des paquets conformes. En général nous allons parler de transposition du trafic agrégé sur un DSCP (même si un second DSCP peut être utilisé pour le trafic non conforme).

Quels que soient le ou les PHB utilisés pour porter les réservations agrégées, il faut faire attention dans un environnement où l'approvisionnement en Diff-Serv et en RSVP agrégé sont utilisés dans le même réseau, pour s'assurer que la charge totale admise pour un seul PHB n'excède pas la capacité de liaison allouée à ce PHB. Une solution pour cela est de réserver un PHB (ou plus) strictement au trafic de réservation agrégée (par exemple, de classe AF1) tout en utilisant d'autres PHB pour le Diff-Serv approvisionné (par exemple, les classes AF2, AF3 et AF4).

À l'intérieur de la région d'agrégation, certains états de réservation RSVP sont conservés par réservation agrégée, alors que les états de classification et de programmation (par exemple, les DSCP utilisés pour classer le trafic) sont conservés sur la base de la classe par réservation agrégée (plutôt que par réservation agrégée). Par exemple, si les réservations de service garanti sont transposées dans le DSCP EF dans toute la région d'agrégation, il peut y avoir une réservation pour chaque paire d'agrégateur/désagrégateur dans chaque routeur, mais seul le DSCP EF a besoin d'être inspecté à chaque interface intérieure, et une seule file d'attente est utilisée pour tout le trafic EF.

1.4.2	Détermination du désagrégateur
La première question est "Comment déterminons nous la paire agrégateur/désagrégateur qui est chargée d'agréger un flux E2E particulier à travers la région d'agrégation ?"

La détermination de l'agrégateur est triviale : nous savons qu'un flux E2E est arrivé à un agrégateur lorsque son message Path arrive chez un routeur sur une interface extérieure et doit être transmis sur une interface intérieure.

La détermination du désagrégateur est plus compliquée. Si un protocole d'acheminement SPF, tel que OSPF ou IS-IS, est utilisé, et si il a été étendu pour annoncer des informations sur les rôles de désagrégation, il peut nous dire l'ensemble de routeurs dans lequel sera choisi le désagrégateur. En principe, si l'agrégateur et le désagrégateur sont dans la même zone, l'identité du désagrégateur pourra alors être déterminée à partir de la base de données d'état de liaison. Cependant, cette approche ne va pas fonctionner dans les environnements multi zones ou pour les protocoles de vecteur de distance.

Une méthode pour la détermination du désagrégateur est la configuration manuelle. Par cette méthode, l'opérateur du réseau va configurer l'agrégateur et le désagrégateur avec les informations nécessaires.

Une autre méthode permet la détermination automatique du désagrégateur et la notification de l'agrégateur correspondant. Lorsque le message Path d'E2E RSVP transite d'une interface intérieure à une interface extérieure, le routeur désagrégateur doit aviser le routeur agrégateur de la corrélation entre lui et le flux. Ceci a la particularité agréable de n'être pas spécifique du protocole d'acheminement. Elle a aussi la propriété de s'ajuster automatiquement aux changements de chemin. Par exemple, si, à cause d'un changement de topologie, un autre désagrégateur est maintenant sur le plus court chemin, cette méthode va automatiquement identifier le nouveau désagrégateur et y passer.

1.4.3	Transposition des réservations E2E en réservations agrégées
Comme exposé ci-dessus, il peut y avoir plusieurs réservations agrégées entre la même paire d'agrégateur/désagrégateur. Les règles pour transposer les réservations E2E en réservations agrégées sont des décisions de politique qui dépendent de l'environnement du réseau et des objectifs de l'administrateur du réseau. Une telle politique sort du domaine d'application de la présente spécification et nous allons simplement supposer que cette politique est définie par l'administrateur du réseau. Nous supposons aussi qu'une telle politique est d'une certaine manière accessible aux agrégateurs/désagrégateurs mais les détails de la façon dont cette politique est rendue accessible aux agrégateurs/désagrégateurs (configuration locale, COPS, LDAP, etc.) sortent du domaine d'application de la présente spécification.

Un exemple de politique très simple serait que toutes les réservations E2E soient transposées en une seule réservation agrégée (c'est-à-dire, un seul DSCP) entre une paire donnée d'agrégateur/désagrégateur.

Un autre exemple de politique, qui tient compte du type de service Int-Serv exigé par le receveur (et signalé dans la Resv E2E), serait quand des réservations E2E de service garanti sont transposées dans un DSCP dans la région d'agrégation et que des réservations E2E de charge contrôlée sont transposées dans un autre DSCP.

Un troisième exemple de politique serait celui où la transposition de réservations E2E en des réservations agrégées prend en compte des objets de politique (telles que des informations d'authentification de l'utilisateur final) qui peuvent être incluses par l'envoyeur dans le chemin E2E et/ou par le receveur dans la Resv E2E.

Sans considération de la politique réelle, une gamme d'options est concevable pour l'endroit où doit être prise la décision de transposer une réservation E2E en une réservation agrégée et comment cette décision est communiquée entre l'agrégateur et le désagrégateur. Tous deux peuvent être supposés prendre indépendamment une telle décision. Cependant, cela exigerait la définition de procédures supplémentaires pour résoudre les incohérences de décisions de transposition (c'est-à-dire, que l'agrégateur et le désagrégateur décident de transposer une réservation E2E sur des réservations agrégées différentes) ou résulterait en de possibles mauvais comportements indétectés dans le cas d'incohérences de décision.

Pour la simplicité et la fiabilité, on alloue entièrement la responsabilité de la décision de transposition au désagrégateur. Le désagrégateur notifie la transposition choisie à l'agrégateur qui suit cette décision. Le désagrégateur a été choisi plutôt que l'agrégateur parce que le désagrégateur est le premier à avoir  accès à toutes les informations requises pour prendre une telle décision (en particulier, la réception de la Resv E2E qui indique le type de service Int-Serv requis et comporte les informations signalées par le receveur). Cela permet des opérations plus rapides comme un établissement ou un réglage de taille d'une réservation agrégée dans un certain nombre de situations résultant en un établissement de réservation E2E plus rapide.

1.4.4	Taille des réservations agrégées
Il existe une gamme d'options pour déterminer la taille de la réservation agrégée, qui présente un compromis entre simplicité et modularité. De façon simpliste, la taille de la réservation agrégée doit être supérieure ou égale à la somme de la bande passante des réservations E2E qu'elle agrège, et sa capacité de salve doit être supérieure ou égale à la somme de leurs capacités de salves. Cependant, si on le suit aveuglément, cela nous conduirait à changer la bande passante de la réservation agrégée chaque fois que change une réservation E2E sous-jacente, ce qui perdrait l'avantage clé de l'agrégation, qui est la réduction du coût du traitement de message dans la région d'agrégation.

On suppose donc qu'il y a une politique, non définie dans la présente spécification (bien que des exemples de politiques soient suggérés avec les caractéristiques nécessaires). Cette politique conserve la quantité de bande passante requise sur une réservation agrégée donnée en tenant compte de la somme des bandes passantes des réservations E2E sous-jacentes, tout en entreprenant de la changer peu fréquemment. Cela peut exiger un certain niveau d'analyse des tendances. Si il y a une probabilité significative que le prochain intervalle de temps de la réservation agrégée en cours soit épuisé, le routeur doit prédire la bande passante nécessaire et la demander. Si le routeur a une quantité significative de bande passante réservée mais a une très faible probabilité de l'utiliser, la politique peut être de prédire la quantité de bande passante requise et de libérer l'excédant.

Cette politique va vraisemblablement bénéficier de l'introduction d'une certaine hystérésis (c'est-à-dire, de s'assurer que la condition de déclenchement pour l'augmentation de taille de réservation agrégée est suffisamment différente de la condition de déclenchement pour la diminution de taille de la réservation agrégée) pour éviter des oscillations dans des conditions stables.

En clair, la définition et le fonctionnement de telles politiques sont autant des questions commerciales que des questions techniques, et sortent du domaine d'application de ce document.

1.4.5	Mise à jour de l'ADSPEC de chemin E2E
Comme décrit ci-dessus, les messages RSVP E2E sont cachés aux routeurs intérieurs au sein de la région d'agrégation. Par conséquent, les ADSPEC des messages Path E2E ne sont pas mis à jour lorsque ils voyagent à travers la région d'agrégation. Donc, le désagrégateur pour un flux est responsable de la mise à jour de l'ADSPEC dans le Path E2E correspondant pour refléter l'impact de la région d'agrégation sur la QS qui peut être réalisée de bout en bout. Le désagrégateur devrait mettre à jour le ADSPEC du Path E2E aussi précisément que possible.

Comme le message Chemin agrégé est traité à l'intérieur de la région d'agrégation, son ADSPEC est mis à jour par les routeurs intérieurs pour refléter l'impact de la région d'agrégation sur la QS qui peut être réalisée au sein de la région intérieure. Par conséquent, le désagrégateur devrait faire usage des informations incluses dans le ADSPEC provenant d'un Chemin agrégé lorsqu'elles sont disponibles. Le désagrégateur peut choisir d'attendre jusqu'à ce que de telles informations soient disponibles avant de transmettre le Chemin E2E afin de mettre à jour de façon précise son ADSPEC.

Pour maximiser les informations rendues disponibles au désagrégateur, chaque fois que l'agrégateur signale un Chemin agrégé, l'agrégateur devrait inclure un ADSPEC avec fragments pour tous les types de service pris en charge dans la région d'agrégation (même si le Chemin agrégé correspond à une Réservation agrégée qui ne prend en charge qu'un sous-ensemble de ces types de service). Fournir ces informations au désagrégateur pour chaque type de service possible facilite une mise à jour précise et à temps de l'ADSPEC E2E par le désagrégateur.

Selon l'environnement et la politique de transposition des réservations E2E en réservations agrégées, pour mettre à jour précisément l'ADSPEC Chemin E2E, le désagrégateur peut par exemple :

-	mettre à jour tous les segments d'ADSPEC Path E2E (Fragment de paramètres généraux par défaut, Fragment de service garanti, Fragment de service de charge contrôlée) sur la base de l'ADSPEC d'un seul Chemin agrégé, ou

-	mettre à jour l'ADSPEC Path E2E en prenant en compte l'ADSPEC provenant de plusieurs messages Chemin agrégé (par exemple, mettre à jour le fragment Paramètres généraux par défaut en utilisant la "pire" valeur pour chaque paramètre à travers tous les ADSPEC de chemins agrégés, mettre à jour le fragment Service garanti en utilisant le fragment Service garanti provenant de l'ADSPEC du chemin agrégé pour la réservation utilisée pour les services garantis).

En prenant en compte les informations contenues dans l'ADSPEC du ou des chemins agrégés comme mentionné ci-dessus, le désagrégateur devrait être capable de mettre à jour de façon précise l'ADSPEC Path E2E dans la plupart des situations.

Cependant, il peut y avoir des situations particulières dans lesquelles la mise à jour de l'ADSPEC Path E2E ne peut pas être faite avec une totale précision par le désagrégateur. Cela va très vraisemblablement se produire lorsque le chemin à travers la région d'agrégation dépend du service demandé dans la Resv E2E, qui n'est pas encore arrivée. Une telle situation pourrait se produire si, par exemple :

-	La politique de transposition de service pour la région d'agrégation est telle que les réservations E2E qui demandent le service garanti sont transposées en un PHB différent de celui de celles qui demandent le service à charge contrôlée.

-	L'acheminement à capacité Diff-Serv est utilisé dans la région d'agrégation, de sorte que les paquets avec des DSCP différents suivent des chemins différents (les envoyant sur des chemins MPLS à commutation d'étiquette différents, par exemple).

Il en résulte que l'ADSPEC pour la réservation agrégée qui prend en charge le service garanti peut différer de l'ADSPEC pour la réservation agrégée qui prend en charge la charge contrôlée.

Supposons que l'envoyeur envoie un Path E2E avec un ADSPEC contenant des segments à la fois pour le service garanti et la charge contrôlée. Alors, au moment de la mise à jour de l'ADSPEC E2E, le désagrégateur ne va pas savoir quel type de service va réellement être demandé par le receveur et ne peut donc pas savoir quel PHB sera utilisé pour transporter ce flux E2E et par suite, ne peut prendre les bonnes valeurs de paramètre pour les mettre en facteur lors de la mise à jour du fragment de paramètres généraux par défaut. Comme mentionné ci-dessus, dans ce cas particulier, une attitude prudente serait de toujours prendre en compte la pire valeur pour chaque paramètre. Sans considérer si l'approche prudente est suivie ou si une approche plus simple, comme de prendre en compte un des deux ADSPEC de chemin agrégé, l'ADSPEC Path E2E sera inapproprié (trop optimiste ou trop pessimiste) pour au moins un type de service réellement demandé par la destination.

Reconnaissant qu'une mise à jour totalement appropriée de l'ADSPEC Path E2E peut n'être pas possible dans toutes les situations, nous recommandons que l'approche prudente soit retenue dans de telles situations (trop pessimiste plutôt que trop optimiste) et que l'ADSPEC Path E2E soit corrigée aussitôt que possible. Dans l'exemple décrit ci-dessus, cela signifierait qu'aussitôt que le désagrégateur reçoit la Resv E2E de la part du receveur, le désagrégateur devrait générer un autre Path E2E avec un ADSPEC mis à jour de façon appropriée sur la base de la connaissance de la réservation agrégée que va réellement porter le flux E2E.

1.4.6	Chemins intra-domaine
RSVP traite directement les changements de chemin, en ce que les réservations suivent les chemins que suivent leurs données. Cela découle de la propriété que les messages Path contiennent la même adresse IP de source et de destination que le flux de données pour lequel une réservation est à établir. Cependant, comme nous faisons maintenant les réservations agrégées en envoyant un message Path d'un routeur agrégateur à un routeur désagrégateur, les paquets de données réservés (E2E) ne portent plus les mêmes adresses IP que le message Path pertinent (agrégé). Le problème devient de s'assurer que les paquets de données pour les flux réservés suivent le même chemin que le message Path qui a établi l'état Path pour la réservation agrégée. Plusieurs approches sont viables.

D'abord, les données peuvent être tunnelées de l'agrégateur au désagrégateur, en utilisant des technologies telles que les tunnels IP dans IP, les tunnels GRE, les chemins MPLS à commutation d'étiquette, et ainsi de suite. Chacun a ses avantages particuliers, et tout spécialement MPLS, qui permet l'ingénierie du trafic. Ils ont tous aussi un certain coût en redondance de liaison et en complexité de configuration.

Si les données ne sont pas tunnelées, nous dépendons alors d'une caractéristique de l'acheminement IP à la meilleure métrique, qui est que si le chemin de A à Z inclut le chemin de H à L, et si le chemin à la meilleure métrique a été choisi tout le long, le chemin à la meilleure métrique a alors été choisi de H à L. Donc, un message de chemin agrégé qui traverse un agrégateur et un désagrégateur donnés va nécessairement utiliser le meilleur chemin entre eux.

Si c'est un chemin unique, le problème est résolu. Si c'est une route multi-chemins, et si les chemins sont de coût égal, nous sommes alors forcés de déterminer, peut-être par mesure, quelle proportion du trafic pour une réservation E2E donnée est passée le long de chacun des chemins, et de nous assurer d'une bande passante suffisante pour l'utilisation présente. Une façon simple, mais ruineuse, de faire cela est de réserver la capacité totale du chemin agrégé sur chaque route.

Pour cette raison, nous pensons qu'il est avantageux d'utiliser un des mécanismes de tunnelage susmentionnées dans les cas où existent plusieurs chemins de coût égal.

1.4.7	Chemins inter-domaines
Le cas des chemins inter-domaines diffère un peu de celui de l'intra-domaine qu'on vient de décrire. Précisément, les considérations de meilleur chemin ne s'y appliquent pas, car l'acheminement est fait par une combinaison de politique d'acheminement et de plus court chemin du système autonome plutôt que la simple meilleure métrique.

Dans le cas des chemins inter-domaines, le trafic de données qui appartient à des sessions E2E différentes (mais de la même session agrégée) peut ne pas entrer dans la région d'agrégation via la même interface d'agrégateur, et/ou peut ne pas la quitter via la même interface de désagrégateur. Il est possible qu'on puisse identifier cette occurrence dans un système central qui voit les informations de réservation pour les deux sessions apparentes, mais il n'est pas sûr qu'on puisse déterminer à priori quelle quantité de trafic est venu par l'un ou l'autre chemin sauf à pratiquer des mesures.

On note simplement que ce problème peut survenir et qu'il est nécessaire de le prévoir dans une mise en œuvre. Nous recommandons que chacune de ces réservations E2E soit ajoutée dans sa réservation agrégée appropriée, même si cela implique de la surréservation.

1.4.8	Réservations pour sessions en diffusion groupée
Agréger des réservations pour des sessions de diffusion groupée est significativement plus complexe que pour les sessions en envoi individuel. Le premier défi est de construire un arbre de diffusion groupée pour la distribution des messages Path agrégés qui suivent le même chemin que vont suivre les paquets de données pour lesquels est à faire la réservation agrégée. Ceci est compliqué par le fait que le chemin pris par un paquet de données peut dépendre de nombreux facteurs comme l'adresse de source, le choix d'arbres partagés ou d'arbres spécifiques de source, et de la localisation d'un point de rendez-vous pour l'arborescence.

Une fois résolu le problème de la distribution des messages Path agrégés, il reste des problèmes considérables pour déterminer la quantité correcte de ressources à réserver sur chaque liaison le long de l'arborescence de diffusion groupée. À cause du niveau d'hétérogénéité qui peut exister dans une réservation agrégée de diffusion groupée, il apparaît qu'il serait nécessaire de conserver les informations sur les réservations E2E individuelles au sein de la région d'agrégation pour allouer correctement les ressources. On peut donc se retrouver avec un ensemble complexe de procédures pour former des réservations agrégées qui ne réduisent pas réellement significativement la quantité d'état mémorisé pour les sessions de diffusion groupée.

Comme noté plus haut, il y a plusieurs aspects à l'état RSVP, et notre approche pour l'envoi individuel agrège toutes les formes d'état : classification, programmation, et réservation. Une approche possible pour la diffusion groupée et de ne se concentrer que sur l'agrégation des états de classification et de programmation, qui sont sans conteste les plus importants à cause de leur impact sur le chemin de transmission. Cette approche est celle décrite dans le présent document.

1.4.9	Agrégation multi niveau
Dans l'idéal, un schéma d'agrégation devrait être capable de traiter l'agrégation récurrente, où les réservations agrégées sont elles-mêmes agrégées. Une agrégation à plusieurs niveaux peut être réalisée en utilisant les procédures décrites ici avec une simple extension au processus d'échange du numéro de protocole.

On peut considérer les réservations E2E RSVP comme étant le niveau d'agrégation 0. Lorsque on agrège ces réservations, on produit des réservations au niveau d'agrégation 1. En général, les réservations de niveau n peuvent être agrégées pour former des réservations au niveau n+1.

Lorsque un routeur agrégateur reçoit un Path E2E, il change le numéro de protocole de RSVP à RSVP-E2E-IGNORE. De plus, il devrait écrire le niveau d'agrégation (1, dans ce cas) dans le champ de deux octets qui est présent (et actuellement inutilisé) dans l'option d'alerte de routeur. En général, un routeur qui agrège des réservations au niveau n pour créer des réservations au niveau n+1 va écrire le nombre n+1 dans le champ d'alerte de routeur. Un routeur qui désagrège les réservations de niveau n+1 va examiner tous les messages qui ont le numéro de protocole IP RSVP- E2E-IGNORE mais va traiter le message et remettre le numéro de protocole à RSVP dans le seul cas où le champ d'alerte de routeur porte le numéro n+1. Pour toute autre valeur, le message est transmis inchangé. Les routeurs intérieurs ignorent tous les messages qui ont le numéro de protocole IP RSVP-E2E-IGNORE. Noter que seuls quelques bits du champ de deux octets de l'option seront nécessaires, étant donné le nombre vraisemblable de niveaux d'agrégation.

Pour IPv6, certaines valeurs du champ "valeur" de l'alerte de routeur sont réservées. La présente spécification demande à l'IANA l'allocation d'un petit nombre de valeurs consécutives pour les besoins de l'enregistrement du niveau d'agrégation.

1.4.10	Questions de fiabilité
Un certain nombre de problèmes divers qui apparaissent dans le contexte de l'agrégation tireraient parti d'une forme explicite de mécanisme d'accusé de réception des messages RSVP. Par exemple, il est possible de configurer un ensemble de routeurs tels qu'un Path E2E du type de protocole RSVP-E2E-IGNORE serait effectivement "mis dans un trou noir", si il n'atteignait jamais un routeur configuré de façon appropriée pour agir comme désagrégateur. Il pourrait alors voyager jusqu'à sa destination où il serait probablement ignoré du fait de son numéro de protocole non standard. Cette situation n'est pas facile à détecter. L'agrégateur peut s'assurer que ce problème ne s'est pas présenté si un message PathErr agrégé est reçu du désagrégateur (comme exposé en détails ci-dessous). Il peut aussi s'assurer qu'il n'y a pas de problème si un Resv E2E est reçu. Cependant, le fait qu'aucun de ces événements ne soit arrivé peut seulement signifier qu'aucun receveur ne souhaite réserver de ressources pour cette session, ou qu'une perte de message RSVP est arrivée, ou cela peut signifier que le message Path est dans un trou noir. Cependant, si il existait un mécanisme d'accusé de réception de voisin à voisin, l'agrégateur s'attendrait à recevoir un accusé de réception du Path E2E de la part du désagrégateur, et il interprèterait l'absence de réponse comme l'indication d'un problème de configuration. Il pourrait alors s'abstenir d'agréger cette session. Notons qu'un tel mécanisme de fiabilité a été proposé pour RSVP dans la [RFC291] et nous proposons de l'utiliser.

1.4.11	Intégrité de message et authentification de nœud
La [RFC2205] définit une authentification bond par bond et une vérification d'intégrité. La présente spécification permet l'utilisation de cette vérification sur les messages RSVP agrégés et préserve aussi cette vérification sur les messages RSVP E2E pour les messages RSVP E2E.

En dehors de la région d'agrégation, tout message RSVP E2E peut contenir un objet INTEGRITY en utilisant une technique de résumé chiffré qui suppose que les voisins RSVP partagent un secret. Comme les messages RSVP E2E ne sont pas traités par les routeurs dans la région d'agrégation, l'agrégateur et le désagrégateur apparaissent comme des voisins RSVP logiques l'un à l'autre. Le désagrégateur est le prochain bond de l'agrégateur pour les messages RSVP E2E alors que l'agrégateur est le bond précédent du désagrégateur. Par conséquent, les objets INTEGRITY qui peuvent apparaître dans les messages RSVP E2E qui traversent la région d'agrégation sont échangés directement entre l'agrégateur et le désagrégateur d'une façon entièrement transparente pour les routeurs intérieurs. Donc, la vérification d'intégrité bond par bond pour les messages E2E sur la région d'agrégation exige que l'agrégateur et le désagrégateur partagent un secret. Les techniques pour établir ce secret sont décrites dans la [RFC2747].

À l'intérieur de la région d'agrégation, un message RSVP Aggregate peut contenir un objet INTEGRITY qui suppose que les voisins RSVP correspondants à l'intérieur de la région agrégation (par exemple, agrégateur et routeur intérieur, deux routeurs intérieurs, un routeur intérieur et un désagrégateur) partagent un secret.

1.4.12	Réservations agrégées sans réservation E2E
Jusqu'à maintenant, nous avons supposé que la réservation agrégée est établie par suite de l'établissement de réservations E2E depuis l'extérieur de la région d'agrégation. Il devrait être clair que d'autres déclenchements sont possibles. Comme exposé dans la [RFC2998], une réservation RSVP agrégée peut être utilisée pour gérer la bande passante dans un nuage diff-serv même si RSVP n'est pas utilisé de bout en bout.

Le plus simple exemple d'une autre configuration est la configuration statique d'une réservation agrégée pour une certaine quantité pour du trafic provenant d'un routeur d'entrée (agrégateur) vers un routeur de sortie (désagrégateur). Cela devrait être configuré au moins dans le système qui génère le message PATH agrégé (l'agrégateur). Le désagrégateur pourrait détecter que le message PATH lui est destiné, et il pourrait être configuré pour "retourner" de tels messages, c'est-à-dire, il répond par un RESV à l'agrégateur. Autrement, la configuration de la réservation agrégée pourrait être effectuée à la fois à l'agrégateur et au désagrégateur. Comme précédemment, une réservation agrégée est associée à un DSCP pour le trafic qui va utiliser la capacité réservée.

En l'absence de réservation de microflux de bout en bout, l'agrégateur peut utiliser diverses politiques pour établir le DSCP des paquets qui passent dans la région d'agrégation, déterminant ainsi si ils obtiennent l'accès aux ressources réservées par la réservation agrégée. Ces politiques sont une affaire de configuration locale, comme c'est l'usage pour un appareil à la bordure d'un nuage diffserv.

Noter que l'"agrégateur" pourrait même être un appareil tel qu'une passerelle du RTPC qui fait une réservation agrégée pour l'ensemble des appels à une autre passerelle RTPC (le désagrégateur) à travers une région diff-serv interposée. Dans ce cas, la réservation peut être établie en réponse à la signalisation d'appel.

Du point de vue de la signalisation RSVP et du traitement des paquets de données dans la région d'agrégation, ces cas sont équivalents au cas de l'agrégation de réservations RSVP de bout en bout. La seule différence est que la signalisation RSVP de bout en bout n'a pas lieu et ne peut donc pas être utilisée comme déclencheur, de sorte qu'il est nécessaire d'avoir des données supplémentaires pour établir la réservation agrégée.

2.	Éléments de procédure

Pour mettre en œuvre l'agrégation, on définira un certain nombre d'éléments de procédure.

2.1	Réception du message Path E2E par un routeur d'agrégation
Le tout premier événement est l'arrivée du message Path de bout en bout à une interface extérieure d'un agrégateur. Les procédures RSVP standard [RFC2205] sont suivies pour cela, y compris sur l'ensemble des interfaces sur lesquelles le message devrait être transmis. Ces interfaces comprennent zéro, une ou plusieurs interfaces extérieures et zéro, une ou plusieurs interfaces intérieures. (Si le nombre d'interfaces intérieures est zéro, le routeur n'agit pas comme un agrégateur pour ce flux de bout en bout.)

Le service sur les interfaces extérieures est traité comme défini dans la [RFC2205].

Le service sur les interfaces intérieures est compliqué par le fait que le message doit être inclus dans une réservation agrégée, mais on ne sait pas encore laquelle, parce que on ne connaît pas le désagrégateur. Le messages Path de bout en bout est donc transmis sur la ou les interfaces intérieures en utilisant le numéro de protocole IP RSVP-E2E-IGNORE, mais identique sous tous les autres rapports à ce qu'il aurait été s'il avait été envoyé par un routeur RSVP qui n'effectuait pas d'agrégation.

2.2	Traitement du message Path E2E par des routeurs intérieurs
À ce moment, le message Path de bout en bout traverse zéro, un ou plusieurs routeurs intérieurs. Les routeurs intérieurs reçoivent le message Path de bout en bout sur une interface intérieure et le transmettent sur une autre interface intérieure. L'option IP Alerte de routeur avertit les routeurs intérieurs de vérifier en interne, mais ils vont trouver que le protocole IP est RSVP-E2E-IGNORE et que l'interface du prochain bond est intérieure. À ce titre, ils le transmettent simplement comme un datagramme IP normal.

2.3	Réception du message Path E2E par un routeur de désagrégation
Le message Path de bout en bout arrive finalement à un routeur désagrégateur, qui le reçoit sur une interface intérieure et le transmet sur une interface extérieure. Là encore, l'option IP Alerte de routeur l'avertit d'intercepter le message, mais cette fois le protocole IP est RSVP-E2E-IGNORE et l'interface de prochain bond est une interface extérieure.

Avant de transmettre le Path E2E vers le receveur, le désagrégateur devrait mettre à jour son ADSPEC. Cette mise à jour est destinée à refléter l'impact de la région d'agrégation sur la QS à réaliser de bout en bout par le flux. De telles informations peuvent être collectées par l'ADSPEC des messages Chemin agrégé qui voyagent de l'agrégateur au désagrégateur. Donc, pour permettre une mise à jour correcte de l'ADSPEC, un routeur désagrégateur peut attendre comme décrit ci-dessous l'arrivée d'un Chemin agrégé avant de transmettre le Path E2E.

À la réception du Path E2E, selon la politique de transposition de réservations de bout en bout en réservations agrégées, le désagrégateur peut être ou non en mesure de décider en quel DSCP le flux E2E pour le Path E2E traité va être transposé, comme décrit ci-dessus. Si le désagrégateur est en mesure de connaître à ce moment la transposition, le désagrégateur va alors d'abord vérifier qu'il y a un Chemin agrégé en place pour le DSCP correspondant. S'il en est ainsi, le désagrégateur va alors utiliser l'ADSPEC de ce Chemin agrégé pour mettre à jour l'ADSPEC du Path E2E puis transmettre le Path E2E vers le receveur. Sinon, le désagrégateur demande alors l'établissement du Chemin agrégé correspondant en envoyant un message PathErr de bout en bout avec un code d'erreur de NEW-AGGREGATE-NEEDED (nouvelle agrégation nécessaire) et le DSCP désiré codé dans l'objet DCLASS. Le désagrégateur peut aussi en même temps demander l'établissement d'une réservation agrégée pour d'autres DSCP. Lors de la réception du Chemin agrégé pour le DSCP désiré, le désagrégateur utilise alors l'ADSPEC de ce Chemin agrégé pour mettre à jour l'ADSPEC du Path E2E.

Si le désagrégateur n'est pas en mesure de connaître la transposition à ce moment, il utilise alors les informations contenues dans l'ADSPEC d'un ou plusieurs Chemin agrégé pour mettre à jour l'ADSPEC du Path E2E. De même, si un ou plusieurs des Chemin agrégé nécessaires ne sont pas encore établis, le désagrégateur demande l'établissement du Chemin agrégé correspondant en envoyant un message PathErr de bout en bout avec un code d'erreur de NEW-AGGREGATE-NEEDED et le DSCP désiré codé dans l'objet DCLASS pertinent. À la réception du Chemin agrégé pour le DSCP désiré, le désagrégateur utilise alors l'ADSPEC de ce Chemin agrégé pour mettre à jour l'ADSPEC du Path E2E.

La génération d'un message PathErr de bout en bout avec un code d'erreur de NEW-AGGREGATE-NEEDED ne devrait pas résulter en la suppression d'un état Path, mais devrait résulter en ce que le routeur agrégateur initie le message Chemin agrégé nécessaire, comme décrit au paragraphe suivant.

Le routeur désagrégateur change le protocole IP du message Path de bout en bout de RSVP-E2E-IGNORE à RSVP et transmet le message Path de bout en bout vers la destination prévue.

2.4	Initiation d'un nouveau message de chemin agrégé par un routeur d'agrégation
Le routeur agrégateur est chargé de générer un nouveau Chemin agrégé pour un DSCP lorsque il reçoit un message PathErr de bout en bout avec le code d'erreur NEW-AGGREGATE-NEEDED du désagrégateur. La valeur de DSCP à inclure dans la session de chemin agrégé se trouve dans l'objet DCLASS du message PathErr de bout en bout reçu. L'identité du désagrégateur lui-même se trouve dans la spécification d'erreur du message PathErr de bout en bout. L'adresse de destination du message Chemin agrégé est l'adresse du routeur désagrégateur, et le message est envoyé avec le numéro de protocole IP de RSVP.

Les procédures existantes de RSVP spécifient que la taille d'une réservation établie pour un flux est réglée au minimum de Path SENDER_TSPEC et de Resv FLOW_SPEC. Par conséquent, la taille d'une réservation agrégée ne peut pas être supérieure au SENDER_TSPEC inclus dans le chemin agrégé par l'agrégateur. Pour s'assurer que les réservations agrégées peuvent être dimensionnées par le désagrégateur sans limitations non désirées, le routeur agrégateur devrait toujours essayer d'inclure dans le Chemin agrégé un SENDER_TSPEC au moins de la taille qui serait réellement exigée comme déterminé par le désagrégateur. Une méthode pour faire cela est d'utiliser une SENDER_TSPEC qui est visiblement supérieure à la plus forte charge de réservation de bout en bout qui peut être acceptée sur ce réseau. Une autre méthode est que l'agrégateur garde trace des flux qui sont transposés sur un DSCP et de toujours ajouter leur SENDER_TSPEC de chemin de bout en bout dans la SENDER_TSPEC de chemin agrégé (et éventuellement d'ajouter aussi de la bande passante supplémentaire en anticipation des réservations de bout en bout futures).

La notification au routeur agrégateur de la transposition d'un flux E2E en un DSCP est faite de deux façons. D'abord, lorsque le routeur agrégateur reçoit une PathErr E2E avec le code d'erreur NEW-AGGREGATE-NEEDED, il est notifié à l'agrégateur que le flux E2E correspondant est (au moins temporairement) transposé en un DSCP donné. Ensuite, lorsque le routeur agrégateur reçoit une Resv E2E contenant un objet DCLASS (comme décrit un peu plus loin), il est notifié au routeur agrégateur que le flux E2E correspondant est transposé en un DSCP donné.

2.5	Traitement d'un message de réservation E2E par un routeur désagrégateur
Ayant envoyé le message Path de bout en bout vers la destination, le désagrégateur doit maintenant s'attendre à recevoir une Resv E2E pour la session. À réception, sa responsabilité est de s'assurer qu'une bande passante suffisante est réservée au sein de la région d'agrégation pour prendre en charge la nouvelle réservation de bout en bout, et si elle l'est, de transmettre alors la Resv E2E au routeur agrégateur.

Le routeur désagrégateur prend d'abord la décision finale sur quelle réservation agrégée (et donc sur quel DSCP) cette réservation E2E va être transposée. Cette décision est prise conformément à la politique choisie par l'administrateur de réseau, comme décrit plus haut.

Si cette décision finale de transposition est telle que le désagrégateur puisse maintenant faire une mise à jour plus précise de l'ADSPEC Path E2E que celle faite lors de la transmission du Path E2E initial, le désagrégateur devrait le faire et générer immédiatement un nouveau Path E2E afin de fournir les informations précises d'ADSPEC au receveur aussitôt que possible. Autrement, la procédure de rafraîchissement normale devrait être suivie pour le Path E2E.

Si aucune réservation agrégée n'existe actuellement de la part du routeur agrégateur correspondant avec le DSCP correspondant, le routeur désagrégateur va établir une nouvelle réservation agrégée comme décrit au paragraphe suivant.

Si la réservation agrégée correspondante existe mais a une réservation de bande passante insuffisant pour s'accommoder de la nouvelle réservation de bout en bout (en plus de toutes les réservations E2E existantes actuellement transposées sur elle) elle devrait suivre les procédures RSVP normales [RFC2205] pour une réservation passée avec une bande passante insuffisante pour prendre en charge la réservation. Elle peut aussi essayer d'abord d'augmenter la réservation agrégée qui fournit la bande passante en augmentant la taille de la FLOW_SPEC qu'elle inclut dans la réservation agrégée qui est envoyée vers l'amont. Comme exposé au paragraphe précédent, le routeur agrégateur devrait s'assurer que le SENDER_TSPEC qu'il inclut dans le chemin agrégé est toujours en excès par rapport à la FLOW_SPEC qui peut être demandée dans la réservation agrégée par le désagrégateur, de sorte que le désagrégateur ne soit pas inutilement empêché d'augmenter effectivement comme nécessaire la bande passante de la réservation agrégée.

Lorsque la bande passante suffisante est disponible sur la réservation agrégée correspondante, le routeur désagrégateur peut simplement envoyer le message Resv E2E avec le protocole IP RSVP au routeur agrégateur. Ce message devrait inclure l'objet DCLASS pour indiquer quel DSCP l'agrégateur doit utiliser pour ce flux de bout en bout. Le désagrégateur va aussi ajouter le baquet de jetons provenant de l'objet FLOWSPEC de la Resv de bout en bout dans sa compréhension interne de la quantité de la réservation agrégée qui est utilisée.

Comme exposé ci-dessus, afin de minimiser le nombre de situations où une bande passante insuffisante est réservée sur la réservation agrégée correspondante au moment du traitement d'une réservation de bout en bout, et donc d'éviter le retard associé à l'augmentation de cette bande passante agrégée, le désagrégateur PEUT anticiper la demande actuelle et augmenter la taille des réservations agrégées avant les exigences réelles par des réservations de bout en bout.

2.6	Initiation d'un nouveau message de réservation agrégée par un routeur de désagrégation
À réception d'un message de réservation de bout en bout sur une interface extérieure, et ayant déterminé le DSCP approprié pour la session conformément à la politique de transposition, le désagrégateur recherche l'état de chemin correspondant pour une session avec le DSCP choisi. Si il existe un état de chemin agrégé, mais qu'il n'existe pas d'état Resv agrégé, le désagrégateur crée une nouvelle Resv agrégée.

Si il n'existe pas d'état de chemin agrégé pour le DSCP approprié, cela peut être parce que le désagrégateur n'a pas pu décider plus tôt la transposition finale pour ce flux de bout en bout et a choisi de ne pas établir d'état de chemin agrégé pour tous les DSCP. Dans ce cas, le désagrégateur devrait demander l'établissement du chemin agrégé correspondant en voyant un PathErr de bout en bout avec le code d'erreur NEW-AGGREGATE-NEEDED et avec une DCLASS contenant le DSCP requis. Cela va déclencher l'établissement par l'agrégateur du chemin agrégé correspondant. Une fois que le désagrégateur a déterminé que l'état de chemin agrégé est établi, il crée une nouvelle réservation agrégée.

La FLOW_SPEC de la nouvelle réservation agrégée est réglée à une valeur qui n'est pas inférieure à l'exigence de la réservation de bout en bout qu'elle prend encharge. La réservation agrégée est envoyée vers l'agrégateur (c'est-à-dire, au bond précédent) en utilisant la spécification de AGGREGATED-session RSVP et de filtre définis ci-dessous. Comme le DSCP est dans l'objet SESSION, aucun objet DCLASS n'est nécessaire. Le message devrait être livré fiablement en utilisant les mécanismes de la [RFC2961] ou, autrement, l'objet CONFIRM peut être utilisé, pour garantir que la réservation agrégée arrive bien et est accordée. Cela permet au désagrégateur de déterminer si la bande passante demandée est disponible pour l'allouer aux flux de bout en bout qu'il prend en charge.

Afin de minimiser l'occurrence de situations où aucune réservation agrégée correspondante n'est établie au moment du traitement d'une réservation de bout en bout, et par suite éviter les délais associés à la création de cette réservation agrégée, le désagrégateur PEUT anticiper la demande actuelle et créer la réservation agrégée avant de recevoir les messages de réservation de bout en bout qui demandent de la bande passante sur ces réservations agrégées.

2.7	Traitement de message de réservation agrégé par les routeurs intérieurs
Le message de réservation agrégée est essentiellement traité de la même façon que ce qui est défini dans la [RFC2205]. L'objet Session contient l'adresse du routeur désagrégateur (ou de l'adresse de groupe pour la session dans le cas de la diffusion groupée) et le DSCP qui a été choisi pour la session. L'objet Filterspec identifie le routeur agrégateur. Ces routeurs effectuent le contrôle d'admission et l'allocation de ressource comme d'habitude et envoient la réservation agrégée vers l'agrégateur.

2.8	Traitement de message de réservation E2E par un routeur d'agrégation
La réception du message de réservation de bout en bout avec un objet DCLASS est la confirmation finale au routeur agrégateur de la transposition de la réservation de bout en bout en réservation agrégée. Dans des circonstances normales, c'est la seule façon dont il sera informé de cette association. Il devrait maintenant transmettre la réservation de bout en bout à son bond précédent, suivant les règles normales de traitement RSVP de la [RFC2205].

2.9	Retrait de réservation E2E
Les réservations de bout en bout sont retirées de la façon usuelle via PathTear, ResvTear, fin de temporisation, ou par suite d'une condition d'erreur. Lorsque elles sont retirées, leurs informations de FLOWSPEC doivent être aussi retirées de la portion allouée de la réservation agrégée. Cette même bande passante peut être réutilisée pour d'autre trafic dans un proche avenir. Lorsque des messages Path de bout en bout sont retirés, leurs informations de SENDER_TSPEC doivent être aussi retirées du chemin agrégé.

2.10	Retrait de réservation agrégée
Si une réservation agrégée devait être retirée (vraisemblablement à cause d'un changement de configuration, d'un changement de chemin, ou d'un événement de politique) les réservations de bout en bout qu'elle prend en charge ne seraient plus actives. Elles doivent être traitées en conséquence.

2.11	Traitement des données sur un flux E2E réservé par un routeur d'agrégation
Avant d'établir qu'un certain flux de bout en bout fait partie d'un agrégat donné, les données du flux devraient être traitées comme du trafic sans réservation par toute politique qui a cours dans ce cas. Généralement, cela signifierait de donner le même comportement de transmission qu'au trafic au mieux. Cependant, lorsque il est établi que le flux appartient à un certain agrégat, le routeur agrégateur est chargé de marquer tout le trafic concerné avec le DSCP correct et de le transmettre de la façon approprié au trafic de cette réservation. Cela peut impliquer de le transmettre à un certain prochain bond IP, ou de le passer sur un certain circuit de couche liaison, de le tunneler, ou de l'envoyer sur un chemin MPLS à commutation d'étiquettes.

L'agrégateur est chargé d'effectuer la régulation par réservations sur les flux de bout en bout qu'il agrège. L'agrégateur effectue les mesures de trafic qui relèvent de chaque réservation pour vérifier la conformité au baquet de jetons pour la réservation de bout en bout correspondante. Les paquets dont la conformité est vérifiée sont transmis comme mentionné ci-dessus. Les paquets qui sont trouvés non conformes doivent être abandonnées, reformatés ou marqués d'un DSCP différent. Le comportement détaillé de politique est un aspect de la transposition de service décrite dans la [RFC2998].

2.12	Procédures pour les sessions en diffusion groupée
À cause de la difficulté d'agréger des sessions de diffusion groupée comme décrit ci-dessus, on se concentre sur l'agrégation de l'état de programmation et de classification dans le cas de la diffusion groupée. La principale différence entre les cas de la diffusion groupée et de l'envoi individuel est que plutôt que d'envoyer un message de chemin agrégé à l'adresse d'envoi individuel d'un seul routeur désagrégateur, on envoie dans le cas de la diffusion groupée le message Chemin "agrégé" à la même adresse de groupe que la session de bout en bout. Cela assure que le message Chemin agrégé suit la même route que le chemin de bout en bout. Cette différence entre l'envoi individuel et la diffusion groupée est reflétée dans les objets Session définis ci-dessous. Une conséquence de cette approche est que l'on continuera d'avoir un état de réservation par session de diffusion groupée à l'intérieur de la région d'agrégation.

Un autre défi survient dans les sessions de diffusion groupée avec les receveurs hétérogènes. Considérons un routeur intérieur qui doit transmettre les paquets pour une session en diffusion groupée sur deux interfaces, mais n'a reçu une demande de réservation que sur une de ces interfaces. Il reçoit des paquets marqués avec le DSCP choisi pour la réservation agrégée. Lorsque il les envoie par l'interface qui n'a pas installé les réservations, il a les options suivantes :
a)	remarquer ces paquets comme au mieux avant de les envoyer par cette interface ;
b)	envoyer les paquets par cette interface avec le DSCP choisi pour la réservation agrégée.

La première approche souffre de l'inconvénient d'exiger une classification nMF à un routeur intérieur afin de reconnaître les flux dont les paquets doivent être rétrogradés. La seconde approche exige une surréservation de ressources sur l'interface sur laquelle aucune réservation n'a été reçue. En l'absence d'une telle surréservation, les paquets envoyés avec le "mauvais" DSCP seront capables de dégrader le service subi par les paquets qui utilisent légitimement ce DSCP.

Pour rendre la classification MF acceptable dans un routeur intérieur, il est possible de traiter le cas des flux hétérogènes comme une exception. C'est à dire qu'un routeur intérieur n'a besoin que d'être capable de reconnaître les microflux individuels qui ont des besoins de ressources hétérogènes sur l'interfaces de sortie de ce routeur.

3.	Éléments de protocole
3.1	RSVP-E2E-IGNORE du protocole IP
La présente spécification requiert l'allocation d'un type de protocole RSVP- E2E-IGNORE, dont le numéro est actuellement 134. Ceci n'est utilisé que sur les messages de bout en bout qui exigent une alerte de routeur (Path, PathTear, et ResvConf) et signifie que le message doit être traité d'une façon quand il est destiné à une interface intérieure, et d'une autre façon quand il est destiné à une interface extérieure. Le type de protocole est changé par l'agrégateur de RSVP en RSVP-E2E-IGNORE dans les messages de bout en bout Path, PathTear, et ResvConf lorsque ils entrent dans la région agrégation. Le type de protocole est changé à nouveau par le désagrégateur de RSVP-E2E-IGNORE en RSVP dans de tels messages de bout en bout lorsque ils sortent de la région d'agrégation

3.2	Code d'erreur de chemin
Un code PathErr NEW-AGGREGATE-NEEDED est nécessaire. Cette valeur ne signifie pas qu'une erreur fatale est survenue, mais qu'une action est requise de la part du routeur agrégateur pour éviter une condition d'erreur dans un futur proche.

3.3	Objet SESSION
L'objet SESSION contient deux valeurs : l'adresse IP pour la session agrégée de destination, et le DSCP qu'elle va utiliser sur les données de bout en bout que contient la réservation. Pour les sessions en envoi individuel, l'adresse de destination de la session est l'adresse du routeur désagrégateur. Pour les sessions en diffusion groupée, la destination de la session est l'adresse de diffusion groupée de la session de bout en bout (ou des sessions) qui sont agrégées. l'inclusion du DSCP dans la session permet que plusieurs sessions pour la même adresse soient distinguées par leur DSCP et mises séparément en file d'attente. Cela donne aussi le moyen d'agréger les états de programmation et de classification. Dans le cas d'une session qui utilise une paire de PHB (par exemple, AF11 et AF12) le DSCP utilisé devrait représenter le PHB numériquement inférieur (par exemple, AF11). Cela suit la même convention de dénomination que décrit la [RFC2836].

Les types de session sont définis pour les adresses IPv4 et IPv6.

o	Objet IP4 SESSION : Classe = SESSION, C-Type = RSVP-AGGREGATE-IP4

        +-------------+-------------+-------------+-------------+
        |        Adresse de session IPv4    (4 octets)          |
        +-------------+-------------+-------------+-------------+
        | /////////// |  Fanions    |  /////////  |     DSCP    |
        +-------------+-------------+-------------+-------------+

o	Objet IP6 SESSION : Classe = SESSION, C-Type = RSVP-AGGREGATE-IP6

        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +         Adresse de session IPv6  (16 octets)          +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        | /////////// |  Fanions    |  /////////  |     DSCP    |
        +-------------+-------------+-------------+-------------+

3.4	Objet SENDER_TEMPLATE
L'objet SENDER_TEMPLATE identifie le routeur agrégateur pour la réservation agrégée.

o	Objet IP4 SENDER_TEMPLATE : Classe = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP4

        +-------------+-------------+-------------+-------------+
        |       Adresse d'agrégateur IPv4 (4 octets)            |
        +-------------+-------------+-------------+-------------+

o	Objet IP6 SENDER_TEMPLATE : Classe = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP6

        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +        Adresse d'agrégateur IPv6 (16 octets)          +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+

3.5	Objet FILTER_SPEC
L'objet FILTER_SPEC identifie le routeur agrégateur pour la réservation agrégée, et est syntaxiquement identique à l'objet SENDER_TEMPLATE.

4.	Politiques et algorithmes de gestion prévisionnelle des blocs de bande passante

Les politiques exactes utilisées pour déterminer quelle quantité de bande passante devrait être allouée à une réservation agrégée à tout moment sortent du domaine d'application de ce document, et peuvent relever du fournisseur de service en question. Cependant, nous allons explorer ici quelques unes des questions et suggérer des approches.

En bref, la condition idéale est que la réservation agrégée ait toujours des ressources suffisantes pour allouer à toute réservation de bout en bout ce qui est nécessaire à sa prise en charge, et de ne jamais en prendre trop. Dit simplement, mais plus difficile à réaliser. Les facteurs à prendre en compte incluent des moments significatifs du cycle diurne : chacun peut voir qu'un grand nombre de gens commencent à passer des appels à 8 h du matin même si l'heure de 7 à 8 est du calme plat. Cela inclut aussi l'histoire récente : si plus de gens se sont mis à passer des appels récemment qu'il ne s'en termine, la prédiction de la bande passante nécessaire d'ici un petit moment est qu'il faudra plus de bande passante qu'il n'en est actuellement alloué. De même, à la fin d'une période chargée, on peut trouver que la tendance des appels sera au déclin des quantités de réservation.

La politique recommandée suit ces lignes. À tout moment, on devrait s'attendre à ce que la quantité de bande passante requise pour la réservation agrégée soit le plus grand de ce qui suit :
(a)	une exigence connue à priori, tirée de l'historique du cycle diurne d'un jour et d'une heure particuliers, et
(b)	la ligne de tendance sur l'histoire récente, avec une marge de confiance statistique à 90 ou 99 %.

On s'attend de plus à ce que les changements de cette réservation agrégée ne soient pas faits plus souvent que toutes les quelques minutes, et peut être idéalement avec une plus grosse granularité que des intervalles d'un quart d'heure ou d'une heure. Plus la granularité est fine, plus est important le niveau de signalisation requis, alors que plus la granularité est grosse, plus grandes sont les chances d'erreur, et donc le besoin de récupérer cette erreur.

En général, on s'attend à ce que la réservation agrégée ne s'ajuste pas exactement à la somme des réservations qu'elle prend en charge, mais plutôt qu'elle sera un multiple entier d'une certaine taille de bloc de réservations, qui excède cette valeur.

5.	Considérations pour la sécurité

Le présent document soulève de nombreux problèmes de sécurité ; par exemple, la perte d'une réservation agrégée par suite d'une agression est cause que de nombreux appels vont se faire sans réservation, et la réservation d'une grande quantité de bande passante excédentaire peut résulter en un déni de service. Cependant, ces questions ne sont pas confinées à la présente extension : c'est RSVP lui-même qui les a. On pense que les mécanismes de sécurité de RSVP traitent aussi ces questions.

Un problème de sécurité spécifique de l'agrégation RSVP concerne la modification du numéro de protocole IP dans les messages Path RSVP qui traversent une région d'agrégation. Si ce champ est modifié par un malveillant dans un message Path, cela va faire que le message sera ignoré par tous les appareils suivants sur son chemin, empêchant les réservations d'être faites. Il serait même possible de corriger la valeur avant qu'il atteigne le receveur, rendant difficile la détection de l'attaque. En théorie, il serait aussi possible à un nœud de modifier le numéro de protocole IP aussi bien pour des messages non RSVP, interférant donc avec le fonctionnement d'autres protocoles.

Une façon d'atténuer les risques de modification malveillante du numéro de protocole IP est d'utiliser un en-tête d'authentification IPSEC, ce qui garantirait que la modification malveillante de l'en-tête IP sera détectée. C'est une approche souhaitable mais elle impose une charge administrative de la forme de la gestion de clés pour les besoins de l'authentification.

Il est RECOMMANDÉ que les mises en œuvre de la présente spécification n'acceptent la modification du numéro de protocole IP que pour les messages RSVP Path, PathTear, et ResvConf. C'est-à-dire qu'une facilité générale de modification du numéro de protocole IP NE DEVRAIT PAS être disponible.

Les opérateurs de réseau qui mettent en place des routeurs avec la capacité d'agrégation RSVP devraient être conscients des risques de modification inappropriée du numéro de protocole IP et devraient prendre les mesures appropriées (sécurité physique, protection par mot de passe, etc.) pour réduire le risque qu'un routeur puisse être configuré par un agresseur pour perpétrer des modification malveillantes du numéro de protocole.

6.	Considérations relatives à l'IANA

Le paragraphe 1.2 propose un nouveau type de protocole, RSVP-E2E-IGNORE, qui est utilisé pour identifier un message que vont voir les routeurs dans le cœur de réseau ; un traitement ultérieur de tels messages peut être ou non requis, selon le type d'interface de sortie, comme décrit au paragraphe 1.2. L'IANA a alloué le numéro de protocole IP 134, conformément à la [RFC2780], satisfaisant aux critères de publication de RFC en cours de normalisation.

Le paragraphe 1.4.9 décrit la manière dont est utilisée l'alerte de routeur dans le contexte de cette spécification, qui est essentiellement un simple compteur de la profondeur de l'incorporation de l'agrégation. L'alerte de routeur IPv4 de la [RFC2113] a l'option de simplement demander au routeur de regarder le type de protocole du datagramme intercepté et de décider de ce qu'il va en faire ; le paramètre est une information supplémentaire à cette décision. L'alerte de routeur IPv6 [RFC2711] transforme le paramètre en un sous-type d'option. Il s'ensuit que l'option d'alerte de routeur IPv6 ne peut pas être utilisée par un algorithme dans le contexte du protocole en question. L'IANA a alloué un bloc de 32 valeurs (3-35, "Niveaux d'incorporation de réservations agrégées") qu'on peut transposer en profondeurs d'incorporation de 0 à 31, en espérant que 32 niveaux suffisent.

Le paragraphe 3.2 expose un nouveau code d'erreur de chemin exigé. L'IANA a alloué le code d'erreur de paramètre RSVP de 26 à NEW-AGGREGATE-NEEDED.

Les paragraphes 3.3, 3.4, et 3.5 décrivent les extensions à trois classes d'objet : Session, Spécification de filtre, et Gabarit d'envoyeur. L'IANA a alloué deux nouveaux C-Types communs à spécifier pour l'adresse de l'agrégateur. RSVP-AGGREGATE-IP4 est le C-Type 9 et RSVP-AGGREGATE-IP6 est le C-Type 10. En ajoutant ces C-types aux registres des Noms de classe, Numéro de classe et Types de classe de l'IANA, la même numérotation est utilisées pour eux dans les trois classes, comme c'est fait pour les tuplets d'adresse IPv4 et IPv6 dans la [RFC2205].

7.	Remerciements

Les auteurs reconnaissent leur dette à l'égard des documents publiés par, et des discussions menées avec, plusieurs personnes, en particulier John Wroclawski, Steve Berson, et Andreas Terzis qui ont matériellement contribué au présent document. La conception a été influencée par le document sur les tunnels RSVP, la [RFC2746].

Appendice 1	Exemple de flux de signalisation pour un premier flux E2E

Le présent Appendice n'apporte pas de spécifications supplémentaires. Il illustre simplement la spécification détaillée ci-dessus par un flux possible de messages de signalisation RSVP impliqués par l'établissement réussi d'une réservation de bout en bout en envoi individuel qui est la première entre une certaine paire d'agrégateur/désagrégateur.

	agrégateur	désagrégateur
Chemin de bout en bout
-------------------------------->  (1)
	Chemin de bout en bout
	------------------------------------------------->            (2)
	E2E PathErr(New-agg-needed, DCLASS=x)
	<--------------------------------------------
	E2E PathErr(New-agg-needed, DCLASS=y)
	(3)   <---------------------------------------------
	      AggPath(DSCP=x)
	 ----------------------------------------------->
	     AggPath(DSCP=y)
	 ------------------------------------------------->            (4)
		Chemin de bout en bout
		---------------------------->    (5)
	     AggResv (DSCP=x)
	<-------------------------------------------------
	     AggResv (DSCP=y)
	(6)    <------------------------------------------------
	    AggResvConfirm (DSCP=x)
	--------------------------------------------------->
	    AggResvConfirm (DSCP=y)
	 ---------------------------------------------------->          (7)
		   Réservation de bout en bout
		  (8)    <--------------------------------  
	  Réservation de bout en bout (DCLASS=x)
	 (9)   <-------------------------------------------------  
 Réservation de bout en bout
<---------------------------------

(1)	L'agrégateur transmet le chemin de bout en bout dans la région d'agrégation après modification de son numéro de protocole IP en RSVP-E2E-IGNORE

(2)	Supposons qu'il n'existe pas de chemin agrégé. Pour être capable de mettre précisément à jour l'ADSPEC du chemin de bout en bout, le désagrégateur a besoin de l'ADSPEC de Aggregate PATH. Dans cet exemple, le désagrégateur choisit de donner pour instruction à l'agrégateur d'établir des états Aggregate Path pour les deux DSCP pris en charge en envoyant un code PathErr New-Agg-Needed pour chaque DSCP.

(3)	L'agrégateur suit la demande du désagrégateur et signale un Chemin agrégé pour les deux DSCP.

(4)	Le désagrégateur prend en compte les informations contenues dans l'ADSPEC provenant des deux Aggregate Path et met à jour l'ADSPEC du chemin de bout en bout en conséquence. Le désagrégateur modifie aussi le numéro de protocole IP du chemin de bout en bout en RSVP avant de le transmettre.

(5)	Dans cet exemple, le désagrégateur choisit de procéder immédiatement à l'établissement de réservations agrégées pour les deux DSCP. En effet, le désagrégateur peut être vu comme anticipant la demande réelle de réservations de bout en bout afin que les ressources soient disponibles pour les réservations agrégées lorsque les demandes de réservation de bout en bout arrivent afin d'accélérer leur établissement. On suppose aussi que le désagrégateur inclut la demande facultative de confirmation de réservation dans ces réservations agrégées.

(6)	L'agrégateur se conforme simplement à la demande ResvConfirm reçue et retourne la ResvConfirm agrégée correspondante.

(7)	Le désagrégateur a une confirmation explicite que les deux réservations agrégées sont établies.

(8)	À réception de la réservation de bout en bout, le désagrégateur applique la politique de transposition définie par l'administrateur de réseau de transposer la réservation de bout en bout en réservation agrégée. Supposons que cette politique est telle que la réservation de bout en bout est à transposer en réservation agrégée avec DSCP=x. Le désagrégateur sait qu'une réservation agrégée est en place pour le DSCP correspondant depuis (7). Le désagrégateur effectue le contrôle d'admission pour la réservation de bout en bout sur la réservation agrégée pour DSCP=x. En supposant que la réservation agrégée pour DSCP=x a été établie avec une bande passante suffisante pour prendre en charge la réservation de bout en bout, le désagrégateur ajuste son compteur qui récapitule la bande passante non utilisée sur la réservation agrégée et transmet la réservation de bout en bout à l'agrégateur y compris un objet DCLASS convoyant la transposition choisie en DSCP=x.

(9)	L'agrégateur enregistre la transposition de la réservation de bout en bout en DSCP=x. L'agrégateur retire l'objet DCLASS et transmet la réservation de bout de bout vers l'envoyeur.

Appendice 2	Exemple de flux de signalisation pour flux E2E suivants sans redimensionnement de réservation

Le présent Appendice n'apporte pas de spécifications supplémentaires. Il illustre simplement la spécification détaillée ci-dessus par un flux possible de messages de signalisation RSVP impliqués par l'établissement réussi d'une réservation de bout en bout en envoi individuel qui suit les autres réservations de bout en bout entre une certaine paire d'agrégateur/désagrégateur. Ce flux pourrait être imaginé comme suivant le flux de messages illustrés à l'Appendice 1.

	agrégateur	désagrégateur
 Chemin de bout en bout
   -------------------------->    (10)
	    Chemin de bout en bout
	--------------------------------------->  (11)
	 Chemin de bout en bout
	   -------------------------->
	  Réservation de bout en bout
	(12)  <--------------------------   
	Réservation de bout en bout (DCLASS=x)
	(13)   <----------------------------------------  
 Réservation de bout en bout
   <-----------------------------

(10)	L'agrégateur transmet le chemin de bout en bout dans la région d'agrégation après avoir modifié son numéro de protocole IP en RSVP-E2E-IGNORE

(11)	Parce que les précédentes réservations de bout en bout ont été établies, supposons que le chemin agrégé existe pour tous les DSCP pris en charge. Le désagrégateur prend en compte les informations contenues dans l'ADSPEC provenant des chemins agrégés et met à jour l'ADSPEC du chemin de bout en bout en conséquence. Le désagrégateur modifie le numéro de protocole IP du chemin de bout en bout en RSVP avant de le transmettre.

(12)	À réception de la réservation de bout en bout, le désagrégateur applique la politique de transposition définie par l'administrateur de réseau pour transposer la réservation de bout en bout en réservation agrégée. Supposons que cette politique est telle que la réservation de bout en bout est à transposer en réservation agrégée avec DSCP=x. Parce que les précédentes réservations de bout en bout ont été établies, supposons qu'une réservation agrégée est en place pour DSCP=x. Le désagrégateur effectue le contrôle d'admission de la réservation de bout en bout en réservation agrégée pour DSCP=x. Supposons que la réservation agrégée pour DSCP=x a une bande passante inutilisée suffisante pour prendre en charge la nouvelle réservation de bout en bout, le désagrégateur ajuste alors son compteur qui récapitule la bande passante inutilisée sur la réservation agrégée et transmet la réservation de bout en bout à l'agrégateur en incluant un objet DCLASS qui porte la transposition choisie en DSCP=x.

(13)	L'agrégateur enregistre la transposition de la réservation de bout en bout en DSCP=x. L'agrégateur retire l'objet DCLASS et transmet la réservation de bout en bout vers l'envoyeur.

Appendice 3	Exemple de flux de signalisation pour flux E2E suivant avec redimensionnement de réservation

Le présent Appendice n'apporte pas de spécifications supplémentaires. Il illustre simplement la spécification détaillée ci-dessus par un flux possible de messages de signalisation RSVP impliqués par l'établissement réussi d'une réservation de bout en bout en envoi individuel qui suit les autres réservations de bout en bout entre une certaine paire d'agrégateur/désagrégateur. Ce flux pourrait être imaginé comme suivant le flux de messages illustrés à l'Appendice 2.

	 agrégateur	désagrégateur
     Chemin de bout en bout
   ------------------------------>   (14)
	Chemin de bout en bout
	---------------------------------------------->    (15)
	    Chemin de bout en bout
	     ----------------------------->
	Réservation de bout en bout
	(16)   <------------------------------
	AggResv (DSCP=x, bande passante augmentée
	(17)    <----------------------------------------   
	AggResvConfirm (DSCP=x, bande passante augmentée)
	----------------------------------------------->       (18)
	 Réservation de bout en bout (DCLASS=x)
	(19)       <-----------------------------------------   
  Réservation de bout en bout
   <-------------------------------

(14)	L'agrégateur transmet le chemin de bout en bout dans la région d'agrégation après avoir modifier son numéro de protocole IP en RSVP-E2E-IGNORE

(15)	Parce que les précédentes réservations de bout en bout ont été établies, supposons que le chemin agrégé existe pour tous les DSCP pris en charge. Le désagrégateur tient compte des informations contenues dans l'ADSPEC provenant des chemins agrégés et met à jour en conséquence l'ADSPEC du chemin de bout en bout. Le désagrégateur modifie aussi le numéro de protocole IP du chemin de bout en bout en RSVP avant de la transmettre.

(16)	À réception de la réservation de bout en bout, le désagrégateur applique la politique de transposition définie par l'administrateur de réseau pour transposer la réservation de bout en bout en réservation agrégée. Supposons que cette politique est telle que la réservation de bout en bout soit à transposer en réservation agrégée avec DSCP=x. Parce que les précédentes réservations de bout en bout ont été établies, supposons qu'une réservation agrégée est en place pour DSCP=x. Le désagrégateur effectue le contrôle d'admission de la réservation de bout en bout dans la réservation agrégée pour DSCP=x. Supposons que la réservation agrégée pour DSCP=x N'A PAS la bande passante inutilisée suffisante pour prendre en charge la nouvelle réservation de bout en bout. Le désagrégateur tente alors d'augmenter la bande passante de réservation agrégée pour DSCP=x en envoyant une nouvelle réservation agrégée avec une bande passante augmentée suffisante pour s'accommoder de toutes les réservations de bout en bout déjà transposées dans cette réservation agrégée plus la nouvelle réservation de bout en bout plus éventuellement un peu de bande passante additionnelle en prévision des réservations de bout en bout supplémentaires à venir. Supposons aussi que le désagrégateur inclut la demande facultative de confirmation de réservation dans ces réservations agrégées.

(17)	L'agrégateur se conforme simplement à la demande ResvConfirm reçue et retourne la ResvConfirm agrégée correspondante.

(18)	Le désagrégateur a une confirmation explicite que la réservation agrégée a bien été augmentée. Le désagrégateur effectue une nouvelle fois le contrôle d'admission de la réservation de bout en bout sur la réservation agrégée pour DSCP=x. En supposant que la réservation agrégée augmentée pour DSCP=x a maintenant une bande passante et des ressources inutilisées suffisantes pour prendre en charge la nouvelle réservation de bout en bout ; le désagrégateur ajuste alors son compteur qui récapitule la bande passante non utilisée sur la réservation agrégée et transmet la réservation de bout en bout à l'agrégateur en incluant un objet DCLASS qui porte la transposition choisie en DSCP=x.

(19)	L'agrégateur enregistre la transposition de la réservation de bout en bout en DSCP=x. L'agrégateur retire l'objet DCLASS et transmet la réservation de bout en bout vers l'envoyeur.

Références
[CSZ]	Clark, D., S. Shenker, and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism," dans le compte-rendu de SIGCOMM'92, septembre 1992.
[RFC791]	J. Postel, "Protocole Internet", STD 5, septembre 1981.
[RFC1122]	R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre 1989.
[RFC1958]	B. Carpenter, "Principes d'architecture de l'Internet", juin 1996.
[RFC2113]	D. Katz, "Option d'alerte de routeur IP," février 1997.
[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 par RFC2750, RFC3936, RFC4495).
[RFC2474]	K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS Field) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260) (P.S.)
[RFC2597]	J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Groupe PHB Transmission assurée (AF)", juin 1999. (MàJ par RFC3260) (P.S.).
[RFC2638]	K. Nichols, V. Jacobson, L. Zhang, "Architecture de services différenciés à deux bits pour l'Internet", juillet 1999. (Info.)
[RFC2711]	C. Partridge, A. Jackson, "Option d'alerte de routeur IPv6", octobre 1999. (P.S.)
[RFC2746]	A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang, "Fonctionnement de RSVP sur tunnels IP", janvier 2000. (P.S.)
[RFC2747]	F. Baker, B. Lindell, M. Talwar, "Authentification cryptographique RSVP", janvier 2000. (MàJ par RFC3097)
[RFC2780]	S. Bradner et V. Paxson, "Lignes directrices pour les allocations par l'IANA des valeurs du protocole Internet et des en-têtes qui s'y rapportent", BCP 37, mars 2000.
[RFC2836]	S. Brim, B. Carpenter, F. Le Faucheur, "Codes d'identification de comportement par bond", mai 2000. (Obsolète, voir RFC3140) (P.S.)
[RFC2961]	L. Berger et autres, "Extensions de réduction de redondance de rafraîchissement pour RSVP", avril 2001. (MàJ par RFC5063) (P.S.)
[RFC2996]	Y. Bernet, "Format de l'objet DCLASS RSVP", novembre 2000. (P.S.)
[RFC2998]	Y. Bernet et autres, "Cadre de fonctionnement de services intégrés sur réseaux Diffserv", novembre 2000. (Information)
Adresse des auteurs

Fred Baker	Carol Iturralde	Bruce Davie	
Cisco Systems	Cisco Systems	Cisco Systems	
1121 Via Del Rey	250 Apollo Drive	250 Apollo Drive	
Santa Barbara, CA, 93117  USA	Chelmsford MA, 01824 USA	Chelmsford MA,01824 USA	
téléphone : (408) 526-4257	téléphone : 978-244-8532	téléphone: 978-244-8921	
mél : fred@cisco.com	mél : cei@cisco.com	mél : bdavie@cisco.com	

Francois Le Faucheur
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06410 Biot - Sophia Antipolis
France
téléphone : +33.4.97.23.26.19
mél : flefauch@cisco.com

Déclaration de droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.