Résumé

  • La RFC 3654 n’imposait ni de poursuivre systématiquement le transfert ni de l’interrompre après la perte d’association entre un Control Element (CE) et un Forwarding Element (FE). Elle exigeait que l’architecture détecte la rupture, rétablisse l’association, resynchronise l’état et permette de définir à l’avance la conduite du FE.
  • La RFC 7121 a ensuite décrit deux modes distincts : l’un ramène le FE à la phase pré-association ; l’autre peut essayer des CE de secours et maintenir le transfert jusqu’à l’expiration d’un délai. Une nouvelle association ne prouve toujours pas que tout l’état du FE a été restauré.

Séparer les fonctions n’éteint pas le routeur

En novembre 2003, la RFC 3654 décrivait un élément réseau composé de fonctions de contrôle et de transfert qui coopèrent, tout en pouvant apparaître comme un routeur intégré à ses voisins. Le CE traite notamment les protocoles de routage ou de signalisation ; le FE applique les opérations paquet par paquet. Il s’agit d’une séparation logique, pas d’une obligation d’installer deux châssis. Le document invoque la scalabilité et l’évolution indépendante des plans ; il ne prétend pas que cette architecture avait été largement déployée. RFC 3654

La difficulté apparaît lorsque le FE conserve encore des tables et des fonctions déjà configurées, mais n’a plus d’association avec son CE. Dire « le contrôleur a échoué » ne suffit donc pas à décrire le transfert : le FE peut poursuivre avec son état présent, s’arrêter ou tenter de joindre un secours.

La norme demandait un choix explicite, pas une réponse universelle

L’exigence architecturale 7 regroupe quatre étapes : détecter la perte d’association, la rétablir, resynchroniser efficacement l’état et prédéfinir la réaction du FE. Le texte cite le maintien du transfert et l’arrêt des opérations comme deux exemples. Il ne choisit pas l’un pour tous les équipements ; l’exigence de protocole 8 reprend la même distinction. RFC 3654

Le compromis est concret. Continuer peut préserver le trafic tout en laissant le FE sur un état qui ne reçoit plus d’instructions ; arrêter peut éviter cette période mais transforme l’association de contrôle en dépendance de service. Ce sont des conséquences à évaluer, non des incidents rapportés par la RFC. La règle est que l’architecture rende l’action prévisible avant la rupture.

La haute disponibilité ultérieure a ajouté un délai et des états

La RFC 5810, devenue spécification de protocole sur le Standards Track en 2010, a défini le protocole ForCES et son Transport Mapping Layer. La RFC 5812 a décrit le modèle du FE : capacité, état présent, configuration souhaitée et blocs fonctionnels. Ces informations ne disent pas la même chose. RFC 5810 RFC 5812

La RFC 7121 de 2014 a précisé une procédure de haute disponibilité au sein d’un même élément réseau. En mode 0, valeur par défaut décrite par la RFC, le FE retourne à la phase pré-association après la perte ; il faudra recréer son état s’il s’associe de nouveau. Le mode 1 permet une reprise : le FE essaie les CE de secours en rotation pendant le CE Failover Timeout Interval. Il peut continuer à transférer des paquets pendant l’état « non associé », selon la politique configurée. Si le délai expire sans association, le FE passe en pré-association et abaisse son chemin de transfert. Après reconnexion, le CE peut tenter de synchroniser l’état perdu ; la méthode ne fait pas partie de l’architecture ForCES et implique généralement de nouvelles configurations et requêtes. RFC 7121

La détection et le transfert restent deux signaux différents. La RFC 3654 admet que les heartbeats servant à repérer une perte d’association privilégient la rapidité plutôt qu’une livraison strictement fiable, tandis que les tables de transfert et les configurations critiques doivent être transportées de façon robuste. Un heartbeat manquant ne prouve donc ni une panne physique ni l’incorrectitude d’une route. RFC 3654

La RFC 3532, autre document ForCES, portait sur la réallocation dynamique des ressources et le retard possible de la représentation qu’en a le contrôleur. Cette question est voisine, mais distincte : ici, l’analyse suit la conduite du FE après une perte d’association, non le déplacement des ressources ou un inventaire devenu obsolète. La RFC 3654 est Informational ; les normes ultérieures racontent l’élaboration du protocole, pas son adoption par un opérateur donné. RFC 3532 RFC 3746 RFC 1812 Fiche RFC 3654 Datatracker RFC 3654

Sources