Resumen

  • La RFC 1074 documentó un IS-IS ANSI recortado al nivel 2 y a enlaces punto a punto permanentes. Sus PDU IS-IS y ES-IS viajaban dentro de IP con el número de protocolo 85, mientras direcciones IPv4 y dominios derivados de AS ocupaban posiciones definidas en una forma NSAP.
  • La información de alcanzabilidad EGP pasaba por la Routing Policy Data Base. El NSS convertía una afirmación autorizada en un prefijo de End System PDU, le aplicaba un coste de política y distribuía ese nuevo estado por el núcleo.

La RFC 1074 describió una red de trece emplazamientos en Estados Unidos, unidos por circuitos T1 permanentes de 1,544 Mbit/s. En cada punto, un Nodal Switching Subsystem basado en varios IBM RT/PC y un núcleo 4.3BSD modificado realizaba la conmutación. Para el enrutamiento, el conjunto aparecía como un solo nodo.

Entre esos NSS se ejecutaba una adaptación del protocolo IS-IS que ANSI había remitido a ISO. Las redes regionales conectadas no tenían que compartirlo: en el borde hablaban EGP. El interés histórico está en el empalme. La arquitectura no escogió una familia y expulsó a la otra; definió cómo una declaración exterior, después de ser autorizada, podía adquirir una representación interior.

El nombre IS-IS ocultaba un recorte deliberado

El diseño ANSI separaba nivel 1 dentro de un área y nivel 2 entre áreas. El NSFNET implementó solo el nivel 2. También redujo las funciones dependientes de subred al caso que necesitaba: una topología general de enlaces punto a punto permanentes. No era una instalación completa del universo OSI, sino el uso selectivo de un algoritmo y su lenguaje de control.

La diferencia vertical era aún más visible. En la arquitectura ISO, IS-IS iba directamente sobre la capa de enlace. En NSFNET, las PDU IS-IS y ES-IS se enviaban sobre IP. El campo Protocol usaba el valor 85, que el registro de IANA conserva bajo el nombre NSFNET-IGP. Dentro de la PDU, un discriminador indicaba la familia concreta.

Que el registro mantenga el 85 no demuestra que alguien lo use hoy. Tampoco una captura de un datagrama 85 probaría la existencia de una ruta útil. Aún faltarían el análisis correcto, la incorporación a la base de estado, el cálculo SPF, la instalación y la prueba del plano de datos.

El transporte sobre IP también resolvía —y heredaba— el problema del tamaño. La implementación confiaba en la fragmentación y el reensamblado IP para una PDU grande, pues consideraba improbable superar el máximo. No añadió otro mecanismo IS-IS. La envoltura elegida determinaba, por tanto, dónde podía romperse un mensaje de control.

Los huecos de la dirección cuentan la historia

IS-IS esperaba direcciones NSAP; el NSFNET tenía direcciones IPv4, números de red y AS. La solución no borró la diferencia. Construyó una pieza adaptadora de nueve octetos en la parte específica del dominio: dos para el dominio administrativo, dos vacíos, cuatro para la dirección IP y otro vacío. La parte inicial del dominio no se usaba.

El identificador de router, de seis octetos, colocaba dos vacíos delante de los cuatro octetos IP. El título de entidad de red se obtenía de la forma NSAP construida. Los campos vacíos no eran desperdicio accidental: mostraban que los significados se estaban ubicando en una estructura ajena con una regla conocida.

Para esta aplicación, cada Autonomous System se trató como un Administrative Domain. Esa correspondencia permitió transportar junto al destino la identidad del dominio que lo anunciaba. Era una convención operativa del NSFNET, no una equivalencia ontológica válida para todas las redes.

Antes de la conversión venía el derecho a representar

La RFC 1092 explica por qué no bastaba EGP. Su modelo suponía una topología de árbol diseñada, pero NSFNET tenía rutas alternativas entre regiones. Varias redes regionales podían afirmar que alcanzaban el mismo número de red. EGP no daba una interpretación universal de la métrica que distinguiera representante primario y secundario, ni impedía anunciar sin permiso una red ajena con distancia cero.

