Acceso al backbone NSFNET y poder de direcciones, 1986-1995

Resumen

El registro de direcciones y el acceso a la red estaban relacionados pero eran independientes. Un número de red de Internet válido establecía unicidad y un registro administrativo; no proporcionaba un circuito, membresía regional, elegibilidad para NSFNET o una ruta que otros operadores aceptaran.
La NSF financió y supervisó el programa del backbone, Merit lo gestionó, IBM suministró tecnología y ingeniería de conmutación de paquetes crucial, MCI proporcionó las instalaciones de transmisión, y más tarde ANS operó gran parte de la infraestructura T3. Las redes regionales, las universidades, las autoridades de identificadores y los pares operadores retuvieron decisiones diferentes.
El sistema de enrutamiento de NSFNET convertía las relaciones institucionales en alcance operativo validando los números de red, las identidades de sistema autónomo y la representación regional autorizada. Esto hizo que los registros de enrutamiento fueran tan importantes como los registros del registro sin convertir a Merit en el asignador de direcciones de Internet.
La inversión pública produjo beneficios sustanciales de interoperabilidad: enlaces nacionales más rápidos, operaciones compartidas, acceso universitario más amplio y un sistema de rutas que conectaba miles de redes. Sin embargo, la dependencia de ese alcance subsidiado dio a las decisiones regionales y del backbone consecuencias más allá de sus mandatos formales.
La transición de 1993–1995 demostró la separación de los dos ejes. El registro se trasladó a InterNIC mientras las redes regionales contrataban tránsito comercial, las rutas migraban a múltiples proveedores y puntos de intercambio, y el antiguo Servicio de Backbone NSFNET finalizó el 30 de abril de 1995.

Una ilustración por capas, no un caso documentado de admisión

La Universidad Estatal de Kent ofrece una visión útil de las capas a través de las cuales una dirección se volvía utilizable, pero la evidencia conservada no registra una única transacción continua de admisión.

El registro de números de Internet de julio de 1990 publicado comoRFC 1166listaba131.123comoKENT-STATEen la categoría de investigación. Esa entrada establece que el número estaba registrado a la Universidad Estatal de Kent en esa fecha. No revela la solicitud original, la fecha en que se pidió el número por primera vez, el razonamiento utilizado para aprobarlo ni los términos bajo los cuales la universidad obtuvo conectividad externa.

Un relato operativo separado de 1991,RFC 1246, describió la posición de la Universidad Estatal de Kent dentro de la Red de Recursos Académicos de Ohio, u OARnet. Registró un circuito DS1 desde Kent State hasta el punto de presencia de OARnet en Akron y una conexión de 56 kilobits representada como131.187.36.0. Este último número pertenecía a la infraestructura de OARnet, no a la red registrada de Kent State131.123. El documento también describía una ruta de respaldo indirecta a través de Cleveland cuando los enlaces preferidos no estaban disponibles.

Esas son dos observaciones genuinas: una instantánea del registro y una instantánea operativa posterior de la red regional. No prueban los términos originales de membresía de Kent State, su primer anuncio exitoso de ruta externa o la ruta exacta que tomó un paquete en un día determinado. El reinicio de OARnet descrito en RFC 1246 se refería a la convergencia de rutas hacia las direcciones de infraestructura de OARnet. No debe interpretarse erróneamente como una ruta capturada de extremo a extremo hacia131.123.

El ejemplo limitado aún expone el mecanismo de gobierno. Kent State necesitaba un identificador que no estuviera en conflicto con otra red. Necesitaba un enlace a OARnet. OARnet necesitaba conexiones externas funcionales y permiso para representar las redes detrás de ella. Los enrutadores del backbone y los pares entonces necesitaban aceptar la información de alcanzabilidad relevante. Una falla en cualquiera de esas etapas podría hacer que un destino fuera inalcanzable aunque los demás registros permanecieran intactos.

La distinción importa porque el resultado podía parecer unitario desde el campus. Un usuario solo veía si se podía o no alcanzar un host remoto. Detrás de ese resultado había decisiones de un registro, una universidad, una red regional, operadores del backbone, proveedores de circuitos y pares remotos. Sus poderes interactuaban, pero no eran intercambiables.

Lo que la NSF encargó—y lo que prueba el registro público

El primer instrumento en la cadena del backbone no fue una política de asignación de direcciones. Fue la solicitud de la Fundación Nacional de Ciencias de 1987 para la gestión y operación de un backbone NSFNET expandido.

La historia posterior de Merit data la Solicitud de Proyecto NSF 87-37 al 15 de junio de 1987. La audiencia del Subcomité de Ciencia de la Cámara de Representantes de 1992,Gestión de NSFNET, reproduce lenguaje importante de la solicitud. Describe el sistema propuesto como una jerarquía de tres niveles: un backbone transcontinental, redes de segundo nivel administradas autónomamente y redes de campus conectadas debajo de ellas. El texto reproducido también invitaba a los proponentes a sugerir arquitecturas o métodos alternativos que pudieran ser más apropiados, económicos o efectivos.

Ese lenguaje establece la separación prevista entre la gestión del backbone nacional y la administración regional. No establece todos los términos del acuerdo eventual. Un conjunto completo autenticado que contenga el Acuerdo Cooperativo ejecutado NCR-8720904, todas las enmiendas, cada arreglo con IBM y MCI, y el instrumento operativo posterior Merit–ANS no está disponible a través del archivo público citado. Por lo tanto, las afirmaciones sobre cláusulas no publicadas excederían la evidencia.

La cadena institucional más estrecha está bien respaldada. Merit propuso un backbone T1 de 1.5 megabits por segundo con IBM y MCI en agosto de 1987. La NSF anunció un acuerdo cooperativo de cinco años con Merit en noviembre. Testimonios contemporáneos ante el Congreso y el relato institucional de Merit identifican a Merit como la organización responsable ante la NSF de la gestión y operación del proyecto del backbone. IBM suministró hardware, software e ingeniería de conmutación de paquetes. MCI suministró las instalaciones de transmisión de larga distancia. El Estado de Michigan proporcionó apoyo adicional.

