Résumé

  • Un rafraîchissement complet et un résumé peuvent tous deux prolonger un état RSVP, mais le premier remet aussi sa description en circulation. Les deux opérations ne fournissent donc pas les mêmes éléments de contrôle.
  • Le résumé permet de réclamer une description absente. Il ne garantit pas la détection d’un contenu corrompu conservé sous un identifiant reconnu : la RFC 2961 le précise expressément.
  • Des descriptions complètes occasionnelles, puis des mécanismes plus explicites de livraison et de détection des voisins défaillants, ont repris certaines fonctions de la répétition. Un simple changement de minuterie ne suffisait pas.

Deux opérations, un même compteur

Dans un relevé d’exploitation simplifié, deux opérations pourraient paraître identiques : une réservation a été rafraîchie à l’heure prévue, puis sa durée de vie a été prolongée. Pourtant, la première opération a pu transporter toute la description de l’état ; la seconde, seulement une référence à une description déjà enregistrée.

Le compteur de maintien en vie ne révèle pas cette différence. Le destinataire, lui, n’a pas reçu les mêmes informations. Dans un cas, le réseau lui a présenté de nouveau ce qu’il devait conserver. Dans l’autre, il lui a demandé de continuer à conserver ce qu’il connaissait déjà.

C’est le choix ouvert en avril 2001 par la RFC 2961, consacrée à la réduction du coût des rafraîchissements RSVP. Il serait réducteur de raconter cette évolution comme une simple économie d’octets. Elle modifiait aussi ce que l’opération périodique pouvait constater sur l’état du destinataire.

La répétition n’était pas entièrement redondante

RSVP organise la signalisation des réservations de ressources. Sa spécification de septembre 1997, la RFC 2205, repose sur des états entretenus périodiquement par des messages Path et Resv. Sans rafraîchissement pendant un délai suffisant, les états expirent. Un message de suppression peut accélérer leur disparition, mais sa perte ne doit pas les rendre éternels.

Répéter une description complète remplissait cependant une seconde fonction. Une information perdue ou manquée pouvait revenir. Une modification de route pouvait être accompagnée de la création de l’état nécessaire sur le nouveau trajet. La régularité du protocole compensait en partie l’imperfection de chaque échange individuel.

Cette assurance avait un coût. Lorsque les états se multipliaient, la répétition mobilisait de la transmission et du traitement. Allonger l’intervalle allégeait le travail courant mais pouvait retarder la réparation ; le raccourcir produisait l’effet inverse. Une optimisation devait donc décider quelle partie de cette répétition elle pouvait supprimer sans prétendre que ses autres fonctions n’avaient jamais existé.

La RFC 2961 commence par séparer les changements des répétitions. Une information nouvelle ou modifiée appelle un message déclenché par ce changement. Cela vaut aussi pour un objet de politique modifié, même si une lecture superficielle de la demande de ressources ne remarque aucune différence. Le résumé n’est pas un moyen d’introduire discrètement un nouveau contenu sous une ancienne référence.

Réduire la description, pas encore espacer les rendez-vous

Le destinataire doit d’abord avoir reçu l’état complet, accompagné d’un MESSAGE_ID. Ensuite, Srefresh peut citer l’identifiant d’un Path ou d’un Resv déjà annoncé. Le destinataire retrouve l’état et le rafraîchit sans reparcourir une nouvelle description complète reçue sur le réseau.

Dans cette extension de 2001, le résumé ne devait pas être envoyé moins souvent que le rafraîchissement complet qu’il remplaçait. Le premier gain concernait donc la quantité de description répétée, et non une permission générale de prolonger le silence. Confondre cette étape avec les intervalles beaucoup plus longs proposés ultérieurement ferait disparaître une distinction essentielle de la conception.

L’identifiant a lui-même un contexte : une adresse de générateur, un epoch et une valeur d’identification. Pour les messages Path et Resv initiaux, l’adresse pertinente est celle de RSVP_HOP, pas nécessairement l’adresse source de l’enveloppe IP. L’epoch permet notamment de distinguer des périodes d’exécution séparées par un redémarrage.

Ce dispositif nomme une annonce et l’état associé. Il ne calcule pas une empreinte de son contenu. Retrouver la référence n’est donc pas comparer tous les champs du document qu’elle désigne. Cette limite n’est pas un défaut caché dans un détail de format : elle découle de ce que le résumé choisit de ne pas transporter.

La réparation savait demander ce qui manquait

Lorsqu’un destinataire concerné ne trouve pas l’état indiqué, il peut renvoyer MESSAGE_ID_NACK. L’émetteur qui possède encore l’état correspondant doit alors transmettre un Path ou un Resv complet. S’il ne possède lui-même aucun état correspondant, il n’a pas de description à restituer.

Cette réponse négative ne rejette pas une demande de bande passante. Elle indique un défaut de correspondance dans l’état mémorisé. L’admission des ressources reste une autre décision. Le succès de la retransmission d’une description ne permet pas davantage d’affirmer que toute la réservation, d’un bout à l’autre, a été accordée.

Le multicast impose encore de vérifier que le destinataire est concerné. Des informations sur la source et le groupe, ainsi que les vérifications de chemin inverse, empêchent un nœud sans rôle pour le flux de réclamer inutilement un état qu’il n’est pas censé avoir. Une liste d’identifiants n’est pas une liste universelle que chaque routeur devrait reproduire.

