Résumé

  • RFC 2353 utilisait volontairement UDP/IP comme contrôle de liaison natif sous APPN/HPR ; HPR RTP prenait en charge la fiabilité de bout en bout et LDLC la détection de vie.
  • L’option d’arrêter les sondes pendant l’inactivité réduisait le trafic, mais un voisin pouvait détecter la panne et supprimer le lien longtemps avant l’autre.
  • Au retour du trafic, une réactivation légitime pouvait être rejetée comme liaison parallèle, ou une activation de session envoyée vers un état déjà abandonné. La récupération devait réinterroger les états.

Une sonde périodique n’est pas seulement une dépense. C’est un rendez-vous au cours duquel deux machines renouvellent une petite part de réalité commune. RFC 2353 autorisait à suspendre ce rendez-vous lorsque la liaison était inactive. Le gain était concret ; la dette l’était aussi.

Le document de mai 1998 décrivait APPN/HPR sur réseaux IP. Classé Informational, il ne définissait pas une norme Internet. Il consignait une architecture passée au statut « Closed Pages » dans l’APPN Implementers’ Workshop en décembre 1997, c’est-à-dire suffisamment détaillée pour l’interopérabilité recherchée par ce processus.

L’objectif était de faire d’IP un contrôle de liaison natif pour HPR, de conserver les classes de service et d’éviter de prédéfinir chaque connexion grâce au modèle optionnel de réseau de connexion. Le choix de UDP était donc architectural, pas accidentel.

Répartir la fiabilité plutôt que la dupliquer

RFC 768 fournit le datagramme UDP et ses ports, sans état de connexion ni avis de rupture. RFC 791 fournit l’acheminement IPv4. RFC 2353 confiait les pertes, doublons, retards, désordres et ruptures aux couches supérieures.

Le RTP propre à HPR — à ne pas confondre avec le protocole temps réel de l’IETF — assurait retransmission sélective, remise en ordre et contrôle adaptatif du débit et de la congestion. LDLC gérait les échanges de contrôle et la vie logique du lien. Ajouter TCP aurait dupliqué des files de retransmission, minuteurs et blocs de contrôle, au prix de l’échelle.

Cette organisation produit des preuves distinctes. UDP/IP atteste un datagramme dans son périmètre. RTP atteste la récupération et l’ordre de son transport. LDLC atteste un test sur une instance de liaison. Aucun ne prouve à lui seul que le voisin conserve la même instance active.

Le silence créait deux chronologies

Puisque UDP ne signalait pas les ruptures, LDLC devait tester périodiquement les liens HPR/IP. Le texte indique notamment des valeurs par défaut de dix secondes pour le rythme de vie, quinze secondes pour la relance et trois essais.

L’option d’optimisation arrêtait les sondes quand aucune donnée n’avait circulé. Elle pouvait permettre à une infrastructure sous-jacente de se mettre en sommeil. Mais si une panne survenait, un nœud pouvait l’apprendre avant l’autre.

Le nœud informé désactivait son instance. Plus tard, sa tentative de réactivation rencontrait chez le voisin une ancienne instance toujours marquée active. Celui-ci pouvait répondre que les liaisons parallèles n’étaient pas prises en charge. Inversement, le voisin non informé pouvait envoyer des données ou une nouvelle activation de session sur le lien ancien ; l’autre, qui l’avait supprimé, pouvait les jeter.

Le problème n’était pas que l’un « mentait ». Les deux états reflétaient des observations différentes. L’erreur serait de prendre l’un d’eux pour un reçu partagé.

Les règles de reprise remettaient la preuve en circulation

RFC 2353 demandait, lors d’un rejet pour liaison parallèle, de tester la vie des liaisons actives pertinentes utilisant la même paire d’adresses IP et d’autres paires SAP. Une entrée périmée pouvait ainsi être invalidée.

Lorsqu’un XID d’activation arrivait avec la même paire IP et SAP qu’une liaison active, le nœud devait supprimer l’ancienne instance et permettre sa reconstruction, avec un minuteur contre les XID errants. Il était aussi recommandé d’essayer une réactivation avant de tirer toutes les conséquences d’une panne détectée par LDLC.

Les codes de sens relatifs aux liaisons parallèles expliquaient un refus local. Ils ne reconstituaient ni la première rupture, ni la totalité de l’état distant, ni le résultat d’une application. La télémétrie restait un reçu de couche.

Une liaison vivante n’était pas une session réussie

La séparation est essentielle. RTP pouvait récupérer un flux de bout en bout sans garantir que les deux automates LDLC nommaient la même instance. Un test de vie réussi ne prouvait ni activation de session APPN ni résultat métier. Un échec de session muni d’un code ne prouvait pas ce que le pair avait traité auparavant.

La sécurité formait encore un autre plan : authentification et chiffrement de session SNA, IPsec pour les datagrammes HPR, filtres de pare-feu par adresse et port. Ces mécanismes protégeaient ou admettaient le trafic ; ils ne synchronisaient pas l’histoire des liens.

La fiche RFC Editor et le Datatracker établissent le statut du texte, non un déploiement actuel. RFC 1122 apporte des exigences d’hôte citées par l’architecture ; il ne transforme pas une adresse IP en autorité sur l’état HPR.

La primauté du code en fonctionnement de Lu Heng impose une lecture simple : l’état local vaut dans la mesure où le pair en fonctionnement l’accepte. Son principe de spécification minimale et d’adoption locale privilégie les règles vérifiables aux proclamations. Les couches de réalité séparent enfin transport, vie, activation et résultat.

Leçon durable : économiser l’observation revient à accepter un délai d’accord. La reprise doit donc traiter l’état local comme une hypothèse à confronter, non comme la mémoire souveraine du lien.