Résumé

  • RFC 1223 adaptait ES-IS et IS-IS à HYPERchannel, dont la technologie n'offrait ni véritable diffusion ni multidiffusion.
  • Le système remplaçait l'envoi collectif par une réplication pilotée par des listes : chaque destinataire recevait une copie distincte, espacée des autres.
  • Un PDU valide ou une copie reçue ne prouvait ni l'exhaustivité de la liste, ni la réception par tous, ni la formation des voisinages, ni la convergence des routes.

Le service collectif n'existait pas dans le support

Publié en mai 1991, RFC 1223 décrit le transport de CLNS et de LLC1 sur les équipements HYPERchannel de Network Systems Corporation. Sa notice RFC Editor le classe Informational et le Datatracker de l'IETF le conserve dans le flux Legacy. C'est un contrat technique historique, non la preuve d'un déploiement et encore moins une norme Internet.

ES-IS et IS-IS comptaient sur un sous-réseau capable d'atteindre un groupe. HYPERchannel négociait des livraisons point à point et pouvait mutualiser du matériel entre plusieurs hôtes, mais ne proposait aucune diffusion véritable. Le document insiste sur la limite : les procédés décrits résolvent certains besoins de routage, pas la multidiffusion en général.

Une phrase comme « le Hello a été multidiffusé » cachait donc une chaîne. Un processus construisait le PDU, choisissait une photographie de la liste, créait plusieurs copies, les plaçait en file et les envoyait l'une après l'autre. Les récepteurs les traitaient séparément. La réussite de la première étape ne contenait pas celles qui suivaient.

La liste mélangeait configuration et observation

En présence de vrais systèmes intermédiaires, chaque système terminal recevait une liste configurée de ces routeurs. Pour émettre un ESH, il envoyait une copie individuelle à chaque IS connu. Il pouvait aussi apprendre l'adresse d'un IS absent de la configuration en recevant un ISH, puis la conserver pendant la durée de rétention annoncée.

Ces membres n'avaient pas la même provenance. L'un venait d'une décision d'opérateur et durait jusqu'à modification ; l'autre venait d'une observation et expirait. Une liste fusionnée en mémoire ne transformait pas ces preuves en une source unique. Pour savoir qui devait recevoir le message, il fallait connaître la version de liste et l'instant précis de l'expansion.

Le RFC propose d'espacer les copies, environ 0,1 seconde sur beaucoup de systèmes, afin de ne pas gêner le trafic utile. Cette prudence créait aussi des résultats temporellement distincts. Une file pouvait accepter les premiers destinataires et abandonner les derniers. La réception d'une copie ne valait pas acquittement de la série.

IS-IS dépendait d'une liste complète

Les systèmes intermédiaires étaient eux-mêmes configurés avec les adresses de leurs pairs. Pour IS-IS, la liste devait être complète et ne pas partitionner l'ensemble qui participait à l'élection et à l'échange d'état. Un IS consultait tous les destinataires de niveau 1 ou de niveau 2, puis leur adressait des copies séparées. RFC 1223 voulait rendre cette multiplicité transparente au protocole.

La transparence simplifiait le logiciel supérieur, pas la preuve d'exploitation. RFC 1142 expose le modèle IS-IS contemporain ; RFC 1195 l'étend aux environnements IP et mixtes. Aucun des deux ne certifie la liste locale utilisée par une machine HYPERchannel.

RFC 995 fournit le contexte ES-IS. Un PDU conforme attestait une syntaxe et un sens de protocole. Il n'attestait pas que tous les pairs figuraient dans la sélection, que toutes les copies avaient quitté leurs files ou que les bases de routage avaient convergé.

Un gestionnaire d'adresses pouvait jouer le rôle du routeur

Sans véritable système intermédiaire, un ou plusieurs systèmes devenaient des gestionnaires SNARE. Chaque système terminal devait être configuré avec tous ces gestionnaires. La redondance était possible, mais elle restait dépendante d'un inventaire exhaustif.

Le SNARE se présentait comme un IS, mémorisait les ESH, transférait le paquet vers le bon système terminal et renvoyait une redirection. Ce sont quatre responsabilités, non un seul résultat. Le nom du rôle ne prouvait ni fraîcheur de la table ni transfert d'un paquet particulier.

HYPERchannel ne prenait pas en charge la fonction de requête de configuration ES-IS. Chaque système devait donc partir avec au moins un IS réel ou un SNARE configuré. La découverte pouvait enrichir une base ; elle ne remplaçait pas la graine initiale.

L'abstraction déplaçait la responsabilité

RFC 1223 réussissait à préserver l'interface attendue par le routage. En contrepartie, l'opérateur devait conserver les faits pluriels sous l'événement unique : autorité sur la liste, appartenance apprise, création de copies, cadence, transmission, réception, changement de base et convergence.

Sans ces traces, un membre absent peut être expliqué de cinq manières incompatibles : oublié dans la configuration, expiré, non sélectionné, perdu dans une file ou incapable de traiter le PDU. La vieille architecture rappelle ainsi qu'une abstraction ne supprime jamais les obligations qu'elle masque.

Sources