Résumé

  • RSVP fait remonter une demande du récepteur vers l’émetteur, mais chaque nœud conserve sa propre décision d’admission, sa propre politique et son propre état de contrôle du trafic. Cet état disparaît si les messages Path et Resv ne le rafraîchissent plus.
  • Un ResvConf n’atteste pas un service de bout en bout : le RFC 2205 dit expressément qu’il n’offre aucune garantie. Il faut relier chemin, requête, décisions locales, installation, époque de rafraîchissement et mesures du trafic.

Le présent a une date d’expiration

Une console peut afficher une réservation en vert alors que la phrase qu’elle résume est déjà trop longue. Quel récepteur l’a demandée ? Pour quel flux ? Sur quel chemin ? Quel nœud l’a admise ? À quand remonte le dernier rafraîchissement ?

Le RFC 2205 apporte une réponse architecturale à cette fragilité : RSVP conserve un « état souple ». Les messages Path et Resv le créent et le renouvellent périodiquement. Si aucun message correspondant n’arrive avant le délai de nettoyage, le routeur le supprime. La disparition n’est donc pas une panne du modèle ; elle empêche une ancienne intention de devenir un droit perpétuel sur des ressources nouvelles.

La réservation n’est exacte qu’au présent. Son reçu doit contenir une époque, un dernier signal reçu et une échéance. Le mot isolé perd la propriété la plus importante du protocole : il sait oublier.

Le récepteur parle à rebours du trafic

RSVP est un protocole simplex et orienté récepteur. L’émetteur envoie périodiquement des messages Path dans le sens des données. Les routeurs mémorisent notamment le saut précédent. Le récepteur produit ensuite un message Resv qui remonte de saut en saut vers l’émetteur en utilisant cet état de chemin.

Cette inversion évite de confondre l’existence d’une source avec la demande de service. Dans un groupe multicast, plusieurs récepteurs peuvent formuler des besoins différents. Les demandes peuvent être fusionnées en remontant ; le flowspec transmis plus loin n’est pas nécessairement la copie de celui qui vient d’arriver.

Un paquet Resv observé prouve donc qu’une requête a traversé un point donné. Il ne dessine pas tout le chemin. Un message Path prouve qu’un état de route existait à un instant donné ; il ne prouve pas que la réservation inverse a été installée partout. Les deux directions sont complémentaires, jamais interchangeables.

Deux portes avant le programmateur

Chaque nœud doit répondre à deux questions. L’admission vérifie si les ressources suffisent. Le contrôle de politique vérifie si l’utilisateur est autorisé à les demander. Les deux réponses doivent être favorables.

Alors seulement le nœud configure son classificateur de paquets et son programmateur, ou le mécanisme de couche liaison qui fournit le service. RSVP transporte des paramètres de qualité et de politique mais ne possède pas leur sens complet : les modules locaux les interprètent.

Cette séparation interdit quatre raccourcis. Une capacité disponible n’est pas une permission. Une permission n’est pas une installation. Une installation locale n’est pas une transaction atomique sur tout le trajet. Et une configuration ne démontre pas le résultat vécu par les paquets.

Le RFC 2208 rappelait dès 1997 que traitement, mémoire, agrégation, sécurité et politique compliquaient le déploiement à grande échelle. Ce texte n’est pas une statistique contemporaine. Il montre pourquoi la signalisation ne pouvait pas, seule, porter toutes les institutions nécessaires au service.

La confirmation qui refuse le rôle de certificat

Le récepteur peut demander une confirmation dans son Resv. À un point de fusion, si une réservation égale ou supérieure existe déjà, le nœud peut renvoyer ResvConf sans propager plus loin la nouvelle demande.

L’image est séduisante : une réponse positive revient au demandeur. Mais le RFC 2205 écrit que la réception d’un ResvConf ne donne aucune garantie. Son exemple est décisif. Deux demandes arrivent à un point de fusion ; la seconde peut être confirmée alors que la première n’a pas encore atteint un émetteur correspondant et peut toujours échouer. Un ResvConf peut même précéder un ResvErr.

Le reçu honnête dit seulement quel nœud a traité quelle demande de confirmation avec quel état local. Il ne certifie ni l’admission de chaque saut, ni l’installation de chaque programmateur, ni la stabilité du routage, ni la qualité observée par l’application.

