Summary

  • RFC 1609 proposed an X.500 directory model in March 1994 for physical networks, nodes and interfaces, with separate logical “images” of the same objects for IP, OSI or another purpose.
  • Its imageOf link connected a logical entry to a physical object or another image. A router could be a gateway in one protocol view and an ordinary node in another; the two maps shared equipment without sharing every route.

Put a router on a shelf. Its metal, ports and cables occupy one place. Now ask an IP operator and an OSI operator to draw the network it serves. They can both point to the same shelf and produce different maps. Glenn Mansfield, Thomas Johannsen and Mark Knopper made that split the organizing problem of their March 1994 Experimental RFC. Their ambition was a directory broad enough to show infrastructure across administrative borders, while letting each operator ask the question relevant to its protocol.

At the time, the authors said network management concentrated on local faults and performance. A wider pool of information about nodes, links, addresses, contacts and policy was missing. Their proposed map would describe connections as a graph: equipment and subnetworks as vertices, their links as edges. A network might be a single medium, such as a cable, or a collection of smaller networks. Drawing that graph once sounds efficient. It also conceals a trap. The physical graph and the path available to one protocol are different things.

The RFC called each distinct view an image. It placed physical network, node and interface entries in the X.500 Directory Information Tree, usually beneath the organization maintaining them. Then it added networkImage, nodeImage and networkInterfaceImage entries for the logical versions. An image's imageOf attribute pointed to a physical entry or another image. The physical entry could point back to its images. The pointer was a confession that two directory records could describe one underlying piece of kit without being interchangeable records.

The most practical example is the gateway. A box with several interfaces can physically touch two networks, yet act as a gateway for IP on one path and not for OSI on that path. RFC 1609 puts the protocol-specific externalGateway in the network image. It gives a logical interface an address in that view's context, such as an IP number or an OSI NSAP, and a connectedNetwork pointer to that view's network. It creates a logical interface entry only when that protocol uses the physical interface. Copy the physical connections into every logical view and the directory will promise routes that the relevant protocol cannot take.

The authors also wanted to avoid duplicating data and preserve administrative boundaries. That is where the design becomes more than a tidy diagram. A shared router's physical owner, technical contact and location could live with its physical record; protocol-specific gateway or address facts could live with the relevant image. RFC 1608, its companion, applied the general framework to IP networks, addresses, masks and autonomous-system information. A local custodian could maintain a bounded slice rather than pretending to own every view of the Internet.

The directory was a proposal, and the hard bill was maintenance. The memo left caching policy to local choice and did not specify how its security claims would be delivered. It even marked traffic and charge fields as needing further definition. A dated set of real physical and logical directory entries, plus a trace of an operator using them, would show how faithfully the proposed links tracked a changing network. The RFC supplies the schema, not that trace.

Its sharper lesson is about the map's job. imageOf could say which physical thing a logical claim referred to. It could not make a stale IP path current or turn a box into an OSI gateway. The same cable could carry several networks. Anyone who collapsed their maps into one authoritative drawing would be asking the rack to lie on their behalf.