Summary

  • Publiée en mars 1994 comme proposition expérimentale, la RFC 1609 séparait les objets physiques — réseaux, nœuds, interfaces — de leurs « images » logiques propres à un protocole.
  • L'attribut imageOf reliait une image à l'objet matériel ou à une autre image. Une même machine pouvait être passerelle dans la vue IP et simple nœud dans la vue OSI.

Imaginez un technicien devant une baie. Il voit deux routeurs et les câbles qui les unissent. Il ouvre ensuite un plan IP, puis un plan OSI : les boîtiers restent à leur place, mais les passages possibles ne coïncident plus. Voilà le problème que Glenn Mansfield, Thomas Johannsen et Mark Knopper ont confié à X.500 en mars 1994. Le document était expérimental. Sa promesse concernait la manière de décrire le réseau, pas la preuve qu'un annuaire mondial l'avait déjà adopté.

Les auteurs partaient d'un manque pratique. La gestion savait surveiller localement des pannes et des performances, mais disposait mal d'une vue organisée des nœuds, des liaisons, des adresses, des responsables et des politiques au-delà d'un domaine administratif. Ils proposaient une carte sous forme de graphe : des éléments et leurs connexions, enrichis de propriétés. Un réseau pouvait être une ligne simple ou l'assemblage de sous-réseaux. Seulement, la présence d'un fil ne dit pas quel protocole emprunte ce fil.

La solution tient dans le mot image. L'annuaire conserve des entrées pour le réseau physique, ses nœuds et leurs interfaces. Il conserve à côté des networkImage, nodeImage et networkInterfaceImage : autant de versions logiques d'un même équipement, selon IP, OSI ou un autre usage. Chaque image porte un imageOf vers son référent physique, voire vers une autre image. Le pointeur évite de recopier le monde entier à chaque changement de protocole; il oblige aussi à dire de quel monde parle chaque fiche.

Le cas de la passerelle montre l'intérêt de la séparation. Un boîtier peut toucher physiquement plusieurs réseaux sans relayer les mêmes communications pour IP et pour OSI. La RFC place donc externalGateway dans la vue logique concernée. L'adresse de l'interface prend le sens du protocole, numéro IP ou adresse NSAP; connectedNetwork désigne le réseau de cette vue. Une interface logique n'existe dans le modèle que si le protocole utilise effectivement l'interface physique. Copier aveuglément le schéma des câbles promettrait des itinéraires imaginaires.

Cette répartition devait limiter les doublons et respecter les frontières d'administration. La fiche physique pouvait conserver emplacement, propriétaire et contacts; les images portaient les faits propres à leurs usages. La RFC 1608 appliquait ensuite ce cadre aux réseaux IP, aux adresses, aux masques et aux systèmes autonomes. L'annuaire reliait les responsabilités; il ne les fusionnait pas.

Restait le coût du vrai. Le texte renvoyait la politique de cache aux choix locaux, laissait des attributs de trafic et de prix à préciser et ne traitait pas réellement la sécurité. Pour mesurer l'usage de ce modèle, il faudrait des entrées datées d'une installation et une trace montrant comment un opérateur s'en servait. En leur absence, la RFC établit une architecture proposée. Elle livre surtout une discipline : une carte IP peut être exacte et une carte OSI fausse sur le même matériel. Le câble n'aura pas menti; la fiche, si.