Résumé

  • RFC 3473 autorisait un Notify RSVP-TE à atteindre directement un nœud non adjacent enregistré et utilisait l’ACK de RFC 2961 pour confirmer sa réception.
  • Notify ne remplaçait ni PathErr ni ResvErr : l’ACK attestait l’arrivée de l’alarme, pas la convergence d’état, la commutation de protection ou la reprise du service.

Une alarme peut aller plus vite que la réparation qu’elle annonce. RFC 3473 donna une forme protocolaire à cet écart.

Publié en janvier 2003, le document adapta RSVP-TE à GMPLS. Les fonctions générales de RFC 3471 devinrent des objets Path et Resv pour les étiquettes de paquets, créneaux, longueurs d’onde et ports. RFC 3472 faisait le travail parallèle pour CR-LDP. Au milieu de cet ensemble, Notify répondait à un besoin précis : prévenir rapidement le nœud capable de réagir sans attendre la progression saut par saut d’un message d’erreur.

Un objet Notify Request pouvait voyager dans Path pour demander une notification amont ou dans Resv pour demander une notification aval. Il contenait l’adresse IPv4 ou IPv6 du nœud à avertir. Le récepteur devait conserver cette adresse dans l’état correspondant ; un nœud de transit la propageait normalement.

Cette adresse n’était pourtant pas une identité immuable. Une politique locale pouvait la remplacer en sortie. Si plusieurs demandes figuraient dans le même message, seule la première avait un sens. Et la présence de la demande ne garantissait pas la production future d’un Notify.

Lorsqu’une erreur admissible apparaissait, le détecteur pouvait viser un nœud non adjacent. Le Notify était soit relayé intact par les autres nœuds, soit encapsulé dans un nouvel en-tête IP destiné directement à la cible. Il partait sans option Router Alert. Son trajet de preuve était donc distinct de la panne et du chemin ordinaire de PathErr ou ResvErr.

ERROR_SPEC indiquait l’erreur ainsi que le nœud détecteur ou le lien défaillant. Les descripteurs de session bornaient les LSP concernés. Une même erreur pouvait produire des avis dans les deux sens, mais aucun nœud ne devait en générer sans demande préalable appropriée.

RFC 2961 fournissait Message ID et ACK. Le nœud cible devait accuser réception. Cette paire répondait à une question limitée : ce message RSVP identifié est-il arrivé à cette destination ?

Elle ne confirmait ni la vérité physique de la panne, ni la suppression des états à chaque saut, ni la capacité d’un chemin de secours, ni le basculement d’une matrice optique, ni le retour des paquets. RFC 3473 le disait sans ambiguïté : Notify ne remplaçait pas les messages d’erreur existants. Le raccourci d’alarme complétait la machine d’état RSVP ; il ne la validait pas en bloc.

Le bit Path_State_Removed rendait la différence encore plus nette. Un nœud pouvait signaler dans PathErr qu’il avait réellement supprimé l’état Path associé. L’ACK de Notify et cette preuve d’action locale étaient deux reçus différents. Aucun ne décrivait seul le chemin entier.

Le regroupement compliquait aussi le temps. Les avis visant le même nœud et partageant ERROR_SPEC devaient être combinés si possible. Événement, minuterie ou autre méthode relevaient de l’implémentation ; l’intervalle par défaut d’une minuterie était une milliseconde. Le regroupement réduisait la charge, mais l’heure de l’enveloppe ne devenait pas l’heure exacte de chaque événement, et plusieurs sessions ne partageaient pas pour autant une réparation atomique.

La procédure administrative refusait elle-même de confondre avis et résultat. Après un Notify portant l’état Down, l’émetteur devait voir revenir un Path correspondant avec Down dans un délai configurable, trente secondes par défaut. Sans cette confirmation, il lançait suppression et erreurs complémentaires. La première alarme n’était pas tenue pour une fin.

Une panne de canal de contrôle pouvait en outre laisser le transfert intact. Pendant l’attente de redémarrage, les nœuds conservaient l’état RSVP et MPLS. Ils pouvaient annoncer « canal dégradé », puis « canal actif ». Le second message prouvait le retour d’une communication, pas nécessairement la resynchronisation de tous les états ni le rétablissement du signal ou du trafic.

L’envoi direct changeait enfin la sécurité. Le modèle ordinaire de RSVP authentifiait saut par saut. Un Notify non adjacent pouvait contourner cette chaîne ; RFC 3473 proposait IPsec pour une protection équivalente, ou la désactivation du mode direct. Même authentifiée, une alarme accusée reçue ne prouvait que des faits bornés sur son émetteur, son contenu et sa livraison.

RFC 4090, puis RFC 4872 et RFC 4873, détaillèrent d’autres portées de protection et de récupération. Ils ajoutèrent des actions, sans transformer le signalement, la décision, la commutation et le résultat observé en un fait unique.

Dans la lecture de Heng Lu, le code en fonctionnement garde la priorité : le symbole Notify ne devient effet qu’après observation de la transition qu’il devait déclencher. La spécification minimale laisse le choix de regroupement et de politique à l’implémentation. Les niveaux de réalité empêchent l’ACK d’emprunter l’autorité d’un service réellement rétabli.

Un dossier fidèle conserve la demande, sa destination effective après politique, ERROR_SPEC, les sessions, Message ID, envoi, réception et ACK. Il garde séparément PathErr ou ResvErr, suppression d’état, choix de protection, programmation matérielle, signal, trafic dans les deux sens et résultat applicatif. « Rétabli » n’est justifié qu’au bout de cette chaîne.

Sources