Los operadores establecieron acuerdos bilaterales: una red elegía un regional principal y podía nombrar alternativas. El Network Operations Center almacenaba esos acuerdos en la Routing Policy Data Base. El NSS de entrada verificaba la identidad del par, el AS declarado, el número de red y la prioridad admitida. Una discordancia podía activar una alarma y excluir el anuncio.

La información aceptada no se inundaba por el núcleo como paquetes EGP. El NSS tomaba el número de red del registro NR y el dominio administrativo del par, los codificaba en un prefijo con forma NSAP y lo incluía en la sección de alcanzabilidad de una PDU End System. El coste procedía de la misma base de política.

El resultado era una afirmación nueva. Combinaba algo observado en el exterior, el permiso administrativo y una preferencia local. IS-IS distribuía ese resultado entre los NSS. Al salir hacia otra región, la información volvía a pasar por procesamiento y filtrado antes de convertirse en anuncio EGP.

De ahí una regla probatoria. Un registro EGP dice qué declaró un vecino. Una fila de política dice qué pretendían permitir los operadores. Una PDU ES dice qué estado convertido se originó. La base de enlaces, la ruta SPF, la tabla instalada y el trayecto real pertenecen a momentos posteriores.

Filtrar rutas no era inspeccionar todos los paquetes

La RFC 1104 enumeró cuatro controles de entrada: dirección fuente del par, identificación de AS o dominio, números de red anunciados y métrica definida en la base. También indicó que el sistema funcionaba desde julio de 1988.

Era una política de distribución de información, aplicada a redes y dominios. Al construir las tablas de antemano, no obligaba al NSS a consultar la base por cada paquete. Esa eficiencia tenía un límite claro: no autorizaba usuarios individuales ni sustituía a un filtro de paquetes. Una fuente maliciosa, una base desactualizada o una ruta permitida pero caída seguían siendo problemas posibles.

La gobernanza residía en el punto donde una voz exterior se convertía en topología compartida. Para que funcionara, la base debía ser coherente entre nodos y la transformación tenía que ser auditable.

Integrated IS-IS no fue solo un nombre nuevo

La RFC 1195 de 1990 especificó después un IS-IS integrado para dominios IP, OSI y mixtos. Añadió información propia de IP y mantuvo los paquetes IP y OSI sin encapsulación mutua sobre los enlaces. Fue una normalización más amplia, no una simple reedición del mecanismo particular de RFC 1074.

Ambos diseños demostraron que un algoritmo de estado de enlace podía cruzar fronteras de familia. Pero el primero llevaba PDU de control sobre IP y acomodaba hechos de Internet en campos con forma NSAP; el segundo incorporaba explícitamente la alcanzabilidad IP al protocolo integrado. Confundirlos elimina precisamente el experimento histórico.

La retrospectiva de la RFC 1222 señala el objetivo mayor: la fase T1 separó con fuerza el IGP del backbone de los IGP de sus clientes. El exterior servía de frontera para que cada entidad administrativa conservara su autonomía. La homogeneidad no era requisito; lo era una traducción gobernada.

Fuentes y límites

La RFC 904 define la gramática básica de EGP, pero no la política de representación añadida por NSFNET. La RFC 1093 sitúa el límite IGP/EGP dentro de la arquitectura completa. Las RFC 1074, 1092 y 1104 describen decisiones de implementación tomadas por sus participantes. No son mediciones de disponibilidad ni inventarios exhaustivos de paquetes. La RFC 1222 mira la historia desde 1991; la RFC 1195 especifica otro diseño posterior. IANA acredita una asignación, no actividad actual.

La conclusión rigurosa cabe en la cadena: IP transportaba el control; la forma NSAP contenía datos Internet; EGP aportaba una afirmación; la política decidía su legitimidad y coste; IS-IS difundía el estado transformado. La entrega nunca estaba contenida en una sola de esas pruebas.