Estas contribuciones no crearon un único actor corporativo o federal llamado “NSFNET”. La NSF era el financiador y supervisor del programa. Merit era el titular del acuerdo cooperativo y gestor del backbone. Los ingenieros de IBM contribuyeron con sistemas y trabajo de enrutamiento. MCI suministró circuitos y experiencia en comunicaciones. Las universidades y redes regionales permanecieron administradas por separado. La función IANA y el Registro de Internet manejaban los identificadores a través de otra cadena institucional.

La distinción entre un acuerdo cooperativo y una compra ordinaria también es relevante, aunque no decide la cuestión central del artículo. La NSF ejerció una participación continua en un programa de infraestructura cuyo diseño y operación dependían de las contribuciones de varias organizaciones. Podía supervisar el acuerdo, revisar el rendimiento, aprobar cambios y decidir si extender el apoyo. No adquirió la propiedad de todas las direcciones cuyo tráfico cruzó posteriormente el servicio.

El nuevo backbone T1 entró en operación en trece sitios en el verano de 1988. El relato institucional final de Merit sitúa la operación en julio e informa 152 millones de paquetes por mes a 1.5 megabits por segundo. El testimonio de la NSF ante el Congreso en 1992 utilizó una línea de base diferente, describiendo el nuevo backbone como portador de tráfico desde agosto de 1988 y presentando un crecimiento de aproximadamente 200 millones de paquetes por mes a 11 mil millones a principios de 1992.

Esas cifras no son necesariamente contradictorias. Pueden reflejar diferentes fechas de informe, observaciones parciales versus de mes completo o redondeo posterior. Los documentos públicos no definen la diferencia con suficiente precisión como para fusionarlas en un recuento exacto del “primer mes”. La conclusión defendible es que el servicio T1 entró en operación en julio-agosto de 1988, con Merit informando 152 millones de paquetes mensuales en el punto de julio y la NSF usando posteriormente una línea de base de servicio temprano de aproximadamente 200 millones de paquetes.

Esa calificación no disminuye el logro. El sistema de trece nodos reemplazó un arreglo sobrecargado de 56 kilobits con un backbone de producción, apoyó la interconexión regional y dio a las universidades acceso a recursos informáticos y de información remotos sin requerir que cada campus construyera una red nacional.

El sistema T1 unió varias puertas

La estructura operativa de 1988 a 1990 se puede separar en decisiones distintas:

Función	Actor o instrumento principal	Lo que controlaba
Financiación y supervisión del programa	Fundación Nacional de Ciencias	Selección y apoyo del programa del backbone, revisión del rendimiento y condiciones adjuntas al apoyo federal
Gestión del backbone	Merit Network bajo NCR-8720904	Coordinación de ingeniería, operaciones de red, servicios de información, enlace regional y administración de políticas de enrutamiento
Tecnología y transmisión	IBM y MCI, con apoyo de Michigan	Sistemas de conmutación de paquetes, software, ingeniería y circuitos de larga distancia
Acceso orientado al campus	Redes regionales e instituciones participantes	Membresía, circuitos locales, equipos, tarifas, preparación técnica y conexión del campus
Administración de identificadores	IANA en el Instituto de Ciencias de la Información de la USC y funciones del Registro de Internet en el DDN-NIC operado por SRI	Números únicos de red y sistema autónomo y sus registros administrativos
Representación de rutas	Operadores de campus y regionales	Qué red regional podía representar un destino y con qué preferencia
Aceptación de rutas del backbone	Operaciones de Merit y maquinaria de enrutamiento del backbone	Validación de la información de red y sistema autónomo contra los registros de políticas
Propagación adicional	Otros operadores federales, regionales, internacionales y comerciales emergentes	Aceptación y anuncio posterior más allá del backbone inmediato
Elegibilidad de tráfico	Condiciones de uso del backbone de la NSF y políticas de redes conectadas	Si un tráfico particular podía usar la ruta apoyada por el gobierno federal

La estructura financiera aumentó la importancia práctica del alineamiento entre estas puertas.RFC 1192, un informe de un taller de comercialización de 1990, estimó los costos anuales del backbone en aproximadamente $10 millones, de los cuales la NSF pagó menos de $3 millones. Atribuyó gran parte del resto al Estado de Michigan y a los servicios contribuidos de IBM y MCI. El mismo informe estimó que la NSF suministró alrededor del 40 por ciento de los costos de las redes de nivel medio que apoyaba, aunque señaló un rango de cero al 75 por ciento.

Eran estimaciones de taller, no un derecho uniforme o lista de precios. Sin embargo, muestran por qué una ruta apoyada por la NSF podía ser más valiosa que una dirección sola. Fondos federales, apoyo estatal, contribuciones corporativas, tarifas regionales, gastos universitarios e ingeniería en especie se combinaron para crear un servicio nacional cuyo costo total no se cobraba a cada campus conectado como tránsito comercial de larga distancia.

El beneficio era colectivo. Una universidad no tenía que negociar un circuito dedicado a cada centro de supercomputación o a cada otra red regional. Protocolos comunes y un backbone operado permitían que una sola conexión alcanzara un conjunto creciente de destinos. Los efectos de red resultantes aumentaron el valor de cada ruta utilizable.

La dependencia era la otra cara de ese beneficio. Una vez que los investigadores, bibliotecas, administradores y servicios informáticos del campus dependían de la conectividad remota, un retraso en un enlace regional o en una entrada de política del backbone imponía un costo real a los usuarios. Pero la ubicación del remedio dependía de la falla. Una entrada errónea en el registro correspondía a los administradores de identificadores. Una línea dedicada caída correspondía al campus, red regional o proveedor. Un anuncio no autorizado correspondía a las operaciones de enrutamiento. El rechazo de un par remoto no podía corregirse simplemente declarando el destino legítimo por parte de la NSF.

