Groupe de travail Réseau	R. Braden, ISI	
Request For Comments : 2209	L. Zhang, UCLA	
Catégorie : Information	septembre 1997	
Traduction Claude Brière de L'Isle		

Protocole de réservation de ressources (RSVP) version 1 – 
Règles de traitement du message

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

Résumé
Le présent mémoire contient une description algorithmique des règles utilisées par une mise en œuvre de RSVP pour le traitement des messages. Il est destiné à préciser la version 1 de la spécification du protocole RSVP.

Le présent mémoire donne une description générique des règles de fonctionnement de la version 1 de RSVP [RFC2205]. Il est destiné à mettre en évidence un ensemble d'algorithmes qui vont accomplir les fonctions nécessaires, en omettant de nombreux détails.

1.	Structures génériques des données

Le présent mémoire suppose les invocations d'interface générique définies dans la [RFC2005] et les structures de données suivantes. Une mise en œuvre réelle peut utiliser des structures de données et interfaces supplémentaires ou différentes. Les champs de structure de données qui sont indiqués sont exigés sauf si ils sont explicitement marqués comme facultatifs.

o	PSB – Bloc d'état de chemin (Path State Block)
Chaque PSB détient un état de chemin pour une paire (session, envoyeur) particulière, définie respectivement par les objets SESSION et SENDER_TEMPLATE, reçus dans un message PATH.

Le contenu du PSB comporte les valeurs suivantes provenant d'un message PATH :
-	Session
-	Sender_Template
-	Sender_Tspec
-	L'adresse IP du bond précédent et le traitement d'interface logique (LIH, Logical Interface Handle) provenant d'un objet PHOP (Previous Hop, prochain bond).
-	Le TTL (Time To Live, durée de vie) IP restant
-	Les objets POLICY_DATA et/ou ADSPEC (facultatif)
-	Le fanion Non_RSVP
-	Le fanion E_Police
-	Le fanion Local_Only

De plus, le PSB contient les informations suivantes fournies par l'acheminement : OutInterface_list, qui est la liste des interfaces sortantes pour cette paire (envoyeur, destination), et IncInterface, qui est l'interface entrante attendue. Pour une destination en envoi individuel, OutInterface_list contient une entrée et IncInterface est indéfini.

Noter qu'il peut y avoir plus d'un PSB pour la même paire (session, envoyeur) mais différentes interfaces entrantes. Au plus une d'elles, qui aura le fanion Local_Only à zéro, sera le PSB utilisé pour transmettre les messages PATH vers l'aval ; nous l'appellerons le "PSB de transmission" dans la suite de ce texte. Les autres PSB auront le fanion Local_Only établi et une OutInterface_list vide. Le fanion Local_Only est nécessaire pour confronter correctement les PSB aux RSB, selon les règles de la [RFC2205].

o	RSB – Bloc d'état de réservation (Reservation State Block)
Chaque RSB détient une demande de réservation qui est arrivée dans un message RESV particulier, correspondant au triplet (session, prochain bond, Filter_spec_list). Ici, "Filter_spec_list" peut être une liste de FILTER_SPEC (pour le style SE), une seule FILTER_SPEC (style FF), ou vide (style WF). On définit le type d'objet virtuel "FILTER_SPEC*" pour une telle structure de données.

Le contenu d'un RSB comporte :
-	La spécification de session
-	L'adresse IP du prochain bond
-	Filter_spec_list
-	L'interface (logique) sortante OI (outgoing interface) sur laquelle la réservation doit être faite ou a été faite.
-	Le style
-	La Flowspec
-	Un objet SCOPE (facultatif, selon le style)
-	Un objet RESV_CONFIRM qui a été reçu (facultatif)

o	TCSB -- Bloc d'état de contrôle de trafic (Traffic Control State Block)
Chaque TCSB contient la spécification de réservation qui a été passée au contrôle de trafic pour une interface sortante spécifique. En général, les informations de TCSB sont déduites des RSB pour la même interface sortante. Chaque TCSB définit une seule réservation pour un triplet (session, OI, Filter_spec_list) particulier. Le contenu du TCSB comporte :
-	Session
-	OI (Interface sortante)
-	Filter_spec_list
-	TC_Flowspec, la flowspec effective, c'est-à-dire, la LUB (moindre limite supérieure) sur les valeurs de FLOWSPEC correspondantes provenant des RSB correspondants. La TC_Flowspec est passée au contrôle de trafic pour faire la réservation réelle.
-	Fwd_Flowspec, l'objet mis à jour à transmettre après la fusion.
-	TC_Tspec, égal à Path_Te, la Tspec d'envoyeur effective.
-	Les fanions de régulation. Les fanions sont E_Police_Flag, M_Police_Flag, et B_Police_Flag.
-	Rhandle, F_Handle_list. Ce sont les traitements retournés par l'interface de contrôle de trafic, correspondants à une flowspec et peut-être une liste de spécifications de filtres.
-	Un objet RESV_CONFIRM à transmettre.

o	BSB – Bloc d'état de blocage (Blockade State Block)
Chaque BSB contient un élément d'état de blocage. Selon le style de réservation utilisé, les BSB peuvent être par paire (session, sender_template) ou par paire (session, PHOP). En pratique, une mise en œuvre peut incorporer un BSB au sein d'un PSB; cependant, pour être clair, nous décrirons les BSB de façon indépendante.

Le contenu d'un BSB inclut :
-	Session
-	Sender_Template (qui est aussi une spécification de filtre).
-	PHOP (bond précédent).
-	La flowspec Qb
-	Le temporisateur de blocage Tb

Les variables de fanion booléen suivantes sont utilisées dans cette section : Path_Refresh_Needed (rafraîchissement de chemin nécessaire), Resv_Refresh_Needed (rafraîchissement de réservation nécessaire), Tear_Needed (suppression nécessaire), Need_Scope (portée nécessaire), B_Merge, et NeworMod. Refresh_PHOP_list est une liste de longueur variable des PHOP à rafraîchir.

