Résumé

  • La RFC 1070 proposait d’encapsuler les paquets de la couche réseau OSI dans IP afin d’expérimenter le routage OSI à grande distance sans modifier les passerelles Internet existantes. L’Internet devenait un sous-réseau porteur, non l’autorité topologique de l’expérience.
  • EON construisait sa portée logique avec des adresses particulières, le sous-protocole SNAcP, des caches locaux, des rôles ES/IS et des fichiers d’amorçage. Une machine pouvait rester joignable par IP tout en disparaissant, ou en changeant de fonction, dans cette autre représentation.

La RFC 1070 ne cache pas le statut de son dispositif. En février 1989, elle avertit que les méthodes proposées ne conviennent qu’à une expérimentation limitée et non à un environnement opérationnel. Les protocoles de couche réseau OSI se trouvaient à des degrés de maturité différents. Les éprouver exigeait une topologie vaste, diverse et modifiable ; les installer dans les routeurs de l’Internet aurait fait porter leur immaturité au réseau déjà utilisé.

Les auteurs choisirent donc de ne pas toucher aux passerelles IP. Ils placèrent chaque PDU de la couche réseau OSI dans un datagramme IP pour franchir les sites séparés par ces passerelles. Sur le réseau local, l’implémentation pouvait exécuter directement les protocoles OSI. À distance, elle traitait l’Internet comme un lien, nommé dans le texte « IP subnet ». L’ensemble expérimental au-dessus s’appelait EON, Experimental OSI-based Network.

L’encapsulation procurait un chemin, pas une appartenance

Dans EON direct, un ISO-gramme complet occupait la charge utile d’un datagramme IP, avec la valeur 80 dans le champ de protocole. La couche OSI devait, autant que possible, fragmenter elle-même ses unités afin que ce comportement fasse partie du test. IP pouvait néanmoins fragmenter à son tour, ce qui obligeait la destination à savoir réassembler les datagrammes du porteur.

Cette superposition ne fusionnait pas les résultats. Recevoir des fragments IP confirmait une activité du sous-réseau. Cela ne confirmait ni le réassemblage de l’ISO-gramme, ni son acceptation par la couche OSI, ni l’existence d’une route. De même, presque tous les systèmes d’un site participant pouvaient être joignables en IP, tandis qu’un sous-ensemble seulement se déclarait directement attaché au sous-réseau EON.

L’adresse EON rendait la remise pratique. Inspiré de la RFC 1069, son NSAP incorporait l’adresse Internet dans quatre octets, suivis du sélecteur. Le SNPA, c’est-à-dire le point d’attachement au sous-réseau, pouvait être déduit sans annuaire supplémentaire. Un numéro de domaine de routage était attribué par l’IANA et l’aire locale initiale restait nulle.

On pouvait ainsi calculer une destination IP à partir d’un NSAP. On ne pouvait pas en calculer le rôle. Le système pouvait être un terminal OSI, ES, un intermédiaire, IS, ou les deux. Il pouvait changer de rôle sans changer d’adresse. La RFC excluait en outre le routage des ISO-grammes par les algorithmes IP, la production à grande échelle et la traduction IP-CLNP. Le porteur ne devait pas décider à la place du protocole testé.

Un faux broadcast devait être construit destinataire par destinataire

ES-IS et IS-IS supposent des groupes de diffusion tels que tous les ES ou tous les IS. L’Internet utilisé comme sous-réseau ne présentait pas directement ces groupes aux implémentations. La RFC 1070 ajouta donc SNAcP, un SubNetwork Access Protocol entre la couche OSI sans connexion et IP.

Chaque SNAcP gardait un cache des adresses Internet que le système local considérait à un seul saut ISO 8473. Pour un paquet individuel, une seule destination suffisait. Pour tous les ES, tous les IS ou la diffusion générale, SNAcP fabriquait une copie pour chaque adresse du cache. Son en-tête indiquait une version, la sémantique de l’adresse et une somme de contrôle Fletcher. À l’arrivée, la configuration locale décidait si les formes « tous les ES » ou « tous les IS » correspondaient au rôle de la machine.

