Resumen

  • Un anillo de cuatro dominios permitió observar cómo IDPR desmontaba un camino y establecía otro cuando fallaba una pasarela o cambiaba la política del dominio de tránsito; la sesión Telnet permaneció intacta en ambos relatos.
  • El prototipo había excluido la política de origen y las múltiples pasarelas entre dos dominios, sustituyó el servidor de mapeo por tablas locales y no publicó sus cifras de rendimiento, por lo que su éxito no cubría esas superficies.

Lo que sí ocurrió en el anillo

RFC 1477 organiza su experimento principal con cuatro dominios administrativos. S contiene al host que inicia el tráfico y D al destino. T1 y T2 ofrecen dos rutas de tránsito alrededor de un anillo. Al abrir una sesión Telnet, el agente de caminos de S solicita una ruta a su servidor, recibe una ruta por políticas y pone en marcha el camino.

Para ensayar una avería, el equipo detiene los procesos IDPR de una pasarela situada en el camino activo por T1. Las pasarelas adyacentes detectan el cambio, anuncian nueva información y desmontan los restos del camino. El agente de S pide otra ruta; el servidor elige T2 y se establece el reemplazo. El documento afirma que la sesión Telnet se mantuvo intacta.

Después se restaura T1 y se provoca otra clase de cambio. La política de tránsito de T2 pasa a excluir el tráfico de S hacia D. El anuncio de la nueva política invalida el camino, lo desmonta y devuelve el tráfico a T1. La sesión vuelve a sobrevivir.

El valor probatorio no reside sólo en la pantalla Telnet. El prototipo estaba instrumentado para registrar conectividad, cambios de política, mensajes de estado de enlace, rutas generadas, controles de camino y estados de establecimiento o retirada. Había una cadena observable desde la causa introducida hasta la reacción del sistema.

No sabemos, sin embargo, cuántos paquetes se perdieron, cuánto tardaron todos los cambios ni cuántas veces se repitió cada ensayo. La continuidad informada pertenece a esas sesiones y a esa topología. No es una garantía para todo uso futuro.

Dos exclusiones que cambian la lectura

El informe dice que el prototipo incorporó la mayor parte, pero no toda, la funcionalidad de IDPR. Para producir software en marcha cuanto antes, se omitieron deliberadamente las políticas de origen y el caso de varias pasarelas de política entre dos dominios.

La política de tránsito y la de origen resuelven preguntas distintas. Un dominio atravesado expresa quién puede usar sus recursos y bajo qué restricciones. El origen expresa requisitos de servicio y preferencias para su propio tráfico. Cambiar la primera en un experimento no ejecuta la segunda si el código correspondiente no existe.

Tampoco equivale un anillo con una conexión relevante por frontera a varios puntos de enlace entre la misma pareja de dominios. En el segundo caso aparecen selección local, redundancia, consistencia y reparación parcial. El prototipo demostró una alternativa entre T1 y T2, no las ramas internas que había eliminado.

Reducir el alcance era una decisión de ingeniería defendible. Un núcleo ejecutable permite aprender y corregir antes. El límite histórico está en otro lugar: el resultado del núcleo no puede transferirse por el nombre IDPR a funciones ausentes.

Redes reales para una pregunta pequeña

El trabajo comenzó en el verano de 1990 y las pruebas del prototipo terminado en febrero de 1991. USC dispuso estaciones SPARC1+ sobre segmentos Ethernet reconfigurables. SAIC conectó Sun3 en Sparta y MITRE mediante Alternet, con un enlace SLIP de 9,6 kb/s, y mediante una ruta X.25 en el banco DCA EDN. BBN enlazó SPARC1+ de BBN e ISI por DARTnet y TWBnet.

El banco no era imaginario. Combinaba máquinas y redes del periodo. Aun así, la demostración principal buscaba claridad: cuatro dominios, dos tránsitos y políticas inicialmente sin restricciones de acceso.