El acceso regional no era una regla federal uniforme

La arquitectura de tres niveles colocaba las redes regionales entre los campus y el backbone nacional, pero esas redes no eran ramas administrativas idénticas de la NSF o Merit.

El relato operativo de OARnet de 1991 describió una red que servía a la educación superior de Ohio y permitía conexiones para corporaciones involucradas en investigación, desarrollo de productos o instrucción. Utilizaba TCP/IP y DECnet, conectaba 29 sitios directamente y operaba una topología en la que 13 enrutadores funcionaban como enrutadores de frontera de sistema autónomo.

Su principal relación de enrutamiento externo en el relato de RFC 1246 pasaba a través de una red desmilitarizada en Columbus conectada a CICNet. Partes de OARnet generaban una ruta por defecto cuando la sesión exterior relevante estaba disponible, en lugar de transportar toda la información EGP externa a través del interior. OARnet también tenía pasarelas a otros sistemas, incluido el NASA Science Internet.

Este arreglo daba a OARnet opciones operativas. Sus ingenieros determinaban los costos de enrutamiento interno, las rutas de respaldo, el diseño de los puntos de presencia y cómo la alcanzabilidad externa se convertía en un valor por defecto dentro del sistema regional. Los operadores del backbone de Merit no elegían el costo de la ruta de OARnet desde Kent State a Akron, y el DDN-NIC no configuraba los enrutadores OSPF de OARnet.

Los enlaces registrados de Kent State muestran lo que cambió la topología regional. El circuito DS1 ofrecía una ruta preferida más rápida. La conexión de 56 kilobits y la ruta más larga a través de Cleveland proporcionaban una alternativa menos atractiva durante un reinicio. A medida que los enlaces se recuperaban, OSPF recalculaba las rutas. El evento demuestra convergencia y resiliencia regional; no muestra el prefijo externo de Kent cambiando ni prueba que todo el tráfico externo usara NSFNET.

Otras redes regionales utilizaban arreglos organizativos y técnicos diferentes. El estudioEl futuro estratégico de las redes de nivel mediodescribió BARRNet como distribuyendo la propiedad del equipo y la responsabilidad operativa entre las instituciones participantes. NYSERNet dependía en gran medida de arreglos con empresas de telecomunicaciones. PREPnet externalizaba funciones extensas a un proveedor. NorthwestNet utilizaba Boeing Computer Services, mientras que NEARnet usaba BBN.

La huella de BARRNet en 1991 incluía aproximadamente 80 sitios universitarios, gubernamentales y comerciales con velocidades de acceso que iban desde 9.6 kilobits por segundo hasta T1. Se conectaba en Stanford tanto a las instalaciones T1 como T3 de NSFNET y también tenía enlaces a ESnet, redes de defensa y sistemas universitarios de California. Esta no era la misma topología, mercado o entorno institucional que OARnet.

En consecuencia, el “acceso a NSFNET” no podía reducirse a una única solicitud nacional de campus. Una universidad típicamente necesitaba una organización regional dispuesta y capaz de conectarla, un circuito dedicado adecuado, equipos, personal técnico y un arreglo de enrutamiento. La organización regional podía recibir apoyo federal, pero también podía depender de asignaciones estatales, tarifas institucionales, miembros corporativos, contratos con proveedores o contribuciones en especie.

Un campus retrasado no estaba necesariamente prohibido de Internet por decreto federal. Más bien, podría carecer de un circuito de última milla asequible, quedar fuera de la clase de membresía de una red regional o no poder cumplir con un requisito de equipo. Si existía otra ruta dependía de la geografía, la presencia de proveedores, la elegibilidad y la interconexión.

Este límite probatorio es importante para Kent State. Los materiales conservados no proporcionan el acuerdo de conexión original de Kent con OARnet, la tarifa, la fecha de instalación o las cotizaciones de servicios alternativos. Por lo tanto, no pueden respaldar una afirmación de que un proveedor de reemplazo específico estaba disponible para Kent en 1988 a un precio conocido. Las conexiones de OARnet a CICNet y NASA no establecen que Kent pudiera haber comprado esas rutas de forma independiente o usarlas si se le hubiera rechazado su conexión a OARnet.

La admisión regional era una puerta real. No era una puerta estandarizada a nivel nacional, y el registro disponible de Kent no preserva una denegación, apelación o alternativa costeada.

Un número registrado no era un derecho al servicio

El sistema de identificadores llevaba rastros de políticas de interconexión anteriores. RFC 1166 distinguía las redes que participaban en la Internet de investigación y operativa de las redes IP independientes. Las redes independientes estaban marcadas con un asterisco y requerían permiso separado para interconectarse. La131.123de Kent State y la131.187de OARnet aparecían como redes de investigación sin esa marca.

Eso era información administrativa significativa en julio de 1990, pero su significado debe permanecer limitado. La entrada no demostraba que una ruta estuviera activa en todo momento. No especificaba qué red regional era responsable de cada paquete. No ordenaba a un proveedor suministrar un circuito ni obligaba a una red extranjera a aceptar el destino.

RFC 1174, emitida en agosto de 1990, explica tanto la división institucional como la creciente insuficiencia del “estado de conexión”. Identificaba la función IANA como realizada por el Instituto de Ciencias de la Información de la USC. Identificaba a SRI International como el Registro de Internet responsable de recopilar y registrar información sobre los identificadores de red y sistema autónomo asignados.

El documento describía una historia en la que los números se habían asignado primero a organizaciones que participaban en la investigación de Internet y más tarde a redes gubernamentales o patrocinadas por el gobierno a las que se permitía interconectarse. A medida que TCP/IP se difundió en redes privadas, el registro asignaba números globalmente únicos incluso cuando una organización no tenía intención de conectarse a la Internet patrocinada por el gobierno federal. El “estado de conexión” se convirtió en la distinción intentada entre poseer un identificador y tener sanción gubernamental para interconectarse.

