Resumen

  • RFC 1223 llevó ES-IS e IS-IS a HYPERchannel, una tecnología sin difusión ni multidifusión auténticas.
  • La solución convirtió cada intención colectiva en copias individuales dirigidas por listas configuradas o aprendidas y enviadas con pausas.
  • Ver un PDU válido o una copia no probaba que la lista estuviera completa, que todos recibieran, que naciera una adyacencia o que las rutas convergieran.

Un protocolo de difusión sobre un medio sin difusión

RFC 1223, de mayo de 1991, documentó el transporte de CLNS y LLC1 sobre equipos HYPERchannel de Network Systems Corporation. El registro del RFC Editor lo clasifica como Informational y el Datatracker del IETF lo conserva en el flujo Legacy. Describe un diseño histórico, no un estándar de Internet ni un despliegue observado.

ES-IS e IS-IS suponían que la subred podía alcanzar a un grupo con un mensaje. HYPERchannel negociaba entregas puntuales y compartía ciertos adaptadores entre hosts, pero no ofrecía broadcast real. El propio memo limita su ambición: sus técnicas atienden problemas concretos, no crean multidifusión general.

La frase “se envió un Hello multicast” escondía, por tanto, una secuencia. Un proceso formaba el PDU; otro tomaba una instantánea de miembros; se generaban copias, entraban en colas y salían por separado; cada receptor decidía si procesarlas. Ningún paso adelantaba la prueba del siguiente.

Configurar y aprender no producían el mismo dato

Con sistemas intermedios reales, cada sistema final mantenía una lista configurada de ellos. Al originar un ESH enviaba una copia a cada IS conocido. Si recibía un ISH de un IS ausente de su configuración, debía incorporarlo durante el tiempo de retención anunciado.

La lista reunía fuentes distintas. Una dirección expresaba una decisión administrativa hasta nueva edición; otra expresaba una observación temporal. Para auditar el abanico había que conservar origen, vencimiento y versión exacta usada en ese instante.

RFC 1223 aconsejaba separar las copias —aproximadamente 0,1 segundos en muchos sistemas— para no ahogar el tráfico útil. El primer y el último destino no compartían entonces el mismo evento de cola o enlace. Que uno recibiera no cerraba la operación para los demás.

La lista de IS debía ser completa

Los sistemas intermedios también se configuraban con sus pares. En IS-IS, una lista incompleta podía partir el conjunto que intercambiaba estado y participaba en la elección del IS designado. Al transmitir, el IS consultaba todos los destinos de nivel 1 o nivel 2 y enviaba copias individuales. La multiplicidad debía ser transparente para IS-IS.

Transparencia no significaba prueba única. RFC 1142 aporta el modelo IS-IS de la época y RFC 1195 su empleo con IP y entornos duales. Ninguno certifica la instantánea local de miembros ni la recepción de una serie concreta.

RFC 995 da el marco de ES-IS. La conformidad del PDU demostraba que el objeto podía interpretarse. No demostraba selección exhaustiva, envío de cada copia, actualización de bases ni convergencia.

Sin router, un gestor de direcciones asumía el papel

Donde no había un IS verdadero, uno o varios sistemas podían actuar como gestores SNARE. Cada sistema final debía tener configurados todos esos gestores. La redundancia añadía destinos, pero no eliminaba la obligación de inventariarlos.

El SNARE se presentaba como IS, conservaba información de ESH, reenviaba hacia el sistema final correcto y devolvía una redirección. El papel no era una constancia de esos cuatro actos. Hacían falta registros separados para saber qué tabla estaba vigente y qué paquete se trató.

HYPERchannel tampoco soportaba la función de consulta de configuración de ES-IS. Todo sistema debía arrancar con al menos un IS o SNARE configurado. El aprendizaje podía ampliar la semilla; no podía sustituir su ausencia.

La abstracción trasladó la deuda de evidencia

RFC 1223 permitió que el software de routing conservara una operación familiar. Debajo quedaron hechos plurales: autoridad de la lista, membresía aprendida, creación y ritmo de copias, transmisión, recepción, cambio de estado y convergencia.

Si esos hechos se borran tras el “éxito multicast”, un miembro ausente puede ser una omisión de configuración, una entrada vencida, una copia nunca admitida, un fallo de enlace o un PDU recibido sin efecto. La abstracción es útil sólo cuando no destruye las pruebas que hacen posible distinguirlos.

Fuentes