Le broadcast résultait donc de deux décisions indépendantes : le cache de l’émetteur fixait qui recevrait une copie et le rôle du destinataire fixait qui l’accepterait. Un envoi réussi ne prouvait pas que le cache était complet. Une acceptation ne prouvait pas que les autres systèmes connaissaient le nouveau rôle.

Les erreurs du porteur entraient dans ce modèle par une autre décision locale. La RFC proposait qu’une destination inaccessible, un problème de paramètre ou un délai dépassé signalé par ICMP rende une adresse de cache inutilisable. Source quench pouvait produire une suspension temporaire. Mais « informer l’administration réseau » pouvait signifier écrire dans un journal, incrémenter un compteur ou ne rien faire. L’observation IP devenait un état EON seulement après cette politique.

L’amorçage et l’annuaire ne répondaient pas à la même question

Pour émettre ses premiers messages de configuration, une machine avait besoin d’un groupe initial. L’IANA devait publier core.EON pour l’expérience IP directe et core.EON-UDP pour sa variante. Ces fichiers contenaient les adresses SNPA que les autres systèmes centraux devaient considérer à un saut logique au démarrage.

Le mot core n’accordait pas le rôle de routeur. Une adresse de core.EON pouvait appartenir à un ES, à un IS ou à une machine cumulant les deux. À côté, hosts.EON et hosts.EON-UDP recensaient des systèmes terminaux pour les logiciels d’application ou les humains. La couche réseau OSI ne les utilisait pas. La première paire amorçait un comportement ; la seconde facilitait la découverte descriptive.

Un participant central pouvait rejoindre l’expérience avant la diffusion de son adresse. Il serait joignable en IP et pourrait fonctionner, mais les pairs redémarrant avec l’ancien fichier ne sauraient pas lui envoyer leurs messages ESH ou ISH. La connaissance de départ restait incomplète jusqu’à une mise à jour ou un échange de protocole.

L’exemple fictif de Fordor rend cette asymétrie mesurable. 192.5.2.1, initialement IS et système central, échange son rôle avec 192.5.2.2, initialement ES. Les deux machines conservent leur connectivité Internet. Si core.EON reste ancien, les autres systèmes continuent à solliciter .1, qui répond désormais comme ES, et ignorent le nouvel IS .2. Celui-ci paraît absent de la topologie EON malgré sa parfaite portée IP.

Au démarrage, .2 peut annoncer son existence par les échanges de routage OSI. Les autres IS répondent alors et corrigent leurs caches. Ce qui rétablit le lien logique n’est ni une nouvelle fibre ni une nouvelle route IP : c’est une preuve de rôle arrivée après une graine d’amorçage périmée.

UDP ouvrait une deuxième expérience sans réunir les deux mondes

Certains développeurs disposaient d’une interface UDP, mais pas d’un accès direct à IP. EON-UDP plaçait les NPDU OSI sur le port 147 et insérait SNAcP au-dessus d’UDP. La logique générale restait semblable. Toutefois, la RFC précise que les participants EON et EON-UDP n’interopéraient pas directement. Une passerelle était imaginable, mais sa construction et son routage sortaient du sujet. Les listes séparées reflétaient deux expériences parallèles.

La position dans la pile distingue également ce travail de ses voisins. La RFC 1006 fournissait le service de transport OSI au-dessus de TCP pour les couches session et supérieures. La RFC 1070 faisait circuler les couches réseau et transport OSI dans un interréseau IP. La RFC 1069 s’appuyait sur l’adressage et le routage Internet pour une passerelle CLNP ; EON voulait justement exercer l’adressage et le routage OSI.

Sources et limites

La RFC 1070 décrit un scénario expérimental et une topologie hypothétique. Elle ne démontre pas une adoption étendue, une exploitation en production, un incident réel à Fordor ni une filiation directe avec une architecture moderne. Les RFC 994 et 995 documentent respectivement le contexte CLNP et ES-IS ; elles n’attestent pas l’état d’un participant concret.

L’apport historique tient à une discipline de preuve. Une adresse, une liste, un cache, un rôle annoncé et une route apprise sont des objets voisins, pas interchangeables. En transformant l’Internet en liaison, EON révélait précisément tout ce que la liaison ne savait pas.