Para 1990, ese campo binario ya no describía la red con precisión. Los sistemas regionales servían membresías mixtas. Las redes comerciales estaban emergiendo. Las redes internacionales no podían reducirse sensatamente a la aprobación de un patrocinador estadounidense. Una red podía transportar parte del tráfico sobre una ruta apoyada por la NSF y otro tráfico sobre un par o backbone diferente.

RFC 1174 recomendó, por lo tanto, que el Registro de Internet eliminara el estado de conexión de los formularios y bases de datos, recopilara en su lugar información sobre políticas de acceso y tránsito, y permitiera que cualquier red registrada entrara en el Sistema de Nombres de Dominio sin importar el estado de conexión. Declaró que el registro debería administrar el espacio de números mientras que los administradores de red aplicaban la política de tráfico.

El documento era una recomendación del IAB, no un estándar técnico y no prueba que cada formulario, base de datos y enrutador cambiara inmediatamente. Su cronología no debe comprimirse en una reforma de la noche a la mañana. Lo que establece claramente es que los formuladores de políticas reconocieron el registro y la interconexión como funciones diferentes y buscaron eliminar la aplicación del acceso de la capa de nombres y registro de identificadores.

Esta no era una distinción meramente teórica. Una organización podía requerir un número único para una red TCP/IP privada sin tener tránsito externo. A la inversa, un campus podía tener acceso físico a una red regional mientras aún necesitaba espacio de direcciones legítimo y no conflictivo antes de poder ser representado de manera segura a la Internet más amplia.

La política de enrutamiento creó la unión operativa

El registro hacía que un identificador fuera administrativamente legítimo. La política de enrutamiento determinaba si el backbone creía que una red particular era alcanzable a través de un sistema regional particular.

EnRFC 1092, Jacob Rekhter describió una limitación del Protocolo de Pasarela Exterior utilizado entre el nuevo backbone y las redes regionales. EGP por sí solo no podía evitar que una red regional reclamara un destino que pertenecía detrás de otra. Tampoco podía expresar una jerarquía confiable de rutas preferidas y de respaldo en un entorno mallado con enlaces “traseros” adicionales.

El remedio propuesto era tanto institucional como técnico. Una red seleccionaría uno o más representantes regionales a través de arreglos bilaterales. La información sobre los representantes primario y secundario elegidos se suministraría al Centro de Operaciones de Red de NSFNET y se ingresaría en la Base de Datos de Políticas de Enrutamiento. El backbone ignoraría un anuncio de una red regional que no estuviera autorizada para representar ese destino.

RFC 1093describió la arquitectura correspondiente. Se esperaba que los backbones regionales usaran números de sistema autónomo únicos. Los nodos del backbone verificaban tanto los números de red como el número de sistema autónomo de origen. Las rutas preferidas se derivaban de la información suministrada por los backbones regionales y los campus conectados. Las redes regionales podían generar valores por defecto internos, mientras que el backbone mantenía alcanzabilidad explícita para las redes conectadas y pares.

Por lo tanto, la ruta dependía de que los registros de diferentes autoridades coincidieran:

Un número de red debía ser único y estar correctamente registrado.
Un campus necesitaba una relación de conexión con una red regional.
El campus y la red regional necesitaban una representación y preferencia de ruta acordadas.
Los datos de política del backbone debían autorizar al sistema autónomo regional a anunciar ese destino.
El circuito y las sesiones de enrutador relevantes debían estar operativos.
Otros operadores debían aceptar y propagar la ruta si se requería alcance más allá de NSFNET.

Estas condiciones eran acumulativas pero no constitucionalmente unificadas. El registro podía corregir la identidad asociada con un número pero no podía reparar un circuito DS1 fallado. Un operador regional podía restaurar un enlace pero no podía hacer que un número duplicado fuera globalmente único. El Centro de Operaciones de Red de Merit podía rechazar un anuncio no autorizado pero no podía obligar a un par independiente a aceptar una ruta.

Aquí es donde el acceso al backbone dio forma al poder de las direcciones. La base de datos de políticas de NSFNET no era el registro de direcciones, sin embargo, la inclusión en un sistema de enrutamiento ampliamente utilizado hacía que un número registrado fuera más útil. A medida que la red alcanzable crecía, la representación correcta a través del backbone adquiría mayor valor práctico.

El mismo sistema restringía las reclamaciones unilaterales de rutas. Una red regional no podía simplemente anunciar el número de red de otra organización con una métrica preferida y esperar que el backbone lo creyera. Los registros de políticas y la validación del sistema autónomo convertían una relación administrativa en un permiso de enrutamiento.

La autoridad resultante era más estrecha que la propiedad de direcciones y más amplia que el reenvío mecánico de paquetes. Los operadores del backbone controlaban lo que su propio servicio aceptaba. Debido a que ese servicio tenía un alcance excepcional, sus decisiones operativas podían afectar a muchos usuarios. La escala de la consecuencia provenía de la topología y la adopción, no de un mandato global.

Lo que cuentan las cifras de crecimiento

La expansión de NSFNET es evidencia material del beneficio público, pero sus estadísticas describen poblaciones diferentes.

La cifra de Merit de julio de 1988 de 152 millones de paquetes mensuales y la línea de base posterior de la NSF de aproximadamente 200 millones de servicio temprano se refieren al tráfico. No cuentan direcciones ni instituciones. El testimonio de la NSF informó aproximadamente 11 mil millones de paquetes por mes para marzo de 1992, una medida del uso en rápido aumento más que un censo de organizaciones conectadas.

El backbone mismo creció de 13 sitios T1 a una arquitectura T3 de 16 sitios. Un sitio del backbone no era un campus, red regional o usuario individual. Era un nodo o punto de conexión dentro del servicio nacional.

Las declaraciones ante el Congreso en 1992 se refirieron a aproximadamente 5,000 redes, incluyendo alrededor de 1,500 fuera de los Estados Unidos, conectadas al sistema más amplio. Esas estimaciones se presentaron en una audiencia política e institucional y no deben tratarse como una instantánea exacta de la tabla de enrutamiento.

