Resumen

  • En 1991, BARRNet registraba 1.816 rutas externas. Su primer despliegue de OSPF reveló un salto adicional para parte del tráfico de NSFNET y presión de memoria en routers pequeños.
  • El informe vinculó esos límites con dos funciones de OSPFv2: las direcciones de reenvío y las áreas stub. Es un caso operativo concreto, no la explicación única de toda la evolución del protocolo.

En abril de 1990, BARRNet puso en servicio OSPF versión 1 en una red de investigación del norte de California. Para noviembre ya funcionaba con la versión 2. Cuando John Moy describió la red al julio siguiente, no se limitó a señalar a un usuario temprano. El informe mostró una ruta que daba un rodeo innecesario y routers sin memoria suficiente para conservar todas las rutas que llegaban desde fuera. Esos dos límites aparecen como motivo de dos funciones añadidas a OSPFv2. La historia es concreta: los operadores podían señalar tráfico y equipos que hacían visible qué debía resolver el protocolo. RFC 1246, §§6.0, 6.2.1–6.2.2

BARRNet no era una sola red universitaria. El informe de 1991 dice que atendía cerca de 80 sitios miembros, desde Sacramento hasta Monterey, con conexiones entre 9,6 kbps y un T1 completo. Entre sus miembros había universidades, organismos públicos y empresas. La red regional se conectaba con NSFNET en Stanford mediante enlaces T1 y T3; también llegaba a ESnet en Lawrence Livermore, al DDN a través del Federal Internet Exchange de NASA Ames y a las redes universitarias de California. Por tanto, debía transportar el alcance local e intercambiar rutas con varios sistemas mayores. RFC 1246, §6.2

El núcleo tenía catorce routers Proteon. Seis formaban un anillo redundante, unido por circuitos T1 completos entre los sitios centrales. Los sitios miembros se conectaban detrás de esos routers y la mayoría lo hacía en una estrella centrada en Stanford. La topología importa porque las puertas de enlace externas y los routers que trataban el tráfico estaban en distintos puntos de la misma red regional. El RFC cuenta 1.816 rutas externas en el sistema OSPF en ese momento. La mayoría procedía de NSFNET; otras llegaban de NSN, de routers de BARRNet que aún usaban otros protocolos y de ESnet. BARRNet importaba rutas RIP y EGP en OSPF, usaba métricas externas de tipo 1 y etiquetas para administrar qué rutas se anunciaban de nuevo mediante EGP. No se trataba de sustituir un protocolo por otro de forma limpia: OSPF debía convivir con las conversaciones de enrutamiento existentes. RFC 1246, §§6.2.1–6.2.2

Un directorio de redes de 1990 también describe BARRNet como una red regional compuesta por circuitos arrendados, enlaces de microondas y conexiones de distintos tipos. Una retrospectiva posterior de Internet2 dice que las universidades miembros tenían una responsabilidad especialmente descentralizada sobre la propiedad y el mantenimiento de los routers. Estas fuentes ayudan a distinguir el sistema de enrutamiento compartido de quién poseía o mantenía cada equipo; no demuestran que ese modelo causara el salto adicional o el límite de memoria. RFC 1245 documenta las pruebas de interoperabilidad de OSPF y RFC 1131 aporta la especificación original: norma, implementaciones y experiencia de campo avanzaban en paralelo. The User’s Directory of Computer Networks (1990); retrospectiva de Internet2; RFC 1245; RFC 1131

El primer problema estaba en el borde. Solo los routers BR5 y BR6 intercambiaban información EGP con el sistema que el RFC denomina NSS. Sin una dirección de reenvío separada en un anuncio externo de OSPF, BR10, BR16 y BR28 enviaban primero el tráfico de NSFNET al gateway que anunciaba la ruta, incluso cuando el siguiente salto externo era directamente alcanzable. Los paquetes atravesaban un router adicional. El campo de dirección de reenvío de OSPFv2 permitía indicar en el anuncio el router siguiente para ese destino y tomar la ruta directa. La explicación de la norma emplea un ejemplo genérico; el informe de Moy vincula el mismo comportamiento con routers identificados de BARRNet. Como la fuente no desarrolla “NSS”, conservamos esas siglas. RFC 1246, §6.2.2; RFC 1247, §§2.2, 12.4.4

El segundo problema era la memoria. Algunos routers no podían guardar todas las rutas externas. BARRNet utilizaba cuatro áreas stub, cada una formada por una sola LAN sin routers OSPF en su interior. Estas áreas excluían los anuncios externos y reducían la información que debían conservar sus routers. El informe presenta la función como un intento de usar OSPF en equipos con memoria limitada, no como garantía de que cualquier equipo pequeño funcionaría. No ofrece tamaños de memoria ni mediciones antes y después. El diseño intercambiaba una vista completa de rutas externas por una carga menor de estado de enrutamiento en el área. RFC 1246, §§6.2.1–6.2.2; RFC 1247, §3.6

Moy situó BARRNet junto a otros despliegues tempranos. El mismo informe enumera NASA Science Internet y OARnet; la implantación de OSPF en Internet comenzó en la primavera de 1990. El primer despliegue no detectó errores del protocolo, aunque sí funciones convenientes. La relevancia de BARRNet es más concreta que cualquier afirmación de prioridad: el informe identifica el desvío de ruta y el límite de memoria que motivaron dos funciones de la versión 2. RFC 1247 también afirma que las versiones 1 y 2 no eran interoperables, así que el cambio suponía una frontera operativa. El informe da las fechas de uso de BARRNet, pero no una secuencia de migración router por router ni prueba de que todos cambiaran a la vez. RFC 1246, §§6.0, 6.2.2; RFC 1247, apéndice F

Esta precisión mantiene la historia en su escala. La especificación describía el comportamiento esperado; la red desplegada mostró dónde el modelo añadía un tránsito o exigía más estado del que un equipo podía mantener. La contribución documentada de BARRNet no fue demostrar que una topología o un protocolo resolvía los problemas de Internet. Fue ofrecer un caso operativo que los diseñadores podían abordar: anunciar el siguiente salto real y dejar que una zona con recursos limitados guardara menos rutas externas.

Fuentes