Resumen

  • El trabajo de Ginny Strazisar en BBN hizo que la pasarela dejara de ser solo un concepto: el código debía coincidir con el PDP-11, los controladores y la red local de cada emplazamiento antes de reenviar un solo paquete.
  • Los documentos conservados enseñan a no exagerar una demostración: discrepan sobre su fecha, distinguen lugares instalados de rutas ejercitadas y muestran cómo el prototipo evolucionó hacia colas limitadas, contadores y alarmas operativas.

Cuando Ginny Strazisar llegó a Oslo para instalar el software, faltaba el soporte más básico: el equipo aún no estaba listo. Se quedó unos días con Paal Spilling, recorrió parte de Noruega y regresó después para cargar el programa. La anécdota, contada en una historia oral del Computer History Museum, revela una verdad incómoda para cualquier gran relato tecnológico. La interoperabilidad no ocurre cuando dos equipos acuerdan un dibujo. Ocurre cuando el binario, la máquina, la interfaz y las personas coinciden en el lugar adecuado.

Strazisar había entrado en Bolt Beranek and Newman en abril de 1975. Pronto trabajó en las «gateways», las máquinas que conectaban redes. BBN ya tenía una entre su Resource Computer Network experimental y ARPANET. Después llegaron las fronteras con el Packet Radio Network y el Atlantic Satellite Network. El museo atribuye a Strazisar el primer software de router de internetworking para los nuevos protocolos TCP/IP, cuando el vocabulario habitual todavía era «pasarela».

Ese crédito es específico. No convierte una pieza en la totalidad del Internet ni borra el trabajo colectivo. Describe a quien programó un punto de tránsito que debía entender mecanismos locales incompatibles sin obligar a las redes a transformarse en una sola. El valor de TCP estaba precisamente en conservar la diferencia debajo de una comunicación común.

La diferencia era física y temporal. La red de radio se movía, dependía de repetidores y no siempre estaba encendida. ARPANET tenía sus convenciones de interfaz y de acceso. SATNET exigía coordinar estaciones a ambos lados del Atlántico. La pasarela debía recibir en un mundo y transmitir en otro, aunque el rendimiento, el tamaño de los mensajes y la disponibilidad no coincidieran.

Tampoco había una caja idéntica para todo. Strazisar recordó que el código de la estación de radio y el de la pasarela convivían en un PDP-11. Las pasarelas entre ARPANET y la red satelital eran PDP-11 separados, con una cara hacia cada red. La función común se preservaba; la integración local cambiaba.

Su calendario de instalaciones dibuja la infraestructura mejor que una lista de protocolos. Según su memoria, trabajó en BBN durante el verano de 1976, instaló Londres en diciembre y llegó a Noruega en el verano de 1977. El equipo que preparaba el hardware no era el mismo que instalaba el software. Si la máquina se retrasaba, la frontera no existía todavía, aunque la arquitectura estuviera aprobada.

Las pruebas también avanzaron por etapas. Una revista del Computer History Museum sitúa en el verano de 1976 los ensayos de radio a un solo salto de la estación donde corría la pasarela bidireccional de Strazisar hacia ARPANET. Su pie de figura fecha una transmisión ceremonial entre dos redes el 27 de agosto. Quedaba demostrar que la solución no era un truco escrito para una única pareja.

En 1977, un vehículo con radio recorrió carreteras de California mientras sus datos atravesaban la infraestructura de SRI, ARPANET y la red satelital y terminaban en un servidor de USC después de un recorrido transatlántico. Era una prueba de composición: tres clases de red, varios equipos y un servicio extremo a extremo.

La memoria conservada no es perfectamente uniforme. El ensayo del museo de 2017 sitúa la demostración el miércoles 22 de noviembre. La revista de 2002 rotula el diagrama como 27 de noviembre. Tampoco todos los sitios preparados fueron parte del trayecto. Vint Cerf dijo en la conversación oral que el tráfico no entró en Noruega, aunque allí se hubiera instalado una pasarela. Presentar una fecha única o convertir cada instalación en un salto del paquete sería rellenar los huecos con seguridad inexistente.

Esta cautela importa hoy. «Instalado» prueba que el software llegó a una máquina. «Alcanzable» prueba una condición del momento. «Probado extremo a extremo» valida una ruta seleccionada. Ninguno demuestra por sí solo la conmutación ante fallos, el comportamiento de todas las interfaces o la operación sostenida.

El equipo de 1977 fue amplio. El museo habla de más de 35 personas y ocho instituciones. Separa el concepto TCP de Bob Kahn y Vint Cerf, el cliente de Jim Mathis y Dave Retz, el servidor de Ray Tomlinson y Bill Plummer, las redes de radio y satélite desarrolladas por varios grupos, y las pasarelas de BBN a cargo de Virginia Strazisar. Reconocer la distribución no debilita su aportación: define el poder y el límite de quien hace funcionar una frontera sin poseer los sistemas completos.

La documentación posterior muestra cómo ese trabajo se volvió transferible. RFC 823 dice que el diseño se describió primero en IEN 30, Gateway Routing: An Implementation Specification, y después en IEN 109 de Strazisar, How to Build a Gateway. Da crédito especial a V. Strazisar, M. Brescia, E. Rosen y J. Haverty. Ya no bastaba con que el equipo original supiera cómo funcionaba; otras personas necesitaban inspeccionar la estructura.

IEN 30 es valioso por sus límites. Presenta un algoritmo lo bastante detallado para implementarlo y rodear componentes fallidos, pero admite que no puede demostrar que toda pasarela enrute siempre bien ni que ningún conjunto de destinos quede sin entrega indefinidamente. Parte de la vulnerabilidad solo aparece con experimentación y uso real. Además, un algoritmo correcto puede convivir con datos de ruta corruptos, hardware defectuoso o una implementación equivocada.

RFC 823 relata otra transición. Las primeras versiones usaban BCPL y ELF, luego MOS para mejorar el rendimiento. A finales de 1981 comenzó una realización nueva, orientada a una instalación operacional y no solo a un banco de investigación. MACRO-11 ahorraba espacio para más búferes y para mecanismos de monitorización. El lenguaje cambió, pero el documento dice que la arquitectura seguía siendo fundamentalmente la misma.

La operación se hizo visible mediante límites y señales. Cada interfaz tenía una cola de salida limitada para impedir que una red lenta agotara todos los búferes. Si no cabía un datagrama, se descartaba y se emitía una alarma. Los operadores podían observar interfaces, vecinos, redes alcanzables, tráfico y causas de descarte. RFC 823 se definía como una instantánea de la implementación, no como una especificación eterna.

La pregunta contemporánea no es si una caja «soporta» dos redes. Es qué binario corre, con qué controlador, sobre qué hardware, qué interfaces fueron ejercitadas y qué evidencia aparece cuando una salida se frena. Un diagrama prueba intención. Un paquete entregado prueba un recorrido. Una frontera operable exige repetibilidad y explicación de los fallos.

El código viajó primero porque la interoperabilidad siempre conserva un componente local: una revisión de placa, un medio de instalación, un cable, un horario y alguien que sabe leer el estado remoto. La abstracción evitó que todas las redes tuvieran que ser iguales. El trabajo de instalación evitó que esa abstracción quedara en el papel.

Sources