Una actualización de enrutamiento de NSFNET fechada en enero de 1993 informó 8,997 redes configuradas en la base de datos de políticas T3. Ese recuento representaba entradas de red configuradas y sus rutas preferidas de sistema autónomo. No era un recuento de organizaciones únicas. Una institución podía tener múltiples redes con clase, y una entrada configurada podía tener representaciones primarias y de respaldo.

Los totales de asignación enRFC 1366medían algo diferente nuevamente. En 1992, el documento informó 49 números Clase A asignados, 7,354 Clase B y 44,014 Clase C. Eran unidades de asignación en el sistema de direccionamiento con clase, no clientes de NSFNET. Algunas se usaban en redes privadas o no-NSF, y una Clase A representaba una capacidad de direccionamiento mucho mayor que una Clase C.

La visualización de tráfico posterior preservada porCAIDAreporta 18.5 billones de bytes entrantes durante diciembre de 1994. Para esa visualización, 24,435 redes cliente domésticas se agregaron en 12,177 conexiones de tráfico virtuales según la ciudad y el nodo del backbone. De nuevo, una red cliente, una línea virtual en una visualización y una institución no eran equivalentes.

Usadas con cuidado, las cifras muestran varias formas de expansión: más tráfico, más rutas configuradas, más asignaciones de direcciones, más redes cliente y mayor alcance geográfico. No prueban que la financiación del backbone por sí sola causara cada cambio. La caída de los costos de equipos, la difusión del software TCP/IP, la inversión regional, los servicios comerciales, la demanda del campus, las redes internacionales y las nuevas aplicaciones contribuyeron.

La afirmación causal puede, por lo tanto, permanecer modesta pero importante. La inversión de la NSF y el servicio liderado por Merit suministraron un entorno de ruta compartido de alta capacidad que permitió que gran parte de este crecimiento se volviera mutuamente alcanzable. No produjo cada dirección asignada, y la correlación temporal entre el crecimiento de direcciones y el crecimiento del backbone no establece que Merit controlara la asignación.

T3 cambió la capacidad y las operaciones, no la autoridad sobre los identificadores

Para 1990, el sistema T1 estaba nuevamente bajo presión. La actualización a T3 aumentó la transmisión nominal del backbone de 1.5 a 45 megabits por segundo y expandió la arquitectura a 16 sitios. También cambió la organización operativa.

Merit, IBM y MCI formaron Advanced Network & Services, Inc., o ANS, en septiembre de 1990. El registro del Congreso de 1992 describe a Merit como permaneciendo responsable bajo su acuerdo cooperativo mientras subcontrataba la gestión y operación sustancial del backbone actualizado a la nueva organización sin fines de lucro. La historia institucional final de Merit presenta de manera similar a ANS como el vehículo operativo para gran parte del trabajo T3.

Los materiales públicos disponibles establecen el esquema organizativo pero no exponen cada cláusula operativa del acuerdo Merit–ANS del 17 de septiembre de 1990. Por lo tanto, es más seguro describir la división observable que atribuir derechos no documentados. La NSF siguió siendo el financiador y supervisor del programa. Merit siguió siendo responsable en la cadena del acuerdo cooperativo. ANS emprendió una extensa ingeniería y operaciones T3. IBM y MCI continuaron suministrando tecnología, instalaciones, personal y apoyo importantes.

El paso a T3 no fue instantáneo. La instalación de nodos, el transporte de tráfico inicial, la migración de conexiones regionales y el retiro de la red T1 fueron eventos diferentes. El relato de Merit sitúa la finalización del sistema T3 de 16 sitios en 1991. Las instalaciones T1 y T3 coexistieron entonces mientras las conexiones y rutas se movían.

Un aviso operativo de Merit archivado en el registro de NANOG de noviembre de 1992 programó el apagado del backbone T1 para el miércoles 2 de diciembre de 1992. Ese aviso fechado suministra la distinción faltante entre la llegada anterior del servicio de producción T3 y el retiro posterior del servicio T1 restante. El backbone T3 no se volvió completamente exclusivo meramente porque los primeros enlaces T3 transportaron paquetes.

El sistema de rutas también se expandió. La actualización de enero de 1993 que reporta 8,997 redes T3 configuradas ilustra la cantidad de datos de política que las operaciones del backbone tenían que mantener. Cada entrada representaba una red y rutas esperadas de sistema autónomo, no una concesión de una dirección. La base de datos operacionalizaba relaciones ya establecidas en otro lugar.

Por lo tanto, esta fase intensificó la puerta práctica sin cambiar su identidad legal. Una entrada de política T3 faltante o incorrecta podía afectar la alcanzabilidad a través de un servicio mucho más grande. No convirtió a ANS o Merit en la IANA, y no transfirió la propiedad de los números registrados a la NSF.

La comercialización introdujo alternativas de manera desigual

Los servicios TCP/IP comerciales estaban emergiendo antes de que la transición T3 se completara. AlterNet y Performance Systems International comercializaban conectividad. Las redes regionales servían a algunas organizaciones de investigación industrial y buscaban ingresos más allá del apoyo federal. El Commercial Internet Exchange ofrecía interconexión fuera de las condiciones de tráfico del backbone apoyado por la NSF.

ANS creó una subsidiaria con fines de lucro, ANS CO+RE, en 1991 para proporcionar servicio comercial. El arreglo se volvió controvertido porque ANS también operaba infraestructura utilizada para el servicio apoyado por el gobierno federal. Los participantes en la audiencia de la Cámara de Representantes de 1992 disputaron la asignación de costos, la consulta, la interconexión y la ventaja competitiva.

El testimonio no respalda convertir cada alegación en un hallazgo. Los críticos argumentaron que la estructura favorecía un camino y difuminaba los límites del apoyo público. Merit y la NSF argumentaron que el arreglo fomentaba la inversión privada mientras protegía el servicio de investigación y educación. La audiencia establece la presencia de una disputa institucional seria, no una conspiración o reclamo de propiedad probado.

