Résumé

  • RFC 2383 affectait un circuit virtuel ATM à un seul saut ST2+ et séparait les plans utilisateur, de contrôle et de gestion : le support réservé aux données n’était pas la même preuve que le chemin capable d’annoncer sa panne.
  • La reprise ST2+ étant jugée incomplète et plusieurs agents pouvant recevoir la même alerte ATM en même temps, la spécification exigeait NoRecover. Un refus explicite était plus interopérable qu’une promesse de reprise sans autorité commune.

Réserver de la capacité ne revient pas à réserver le chemin du retour après une panne.

C’est la limite que rend visible RFC 2383, publié en août 1998 comme document informatif sur le transport de ST2+ au-dessus d’ATM UNI 3.1. La correspondance était étroite : un saut ST2+ utilisait un circuit virtuel ATM, le circuit n’était pas partagé avec d’autres sauts et un saut n’était pas réparti sur plusieurs circuits. Une demande abstraite de ressources obtenait ainsi un support identifiable.

La reprise ne bénéficiait pas de la même certitude. Toute implémentation devait sélectionner NoRecover dans CONNECT. Une requête contraire devait recevoir REFUSE avec la raison NoRecover. Le texte ne présentait pas cette situation comme une reprise automatique partielle et ne confondait pas l’alarme d’ATM avec la sémantique absente de ST2+. Il déclarait la reprise du flux non prise en charge et la confiait à l’application.

Ce choix est important parce que l’environnement possédait déjà plusieurs éléments que l’on aurait pu appeler trop vite « reprise ». ATM pouvait signaler la perte d’une connexion. Les agents ST2+ échangeaient des messages SCMP. Le FlowSpec réservait des ressources saut par saut. Un nouveau circuit pouvait être établi. Rien de tout cela ne décidait qui devait agir, comment empêcher deux agents de reconstruire en même temps, comment rattacher le nouveau segment au bon flux, ni comment prouver que l’application avait retrouvé un résultat valable.

Un saut, un circuit, plusieurs vérités

RFC 2383 distinguait le plan utilisateur, le plan de contrôle et le plan de gestion. Les données ST2+ empruntaient la connexion ATM du saut. Les agents échangeaient SCMP sur le plan de contrôle. La gestion locale choisissait les adresses, établissait les circuits et observait leur état.

Ces plans ne se réduisaient pas à un chemin unique. Le circuit virtuel de SCMP n’était pas prescrit : une implémentation pouvait réutiliser un circuit IPv4 ou établir un circuit dédié au contrôle ST2+. Les données et SCMP d’un flux devaient suivre la même direction de routage ST2+, tandis que la route IPv4 vers la même adresse pouvait prendre la direction opposée. Le contrôle pouvait donc rester joignable alors que le circuit de données réservé était rompu, ou tomber indépendamment de lui.

Dire que « le réseau est joignable » restait insuffisant. Un paquet IPv4 avait-il une route ? SCMP atteignait-il l’agent ? Le commutateur ATM conservait-il l’appel ? Les données utilisateur traversaient-elles ce VC précis ? Chaque réponse constituait une preuve dans une couche différente. Aucune ne certifiait automatiquement les autres.

La règle un saut–un VC rendait la preuve plus concrète, mais aussi plus locale. Le circuit portait ce segment déterminé. Un flux de bout en bout dépendait de plusieurs sauts, circuits et agents. La disparition d’un VC identifiait un segment cassé ; elle ne reconstruisait pas le flux entier.

Détecter n’était pas coordonner la reprise

La fonction HELLO de ST2+ pouvait ne pas être prise en charge sur ATM, celui-ci étant censé fournir une indication suffisante de panne de connexion. Mais les données et SCMP pouvaient emprunter deux circuits distincts. Un contrôle de vie sur un chemin ne prouvait pas l’état de l’autre.

