Résumé

  • RFC 1307 décrivait un protocole expérimental où un fournisseur de transport demandait l’activation ou la libération d’une liaison coûteuse, tandis qu’un contrôleur distinct s’occupait des détails matériels et administratifs.
  • Le fournisseur ne voyait que up ou down, mais DSLCP conservait six états internes afin d’ordonner les demandes opposées, les réponses en attente, les délais et les retransmissions.
  • Depuis l’état Up, une libération faisait envoyer la commande de démontage puis annoncer immédiatement down au fournisseur, avant que le contrôleur ait nécessairement répondu ; toute demande de libération recevait localement un succès.
  • Une réussite tardive, une transaction inconnue ou un avis asynchrone de panne exigeaient des traitements différents. Aucun de ces messages ne prouvait seul l’état physique, la capacité libérée, l’arrêt de la facturation ou l’issue des données.

Deux horloges pour un seul mot

Les liaisons commutées décrites par RFC 1307 étaient normalement déconnectées : les laisser établies coûtait cher. Le fournisseur de transport savait quand commençait et finissait une session, et pouvait donc demander une activation au premier besoin puis une libération au dernier. Un contrôleur de liaison séparé prenait en charge le matériel et les procédures administratives nécessaires.

Ce partage créait deux horloges. La première appartenait au service de transport, qui devait répondre rapidement à la demande présente. La seconde appartenait au contrôleur, dont l’opération pouvait rester en cours. DSLCP était placé entre les deux pour donner au fournisseur une interface stable sans lui imposer chaque détail du commutateur.

Publié en mars 1992, RFC 1307 avait le statut Experimental et visait des recherches supplémentaires. Le protocole provenait d’un projet de Cray Research consacré au contrôle de liaisons réseau situées en aval d’un hôte. Ce contexte ne documente ni un déploiement actuel ni un circuit particulier. Il révèle en revanche un choix d’abstraction très net : simplifier ce que le transport voit, même si le contrôle réel demeure asynchrone.

Le chemin de commande précédait la liaison commandée

Avant toute transaction DSLCP, un chemin réseau devait déjà relier l’hôte au contrôleur. Les messages de commande pouvaient circuler dans des datagrammes IP ou UDP, sans exigence de transport fiable. La liaison de données que l’on souhaitait préparer dépendait donc d’une autre voie, préexistante, pour recevoir ses ordres.

Cette séparation empêche de raconter l’activation comme un geste indivisible. Il y avait une demande de l’utilisateur de transport, une décision du fournisseur, un message DSLCP transmis sur le réseau de contrôle, un enregistrement chez le contrôleur et, seulement ensuite, un effet possible sur la liaison. La présence du premier chemin ne prouvait pas celle du second ; la transmission d’une commande ne prouvait pas son exécution.

Chaque message portait un identifiant de 16 bits, deux adresses d’extrémité de 32 bits, une fonction, un statut d’événement et un corps dont le sens revenait au contrôleur. L’identifiant devait être associé aux deux extrémités pour reconnaître une transaction de mise en liaison. Pris isolément, il n’était ni un circuit, ni une session, ni un jeton d’autorité universel.

Le statut d’événement avait lui aussi une grammaire limitée. Il décrivait la liaison contrôlée relativement à la dernière fonction demandée : activation réussie ou échouée, démontage réussi ou échoué, ou panne réseau asynchrone. Détacher le statut de l’identifiant, des extrémités, de la fonction antérieure et de l’heure faisait disparaître la question à laquelle il répondait.

Deux états devant la scène, six dans les coulisses

Le fournisseur de transport ne devait connaître que deux états, up et down. RFC 1307 lui demandait même de ne pas suivre le statut détaillé de cette liaison : DSLCP le conservait et pouvait effectuer une redirection ou d’autres traitements invisibles au fournisseur.

Dans les coulisses, la machine avait six états : Down, Coming Up, Up, Going Down, Bring Down et Bring Up. Les quatre premiers semblent décrire une progression ordinaire. Les deux derniers sont les traces d’une intention inversée avant la fin de l’opération précédente.

Si une libération arrivait pendant une activation, DSLCP passait à Bring Down. Il ne pouvait pas effacer la commande déjà partie. Il attendait donc sa réussite, puis envoyait aussitôt le démontage et passait à Going Down. À l’inverse, une nouvelle activation pendant un démontage conduisait à Bring Up : une fois la descente terminée, le protocole relançait la montée.