Para el valor de las direcciones, la comercialización importaba porque hacía un emparejamiento alternativo cada vez más posible: un número registrado válido podía enrutarse a través de un proveedor comercial en lugar de a través de NSFNET. Un cliente podía adquirir servicio, arreglar un circuito y pedir al proveedor que representara su red.

Esa posibilidad permanecía condicional. Un proveedor necesitaba presencia geográfica o un punto de presencia alcanzable. El cliente necesitaba un circuito de última milla, equipos, personal, un acuerdo de servicio y aceptación de enrutamiento. La existencia de un backbone comercial en los Estados Unidos no probaba que cada universidad pudiera comprar un servicio comparable localmente o de manera asequible.

Los materiales conservados de Kent State no proporcionan una cotización contemporánea de AlterNet, PSI u otro servicio comercial que cubra la ubicación de Kent, elegibilidad, instalación y costo completo. No muestran que BITNET, el NASA Science Internet o una red regional vecina estuviera disponible como un sustituto general de tránsito IP. Por lo tanto, sería especulativo afirmar que un servicio alternativo específico era factible para Kent en 1988 o asignarle un precio comparativo.

Lo que el registro más amplio muestra es un cambio en el mercado con el tiempo. A principios de la década de 1990, las organizaciones tenían más posibles proveedores ascendentes y más lugares para intercambiar tráfico. Las múltiples conexiones de BARRNet demuestran que los sistemas regionales podían usar NSFNET junto con rutas de agencias y locales. RFC 1092 ya había contemplado representaciones primarias, secundarias y “traseras”. El crecimiento comercial expandió esas posibilidades técnicas en opciones de servicio, aunque de manera desigual.

La autoridad práctica de NSFNET, en consecuencia, se debilitó antes de que el servicio terminara formalmente. Siguió siendo muy importante, pero una red registrada era menos dependiente de una ruta nacional subsidiada una vez que los proveedores comerciales y las relaciones de intercambio podían entregar destinos comparables.

El registro se movió en un calendario separado

La administración de identificadores experimentó su propio cambio institucional mientras el backbone T3 estaba operando.

La solicitud de la NSF de marzo de 1992,NSF 92-24, dividió los servicios de información de red en funciones de registro, directorio y base de datos, e información. A partir del 1 de enero de 1993, elAcuerdo Cooperativo NCR-9218742 de la NSF con Network Solutionsestableció servicios de registro no militares bajo lo que se convirtió en el marco InterNIC.

La declaración de trabajo cubría el registro de dominios de Internet, la asignación de números de red y la asignación de números de sistema autónomo en coordinación con IANA y los documentos de políticas relevantes. No asignaba a Network Solutions la responsabilidad de operar los enrutadores de NSFNET o seleccionar proveedores de tránsito comercial.

RFC 1400documentó la transición operativa del DDN-NIC al InterNIC. Fijó el 1 de abril de 1993 como el punto efectivo para que las solicitudes de registro no DDN se movieran al nuevo servicio. El registro militar permaneció en su camino separado.

Esta secuencia importa porque ocurrió antes de que el antiguo backbone se apagara. Para 1993, una universidad podía dirigir una solicitud de número o sistema autónomo a InterNIC mientras su red regional continuaba usando el servicio T3 operado por ANS. La base de datos de políticas de enrutamiento y la base de datos de registro eran administrativamente distintas incluso cuando compartían identificadores e información de contacto.

Un registro preciso aún afectaba el enrutamiento. Los operadores necesitaban saber qué organización poseía una red y a quién contactar cuando se disputaba un anuncio. Pero el registro del registro no activaba una interfaz del backbone. De manera similar, una ruta válida en NSFNET no transfería la función de registro subyacente al operador del backbone.

La transición de 1993–1995 redistribuyó la autoridad de acceso

La solicitud de la NSF de mayo de 1993,NSF 93-52, propuso cuatro áreas de proyecto distintas: Puntos de Acceso a la Red, un Árbitro de Enrutamiento, apoyo a redes regionales y un Servicio de Red de Backbone de Muy Alta Velocidad para investigación avanzada.

La estructura evitó deliberadamente reemplazar el antiguo servicio NSFNET con un único backbone comercial. Los proveedores comerciales de servicios de red transportarían el tráfico general y se interconectarían en los Puntos de Acceso a la Red. Las redes regionales contratarían servicio ascendente de esos proveedores, con asistencia transitoria de la NSF. La coordinación de enrutamiento continuaría a través de un proyecto de Árbitro de Enrutamiento. La vBNS serviría requisitos de investigación avanzada en lugar de actuar como el único sucesor universal.

Ladecisión de la GAO sobre el desafío de Sprint a la adjudicación de vBNSconfirma que NSF 93-52 contemplaba varios acuerdos cooperativos y que MCI fue seleccionada para el proyecto vBNS en febrero de 1994. La decisión también refuerza la necesidad de distinguir ese servicio de investigación del tránsito comercial que reemplazaba al antiguo backbone.

La cadena de acceso cambió en consecuencia:

Función en la transición	Actores principales	Consecuencia operativa
Financiación transitoria	NSF	Apoyó la migración sin elegir un backbone comercial permanente único
Continuidad del antiguo backbone	Merit y ANS	Mantuvo el servicio existente disponible mientras las redes regionales se movían
Tránsito de reemplazo	ANSNet, internetMCI, SprintLink, PSINet y otros proveedores	Vendieron conectividad bajo arreglos de servicio separados
Migración regional	Redes regionales y sus miembros	Seleccionaron proveedores, instalaron circuitos, probaron rutas y asumieron el riesgo de transición local
Administración de identificadores	IANA, InterNIC y registros delegados emergentes	Continuaron la administración de números y contactos independientemente de la elección del proveedor
Interconexión	Operadores de Puntos de Acceso a la Red y proveedores participantes	Suministraron ubicaciones para el intercambio entre múltiples backbones
Coordinación de enrutamiento	Participantes del Árbitro de Enrutamiento, proveedores y operadores clientes	Mantuvieron la información de rutas y diagnosticaron alcanzabilidad inconsistente
Backbone de investigación avanzada	NSF y MCI a través del proyecto vBNS	Suministraron un servicio de alto rendimiento distinto en lugar del tránsito de reemplazo comercial general