Además, no se usaron servidores de mapeo. Cada pasarela recibió una tabla configurada que asociaba direcciones con dominios. Esto permitió comprobar el cálculo y establecimiento del camino suponiendo que el mapeo era correcto. No probó distribución, actualización, detección de conflictos o recuperación de datos vencidos.

Un dato inyectado puede ser una condición válida de ensayo. No es una ejecución del servicio que habría producido ese dato.

“Toda la funcionalidad principal” de una pieza concreta

RFC 1477 llama simples a los ensayos y sostiene que abarcaron toda la funcionalidad principal del prototipo. No hay contradicción. La pieza ejecutada vigiló vecindades, distribuyó información, generó rutas, creó caminos, detectó una caída, retiró estados afectados y construyó un sustituto. También reaccionó a una política de tránsito incompatible.

El referente de “toda” es el prototipo. La arquitectura de RFC 1478 y la especificación de RFC 1479 describen un conjunto mayor. Un requisito escrito no deja una huella de ejecución dentro de una versión que confiesa haberlo omitido.

La misma gramática protege la observación de Telnet. El informe permite decir que la sesión permaneció intacta durante los dos cambios. No permite asegurar cero pérdidas, convergencia acotada ni continuidad universal para cualquier aplicación o combinación de políticas.

El adjetivo no contiene los números

USC y SAIC midieron el procesamiento del establecimiento de caminos y del reenvío de mensajes. Compararon el reenvío IDPR encapsulado en IP con el reenvío IP ordinario, y la ausencia de cálculo de integridad/autenticación con RSA/MD4.

Las mediciones parecieron alentadoras. Las cifras no figuran en RFC 1477. El texto ofrece contactos para obtenerlas y advierte que no deben extrapolarse ciegamente, porque el prototipo recibió poco trabajo de optimización.

Por tanto, el expediente conserva la existencia de la medición, sus variables, la valoración de los autores y su cautela. No contiene latencia, rendimiento ni coste relativo reconstruibles. “Alentador” no es una unidad.

La versión gated era una puerta, no un censo

En 1992, SRI se sumó a SAIC y BBN para integrar IDPR en el proceso UNIX gated. Según RFC 1477, esta versión sí contenía la funcionalidad completa de IDPR, tenía una interfaz de configuración y era más eficiente como proceso único que el prototipo multiproceso. Se distribuía libremente, de modo que un usuario de UNIX podía experimentar sin escribir la implementación.

La disponibilidad abrió la puerta a pruebas externas. No contó quién la cruzó. El objetivo declarado era obtener experiencia en redes operativas con restricciones reales y tráfico con requisitos reales. Cuando apareció el RFC, había un piloto y una demostración en curso en lugares seleccionados.

Disponible, descargado, instalado, activado, usado por tráfico y adoptado de forma sostenida son estados diferentes. Un piloto en curso no contiene su informe final.

También la etiqueta documental tiene límite. El registro de RFC 1477 lo clasifica como Informational, aunque su título diga “as a Proposed Standard”. Los registros de RFC 1478 y RFC 1479 preservan la identidad de la arquitectura y el protocolo. RFC 2026 explica el proceso de estándares. Ninguna etiqueta informa por sí sola del estado de un proceso en una pasarela.

El valor de un contrato que no esconde sus condiciones

RFC 1102 había explorado la construcción de rutas de política; RFC 1104 separó distribución de rutas, tratamiento de paquetes, asignación de recursos y contabilidad. RFC 1477 aporta otra cosa: una frontera visible entre arquitectura, subconjunto ejecutable, observación y siguiente fase de despliegue.

La lectura coincide con las notas de Heng Lu sobre primacía del código en ejecución, especificación inicial mínima y adopción voluntaria y capas de realidad. Un prototipo que funciona supera una intención que no se ha ejecutado. Sólo habla, sin embargo, por las funciones que cargó y los escenarios que observó.

El experimento merece conservarse porque fue limitado y transparente, no a pesar de ello. La sesión viva y la política de origen ausente son dos hechos compatibles. Juntos dicen más que un veredicto de éxito o fracaso.

Fuentes