À cet instant, trois vérités pouvaient diverger sans contradiction. Le dernier utilisateur voulait une liaison active ; le contrôleur traitait encore une commande de démontage ; l’interface du fournisseur pouvait déjà afficher down. Les états supplémentaires conservaient précisément cet ordre temporel que l’affichage binaire supprimait.

Une libération réussissait d’abord comme promesse locale

L’activation et la libération n’étaient pas rapportées de la même manière. Le fournisseur apprenait si une demande particulière d’activation avait réussi ou échoué. Pour la libération, il pouvait supposer la réussite, car DSLCP retournait toujours un succès à la demande du fournisseur.

Le cas le plus parlant part de Up. À la réception d’une libération, DSLCP envoyait bring down au contrôleur, entrait dans Going Down et informait immédiatement le fournisseur que la liaison était en bas. La notification ne décrivait donc pas nécessairement une réponse du contrôleur. Elle marquait la convergence de l’interface locale vers l’intention de ne plus utiliser la liaison.

Cette règle protégeait le fournisseur contre la complexité du mécanisme. Elle n’était pas un rapport d’inspection physique. Entre l’envoi de la commande et la réponse du contrôleur, le circuit pouvait être en transition, le message pouvait être retardé, ou le contrôleur pouvait ne pas posséder l’enregistrement attendu. Le mot down restait exact dans le vocabulaire de l’interface, tout en étant insuffisant pour affirmer que des contacts avaient été ouverts, que de la capacité était disponible ailleurs ou qu’une facture avait cessé.

Les messages retardés pouvaient être vrais et déjà périmés

L’absence de transport fiable imposait des délais et des retransmissions. L’environnement des auteurs utilisait un délai de cinq secondes et trois nouvelles tentatives, tout en précisant que ces valeurs devraient être adaptées. Les requêtes redondantes pouvaient provoquer des réponses inattendues ; l’ordre des paquets pouvait faire parvenir une ancienne réussite après un changement d’intention.

RFC 1307 donne à cette possibilité une conséquence concrète. Une réussite d’activation reçue alors que DSLCP était Down pouvait provenir de requêtes dupliquées et d’un réordonnancement. Le protocole répondait par une commande de démontage. En Bring Down, la même réussite déclenchait également le démontage et le passage à Going Down. Le message pouvait décrire une activation réellement accomplie tout en étant devenu incompatible avec l’intention courante.

Une réussite de démontage reçue en Up révélait une autre rupture de synchronisation. Le texte indiquait qu’une erreur avait eu lieu. Son conseil prudent consistait à faire descendre la connexion et à resynchroniser, tout en reconnaissant qu’ignorer le message pouvait aussi être satisfaisant. L’événement inattendu ne livrait pas une histoire physique unique ; il obligeait à choisir une politique face à l’incertitude.

Quand le contrôleur ne connaissait plus la transaction

Dans l’état Up, un échec de démontage signifiait que DSLCP avait envoyé une commande portant une transaction invalide : le contrôleur ne possédait pas d’enregistrement correspondant au triplet formé par l’identifiant et les deux extrémités. La conduite prescrite était pourtant de continuer comme si la demande avait réussi.

Ce « comme si » est le cœur de la frontière. Pour la machine locale, l’absence d’enregistrement suffisait à poursuivre vers un état cohérent. Pour l’historien de l’incident, elle ne reconstruisait rien avec certitude. Le contrôleur pouvait avoir perdu un enregistrement, déjà achevé une opération, ou n’avoir jamais reconnu cette combinaison. La source ne permet pas de choisir un passé physique.

La panne réseau asynchrone formait encore un autre registre. Le contrôleur pouvait l’annoncer sans qu’elle soit la réponse à une libération de l’hôte. Depuis Coming Up, Bring Up ou Up, DSLCP passait à Down et prévenait le fournisseur. Confondre cet avis avec un succès de démontage attribuerait une intention locale à un événement distinct.

Enfin, RFC 1307 ne discutait pas les questions de sécurité. Ses adresses, chaînes du contrôleur et réponses ne peuvent donc pas prouver authentification, autorisation, intégrité ou confidentialité. Une machine d’états bien définie ne remplit pas le silence de sa source sur ces propriétés.

Source et limites de preuve

Cet article s’appuie exclusivement sur RFC 1307 — Dynamically Switched Link Control Protocol, publié en mars 1992. Son sujet est la composition entre vue binaire et contrôle à six états. Il se distingue du problème traité dans l’article RFC 1306 : recherche de route, demande d’activation externe, absence de données avant circuit complet, alias de route et minuterie séparée avant le premier octet. RFC 1307 ne prouve aucun contrôleur, circuit, échange, transfert, coût, usage de capacité, résultat de facturation ou livraison réels.