Un informe de transición de Merit fechado el 30 de septiembre de 1994 muestra por qué el registro por sí solo no podía completar la migración. Rastreó cinco dependencias operativas: Puntos de Acceso a la Red funcionales, conexión de NSFNET a esos puntos, conexiones de nuevos proveedores, servicios del Árbitro de Enrutamiento y la conexión de cada red regional a su proveedor elegido. Una falla en cualquiera de esas áreas podía dejar a una institución con identificadores válidos pero alcanzabilidad incompleta.

La transición final fue por etapas en lugar de ceremonial. El aviso de Merit del 14 de abril de 1995 informó que solo siete organizaciones habían cortado completamente su antigua relación con NSFNET. Muchas estaban usando nuevos proveedores mientras retenían NSFNET como respaldo.

Las sesiones restantes fueron programadas para un apagado de prueba el 21 de abril para revelar redes inalcanzables. La restauración temporal seguía siendo posible mientras se corregían los problemas. El aviso luego pedía la terminación permanente de las sesiones restantes el 28 de abril, seguida de la terminación del servicio de backbone el 30 de abril.

Un comunicado de la NSF fechado el 15 de mayo confirmó que el Servicio de Backbone NSFNET había sido desmantelado a la medianoche del 30 de abril de 1995.

El apagado ilustra fuertemente la separación entre el registro de direcciones y el servicio del backbone, pero no prueba que cada prefijo individual migrara sin interrupción. Demostrar continuidad para el131.123de Kent State, por ejemplo, requeriría observaciones de enrutamiento emparejadas antes y después, además de la entrada del registro. Los avisos de transición disponibles muestran un sistema diseñado para preservar la alcanzabilidad mientras los servicios cambiaban; no suministran una traza específica de prefijo para Kent.

Lo que se puede afirmar con confianza es que la terminación del antiguo backbone no abolió el sistema de identificadores. Las funciones de InterNIC e IANA continuaron. Las redes regionales compraron tránsito de reemplazo. Los proveedores intercambiaron rutas en nuevos puntos de interconexión. El valor operativo de las direcciones persistió solo porque esos nuevos actores transportaron y aceptaron las rutas.

Probando los dos ejes sin inventar alternativas

La distinción se puede probar a través de varios escenarios acotados.

Un identificador válido sin tránsito externo utilizable

Supongamos que una universidad poseía un número de red registrado globalmente único pero carecía de una conexión regional funcional o un proveedor ascendente aceptable.

Podía usar el número internamente sin colisionar con otra red registrada. Podía operar servicios TCP/IP locales e intercambiar tráfico sobre cualquier ruta bilateral que acordara transportarlo. El registro seguiría siendo significativo.

Lo que le faltaría es alcance externo general. La universidad necesitaría una conexión regional, un proveedor comercial, una ruta de agencia elegible o un par dedicado. Cada opción requería su propio acuerdo e instalaciones físicas. El registro no obligaría a ninguno de ellos a proporcionar servicio.

Para Kent State, el registro histórico no establece qué sustituto, si alguno, cumplía todas esas condiciones en 1988. Las múltiples pasarelas posteriores de OARnet demuestran topología, no un derecho de servicio independiente para Kent. La existencia de BITNET no proporcionaría por sí sola tránsito IP general. Los proveedores comerciales se volvieron más plausibles después de 1990, pero no se ha recuperado un registro completo de precio o disponibilidad específico para Kent.

La conclusión justificada es, por lo tanto, limitada: una dirección registrada podía sobrevivir sin NSFNET, pero su utilidad externa dependía de obtener otro portador y ruta aceptada. Si eso era factible o asequible para Kent en una fecha particular sigue siendo desconocido.

Acceso físico sin un identificador público válido

Invirtamos las condiciones. Una red regional podría tener un circuito disponible y estar dispuesta a conectar un campus, pero el campus podría carecer de un número de red válido para uso general en Internet.

El circuito podría transportar tráfico bajo un plan de direccionamiento local u otro arreglo técnicamente coordinado. Las posibilidades genéricas de ingeniería incluían usar espacio de direcciones controlado por el proveedor válido o retrasar la publicación del anuncio hasta que se resolviera el registro. Los materiales conservados de OARnet no establecen qué remedio habría ofrecido a Kent, por lo que ninguno debe presentarse como política de OARnet.

Lo que el campus no podía hacer de manera segura era seleccionar el número público de otra organización y esperar que el enrutamiento global funcionara. La numeración duplicada podía desviar paquetes o hacer que los filtros rechazaran el anuncio. La maquinaria de políticas de NSFNET fue diseñada específicamente para comparar la información de red y sistema autónomo con la representación esperada.

El remedio comenzaría en el lado del identificador: obtener o corregir una asignación legítima y asegurar que los contactos y la representación responsables fueran precisos. Abrir un puerto del backbone no podía hacer que un identificador duplicado fuera único.

Una ruta legítima que un par se negó a transportar

Un destino podía estar correctamente registrado, conectado a una red regional y aceptado por NSFNET mientras permanecía inalcanzable a través de otro proveedor.

Cada par o backbone controlaba su propia política de enrutamiento. La escala de NSFNET hacía que su información fuera influyente, pero no podía ordenar a cada operador de agencia, comercial o internacional que propagara una red. Una dirección enrutada era, por lo tanto, evidencia de aceptación a lo largo de algún camino, no prueba de aprobación universal.

El remedio apropiado era el diagnóstico de rutas y la coordinación entre operadores. El registro podía ayudar a identificar contactos pero no podía obligar al transporte. Merit podía corregir su propia base de datos de políticas pero no podía configurar cada red remota.