La réparation est ainsi précise pour une certaine classe de défauts : une référence attendue ne trouve pas sa description. Mais cette précision ne doit pas lui attribuer une compétence supplémentaire. Si la référence trouve une entrée dont le contenu est erroné, l’absence de réponse négative ne prouve pas que l’entrée est correcte.

Le paragraphe qui refusait de promettre trop

La section 5.5 de la RFC 2961 reconnaît explicitement cette différence. Les résumés répondent à des événements courants tels que la perte de paquets ou les changements de route, sans offrir exactement les propriétés de réparation du rafraîchissement complet. La corruption interne d’un état est l’exemple donné par le texte.

Il faut lire cette réserve pour ce qu’elle est : une limite de conception, pas un relevé d’incidents. On peut imaginer une entrée toujours accessible par son identifiant mais dont une partie du contenu a changé à tort. Le résumé entretient alors une référence reconnaissable sans nécessairement apporter l’information qui permettrait de corriger son contenu.

La spécification propose deux compléments qu’il ne faut pas confondre. Le premier mémorise un résultat de contrôle calculé sur l’état interne, puis le recalcule pour détecter un changement qui aurait dû provoquer l’envoi d’un message mais ne l’a pas fait. Le texte précise que ce moyen ne protège pas contre la corruption interne. Il couvre l’oubli d’un déclenchement.

Le second remet périodiquement une description complète dans l’échange. Envoyer Path et Resv moins souvent que les résumés conserve une partie du gain tout en retrouvant les possibilités de réparation du rafraîchissement ordinaire. La fréquence relative doit pouvoir être réglée ; le même état n’a pas besoin d’être envoyé simultanément sous les deux formes.

Ce partage est plus intéressant qu’un retour pur et simple à la répétition d’origine. Il permet de dissocier le rythme du maintien courant de celui de la remise à disposition des descriptions complètes. L’économie ne supprime pas le choix opérationnel ; elle le rend plus explicite.

Ni accusé de réception, ni preuve cryptographique

La RFC 2961 comporte aussi des accusés de réception et des retransmissions rapides. Ils servent à mieux livrer des messages individuels. Un message invalide sur le plan syntaxique ne doit pas être acquitté. Même une réception valide ne vaut toutefois ni décision d’admission, ni mesure de la qualité du trafic réel.

De même, Bundle réunit plusieurs messages RSVP complets dans un datagramme ; il ne transforme pas plusieurs demandes en une réservation unique. Le conditionnement, la livraison et le contenu de l’état sont des couches différentes du problème.

L’authentification ne les fusionne pas. La RFC 2747 traite de la protection de l’intégrité des messages et de l’authentification des voisins selon les hypothèses de clés employées. MESSAGE_ID n’est pas ce mécanisme. Et un résumé authentique ne restitue pas les champs qu’il a volontairement omis. Ces documents éclairent un choix historique, sans constituer une recommandation cryptographique actuelle.

La mémoire du voisin ne créait pas le chemin

En octobre 2007, la RFC 5063 étend la récupération après redémarrage pour GMPLS RSVP. Le sens du résumé peut alors s’inverser : un voisin aval cite des états Path qu’il avait reçus, afin d’aider un contrôleur amont redémarré. Il ne résume plus simplement ce qu’il avait lui-même envoyé.

Lorsque les anciennes références sont reconnues, cette récupération peut éviter de renvoyer toutes les descriptions. Sinon, un RecoveryPath apporte davantage d’informations. Des indications de capacité et un marquage spécifique distinguent cette procédure d’un maintien ordinaire.

Le texte interdit néanmoins de créer un état de transfert manquant sur la seule foi d’un RecoveryPath. La récupération doit associer la signalisation à l’état de transfert conservé ; une création nouvelle exige les procédures appropriées, notamment un Path amont ou une instruction de gestion à l’entrée. Identifier le voisin ne garantit pas non plus que sa correspondance entre l’avant et l’après-redémarrage soit exacte.

Le principe reste le même : retrouver une description utile ne donne pas à cette description une autorité illimitée sur ce qu’elle ne démontre pas.

Quand le délai augmente, une autre surveillance prend le relais

La RFC 5439, publiée en 2009, examine les limites de passage à l’échelle de RSVP-TE. La mémoire et le traitement par état restent importants. Une longue liste d’identifiants demande toujours du travail ; réduire les paquets ne fait pas disparaître les réservations individuelles. Cette analyse ne fournit pas une capacité universelle des équipements actuels.

La RFC 8370, de mai 2018, associe ensuite de longs intervalles à un ensemble d’exigences : livraison fiable, traitement plus fréquent des messages non acquittés, détection explicite de la perte de l’adjacence de signalisation et déclaration des capacités. Une adjacence défaillante entraîne le traitement des états appris par elle comme expirés.

L’ancienne répétition n’est donc pas simplement supprimée. Une partie de son rôle de détection est attribuée à un mécanisme identifiable. Les voisins sans la capacité requise conservent les intervalles traditionnels. Renforcer les acquittements dans cette nouvelle technique ne permet pas de réinterpréter toutes les implémentations de 2001 comme si elles avaient déjà pris cet engagement.

Le registre RSVP d’IANA fixe les valeurs des messages, objets et capacités. Il rend possible un langage commun ; il ne prouve pas qu’un voisin l’utilise. La capacité doit se manifester dans les échanges, et sa disparition doit être prise au sérieux.

L’histoire documentée est celle de ces règles et de leurs limites, non celle d’une adoption universelle. Elle montre surtout pourquoi un état maintenu en vie n’est pas nécessairement un état examiné à nouveau. Ce qui avait été économisé devait rester visible dans le raisonnement sur la panne.