Résumé

  • RFC 3612 distingue la panne de session, le redémarrage du nœud, la conservation de l’état de transfert et le résultat observé sur les paquets. Une capacité négociée ne remplace aucune de ces preuves.
  • La conservation ouvre une période d’autorité provisoire : les liaisons label/FEC deviennent périmées, les temporisations bornent leur survie, et toute réattribution concurrente peut faire porter deux sens au même label.

Un reçu pour l’intention

Le détail le plus révélateur de RFC 3479 tient en une phrase opérationnelle : un LSR peut acquitter une demande de label dès qu’il l’a enregistrée de façon sûre, avant d’avoir produit la réponse correspondante. L’accusé prouve alors la durabilité d’un message. Il ne prouve ni son traitement complet, ni l’installation d’une entrée, ni le passage d’un paquet.

Cette séparation importe lorsqu’une organisation réduit un redémarrage à une suite de coches vertes. Session rétablie, checkpoint reconnu, base de labels resynchronisée : chacune de ces coches ferme une étape précise. Aucune ne témoigne, seule, de la continuité du plan de transfert. Le vocabulaire doit conserver les verbes exacts : reçu, sécurisé, traité, installé, rafraîchi, observé.

RFC 3612, publié en septembre 2003 comme document informationnel de l’IETF, compare le redémarrage gracieux de RFC 3478 et la tolérance aux pannes de RFC 3479. Il ne normalise pas un résultat universel et ne décrit aucun déploiement particulier. Son apport est de dire quand chaque mécanisme peut être utile et où ses présupposés s’arrêtent.

LDP s’appuyait sur TCP pour l’échange fiable des liaisons entre classes d’équivalence de transfert et labels. Le comportement de base associait la perte de la session à la destruction des LSP et à la libération des ressources. Les extensions de reprise rompent volontairement ce lien : un état peut survivre pendant que l’autorité de la session est reconstruite. C’est un gain de disponibilité, mais aussi une dette de preuve.

Deux pannes qui ne racontent pas la même histoire

Une panne de session laisse les deux pairs actifs tandis que leur relation LDP disparaît. RFC 3612 précise que cela n’implique pas la panne du canal de données, même lorsque la signalisation est dans la bande. Une panne de nœud, elle, redémarre le routeur ou son composant LDP ; le matériel de transfert peut ou non conserver ses entrées.

Il faut donc observer séparément la session TCP/LDP, le processus de contrôle, la table de transfert et les paquets. Une session morte ne prouve pas que les paquets se sont arrêtés. Une session revenue ne prouve pas qu’ils ont continué. Le document exclut en outre les chemins de protection et la protection de liens ou de tunnels : la reprise d’état n’est pas une preuve de reroutage rapide.

Pour préserver effectivement le trafic, les deux extrémités doivent au moins conserver leur état de transfert. Si un seul côté le fait, le mécanisme de RFC 3478 peut faciliter la reconstruction ultérieure, mais le trafic reste affecté pendant la rupture. Une annonce de capacité indique ce qu’un pair sait négocier ; elle ne dit pas ce qu’il a réellement conservé lors de cet épisode.

Les temporisations louent une autorité provisoire

Dans RFC 3478, le FT Reconnect Timeout demande au voisin de retenir l’état existant après la perte de communication. Le Recovery Time décrit combien de temps le routeur redémarré gardera ce qu’il a préservé. Une valeur nulle signifie que cet état n’est pas disponible. Les entrées conservées sont marquées périmées, puis confirmées par de nouvelles annonces ou supprimées à l’expiration.

Une longue temporisation donne davantage de temps à une grande base de labels, mais prolonge aussi la vie d’une erreur. Une temporisation courte réduit cette exposition, au risque de supprimer un état encore nécessaire. Le bon réglage dépend du nombre de LSP, du débit de signalisation, de la capacité de traitement et du taux de changement. Il doit être fondé sur des mesures de reprise, non sur le nom « graceful ».

RFC 5919 a ensuite défini la notification End-of-LIB pour signaler la fin d’une phase d’annonce. Son absence peut être remplacée par une temporisation locale. Ce signal borne une phase de protocole ; il ne certifie ni l’installation distante, ni la cohérence des autres mécanismes d’allocation, ni le résultat des paquets.

Le checkpoint ne photographie pas le réseau

RFC 3479 ajoute des numéros de séquence, des ACK, des checkpoints et une procédure de mise au repos avant un arrêt contrôlé. Des acquittements fréquents réduisent la queue récente susceptible d’être perdue, au prix d’un trafic et d’un traitement supplémentaires. Des checkpoints espacés simplifient l’implémentation mais laissent une fenêtre plus grande à reconstruire.

Avant une mise à niveau planifiée, la procédure de « cork » peut sécuriser les opérations antérieures et empêcher de nouveaux changements. Elle produit une frontière plus nette. Elle ne transforme pas l’état antérieur en vérité : une erreur correctement sauvegardée demeure une erreur.

RFC 3612 le dit explicitement. La conservation peut maintenir un état incorrect ; dans un cas extrême, cet état peut être la cause même de la panne. Rejouer les échanges peut éliminer ce qui n’est plus confirmé, mais peut aussi recréer la même erreur par le même chemin de calcul. La robustesse de la persistance et la justesse du contenu sont deux propriétés.

Quand un label porte deux sens

La période de resynchronisation autorise un conflit dangereux. Un routeur amont peut continuer à utiliser un ancien label pour une FEC tandis que le routeur aval attribue le même nombre à une autre FEC. Une nouvelle annonce et une ancienne entrée peuvent alors être valides dans deux récits locaux incompatibles.

Le risque dépasse la session. Une configuration statique, une autre instance LDP ou un autre protocole peut partager l’espace de labels. Le label retenu pour la reprise ne doit pas être réutilisé ailleurs avant l’extinction de son autorité. Un gestionnaire commun ou des espaces segmentés peuvent imposer cette règle, mais leur existence doit être vérifiable.

Les considérations de sécurité relient directement cette erreur à la livraison. Continuer à utiliser un label après l’expiration de la session qui l’avait autorisé peut envoyer des données au mauvais destinataire ; RFC 3479 envisage également service non autorisé ou déni de service si la réutilisation intervient trop tôt. Ce sont des risques du mécanisme, pas la preuve d’un incident réel.

Le reçu exploitable

Un dossier de reprise doit identifier l’époque de session, le type de panne, les capacités annoncées, les deux temporisations et la liste exacte des entrées conservées. Pour chaque label, il garde l’allocateur, l’espace, la FEC, le prochain saut, l’état périmé et l’issue : rafraîchi, remplacé, retiré ou expiré.

Il conserve ensuite la chaîne d’exécution : message reçu, enregistré, traité, installé, puis observé. Il indique le dernier checkpoint, les opérations rejouées, l’arrivée réelle ou simulée par timeout d’End-of-LIB et les conflits détectés. Enfin, il relie des sondes bidirectionnelles et des compteurs sur les FEC concernées sans les réduire au statut du protocole.

Le code en fonctionnement produit les transitions ; les RFC fournissent un langage commun pour les comparer. La discipline décisive consiste à ne pas promouvoir une mémoire préservée en verdict de continuité avant qu’un témoin du plan de données ne l’ait confirmée.

Sources