Resumen

  • RFC 1070 reutilizó Internet como subred para transportar PDU de la capa de red OSI. Así podía probar protocolos de encaminamiento inmaduros entre sitios sin instalar esos protocolos en las pasarelas IP existentes.
  • EON añadió una topología lógica propia mediante SNAcP, cachés de sistemas centrales, roles ES/IS y listas iniciales de IANA. Una dirección alcanzable por IP no demostraba que el sistema fuera vecino, router, miembro conocido o ruta aprendida en el experimento.

La propuesta de febrero de 1989 empieza con una restricción poco ambigua. Los métodos de RFC 1070 eran únicamente experimentales, a escala limitada, y no servían para un entorno operativo. La advertencia no era decorativa. Los protocolos OSI de capa de red necesitaban pruebas en una topología amplia y cambiante, pero todavía eran demasiado inmaduros para exigir cambios en un gran conjunto de pasarelas de Internet.

Los autores eligieron conservar esas pasarelas. Cuando un destino quedaba más allá de la red local, la implementación colocaba el PDU OSI completo dentro de un datagrama IP. En la LAN podía ejecutar OSI directamente. Al cruzar la infraestructura existente, trataba Internet como una subred, un enlace entre lugares que participarían en otro sistema lógico. Ese experimento recibió el nombre EON, Experimental OSI-based Network.

El sobre IP no dictaba la ruta OSI

EON directo reservaba el valor decimal 80 del campo Protocol de IP. El PDU encapsulado podía ser CLNP, ES-IS o IS-IS. Se prefería fragmentar en la capa OSI, porque su comportamiento era parte de la prueba, aunque el camino IP todavía podía fragmentar el datagrama y obligar al receptor a reensamblarlo.

Cada operación dejaba un límite. La llegada de IP decía algo sobre el portador. La reconstrucción y el procesamiento del ISO-gram pertenecían a la capa experimental. Por eso la RFC observa que casi cualquier máquina de un sitio participante podía ser alcanzable por IP, pero solo algunas se configurarían como directamente conectadas al IP subnet de EON.

La dirección tampoco eliminaba esa decisión. El formato NSAP seguía RFC 1069 e incorporaba la dirección Internet en los octetos 16 a 19. El punto de conexión de subred, SNPA, se obtenía de forma algorítmica; el selector ocupaba el último octeto, IANA asignaba el dominio de encaminamiento y al principio el área local quedaba en cero.

Conocer la SNPA permitía dirigir el datagrama inferior. No indicaba si el proceso superior actuaba como sistema final ES, sistema intermedio IS o ambos. RFC 1070 permitía cambiar esa función y la relación topológica sin alterar la conexión física. También excluía el uso de algoritmos IP para encaminar ISO-gramas entre participantes: el experimento debía observar el encaminamiento OSI, no delegar su pregunta central al portador.

El broadcast era una lista de copias

Las conversaciones ES-IS e IS-IS esperaban una subred con destinos conceptuales para todos los ES y todos los IS. El IP subnet no ofrecía directamente esa semántica. Un nivel intermedio, SNAcP, la simulaba.

SNAcP mantenía en cada sistema un conjunto de direcciones Internet consideradas a un salto ISO 8473. Si la intención era individual, enviaba una copia. Si era todos los ES, todos los IS o broadcast, replicaba el ISO-grama para cada dirección de la caché. Su cabecera versión 1 expresaba el tipo de destino y llevaba una suma Fletcher. El receptor miraba la cabecera y su configuración local: aceptaba siempre individual y broadcast, mientras que los grupos ES o IS dependían de la función activa.

Nada de eso creaba una visión universal. La caché del emisor podía estar incompleta. La máquina receptora podía haber cambiado de función. Los demás participantes podían no haber aprendido el cambio. El aparente medio compartido surgía de muchas tablas y decisiones locales, no de una membresía inherente a Internet.

Los mensajes ICMP aportaban señales del portador que SNAcP podía traducir. Destination unreachable, parameter problem o time exceeded podían marcar una dirección central como inutilizable; source quench podía hacerlo durante un intervalo. El documento dejaba la reacción de gestión a la implementación e incluso aceptaba que informar significara no hacer nada. Al replicar, SNAcP omitía las entradas inutilizables; al enviar de forma individual, devolvía error a OSI CLNL. La política local decidía cómo un fallo IP modificaba el enlace simulado.

Dos pares de archivos separaban arranque y consulta

Una caché recién iniciada no podía aprender de participantes a los que todavía no conocía. IANA debía mantener core.EON y core.EON-UDP con direcciones SNPA que sirvieran de vecinos lógicos iniciales. En paralelo, hosts.EON y hosts.EON-UDP ofrecían nombres de sistemas finales para aplicaciones y personas; la capa OSI sin conexión no los usaba.

Pertenecer al archivo core no otorgaba una función. La propia RFC aclara que una entrada podía ser ES, IS o ambas cosas. Un sistema podía comenzar a participar antes de aparecer en el archivo distribuido, pero los otros nodos, al arrancar, no sabrían enviarle los mensajes de configuración ESH o ISH. El listado era una semilla operativa con retraso posible, no un censo instantáneo de funciones.

La topología hipotética de Fordor muestra el fallo sin recurrir a una caída física. 192.5.2.1 era IS y core; 192.5.2.2 era ES. Las dos máquinas intercambiaban funciones sin perder conectividad IP. Si IANA seguía publicando el estado anterior, los peers enviaban sus mensajes a .1, que ahora respondía como ES, y no buscaban al nuevo IS .2. Desde la perspectiva de EON, el nuevo intermediario parecía inalcanzable.

El arranque de .2 podía corregir la imagen. Al anunciarse por los protocolos OSI, recibía respuestas de otros IS y hacía que actualizaran sus cachés. La conectividad inferior había estado disponible todo el tiempo. Lo que faltaba era una secuencia válida de descubrimiento y aprendizaje después del cambio de función.

La variante UDP conservaba la separación

Quien no tenía acceso directo a IP pero sí a UDP podía participar en EON-UDP. El NPDU se colocaba en el puerto 147 y SNAcP funcionaba entre UDP e ISO 8473. El documento conserva muchas reglas, pero niega interoperabilidad directa entre EON y EON-UDP. Una pasarela sería posible en teoría; su construcción quedaba fuera del alcance. Por eso había archivos separados y dos experimentos paralelos, no una identidad con dos transportes intercambiables.

También importa la capa comparada. RFC 1006 hacía disponible el servicio de transporte OSI sobre TCP para la sesión y las capas superiores. RFC 1070 llevaba las capas OSI de red y transporte a través del inter-network IP. RFC 1069 empleaba el encaminamiento y direccionamiento de Internet en una pasarela CLNP; EON preservaba el encaminamiento y direccionamiento OSI para ponerlos a prueba.

Fuentes y límites

RFC 1070 describe acuerdos propuestos, no un servicio consolidado. Fordor es un ejemplo inventado, no una avería documentada. RFC 994 y RFC 995 dan el marco contemporáneo de CLNP y ES-IS, pero no prueban despliegue, escala o corrección de una implementación EON concreta. Tampoco hay base para convertir el experimento en antepasado directo de una red superpuesta moderna.

Su valor histórico reside en la separación: el portador puede entregar paquetes sin poseer la definición de miembro, función o vecino de lo que transporta. Cuando esas definiciones viven en listas, cachés y anuncios distintos, cada una necesita su propia prueba.