La séparation devenait plus délicate lors d’une panne. RFC 1819 décrivait une reprise ST2+, mais RFC 2383 la jugeait peu claire et incomplète dans ce contexte. ATM pouvait avertir tous les participants touchés. Plusieurs agents ST2+ risquaient donc de détecter le même défaut presque simultanément.

S’ils agissaient indépendamment, leurs actions entraient en concurrence. Un agent pouvait libérer l’ancien état pendant qu’un autre reconstruisait ; deux segments de remplacement pouvaient apparaître ; l’aval pouvait se rattacher à la mauvaise tentative. Il ne suffisait pas d’avoir un déclencheur. Il fallait une règle d’autorité, une identité commune de reprise, un ordre d’opérations et des reçus distincts pour la détection, la libération, la nouvelle admission, la reconstruction des sauts et l’acceptation par l’application.

RFC 2383 ne fournissait pas ce contrat interopérable. NoRecover nommait donc exactement la surface de contrôle manquante. Un commutateur pouvait dire vrai en annonçant la disparition d’un VC, un agent en confirmant qu’il avait reçu l’alerte et un nouveau circuit en attestant son admission. L’application pouvait encore subir une interruption, un doublon ou l’absence du flux attendu.

L’application héritait de la dernière obligation

Dire que l’application devait assurer la reprise ne lui conférait pas une capacité automatique. La phrase transférait la question non résolue à la couche qui connaissait le sens de la continuité. Une application pouvait reprendre à un numéro de séquence. Une autre devait abandonner le résultat partiel et créer un nouveau flux. Une opération aux effets non répétables pouvait exiger une décision humaine.

Le réseau pouvait offrir un autre trajet sans savoir si l’ancien et le nouveau formaient une seule opération correcte. La réussite d’un VC de remplacement ne suffisait donc pas à déclarer le flux rétabli. La preuve devait joindre l’alerte, l’identité des anciens et nouveaux circuits, la libération de la réservation, la reconstruction ST2+, l’identité de bout en bout et le reçu final de l’application.

La lecture par les couches de réalité proposée par Heng Lu éclaire ce point. L’état physique, l’appel ATM, l’état de l’agent ST2+, l’échange SCMP, la session applicative et le résultat visible sont voisins, mais non synonymes. Les fondre dans un voyant vert simplifie le tableau de bord en supprimant les distinctions qui rendent l’énoncé vrai ou faux. Celui qui contrôle le mot « rétabli » n’est pas forcément celui qui supporte les effets d’une perte ou d’une répétition.

L’initiateur du circuit relevait aussi d’une politique

Avant même la panne, l’établissement du circuit avait un acteur. Pour les circuits virtuels commutés, RFC 2383 autorisait le choix de l’initiateur ATM selon la politique d’exploitation ou de facturation. Cette direction était indépendante de l’orientation émetteur–récepteur utilisée pour construire le flux ST2+.

La partie qui paie pouvait initier l’appel, celle qui bâtit le flux pouvait attendre une action du saut suivant, et le premier agent informé de la panne pouvait ne pas être autorisé à créer un nouveau circuit facturable. Une reprise qui ignore ces pouvoirs et ces incitations peut paraître techniquement cohérente tout en restant inexécutable.

La conversion du FlowSpec en paramètres ATM avait une autre limite nette. Les caractéristiques de trafic et la qualité de service étaient traduites à l’aide des modèles de RFC 2211 et RFC 2212 et de la signalisation de RFC 1755. UNI 3.1 ne permettait pas de modifier la QoS d’une connexion établie. Si une modification de FlowSpec prise en charge exigeait d’autres ressources, il fallait libérer les anciennes connexions ATM et en créer de nouvelles.

Il ne s’agissait pas d’une mise à jour sur place, mais d’un passage de garde entre deux allocations. Le moment où l’ancien circuit cessait, celui où le nouveau était admis et l’état conservé en cas d’échec dépendaient de l’implémentation et de la politique. La RFC précisait la correspondance et la nécessité de reconstruire ; elle ne publiait ni mesure de bascule sans perte ni preuve de continuité applicative.