Le vieux chemin s’efface au lieu d’être réécrit

Les messages Path et Resv sont idempotents. Après un changement de route, le prochain Path crée l’état sur le nouveau trajet ; les Resv suivants y construisent la réservation. Sur l’ancien segment devenu inutile, l’état expire.

PathTear et ResvTear peuvent accélérer la suppression, mais ces messages ne sont pas fiables. Le protocole supporte leur perte parce que l’absence de rafraîchissement finit le travail. L’expiration est ainsi une propriété de sûreté plus profonde qu’un ordre unique de suppression.

Une réservation partielle peut néanmoins rester en aval d’un échec d’admission. Le RFC la conserve pour permettre un service partiel ou une reprise rapide après une défaillance transitoire. Un routeur peut donc rapporter, sans mentir, un état réservé alors que l’ensemble du chemin n’est pas réservé.

Comprimer le rafraîchissement ne supprime pas le bail

Le coût des messages complets a conduit au RFC 2961. Des identifiants, des accusés de réception par saut et Summary Refresh permettent de renouveler un état connu sans répéter tout le contenu Path ou Resv.

L’économie porte sur la représentation, non sur le statut. Summary Refresh doit préserver la synchronisation de l’état souple. Si le destinataire ne trouve pas l’état désigné, il peut envoyer un NACK de rafraîchissement. Un ACK de message démontre une réception locale de signalisation ; il n’atteste pas un service de bout en bout.

Il reste donc plusieurs horloges : époque de la requête, intervalle et délai de nettoyage de chaque nœud, époque d’identifiant entre voisins, version de la configuration et fenêtre de mesure du service. Les réunir sous une seule date « active depuis » fabrique une précision imaginaire.

Le diagnostic observe l’état, pas l’expérience

Le RFC 2745 ajoute DREQ et DREP. Une requête peut recueillir, saut après saut, des informations sur les états Path ou Resv. Le résultat aide à localiser un manque ou une divergence.

Mais la réponse peut être fragmentée, s’arrêter sur une erreur, emprunter un trajet retour différent, rencontrer un pare-feu ou expirer. Même complète, elle décrit ce que des nœuds avaient en mémoire au moment du passage. Elle ne voit pas forcément le classificateur effectivement appliqué, encore moins le délai, la perte et le débit vécus par les paquets.

Le diagnostic ajoute un témoin. Il ne lui donne pas compétence pour parler au nom du plan de données.

Une contribution collective, pas une juridiction personnelle

Le profil IETF de Lixia Zhang la relie au RFC 2205 et à de nombreux autres travaux. Sa biographie UCLA indique que RSVP a été conçu et développé pendant son passage à Xerox PARC. Le RFC, lui, inscrit Robert Braden comme éditeur et Zhang, Steven Berson, Shai Herzog et Sugih Jamin comme auteurs, puis remercie une communauté plus large.

L’Internet Hall of Fame associe cette contribution à RSVP et aux usages ultérieurs de RSVP-TE. Cette reconnaissance n’est ni un recensement de déploiement, ni l’identité entre le protocole original de services intégrés et ses extensions d’ingénierie de trafic.

Les sources justifient les termes co-conceptrice, coauteure et contributrice aux standards. Elles ne font pas de Zhang l’inventrice unique, l’opératrice actuelle, la propriétaire du consensus IETF ou la garante d’un réseau réel. Cette modestie d’attribution respecte la structure même de RSVP : l’autorité est distribuée.

Sept reçus pour prononcer « réservé »

Un dossier exploitable relie sept preuves. Le chemin : émetteur, session, route, saut précédent et heure. La demande : récepteur, contenu Resv, filtres, flowspec, confirmation demandée et époque. L’autorité : décisions d’admission et de politique à chaque saut pertinent.

Viennent ensuite l’installation — cible, transaction et relecture du classificateur/programmateur — puis le renouvellement — dernier rafraîchissement, délai de nettoyage, identifiant Summary Refresh et NACK éventuel. Le sixième reçu limite ResvConf ou DREP au nœud et à l’état réellement observés. Le septième mesure le trajet et le service vécus dans une fenêtre définie.

Aucun reçu ne transforme les autres. Ensemble, ils permettent une phrase précise et temporaire. C’est moins spectaculaire qu’un voyant vert permanent, mais infiniment plus gouvernable.

Sources