Summary

  • La RFC 1609, publicada como experimental en marzo de 1994, propuso representar redes, nodos e interfaces físicas en X.500 junto con imágenes lógicas separadas para IP, OSI u otros usos.
  • imageOf conectaba cada imagen con el objeto físico o con otra imagen. Un equipo podía hacer de pasarela para un protocolo y no para otro, aunque los cables fueran idénticos.

El encargado del cuarto de comunicaciones puede contar los puertos de un router sin equivocarse. Aun así, su dibujo no responderá por sí solo a la pregunta de un operador IP: ¿por dónde pueden pasar mis paquetes? Un operador OSI puede obtener otra respuesta mirando la misma máquina. Glenn Mansfield, Thomas Johannsen y Mark Knopper partieron de esa diferencia en su propuesta experimental de marzo de 1994. Querían que un directorio X.500 guardara tanto la infraestructura compartida como las distintas maneras de usarla.

Según la RFC, la gestión de fallos y rendimiento se había concentrado en ámbitos locales. Hacía falta información organizada sobre enlaces, equipos, direcciones, servicios, contactos y políticas que cruzaban límites administrativos. El modelo dibujaba la red como un grafo de elementos y conexiones. Un cable o una línea podía ser una red simple; varias redes interconectadas podían formar otra compuesta. El grafo físico era el punto de partida, pero no la respuesta completa.

El documento llamó imágenes a las vistas lógicas. Propuso entradas para network, node y networkInterface, y otras para networkImage, nodeImage y networkInterfaceImage. Una imagen tenía un atributo imageOf que señalaba el elemento físico al que se refería, o incluso otra imagen. El vínculo permitía describir varias redes lógicas sobre la misma instalación sin fingir que todas tenían idéntico comportamiento.

Ahí entra la pasarela. Un aparato unido a dos segmentos puede encaminar un protocolo por una interfaz y no encaminar otro. Por eso externalGateway pertenece a la imagen de red correspondiente. La dirección de una interfaz lógica se interpreta dentro de su protocolo, como número IP o dirección NSAP; connectedNetwork apunta a la red de esa misma vista. El modelo solo crea una imagen de interfaz cuando el protocolo establece conexiones por la interfaz física. Dibujar toda conexión material como si fuera una ruta IP o OSI sería vender un atajo inexistente.

La RFC buscaba reducir datos repetidos y conservar las fronteras de control. La propiedad, ubicación y contacto del equipo podían acompañar al objeto físico, mientras las funciones de cada protocolo iban en su imagen. La RFC 1608 desarrolló la parte IP, con redes, direcciones, máscaras e información de sistemas autónomos. Ninguna de las dos convirtió por arte de magia una ficha actualizada en otra: cada vista necesitaba mantenimiento propio.

El texto deja el caché a decisión local, señala que tráfico y precios necesitan más definición y no desarrolla la seguridad. Para saber si aquella arquitectura sostuvo un despliegue concreto harían falta registros fechados y un rastro de uso operativo. La propuesta sí deja una regla nítida: un puntero puede unir dos descripciones de la misma máquina, pero no puede hacer verdadera una ruta que el protocolo no ofrece. El metal era compartido. La responsabilidad de cada mapa no.