Cette frontière distingue cette histoire de celle de RFC 2380. RFC 2380 portait sur la modification d’une réservation, la reduced reservation et le point d’engagement entre l’ancienne et la nouvelle allocation. RFC 2383 possède une autre question : plusieurs agents constatent une panne ATM, mais aucun contrat complet ne désigne l’autorité de reprise.

Refuser explicitement créait aussi de l’interopérabilité

On peut lire NoRecover comme le signe d’une fonction inachevée. C’était également une décision positive. Si une implémentation exécutait une séquence privée tandis que l’autre interprétait le même état autrement, elles pouvaient produire des doublons, des réservations orphelines ou deux significations du même flux.

Le drapeau obligatoire exposait la limite dès l’établissement. La demande recevait un REFUSE motivé plutôt qu’une divergence cachée jusqu’à la panne. Une interface qui échoue précisément est plus sûre qu’une interface dont les deux extrémités ne partagent pas la définition du succès.

Dans la perspective de la spécification initiale minimale de Heng Lu, il s’agit d’une incomplétude disciplinée. Une spécification minimale ne doit pas remplir une zone non prouvée avec des mots ressemblant à des garanties. Elle définit le noyau partagé, localise la décision privée et laisse au code en fonctionnement le soin de démontrer un contrat plus fort. Les circuits dédiés, l’adressage, l’établissement et le mappage des ressources appartenaient au noyau ; la reprise du flux n’y appartenait pas.

Supprimer NoRecover exigerait davantage qu’un nouveau paragraphe. Il faudrait confronter plusieurs agents à la même alerte ATM, démontrer la sélection d’une seule autorité, supprimer les doublons, solder l’ancienne réservation, établir le remplacement, le rattacher au flux exact et rendre un résultat sans ambiguïté à l’application. Les essais devraient perdre des messages de contrôle, inverser les routes et faire tomber séparément les VC de données et de contrôle.

RFC 2383 ne revendiquait aucun de ces résultats. Son statut informatif limite aussi la conclusion historique : il s’agit d’une spécification, non d’une enquête de déploiement. L’historique de l’IETF Datatracker montre la trajectoire du document, pas une adoption généralisée.

La sécurité protégeait un bord de la chaîne

La section de sécurité restait elle aussi bornée. Les extensions ATM minimales et les corrections ne devaient pas affaiblir ST2+ ou UNI 3.1. Un numéro d’appelant fourni et vérifié par le réseau pouvait contribuer à l’authentification.

Contribuer ne signifie pas achever la preuve. L’identité de l’appelant pouvait aider à reconnaître l’initiateur, mais pas à établir que le FlowSpec était autorisé, que le nouveau VC appartenait au flux défaillant ou que l’application acceptait la session reconstruite. Identité, ressource, état et résultat demandaient des preuves complémentaires.

Le document ne permet donc pas d’affirmer qu’un opérateur donné a déployé le protocole, qu’une latence a été tenue, qu’un incident réel a été récupéré ou qu’une politique de facturation a choisi une partie déterminée. Ces faits exigent leurs propres traces d’exploitation.

La leçon établie est plus durable : réserver une ressource, détecter une panne, garder le contrôle joignable, reconstruire un flux et réussir au niveau applicatif sont cinq affirmations différentes. Les trois premières peuvent être vraies sans la quatrième ; l’infrastructure peut être rebâtie sans la cinquième. En 1998, RFC 2383 préservait cette distinction avec un drapeau sans détour : NoRecover.

Il ne disait pas que rien n’était possible après la panne. Il refusait que le réseau promette une reprise achevée avant d’en partager l’autorité, l’ordre et le reçu final. Le circuit pouvait réserver les ressources. Les agents pouvaient apprendre qu’il était rompu. Le sens de recommencer appartenait encore à l’application.

Sources