Conectividad elegible con tráfico que requería otra ruta

Un campus también podía poseer un identificador válido y una ruta funcional mientras parte del tráfico no era elegible para el backbone apoyado por el gobierno federal. Eso era un problema de política de tráfico, no la cancelación de la dirección o la denegación de la membresía física.

La institución podría necesitar enrutar el tráfico relevante a través de otro proveedor o demostrar que servía al propósito permitido de investigación y educación. El punto importante aquí es institucional: el cumplimiento del uso aceptable era otra condición en el camino, no la autoridad que creó el número.

Estos escenarios evitan la falsa simetría. Sus consecuencias no eran idénticas, y los remedios disponibles diferían. La falla del registro amenazaba la unicidad y la representación estable. La falla regional amenazaba la conexión local. La falla del backbone amenazaba el transporte interregional. El rechazo de pares amenazaba el alcance más allá del proveedor inmediato. El conflicto de política de tráfico afectaba qué usos podían atravesar un camino apoyado particular.

Para un usuario del campus, todos podían producir el mismo síntoma: un destino remoto no respondía. El análisis de gobernanza tiene que reconstruir la capa en la que ocurrió la falla.

Dónde se asentaban la autoridad y la consecuencia

La NSF gobernaba directamente el programa que financiaba. Seleccionó y supervisó la estructura del acuerdo cooperativo, apoyó la conectividad regional, revisó el rendimiento, aprobó cambios y más tarde diseñó la transición hacia Puntos de Acceso a la Red, proveedores de servicios comerciales, un Árbitro de Enrutamiento y la vBNS.

Merit gestionó y coordinó el backbone bajo su acuerdo con la NSF. Sus responsabilidades incluían operaciones de red, servicios de información, enlace regional y los datos de políticas necesarios para mantener coherente un sistema enrutado en crecimiento.

IBM y MCI suministraron contribuciones técnicas y de comunicaciones distintas. No eran autoridades de membresía universitaria ni registros de números de Internet. Durante la fase T3, ANS asumió un extenso trabajo de ingeniería y operaciones mientras Merit permanecía en la cadena del acuerdo con la NSF.

Las redes regionales controlaban la capa orientada al campus. Decidían a quién podían servir, cómo se arreglarían los circuitos y equipos, qué tarifas y condiciones locales se aplicaban, y cómo funcionaba el enrutamiento interno. Sus estructuras eran heterogéneas, y las consecuencias de la geografía o la elección limitada de proveedores variaban sustancialmente.

La función IANA, el trabajo del Registro de Internet del DDN-NIC y más tarde los servicios de registro InterNIC controlaban los identificadores y registros a través de una secuencia separada. Esos registros importaban porque los números duplicados o mal atribuidos no podían soportar un enrutamiento global confiable. Las autoridades de identificadores no operaban el circuito DS1 de Kent State ni seleccionaban su ruta ascendente.

Los operadores de campus, regionales, de backbone y pares convertían esas relaciones en alcanzabilidad. Configuraban enrutadores, intercambiaban información de enrutamiento, validaban representantes esperados, restauraban sesiones fallidas y decidían qué rutas propagar. Su trabajo determinaba si un número registrado era utilizable en un momento dado.

La proposición de que NSFNET amplificó el poder de las direcciones se sostiene, por lo tanto, solo en un sentido distribuido. La conectividad financiada por la NSF hizo que Internet fuera más útil. Cuantos más destinos conectaban el backbone y sus pares, más valioso se volvía poseer un identificador que estuviera correctamente representado a través de ese entorno.

Ese efecto también aumentó las consecuencias de la admisión regional y las decisiones de política de enrutamiento. Un registro en el registro de números era necesario pero insuficiente. Un circuito regional sin un identificador legítimo también era insuficiente. Ningún eje por sí solo producía alcanzabilidad general.

La inversión pública no debe tratarse como incidental a este resultado. NSFNET creó interoperabilidad nacional a una velocidad y escala que las universidades individuales probablemente no hubieran reproducido por separado. Compartió costos fijos, desarrolló operaciones, apoyó el crecimiento regional y dio a los investigadores acceso a recursos distantes. Su éxito es parte de la explicación de su poder: la dependencia siguió a la utilidad.

Tampoco debe confundirse la dependencia con un monopolio formal sobre las direcciones. Servicios comerciales, redes de agencias, pares directos y puertas traseras regionales existieron o emergieron en diferentes momentos. Su disponibilidad era desigual, y su existencia no garantizaba una alternativa factible para cada institución. Pero demuestran que el valor de la ruta podía migrar sin requerir que el identificador fuera recreado.

La transición de 1995 hizo visible esa separabilidad a escala del sistema. El antiguo backbone terminó. El registro continuó. Las redes regionales cambiaron de proveedores. Las rutas se movieron a través de redes comerciales y puntos de intercambio. La coordinación de enrutamiento persistió en nuevas organizaciones.

Esto no era prueba de que cada migración fuera perfecta. Era evidencia de que la identidad de Internet y el transporte de Internet podían sobrevivir al reemplazo institucional porque nunca habían sido la misma función.

La NSF no era dueña de las direcciones transportadas sobre NSFNET. Merit no decidía toda la admisión global a Internet. ANS no se convirtió en IANA al operar el servicio T3. El DDN-NIC e InterNIC no proporcionaban circuitos de campus. Las redes regionales no controlaban cada par más allá de sus fronteras.

Sin embargo, sus decisiones se alineaban lo suficientemente estrechamente como para que los usuarios pudieran experimentarlas como una sola puerta. La importancia de gobernanza de NSFNET radica en esa alineación. El acceso al backbone moldeó el poder de las direcciones no absorbiendo la autoridad sobre los identificadores, sino determinando si un identificador legítimo podía participar en uno de los entornos de enrutamiento más valiosos de su tiempo.

Merit Network y la puerta NSFNET: Cuando el acceso al backbone moldeó el poder de las direcciones