2.	Règles de traitement
2.1	Message arrivant

Vérifier le numéro de version et la somme de contrôle RSVP, et éliminer le message si la moindre discordance est trouvée.

Si le type de message n'est pas PATH ou PTEAR ou RACK et si l'adresse de destination IP ne correspond pas à une des adresses d'interfaces locales, transmettre alors le message à l'adresse de destination IP et retourner (à l'état précédent).

Analyser la séquence des objets du message. Si un ou des objets requis sont manquants ou si le champ Longueur de l'en-tête commun ne correspond pas à une limite d'objet, éliminer le message et retourner (à l'état précédent).

Vérifier l'objet INTEGRITY, s'il en est. Si la vérification échoue, éliminer le message et retourner (à l'état précédent).

Vérifier la cohérence de l'utilisation des champs d'accès. Si le DstPort (accès de destination) dans l'objet SESSION est zéro mais que le SrcPort (accès de source) dans un objet SENDER_TEMPLATE ou FILTER_SPEC est différent de zéro, le message a alors une erreur "conflit d'accès de source" ; éliminer le message en silence et retourner (à l'état précédent).

Le traitement des objets POLICY_DATA sera spécifié à l'avenir.

Le traitement ultérieur dépend du type de message.

2.2	Message PATH arrivant

On suppose que le message PATH arrive sur l'interface InIf.

Traiter la séquence d'objets de descripteur d'envoyeur du message comme suit. Les fanions Path_Refresh_Needed et Resv_Refresh_Needed sont initialement à zéro.

o	Chercher un bloc d'état de chemin (PSB) dont la paire (session, sender_template) satisfait aux objets correspondants dans le message, et dont la IncInterface correspond à InIf.

Durant cette recherche :

1.	Si on trouve un PSB dont la session correspond aux champs DestAddress et Identifiant de protocole de l'objet SESSION reçu, mais dont les DstPort diffèrent et que l'un d'eux est à zéro, construire alors et envoyer un message PERR "Conflit d'accès de destination", éliminer le message PATH, et retourner (à l'état précédent).

2.	Si on trouve un PSB avec un hôte envoyeur correspondant mais dont les accès de source diffèrent et l'un des accès de source est à zéro, construire et envoyer un message PERR "Chemin ambigu", éliminer le message PATH, et retourner.

3.	Si on trouve un PSB de transmission, c'est-à-dire, un PSB qui satisfait à la paire (session, sender_template) et dont le fanion Local_Only est à zéro, sauvegarder un pointeur sur lui dans la variable fPSB. Si il ne s'en trouve pas, régler fPSB à NULL.

o	Si il n'y a pas de PSB qui corresponde, alors :

1.	Créer un nouveau PSB.

2.	Copier le contenu des objets SESSION, SENDER_TEMPLATE, SENDER_TSPEC, et PHOP (adresse IP et LIH) dans le PSB.

3.	Si l'envoyeur vient de l'API locale, régler OutInterface_List à la seule interface dont l'adresse correspond à l'adresse de l'envoyeur, et rendre IncInterface indéfini. Autrement, mettre le fanion Local_Only à un.

4.	Établir le fanion Path_Refresh_Needed.

o	Autrement (il y a un PSB qui correspond) :
-	Si l'adresse IP du PHOP, le LIH, ou la Sender_Tspec diffèrent entre le message et le PSB, copier la nouvelle valeur dans le PSB et établir le fanion Path_Refresh_Needed. Si l'adresse IP du PHOP ou le LIH diffèrent, établir aussi le fanion Resv_Refresh_Needed.

o	On appelle le PSB résultant "PSB actuel" (cPSB). Mettre à jour le cPSB, comme suit :
-	Lancer ou relancer le temporisateur de nettoyage pour le PSB.
-	Si le message contient un objet ADSPEC,  le copier dans le PSB.
-	Copier le fanion E_Police d'un objet SESSION dans le PSB.
-	Mémoriser le TTL reçu dans le PSB. Si le TTL reçu diffère du Send_TTL dans l'en-tête RSVP commun, établir le fanion Non_RSVP dans le PSB.

o	Si le PSB est nouveau ou si il n'y a pas de notification de changement de chemin en place, effectuer alors les manipulations d'acheminement suivantes, mais pas si le cPSB provient le l'API locale.

1.	Invoquer le programme approprié d'interrogation de chemin (Route_Query) en utilisant la DestAddress provenant de SESSION et (pour l'acheminement en diffusion groupée) la SrcAddress provenant de Sender_Template. Appelons les résultats (Rt_OutL, Rt_InIf).

2.	Si la destination est en diffusion groupée et si Rt_InIf diffère de IncInterface dans le cPSB, mais si fPSB pointe sur le cPSB, effectuer alors ce qui suit :
-	Établir le fanion Local_Only et supprimer la OutInterface_list du fPSB. Établir le pointeur fPSB à NULL.
-	Chercher un PSB pour la même paire (session, sender_template) dont IncInterface correspond à Rt_InIf. S'il en est trouvé un, régler fPSB pour qu'il pointe sur lui.

3.	Si la destination est en diffusion groupée et si Rt_InIf est la même que IncInterface dans le cPSB, mais si fPSB ne pointe pas sur le cPSB, faire alors ce qui suit :
-	Copier dans le cPSB la OutInterface_list provenant du PSB, s'il en est, qui est pointé par fPSB. Éliminer OutInterface_list et établir le fanion Local_Only dans le PSB sur lequel pointe le fPSB, s'il en est.
-	Supprimer le fanion Local_Only dans le cPSB et établir fPSB pour pointer sur cPSB.

4.	Si Rt_OutL diffère de la OutInterface_list du PSB sur lequel pointe fPSB, alors :
-	Mettre à jour la OutInterface_list du PSB provenant de Rt_OutL, puis exécuter la séquence d'événements Réparation locale de chemin du paragraphe 2.13 ci-dessous.

o	Si le fanion Path_Refresh_Needed est maintenant à zéro, abandonner le message PATH et retourner (à l'état précédent).

Autrement (l'état de chemin est nouveau ou modifié) faire le rafraîchissement, les invocations, et la mise à jour d'état comme suit :
1.	Si ce message PATH venait d'une interface réseau et non d'une application locale, faire une invocation d'événement de chemin pour chaque application locale pour cette session :

Invocation : <Upcall_Proc>( session-id, PATH_EVENT, fanions, sender_tspec, sender_template [ , ADSPEC] [ , POLICY_DATA] )

2.	Si OutInterface_list n'est pas vide, exécuter la séquence d'événements PATH REFRESH (ci-dessous) pour l'envoyeur défini par le PSB.

3.	Chercher tout état de réservation correspondant, c'est-à-dire, un RSB dont la Filter_spec_list comporte une FILTER_SPEC correspondant au SENDER_TEMPLATE et dont l'OI apparaît dans la OutInterface_list, et en faire le "RSB actif".

S'il ne s'en trouve aucun, abandonner le message PATH et retourner à l'état précédent.

4.	Exécuter la séquence Rafraîchissement de RESV (paragraphe 2.11 ci-dessous) pour le PHOP dans le PSB.

5.	Exécuter la séquence d'événements Mise à jour de contrôle de trafic (paragraphe 2.9) pour mettre à jour l'état de contrôle de trafic local si nécessaire. Cette séquence va établir le fanion Resv_Refresh_Needed si l'état de contrôle du trafic a été modifié d'une manière qui pourrait déclancher un rafraîchissement de réservation. S'il en est ainsi, exécuter la séquence Rafraîchissement de RESV (paragraphe 2.11) pour le PHOP dans le PSB.

o	Abandonner le message PATH et retourner à l'état précédent.

2.3	Message PTEAR arrivant

o	Chercher un PSB dont la paire (Session, Sender_Template) corresponde aux objets correspondants dans le message. Si on ne trouve aucun PSB correspondant, abandonner le message PTEAR et retourner à l'état précédent.

o	Transmettre une copie du message PTEAR à chacune des interfaces sortantes figurant sur la liste de OutInterface_list du PSB.

o	Trouver chaque RSB qui corresponde à ce PSB, c'est-à-dire, dont la Filter_spec_list corresponde au Sender_Template dans le PSB et dont l'OI soit incluse dans la OutInterface_list.

1.	Si le style du RSB est explicite, alors : 
-	Supprimer dans la Filter_spec_list la FILTER_SPEC qui correspond au PSB.
-	Si la Filter_spec_list est maintenant vide, supprimer le RSB.

2.	Autrement (le style du RSB est générique) alors :
-	Si ce RSB ne correspond à aucun autre PSB, supprimer le RSB.

3.	Si on trouve un RSB, exécuter la séquence d'événements Mise à jour de contrôle de trafic (paragraphe 2.9)) pour mettre à jour l'état de contrôle de trafic pour qu'il soit cohérent avec la réservation en cours et l'état de chemin.

o	Supprimer le PSB.

o	Abandonner le message PTEAR et retourner à l'état précédent.

2.4	Message PERR arrivant

o	Chercher un PSB dont la paire (SESSION, SENDER_TEMPLATE) corresponde aux objets correspondants dans le message. Si aucun PSB correspondant n'est trouve, abandonner le message PERR et retourner à l'état précédent.

o	Si l'adresse du bond précédent dans le PSB est celle de l'API locale, faire une invocation d'erreur à l'application :

Invocation : <Upcall_Proc>( session-id, PATH_ERROR, Error_code, Error_value, Node_Addr, Sender_Template [ , Policy_Data] )

Tout objet SENDER_TSPEC ou ADSPEC dans le message est ignoré.

Autrement, envoyer une copie du message PERR à l'adresse IP du PHOP.

o	Abandonner le message PERR et retourner à l'état précédent.

2.5	Message RESV arrivant

Au départ, Refresh_PHOP_list est vide et les fanions Resv_Refresh_Needed et NeworMod sont à zéro. Ces variables sont utilisées pour contrôler les rafraîchissements immédiats de réservation.

o	Déterminer l'interface sortante OI
L'interface logique sortante OI est tirée du LIH dans l'objet NHOP. (Si l'interface physique n'est pas impliquée par le LIH, elle peut être apprise de l'interface qui correspond à l'adresse de destination IP).

o	Vérifier l'état du chemin
1.	Si il n'existe pas de PSB pour SESSION, construire et envoyer alors un message RERR (comme décrit plus loin) spécifiant "Pas d'informations de chemin", abandonner le message RESV, et retourner à l'état précédent.

2.	Si on trouve un PSB avec un hôte d'envoi correspondant mais si le SrcPorts diffère et si un des SrcPorts est à zéro, construire et envoyer alors un message PERR "Chemin ambigu", abandonner le message RESV, et retourner à l'état précédent.

o	Vérifier si les styles sont compatibles.

Si il existe un RSB pour la session qui a un style incompatible avec le style du message, construire et envoyer un message RERR qui spécifie "Conflit de style", abandonner le message RESV, et retourner à l'état précédent.

Traiter la liste des descripteurs de flux pour faire les réservations comme suit, selon le style. On utilise ci-après une structure de liste de spécification de filtre Filtss de type FILTER_SPEC* (définie à la Section 1).

Pour le style FF, exécuter les étapes suivantes de façon indépendante pour chaque descripteur de flux dans le message, c'est-à-dire, pour chaque paire (FLOWSPEC, Filtss). Ici la structure Filtss consiste en une FILTER_SPEC provenant du descripteur de flux.

Pour le style SE, exécuter les étapes suivantes pour la paire (FLOWSPEC, Filtss), Filtss consistant en la liste des objets FILTER_SPEC provenant du descripteur de flux.

Pour le style WF, exécuter les étapes suivantes une fois pour la paire (FLOWSPEC, Filtss), Filtss étant une liste vide.

o	Vérifier l'état de chemin, comme suit :

1.	Localiser l'ensemble des PSB (d'envoyeurs) qui acheminent sur OI et dont les SENDER_TEMPLATE correspondent à une FILTER_SPEC dans Filtss.

Si cet ensemble est vide, construire et envoyer un message d'erreur spécifiant "Pas d'informations d'envoyeur", et continuer avec le prochain descripteur de flux dans le message RESV.

2.	Si le style a le choix explicite de l'envoyeur (par exemple, FF ou SE) et si une FILTER_SPEC incluse dans Filtss correspond à plus d'un PSB, construire et envoyer un message RERR qui spécifie"Spécification de filtre ambiguë" et continuer avec le prochain descripteur de flux dans le message RESV.

3.	Si le style est SE et si certaines FILTER_SPEC incluses dans Filtss ne correspondent à aucun PSB, supprimer cette FILTER_SPEC de Filtss.

4.	Ajouter le PHOP provenant du PSB à Refresh_PHOP_list, si le PHOP n'est pas déjà sur la liste.

o	Trouver ou créer un bloc d'état de réservation (RSB) pour la paire (SESSION, NHOP). Si le style est distinct, Filtss est aussi utilisé dans la sélection. On appelle cela le "RSB actif".

o	Si le RSB actif est nouveau :
1.	Établir la session, le NHOP, l'OI et le style du RSB à partir du message.
2.	Copier Filtss dans la Filter_spec_list du RSB.
3.	Copier la FLOWSPEC et tout objet SCOPE provenant du message dans le RSB.
4.	Établir le fanion NeworMod.

o	Si le RSB actif n'est pas nouveau, vérifier si le Filtss provenant du message contient des FILTER_SPEC qui ne sont pas dans le RSB ; si il y en a, ajouter les nouvelles FILTER_SPEC et établir le fanion NeworMod.

o	Lancer ou relancer le temporisateur de nettoyage sur le RSB actif ou, dans le cas du style SE, sur chaque FILTER_SPEC du RSB qui apparaît aussi dans Filtss.

o	Si le RSB actif n'est pas nouveau, vérifier si les objets STYLE, FLOWSPEC ou SCOPE ont changé ; si oui, copier les objets changés dans le RSB et établir le fanion NeworMod.

o	Si le message contenait un objet RESV_CONFIRM, le copier dans le RSB et établir le fanion NeworMod.

o	Si le fanion NeworMod est à zéro, continuer avec le prochain descripteur de flux dans le message RESV, s'il en est.

o	Autrement (le fanion NeworMod est établi, c'est-à-dire que le RSB actif est nouveau ou modifié) exécuter la séquence d'événements Mise à jour du contrôle de trafic (paragraphe 2.9). Si le résultat modifie l'état de contrôle du trafic, cette séquence va établir le fanion Resv_Refresh_Needed et faire une invocation RESV_EVENT à toute application locale.

Si la séquence Mise à jour du contrôle de trafic échoue avec une erreur, supprimer alors un nouveau RSB mais restaurer la réservation d'origine dans un ancien RSB.

o	Continuer avec le prochain descripteur de flux.

o	Lorsque tous les descripteurs de flux ont été traités, vérifier le fanion Resv_Refresh_Needed. Si il est maintenant établi, exécuter la séquence Rafraîchissement de RESV (paragraphe 2.11) pour chaque PHOP dans la Refresh_PHOP_list.

o	Abandonner le message RESV et retourner à l'état précédent.

Si le traitement d'un message RESV trouve une erreur, un message RERR est créé qui contient un descripteur de flux et un objet ERRORS. Le champ Nœud erroné de l'objet ERRORS est réglé à l'adresse IP de OI, et le message est envoyé en individuel au NHOP.

2.6	Message RTEAR arrivant

Le traitement d'un message RTEAR est en gros parallèle à celui du message RESV correspondant.

Un message RTEAR arrive avec une adresse de destination IP correspondant à une interface OI sortante. Le fanion Resv_Refresh_Needed est initialement à zéro et la Refresh_PHOP_list est vide.

o	Déterminer l'interface OI sortante.

L''interface logique sortante OI est tirée du LIH dans l'objet NHOP. (Si l'interface physique n'est pas impliquée par le LIH, elle peut être apprise de l'interface qui correspond à l'adresse de destination IP).

o	Traiter la liste de descripteur de flux dans le message RTEAR pour éliminer l'état de réservation local comme suit, selon le style. Ce qui suit utilise une structure de spécification de filtre Filtss de type FILTER_SPEC* (définie plus haut).

Pour le style FF: exécuter les étapes suivantes indépendamment pour chaque descripteur de flux dans le message, c'est-à-dire, pour chaque paire (FLOWSPEC, Filtss). Ici, la structure Filtss consiste en une FILTER_SPEC provenant du descripteur de flux.

Pour le style SE, exécuter les étapes suivantes une fois pour la paire (FLOWSPEC, Filtss) avec Filtss consistant en la liste des objets FILTER_SPEC provenant du descripteur de flux.

Pour le style WF, exécuter les étapes suivantes une fois pour la paire (FLOWSPEC, Filtss), Filtss étant une liste vide.

1.	Trouver un RSB correspondant à la paire (SESSION, NHOP). Si le style est distinct, Filtss est aussi utilisé dans la sélection. On appelle cela le "RSB actif". Si on ne trouve aucun RSB actif, continuer avec le prochain descripteur de flux.

2.	Vérifier le style
Si le RSB actif a un style incompatible avec le style du message, éliminer le message RTEAR et retourner à l'état précédent.

3.	Supprimer du RSB actif chaque FILTER_SPEC qui correspond à une FILTER_SPEC dans Filtss.

4.	Si toutes les FILTER_SPEC ont maintenant été supprimées du RSB actif, supprimer le RSB actif.

5.	Exécuter la séquence d'événements Mise à jour de contrôle de trafic (paragraphe 2.9) pour mettre à jour l'état de contrôle de trafic en cohérence avec l'état de réservation. Si le résultat modifie l'état du contrôle de trafic, le fanion Resv_Refresh_Needed sera établi et une invocation RESV_EVENT sera faite à toute application locale.

6.	Continuer avec le prochain descripteur de flux.

o	Tous les descripteurs de flux ont été traités.
Construire et envoyer tous les messages RTEAR à transmettre, de la façon suivante :
1.	Sélectionner chaque PSB qui achemine par l'interface sortante OI et, pour un style distinct, qui a un SENDER_TEMPLATE correspondant à Filtss.

2.	Choisir un descripteur de flux (Qj,Fj) (où Fj peut être une liste) dans le message RTEAR dont la FILTER_SPEC correspond au SENDER_TEMPLATE dans le PSB. Si on ne trouve pas de correspondance, retourner au prochain PSB.
-	Chercher un RSB (pour toute interface sortante) auquel achemine le PSB et dont la Filter_spec_list comporte le SENDER_TEMPLATE provenant du PSB.
-	Si on trouve un RSB, ajouter le PHOP du PSB à la Refresh_PHOP_list.
-	Autrement (aucun RSB n'est trouvé) ajouter le descripteur de flux (Qj,Fj) au nouveau message RTEAR en cours de construction, d'une façon appropriée au style.
-	Continuer avec le prochain PSB.

3.	Si le prochain PSB est pour un PHOP différent ou si le dernier PSB a été traité, transmettre tout message RTEAR qui a été construit.

o	Si un PSB a été trouvé à l'étape précédente, et si le fanion Resv_Refresh_Needed est maintenant établi, exécuter la séquence Rafraîchissement de RESV (voir au paragraphe 2.10) pour chaque PHOP dans la Refresh_PHOP_list.

o	Abandonner le message RTEAR et retourner.

2.7	Message RERR arrivant

Un message RERR arrive par l'interface (réelle) entrante In_If.

o	Si il n'y a pas d'état de chemin pour SESSION, éliminer le message RERR et retourner à l'état précédent.

o	Si le code d'erreur est 01 (Échec de contrôle d'admission) faire le traitement particulier suivant :

1.	Trouver ou créer un bloc d'état de blocage (BSB) de la façon dépendante du style suivante.
Pour le style WF (générique) il y aura un BSB par paire (session, PHOP).
Pour le style FF, il y aura un BSB par paire (session, filter_spec). Noter qu'un message RERR de style FF ne porte qu'un seul descripteur de flux.
Pour le style SE, il y aura un BSB par paire (session, filter_spec) pour chaque filter_spec contenue dans la liste des spécifications de filtre du descripteur de flux.

2.	Pour chaque BSB de l'étape précédente, établir (ou remplacer) sa FLOWSPEC Qb par la FLOWSPEC provenant du message, et établir (ou rétablir) son temporisateur Tb à Kb*R secondes. Si le BSB est nouveau, régler sa valeur de PHOP, et régler son Sender_Template égal à la filter_spec appropriée provenant du message.

3.	Exécuter la séquence d'événements Rafraîchissement de RESV (voir au paragraphe 2.10) pour le PHOP du bond précédent, mais seulement avec le fanion B_Merge à zéro. C'est-à-dire que si le traitement dans la séquence Rafraîchissement de RESV atteint le point d'établir le fanion B_Merge (parce que toutes les réservations correspondantes sont bloquées) ne pas l'établir mais sortir plutôt de la séquence Rafraîchissement et retourner ici.

o	Exécuter ce qui suit pour chaque RSB pour cette session dont l'OI diffère de In_If et dont la Filter_spec_list a au moins une spécification de filtre en commun avec la FILTER_SPEC* dans le message RERR. Pour le style WF, les structures FILTER_SPEC* vides sont supposées correspondre.

1.	Si Error_Code = 01 et si le fanion InPlace dans la ERROR_SPEC est 1 et que un ou plusieurs des BSB trouvés/créés ci-dessus ont un Qb qui est strictement supérieur à la Flowspec dans le RSB, continuer alors avec le prochain RSB correspondant, s'il en est.

2.	Si le NHOP dans le RSB est l'API locale, alors :
-	Si la FLOWSPEC dans le message RERR est strictement supérieure à la Flowspec du RSB, établir le fanion NotGuilty dans la ERROR_SPEC.
-	Délivrer une invocation d'erreur à l'application :
Invocation : <Upcall_Proc>( session-id, RESV_ERROR, Error_code, Error_value, Node_Addr, Error_flags, Flowspec, Filter_Spec_List [ , Policy_data] )
et continuer avec le prochain RSB.

3.	Si le style a le choix générique d'envoyeur, utiliser l'objet SCOPE SC.In provenant du message RERR pour construire un objet SCOPE SC.Out à transmettre. SC.Out devrait contenir les adresses d'envoyeur qui apparaissaient dans SC.In et qui acheminent vers l'OI, comme déterminé par l'examen des PSB. Si SC.Out est vide, continuer avec le prochain RSB.

4.	Créer un nouveau message RERR contenant le descripteur d'erreur de flux et l'envoyer à l'adresse de NHOP spécifiée par le RSB. Inclure SC.Out si le style a le choix générique d'envoyeur.

5.	Continuer avec le prochain RSB.

o	Éliminer le message RERR et retourner à l'état précédent.

2.8	Arrivée d'une confirmation de RESV

o	Si l'adresse IP (d'envoi individuel) trouvée dans l'objet RESV_CONFIRM dans le message RACK correspond à une interface du nœud, une invocation de confirmation est faite à l'application correspondante :

Invocation : <Upcall_Proc>( session-id, RESV_CONFIRM, Error_code, Error_value, Node_Addr, LUB-Used, nlist, Flowspec, Filter_Spec_List, NULL, NULL )

o	Autrement, transmettre le message RACK à l'adresse IP dans son objet RESV_CONFIRM.

Éliminer le message RACK et retourner à l'état précédent.

2.9	Mise à jour de contrôle de trafic

La séquence est invoquée par nombre des séquences d'arrivée de message pour régler ou ajuster l'état de contrôle local de trafic conformément à l'état actuel de réservation et de chemin. Un paramètre implicite de cette séquence est le RSB "actif".

Si le résultat modifie l'état de contrôle de trafic, cette séquence notifie à toute les applications locales correspondantes l'invocation RESV_EVENT. Si l'état change de façon telle que cela devrait déclancher des messages de rafraîchissement immédiat de RESV, cela va aussi établir le fanion Resv_Refresh_Needed.

o	Calculer les paramètres de contrôle de trafic en utilisant les étapes suivantes :

1.	Initialement, le fanion local Is_Biggest est à zéro.

2.	Considérons l'ensemble des RSB satisfaisant à SESSION et OI du RSB actif. Si le style du RSB actif est distinct, la Filter_spec_list doit aussi être satisfaite.
-	Calculer la flowspec noyau effective, TC_Flowspec, comme LUB des valeurs de FLOWSPEC dans ces RSB.
-	Calculer la spécification (liste) de filtre effectif de contrôle de trafic TC_Filter_Spec* comme l'union des Filter_spec_lists provenant de ces RSB.
-	Si le RSB actif a une FLOWSPEC supérieure à toutes les autres, établir le fanion Is_Biggest.

3.	Examiner tous les RSB qui satisfont à session et Filtss, pour toutes les OI. Établir TC_B_Police_flag si TC_Flowspec est inférieure, ou non comparable, à toute FLOWSPEC dans ces RSB.

4.	Localiser l'ensemble des PSB (d'envoyeurs) dont les SENDER_TEMPLATE satisfont la Filter_spec_list dans le RSB actif et dont la OutInterface_list inclut l'OI.

5.	Établir TC_E_Police_flag si un de ces PSB a son E_Police établi. Établir TC_M_Police_flag si c'est un style partagé et si il y a plus d'un PSB dans l'ensemble.

6.	Calculer Path_Te comme la somme des objets SENDER_TSPEC dans cet ensemble de PSB.

o	Chercher un TCSB satisfaisant SESSION et OI ; pour un style distinct (FF), il doit aussi satisfaire Filter_spec_list.

Si il ne s'en trouve aucun, créer un nouveau TCSB.

o	Si le TCSB est nouveau :

1.	Mémoriser TC_Flowspec, TC_Filter_Spec*, Path_Te, et les fanions de régulation dans le TCSB.

2.	Établir le fanion Resv_Refresh_Needed et faire l'invocation de contrôle de trafic :

TC_AddFlowspec( OI, TC_Flowspec, Path_Te, police_flags) ->  Rhandle, Fwd_Flowspec

3.	Si cette invocation échoue, construire et envoyer un message RERR qui spécifie "Échec de contrôle d'admission" avec le fanion InPlace à zéro. Supprimer le TCSB, supprimer tout objet RESV_CONFIRM du RSB actif, et retourner à l'état précédent.

4.	Autrement (l'invocation réussit) enregistrer Rhandle et Fwd_Flowspec dans le TCSB. Pour chaque filter_spec F dans TC_Filter_Spec*, invoquer :

TC_AddFilter( OI, Rhandle, Session, F) -> Fhandle

et enregistrer la Fhandle retournée dans le TCSB.

o	Autrement, si le TCSB n'est pas nouveau mais qu'aucune flowspec noyau effective TC_Flowspec n'a été calculée précédemment, alors :

1.	Établir le fanion Resv_Refresh_Needed.

2.	Inviter le contrôle de trafic à supprimer la réservation :

TC_DelFlowspec( OI, Rhandle )

3.	Supprimer le TCSB et retourner à l'état précédent.

o	Autrement, si le TCSB n'est pas nouveau mais si la TC_Flowspec, Path_Te, et/ou les fanions de régulation juste calculés diffèrent des valeurs correspondantes dans le TCSB, alors :

1.	Si les valeurs de TC_Flowspec et/ou Path_Te diffèrent, établir le fanion Resv_Refresh_Needed.

2.	Inviter le contrôle de trafic à modifier la réservation :

TC_ModFlowspec( OI, Rhandle, TC_Flowspec, Path_Te, police_flags ) -> Fwd_Flowspec

3.	Si cet appel échoue, construire et envoyer un message RERR qui spécifie "Échec de contrôle d'admission" et avec le bit InPlace à un. Supprimer tout objet RESV_CONFIRM du RSB actif et retourner à l'état précédent.

4.	Autrement (l'appel réussit) mettre à jour le TCSB avec les nouvelles valeurs et sauvegarder Fwd_Flowspec dans le TCSB.

o	Si le TCSB n'est pas nouveau mais si la TC_Filter_Spec* juste calculée diffère de la FILTER_SPEC* dans le TCSB, alors :

1.	Faire un ensemble approprié des ensembles d'invocations de TC_DelFilter et TC_AddFilter pour transformer la Filter_spec_list du TCSB en nouvelle TC_Filter_Spec*.

2.	Établir le fanion Resv_Refresh_Needed.

o	Si le RSB actif contient un objet RESV_CONFIRM, alors :

1.	Si le fanion Is_Biggest est établi, déplacer l'objet RESV_CONFIRM dans le TCSB et établir le fanion Resv_Refresh_Needed. (Cela va ultérieurement causer l'invocation de la séquence Rafraîchissement de RESV, ce qui va transmettre ou retourner l'objet RESV_CONFIRM, le supprimant du TCSB dans l'un et l'autre cas).

2.	Autrement, créer et envoyer un message RACK à l'adresse contenue dans l'objet RESV_CONFIRM. Inclure l'objet RESV_CONFIRM dans le message RACK. Le message RACK devrait aussi comporter un objet ERROR_SPEC dont le paramètre Error_Node est l'adresse IP de l'OI provenant du TCSB et qui spécifie "Pas d'erreur".

o	Si le fanion Resv_Refresh_Needed est établi et si le RSB ne vient pas de l'API, faire une invocation RESV_EVENT à toute application correspondante :

Invocation : <Upcall_Proc>( session-id, RESV_EVENT, style, Flowspec, Filter_spec_list [ , POLICY_DATA] )

où Flowspec et Filter_spec_list viennent du TCSB et le style vient du RSB actif.

o	Retourner à la séquence d'événement qui a invoquée celle-ci.

2.10	Rafraîchissement de chemin

Cette séquence envoie un rafraîchissement de chemin pour un envoyeur particulier, c'est-à-dire, un PSB. Cette séquence peut être introduite soit pas l'arrivée à expiration d'un temporisateur de rafraîchissement, soit directement par suite de l'établissement du fanion Path_Refresh_Needed durant le traitement d'un message PATH reçu.

o	Insérer les objets TIME_VALUES dans le message PATH en cours de construction. Calculer le TTL IP pour le message PATH avec un de moins que la valeur de TTL reçue dans le message. Cependant, si le résultat est zéro, retourner (à l'état précédent) sans envoyer le message PATH.

o	Créer un descripteur d'envoyeur contenant les objets SENDER_TEMPLATE, SENDER_TSPEC, et POLICY_DATA, si ils sont présents dans le PSB, et l'empaqueter dans le message PATH en cours de construction.

o	Envoyer une copie du message PATH à chaque interface OI dans OutInterface_list. Avant d'envoyer chaque copie :

1.	Si le PSB a le fanion E_Police établi et si l'interface OI n'est pas capable de régulation, établir le fanion E_Police dans le message PATH en cours de construction.

2.	Passer l'objet ADSPEC et le fanion Non_RSVP présents dans le PSB à l'(invocation de contrôle de trafic TC_Advertise. Insérer l'objet ADSPEC modifié qui est retourné dans le message PATH en cours de construction.

3.	Insérer dans son objet PHOP l'adresse de l'interface et le LIH pour l'interface.

2.11	Rafraîchissement de RESV

Cette séquence envoie un rafraîchissement de réservation vers un bond précédent particulier à l'adresse IP PH. Cette séquence peut être introduite par l'arrivée à expiration d'un temporisateur de rafraîchissement, ou invoquée à partir des séquence Message PATH arrivant, Message RESV arrivant, Message RTEAR arrivant, ou Message RERR arrivant.

En général, cette séquence considère chacun des PSB avec l'adresse de PHOP PH. Pour un PSB donné, elle examine les TCSB à la recherche de réservations correspondantes et fusionne les styles, les FLOWSPEC et les Filter_spec_list de façon appropriée. Elle construit ensuite un message RESV et l'envoie au PH. Les détails dépendent des attributs du ou des styles inclus dans les réservations.

Initialement, le fanion Need_Scope est à zéro et l'objet new_SCOPE est vide.

o	Créer un message de sortie contenant les objets INTEGRITY (si il est configuré), SESSION, RSVP_HOP, et TIME_VALUES.

o	Déterminer le style pour ces réservations à partir du premier RSB pour la session, et déplacer l'objet STYLE dans le proto-message. (Noter que le présent ensemble de styles n'est jamais fusionné ; si de futurs styles pouvaient être fusionnés, ces règles deviendraient plus complexes).

o	Si le style est générique et si il y a des PSB provenant de plus d'un PHOP et si le protocole d'acheminement de diffusion groupée n'utilise pas d'arborescences partagées, établir le fanion Need_Scope.

o	Sélectionner chaque PSB d'envoyeur dont le PHOP a l'adresse PH. Supprimer le fanion local B_Merge et exécuter les étapes suivantes :

1	Sélectionner tous les TCSB dont la Filter_spec_list satisfait à l'objet SENDER_TEMPLATE dans le PSB et dont l'OI apparaît dans la OutInterface_list du PSB.

2.	Si le PSB provient de l'API, alors :
-	Si le TCSB contient un objet CONFIRM, créer alors et envoyer un message RACK contenant l'objet et supprimer l'objet CONFIRM du TCSB.
-	Continuer avec le prochain PSB.

3.	Si le fanion B_Merge est à zéro, ignorer alors un TCSB bloqué de la façon suivante :
-	Sélectionner les BSB qui correspondent à ce TCSB. Si un BSB sélectionné est arrivé à expiration, le supprimer. Si un des BSB non arrivé à expiration a un Qb qui n'est pas strictement supérieur à la TC_Flowspec, continuer alors le traitement avec le prochain TCSB.
Cependant, si les étapes 1 et 2 résultent en ce que tous les TCSB qui correspondent à ce PSB sont bloqués, alors :
-	Si cette séquence Rafraîchissement de RESV a été invoquée à partir d'une séquence Erreur de RESV reçue, retourner alors à cette dernière.
-	Autrement, établir le fanion B_Merge et recommencer à l'étape 1 ci-dessus.

4.	Fusionner les flowspec provenant de cet ensemble de TCSB de la façon suivante :
-	Si le fanion B_Merge est à zéro, calculer la LUB sur les objets de la flowspec. À partir de chaque TCSB, utiliser l'objet Fwd_Flowspec s'il est présent, autrement, utiliser l'objet Flowspec normal.
Lors du calcul de la LUB, vérifier qu'il y a un objet RESV_CONFIRM dans chaque TCSB. Si un objet RESV_CONFIRM est trouvé :
-	Si la flowspec (Fwd_Flowspec ou Flowspec) dans ce TCSB est supérieur à toutes les autres flowspec (non bloquées) qui font l'objet de la comparaison, sauvegarder alors cet objet RESV_CONFIRM pour la transmission et le supprimer du TCSB.
-	Autrement (la flowspec correspondante n'est pas la plus grande) créer et envoyer un message RACK à l'adresse qui se trouve dans l'objet RESV_CONFIRM.
Inclure l'objet RESV_CONFIRM dans le message RACK. Le message RACK devrait aussi inclure un objet ERROR_SPEC dont le paramètre Error_Node est l'adresse IP de l'OI provenant du TCSB et spécifiant "Pas d'erreur".
-	Supprimer l'objet RESV_CONFIRM du TCSB.
-	Autrement (le fanion B_Merge est établi) calculer le GLB sur les objets Flowspec de cet ensemble de TCSB.

Lors du calcul du GLB, supprimer tout objet RESV_CONFIRM de tous ces TCSB.

5.	(Tous les TCSB correspondants ont été traités). La prochaine étape dépend des attributs de style.

Style de réservation distinct (FF)
Utiliser le Sender_Template comme FILTER_SPEC fusionnée. Empaqueter le triplet (FLOWSPEC, FILTER_SPEC, F_POLICY_DATA) fusionné dans le message comme descripteur de flux.

Style de réservation générique à partage (WF)
Il n'y a pas de FILTER_SPEC fusionnée. Fusionner (calculer la LUB de) la FLOWSPEC fusionnée des TCSB, sur tous les PSB pour PH.

Style de réservation distincte partagée (SE)
En utilisant le Sender_Template comme FILTER_SPEC fusionnée, former l'union des FILTER_SPEC obtenues des TCSB. Fusionner (calculer la LUB de) la FLOWSPEC fusionnée des TCSB, sur tous les PSB pour PH.

6.	Si le fanion Need_Scope est établi et si l'envoyeur spécifié par le PSB n'est pas l'API locale :
-	Trouver chaque RSB qui correspond à cette PSB, c'est-à-dire, dont la Filter_spec_list correspond au Sender_Template dans le PSB et dont l'OI est incluse dans OutInterface_list.
-	Si le RSB n'a pas de liste SCOPE ou si sa liste SCOPE comporte l'adresse IP d'envoyeur provenant du PSB, insérer l'adresse IP de l'envoyeur dans new_SCOPE.

o	(Tous les PSB pour PH ont été traités). Terminer le message RESV.

1.	Si le fanion Need_Scope est établi mais si new_SCOPE est vide, aucun message RESV ne devrait être envoyé ; retourner à l'état précédent. Autrement, si Need_Scope est établi, placer new_SCOPE dans le message.

2.	Si un style de réservation partagé est construit, placer l'objet final FLOWSPEC fusionné et la liste des spécifications de filtre dans le message.

3.	Si un objet RESV_CONFIRM a été sauvegardé précédemment, le placer dans le nouveau message RESV.

4.	Régler l'objet RSVP_HOP dans le message pour qu'il contienne l'adresse IncInterface à travers laquelle il sera envoyé et le LIH de l'un des PSB.

o	Envoyer le message à l'adresse du prochain bond.

2.12	Notification de changement de chemin

Cette séquence est déclanchée lorsque l'acheminement envoie une notification de changement de chemin à RSVP.

o	Chaque PSB dont la SESSION correspond à l'adresse de destination et dont le SENDER_TEMPLATE correspond à l'adresse de source (pour la diffusion groupée) est localisé.

1.	Si la OutInterface_list de la notification diffère de celle du PSB, exécuter la séquence Réparation locale de chemin (paragraphe 2.13).

2.	Si la IncInterface de la notification diffère de celle du PSB, mettre à jour le PSB.

2.13	Réparation locale de chemin

La séquence est introduite pour effectuer une réparation locale après un changement de chemin pour un PSB donné.

o	Attendre un délai de W secondes.

o	Exécuter la séquence d'événements Rafraîchissement de chemin (paragraphe 2.10) pour le PSB.

3.	Références

[RFC2747]	F. Baker, B. Lindell, M. Talwar, "Authentification cryptographique RSVP", janvier 2000. (MàJ par RFC3097).

[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) (P.S.)

[RFC2207]	L. Berger, T. O'Malley, "Extensions RSVP pour flux de données IPSEC", septembre 1997. (P.S.)

[RSVP93]	Zhang, L., Deering, S., Estrin, D., Shenker, S., et D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, septembre 1993.

4.	Considérations sur la sécurité

Le traitement de l'objet RSVP INTEGRITY [RFC2747] est seulement mentionné dans le présent mémoire, parce que les règles de traitement ne sont décrites ici qu'en termes généraux. La prise en charge par RSVP de IPSEC [RFC2207] va impliquer des modifications qui n'ont pas encore été incorporées dans ces règles de traitement.

Adresse des auteurs

Bob Braden	Lixia Zhang	
USC Information Sciences Institute	UCLA Computer Science Department	
4676 Admiralty Way	4531G Boelter Hall	
Marina del Rey, CA 90292	Los Angeles, CA 90095-1596 USA	
téléphone : (310) 822-1511	téléphone : 310-825-2695	
mél : Braden@ISI.EDU	mél : lixia@cs.ucla.edu