Merit Network e o Portão NSFNET: Quando o Acesso ao Backbone Moldou o Poder dos Endereços

Resumo

• O registro de endereços e o acesso à rede eram relacionados, porém separados. Um número de rede Internet válido estabelecia unicidade e um registro administrativo; não fornecia um circuito, associação regional, elegibilidade ao NSFNET ou uma rota que outros operadores aceitariam.
• A NSF financiou e supervisionou o programa de backbone, a Merit o gerenciou, a IBM forneceu tecnologia de comutação de pacotes e engenharia importantes, a MCI forneceu instalações de transmissão e, posteriormente, a ANS operou grande parte da infraestrutura T3. Redes regionais, universidades, autoridades de identificadores e operadores pares mantiveram decisões distintas.
• O sistema de roteamento do NSFNET converteu relacionamentos institucionais em alcance operacional ao validar números de rede, identidades de sistemas autônomos e representação regional autorizada. Isso tornou os registros de roteamento tão importantes quanto os registros de registro sem transformar a Merit no alocador de endereços da Internet.
• O investimento público produziu benefícios substanciais de interoperabilidade: links nacionais mais rápidos, operações compartilhadas, acesso universitário mais amplo e um sistema de rotas que conectou milhares de redes. A dependência desse alcance subsidiado, no entanto, deu às decisões regionais e de backbone consequências além de seus mandatos formais.
• A transição de 1993–1995 demonstrou a separação dos dois eixos. O registro foi transferido para a InterNIC enquanto as redes regionais adquiriram trânsito comercial, as rotas migraram para vários provedores e pontos de troca, e o antigo Serviço de Backbone NSFNET terminou em 30 de abril de 1995.

Uma ilustração em camadas, não um caso documentado de admissão

A Kent State University oferece uma visão útil das camadas pelas quais um endereço se tornava utilizável, mas as evidências remanescentes não registram uma única transação contínua de admissão.

O registro de números da Internet de julho de 1990, publicado comoRFC 1166, listou131.123comoKENT-STATEna categoria de pesquisa. Essa entrada estabelece que o número estava registrado para a Kent State até aquela data. Ela não revela a solicitação original, a data em que o número foi solicitado pela primeira vez, a justificativa usada para aprová-lo ou os termos sob os quais a universidade obteve conectividade externa.

Um relato operacional separado de 1991,RFC 1246, descreveu a posição da Kent State dentro da Ohio Academic Resources Network, ou OARnet. Ele registrou um circuito DS1 da Kent State para o ponto de presença da OARnet em Akron e uma conexão de 56 quilobits representada como131.187.36.0. Este último número pertencia à infraestrutura da OARnet, não à rede131.123registrada da Kent State. O documento também descreveu um caminho de backup alternativo através de Cleveland quando os links preferenciais estavam indisponíveis.

Essas são duas observações genuínas: um instantâneo do registro e um instantâneo operacional posterior da rede regional. Elas não comprovam os termos de associação originais da Kent State, seu primeiro anúncio de rota externa bem-sucedido ou o caminho exato percorrido por um pacote em um dia específico. A reinicialização da OARnet descrita na RFC 1246 dizia respeito à convergência de rotas para endereços da infraestrutura da OARnet. Ela não deve ser mal interpretada como uma rota capturada de ponta a ponta para131.123.

O exemplo limitado ainda expõe o mecanismo de governança. A Kent State precisava de um identificador que não entrasse em conflito com outra rede. Precisava de uma conexão com a OARnet. A OARnet precisava de conexões externas funcionando e permissão para representar as redes por trás dela. Os roteadores do backbone e de pares então precisavam aceitar as informações de alcançabilidade relevantes. Uma falha em qualquer um desses estágios poderia tornar um destino inalcançável, mesmo que os outros registros permanecessem intactos.

A distinção importa porque o resultado poderia parecer unitário do ponto de vista do campus. Um usuário via apenas que um host remoto podia ou não ser alcançado. Por trás desse resultado estavam decisões de um registro, uma universidade, uma rede regional, operadores de backbone, provedores de circuitos e pares remotos. Seus poderes interagiam, mas não eram intercambiáveis.

O que a NSF encomendou – e o que o registro público prova

O primeiro instrumento na cadeia do backbone não foi uma política de alocação de endereços. Foi a solicitação da National Science Foundation de 1987 para gerenciamento e operação de um backbone NSFNET expandido.

O histórico posterior da Merit data a Solicitação de Projeto NSF 87-37 em 15 de junho de 1987. A audiência do Subcomitê de Ciência da Câmara de 1992,Management of NSFNET, reproduz trechos importantes da solicitação. Ela descreve o sistema proposto como uma hierarquia de três níveis: um backbone transcontinental, redes de segundo nível administradas autonomamente e redes de campus conectadas abaixo delas. O texto reproduzido também convidava os proponentes a sugerir arquiteturas ou métodos alternativos que pudessem ser mais apropriados, econômicos ou eficazes.

Esse texto estabelece a separação pretendida entre a gestão do backbone nacional e a administração regional. Ele não estabelece todos os termos do acordo final. Um conjunto autenticado completo contendo o Acordo Cooperativo executado NCR-8720904, todas as emendas, todos os arranjos com IBM e MCI, e o instrumento operacional posterior Merit-ANS não está disponível através do arquivo público citado. Afirmações sobre cláusulas não publicadas, portanto, excederiam as evidências.

A cadeia institucional mais restrita é bem sustentada. A Merit propôs um backbone T1 de 1,5 megabits por segundo com IBM e MCI em agosto de 1987. A NSF anunciou um acordo cooperativo de cinco anos com a Merit em novembro. Testemunhos contemporâneos no Congresso e o relato institucional da Merit identificam a Merit como a organização responsável perante a NSF pela gestão e operação do projeto do backbone. A IBM forneceu hardware de comutação de pacotes, software e engenharia. A MCI forneceu instalações de transmissão de longa distância. O Estado de Michigan forneceu apoio adicional.

Essas contribuições não criaram um único ator corporativo ou federal chamado “NSFNET”. A NSF era a financiadora e supervisora do programa. A Merit era a detentora do acordo cooperativo e gestora do backbone. Os engenheiros da IBM contribuíram com sistemas e trabalho de roteamento. A MCI forneceu circuitos e expertise em comunicações. As universidades e redes regionais permaneceram administradas separadamente. A função IANA e o Internet Registry lidavam com identificadores através de outra cadeia institucional.

A distinção entre um acordo cooperativo e compras comuns também é relevante, embora não decida a questão central do artigo. A NSF exerceu envolvimento contínuo em um programa de infraestrutura cujo projeto e operação dependiam de contribuições de várias organizações. Ela podia supervisionar a concessão, revisar o desempenho, aprovar mudanças e decidir se estenderia o apoio. Ela não adquiriu a propriedade de todos os endereços cujo tráfego posteriormente atravessou o serviço.

O novo backbone T1 tornou-se operacional em treze locais no verão de 1988. O relato institucional final da Merit situa a operação em julho e relata 152 milhões de pacotes por mês a 1,5 megabits por segundo. O testemunho da NSF ao Congresso em 1992 usou uma linha de base diferente, descrevendo o novo backbone como transportando tráfego a partir de agosto de 1988 e apresentando crescimento de aproximadamente 200 milhões de pacotes por mês para 11 bilhões no início de 1992.

Esses números não são necessariamente contraditórios. Eles podem refletir datas de relatório diferentes, observações parciais versus mensais completas, ou arredondamentos posteriores. Os documentos públicos não definem a diferença com precisão suficiente para fundi-los em uma única contagem exata do “primeiro mês”. A conclusão defensável é que o serviço T1 entrou em operação em julho-agosto de 1988, com a Merit relatando 152 milhões de pacotes mensais no ponto de julho e a NSF posteriormente usando uma linha de base de aproximadamente 200 milhões de pacotes no início do serviço.

Essa qualificação não diminui a conquista. O sistema de treze nós substituiu um arranjo sobrecarregado de 56 quilobits por um backbone de produção, apoiou a interconexão regional e deu às universidades acesso a recursos remotos de computação e informação sem exigir que cada campus construísse uma rede nacional.

O sistema T1 reuniu várias comportas

A estrutura operacional de 1988 a 1990 pode ser separada em decisões distintas:

A estrutura financeira aumentou a importância prática do alinhamento entre essas comportas. ARFC 1192, um relatório de um workshop de comercialização de 1990, estimou os custos anuais do backbone em aproximadamente US$ 10 milhões, dos quais a NSF pagou menos de US$ 3 milhões. Atribuiu grande parte do restante ao Estado de Michigan e aos serviços doados pela IBM e MCI. O mesmo relatório estimou que a NSF forneceu cerca de 40% dos custos das redes de nível médio que apoiava, observando uma faixa de zero a 75%.

Essas eram estimativas de workshop, não um direito uniforme ou tabela de preços. No entanto, mostram por que uma rota apoiada pela NSF poderia ser mais valiosa do que apenas um endereço. Fundos federais, apoio estadual, contribuições corporativas, taxas regionais, gastos universitários e engenharia em espécie se combinaram para criar um serviço nacional cujo custo total não era cobrado de cada campus conectado como trânsito comercial de longa distância.

O benefício era coletivo. Uma universidade não precisava negociar um circuito dedicado para cada centro de supercomputação ou para cada outra rede regional. Protocolos comuns e um backbone operado permitiam que uma única conexão alcançasse um conjunto crescente de destinos. Os efeitos de rede resultantes aumentaram o valor de cada rota utilizável.

A dependência era o outro lado desse benefício. Uma vez que pesquisadores, bibliotecas, administradores e serviços de computação do campus dependiam da conectividade remota, atrasos em um link regional ou na entrada de política do backbone impunham um custo real aos usuários. No entanto, a localização da solução dependia da falha. Uma entrada de registro equivocada cabia aos administradores de identificadores. Uma linha alugada com falha cabia ao campus, à rede regional ou à operadora. Um anúncio não autorizado cabia às operações de roteamento.

A rejeição de um par remoto não poderia ser corrigida pela NSF simplesmente declarando o destino como legítimo.

O acesso regional não era uma regra federal uniforme

A arquitetura de três níveis colocava as redes regionais entre os campi e o backbone nacional, mas essas redes não eram ramificações administrativas idênticas da NSF ou da Merit.

O relato operacional da OARnet de 1991 descreveu uma rede que atendia ao ensino superior de Ohio e permitia conexões para corporações engajadas em pesquisa, desenvolvimento de produtos ou instrução. Usava TCP/IP e DECnet, conectava 29 locais diretamente e operava uma topologia na qual 13 roteadores funcionavam como roteadores de fronteira de sistema autônomo.

Seu principal relacionamento de roteamento externo no relato da RFC 1246 passava por uma rede desmilitarizada em Columbus conectada à CICNet. Partes da OARnet geravam uma rota padrão quando a sessão exterior relevante estava disponível, em vez de transportar todas as informações EGP externas pelo interior. A OARnet também tinha gateways para outros sistemas, incluindo a NASA Science Internet.

Esse arranjo dava à OARnet escolhas operacionais. Seus engenheiros determinavam os custos de roteamento interno, caminhos de backup, design de pontos de presença e como a alcançabilidade externa se tornava um padrão dentro do sistema regional. Os operadores de backbone da Merit não escolhiam o custo do caminho da OARnet da Kent State para Akron, e o DDN-NIC não configurava os roteadores OSPF da OARnet.

Os links registrados da Kent State mostram o que a topologia regional mudou. O circuito DS1 oferecia um caminho preferencial mais rápido. A conexão de 56 quilobits e o caminho mais longo através de Cleveland forneciam uma alternativa menos atraente durante uma reinicialização. À medida que os links se recuperavam, o OSPF recalculava as rotas. O evento demonstra convergência e resiliência regional; não mostra o prefixo externo da Kent mudando ou prova que todo o tráfego externo usava NSFNET.

Outras redes regionais usavam arranjos organizacionais e técnicos diferentes. O estudoThe Strategic Future of the Mid-Level Networksdescreveu a BARRNet como distribuindo a propriedade dos equipamentos e a responsabilidade operacional entre as instituições participantes. A NYSERNet dependia fortemente de acordos com empresas de telecomunicações. A PREPnet terceirizou funções extensas para uma operadora. A NorthwestNet usava a Boeing Computer Services, enquanto a NEARnet usava a BBN.

A presença da BARRNet em 1991 incluía cerca de 80 locais universitários, governamentais e comerciais com velocidades de acesso variando de 9,6 kilobits por segundo a T1. Ela se conectava em Stanford tanto a instalações T1 quanto T3 do NSFNET e também tinha links para ESnet, redes de defesa e sistemas universitários da Califórnia. Essa não era a mesma topologia, mercado ou ambiente institucional da OARnet.

Consequentemente, o “acesso ao NSFNET” não poderia ser reduzido a uma única solicitação nacional de campus. Uma universidade normalmente precisava de uma organização regional disposta e capaz de conectá-la, um circuito alugado adequado, equipamentos, equipe técnica e um arranjo de rota. A organização regional poderia receber apoio federal, mas também poderia depender de dotações estaduais, taxas institucionais, membros corporativos, contratos com operadoras ou contribuições em espécie.

Um campus atrasado não estava necessariamente proibido de acessar a Internet por decreto federal. Em vez disso, poderia simplesmente não ter um circuito de última milha acessível, estar fora da classe de associação da rede regional ou não conseguir atender a um requisito de equipamento. A existência de outra rota dependia da geografia, presença de provedores, elegibilidade e interconexão.

Esse limite probatório é importante para a Kent State. Os materiais remanescentes não fornecem o acordo de conexão original da Kent com a OARnet, taxa, data de instalação ou cotações de serviços alternativos. Portanto, não podem sustentar uma alegação de que um provedor substituto específico estava disponível para a Kent em 1988 a um preço conhecido. As conexões da OARnet com a CICNet e NASA não estabelecem que a Kent poderia ter comprado esses caminhos de forma independente ou usado-os se sua conexão à OARnet tivesse sido recusada.

A admissão regional era uma comporta real. Não era uma comporta padronizada nacionalmente, e o registro disponível da Kent não preserva uma recusa, recurso ou alternativa com custo.

Um número registrado não era um direito a serviço

O sistema de identificadores carregava vestígios de políticas de interconexão anteriores. A RFC 1166 distinguia as redes participantes da Internet de pesquisa e operacional das redes IP independentes. Redes independentes eram marcadas com um asterisco e exigiam permissão separada para interconectar. O131.123da Kent State e o131.187da OARnet apareciam como redes de pesquisa sem essa marca.

Isso era uma informação administrativa significativa em julho de 1990, mas seu significado deve permanecer delimitado. A entrada não provava que uma rota estava ativa a cada momento. Não especificava qual rede regional era responsável por cada pacote. Não ordenava que uma operadora fornecesse um circuito ou obrigava uma rede estrangeira a aceitar o destino.

ARFC 1174, publicada em agosto de 1990, explica tanto a divisão institucional quanto a crescente inadequação do “status de conectado”. Ela identificou a função IANA como sendo desempenhada pelo Information Sciences Institute da USC. Identificou a SRI International como o Internet Registry responsável por coletar e registrar informações sobre identificadores de rede e de sistema autônomo atribuídos.

O documento descreveu um histórico no qual os números haviam sido atribuídos inicialmente a organizações que participavam da pesquisa na Internet e, posteriormente, a redes governamentais ou patrocinadas pelo governo autorizadas a interconectar. À medida que o TCP/IP se espalhou para redes privadas, o registro atribuiu números globalmente únicos mesmo quando uma organização não pretendia se conectar à Internet patrocinada pelo governo federal. O “status de conectado” tornou-se a distinção tentada entre possuir um identificador e ter sanção governamental para interconectar.

Em 1990, esse campo binário não descrevia mais a rede com precisão. Os sistemas regionais atendiam a membros diversos. As redes comerciais estavam surgindo. As redes internacionais não podiam ser sensatamente reduzidas à aprovação de um patrocinador dos Estados Unidos. Uma rede poderia transportar parte do tráfego por um caminho apoiado pela NSF e outro tráfego por um par ou backbone diferente.

A RFC 1174, portanto, recomendou que o Internet Registry removesse o status de conectado dos formulários e bancos de dados, coletasse informações de acesso e políticas de trânsito em vez disso, e permitisse que qualquer rede registrada entrasse no Sistema de Nomes de Domínio sem considerar o status de conectado. Afirmou que o registro deveria administrar o espaço de numeração enquanto os administradores de rede aplicavam a política de tráfego.

O documento era uma recomendação do IAB, não um padrão técnico, e não prova que todos os formulários, bancos de dados e roteadores mudaram imediatamente. Sua cronologia não deve ser comprimida em uma reforma instantânea. O que ele estabelece claramente é que os formuladores de políticas reconheceram o registro e a interconexão como funções diferentes e buscaram remover a aplicação de acesso da camada de nomes e registro de identificadores.

Essa não era uma distinção meramente teórica. Uma organização poderia precisar de um número único para uma rede TCP/IP privada sem ter trânsito externo. Inversamente, um campus poderia ter acesso físico a uma rede regional e ainda precisar de espaço de endereçamento legítimo e não conflitante antes de poder ser representado com segurança para a Internet mais ampla.

A política de roteamento criou a junção operacional

O registro tornava um identificador administrativamente legítimo. A política de roteamento determinava se o backbone acreditava que uma determinada rede era alcançável através de um determinado sistema regional.

NaRFC 1092, Jacob Rekhter descreveu uma limitação do Exterior Gateway Protocol usado entre o novo backbone e as redes regionais. O EGP sozinho não podia impedir que uma rede regional reivindicasse um destino que pertencia a outra. Também não podia expressar uma hierarquia confiável de caminhos preferenciais e de backup em um ambiente em malha com links “backdoor” adicionais.

A solução proposta era tanto institucional quanto técnica. Uma rede selecionaria um ou mais representantes regionais por meio de acordos bilaterais. As informações sobre os representantes primário e secundário escolhidos seriam fornecidas ao Centro de Operações de Rede do NSFNET e inseridas no Banco de Dados de Políticas de Roteamento. O backbone ignoraria um anúncio de uma rede regional que não estivesse autorizada a representar aquele destino.

ARFC 1093descreveu a arquitetura correspondente. Esperava-se que os backbones regionais usassem números de sistema autônomo únicos. Os nós do backbone verificavam tanto os números de rede quanto o número do sistema autônomo de origem. Os caminhos preferenciais eram derivados de informações fornecidas pelos backbones regionais e campi conectados. As redes regionais podiam gerar padrões internos, enquanto o backbone mantinha alcançabilidade explícita para redes conectadas e pares.

Portanto, a rota dependia da concordância de registros de diferentes autoridades:

1. Um número de rede precisava ser único e devidamente registrado.
2. Um campus precisava de um relacionamento de conexão com uma rede regional.
3. O campus e a rede regional precisavam de uma representação e preferência de caminho acordadas.
4. Os dados de política do backbone precisavam autorizar o sistema autônomo regional a anunciar aquele destino.
5. O circuito e as sessões de roteador relevantes precisavam estar operacionais.
6. Outros operadores precisavam aceitar e propagar a rota se o alcance além do NSFNET fosse necessário.

Essas condições eram cumulativas, mas não constitucionalmente unificadas. O registro poderia corrigir a identidade associada a um número, mas não poderia reparar um circuito DS1 com falha. Um operador regional poderia restaurar um link, mas não poderia tornar um número duplicado globalmente único. O Centro de Operações de Rede da Merit poderia rejeitar um anúncio não autorizado, mas não poderia forçar um par independente a aceitar uma rota.

É aqui que o acesso ao backbone moldou o poder dos endereços. O banco de dados de políticas do NSFNET não era o registro de endereços, no entanto, a inclusão em um sistema de roteamento amplamente utilizado tornava um número registrado mais útil. À medida que a rede alcançável crescia, a representação correta através do backbone adquiria maior valor prático.

O mesmo sistema restringia reivindicações unilaterais de rota. Uma rede regional não poderia simplesmente anunciar o número de rede de outra organização com uma métrica preferencial e esperar que o backbone acreditasse. Os registros de políticas e a validação de sistema autônomo transformavam um relacionamento administrativo em uma permissão de roteamento.

A autoridade resultante era mais restrita do que a propriedade de endereços e mais ampla do que o encaminhamento mecânico de pacotes. Os operadores de backbone controlavam o que seu próprio serviço aceitava. Como esse serviço tinha um alcance excepcional, suas decisões operacionais podiam afetar muitos usuários. A dimensão da consequência vinha da topologia e da adoção, não de um mandato global.

O que os números de crescimento contam

A expansão do NSFNET é uma evidência material de benefício público, mas suas estatísticas descrevem populações diferentes.

O número da Merit de julho de 1988 de 152 milhões de pacotes mensais e a linha de base posterior da NSF de aproximadamente 200 milhões no início do serviço dizem respeito ao tráfego. Eles não contam endereços ou instituições. O testemunho da NSF relatou aproximadamente 11 bilhões de pacotes por mês em março de 1992, uma medida do uso rapidamente crescente, em vez de um censo de organizações conectadas.

O próprio backbone cresceu de 13 locais T1 para uma arquitetura T3 de 16 locais. Um local de backbone não era um campus, rede regional ou usuário individual. Era um nó ou ponto de conexão dentro do serviço nacional.

Declarações do Congresso em 1992 referiam-se a aproximadamente 5.000 redes, incluindo cerca de 1.500 fora dos Estados Unidos, conectadas ao sistema mais amplo. Essas estimativas foram apresentadas em uma audiência política e institucional e não devem ser tratadas como um instantâneo exato da tabela de roteamento.

Uma atualização de roteamento do NSFNET datada de janeiro de 1993 relatou 8.997 redes configuradas no banco de dados de políticas T3. Essa contagem representava entradas de rede configuradas e seus caminhos de sistema autônomo preferenciais. Não era uma contagem de organizações únicas. Uma instituição poderia possuir várias redes classful, e uma entrada configurada poderia ter representações primária e de backup.

Os totais de alocação naRFC 1366mediam algo diferente novamente. Em 1992, o documento relatou 49 números Classe A alocados, 7.354 números Classe B e 44.014 números Classe C. Essas eram unidades de alocação no sistema de endereçamento classful, não clientes do NSFNET. Alguns eram usados por redes privadas ou não-NSF, e uma Classe A representava uma capacidade de endereçamento muito maior do que uma Classe C.

A visualização de tráfego posterior preservada pelaCAIDArelata 18,5 trilhões de bytes de entrada durante dezembro de 1994. Para essa visualização, 24.435 redes clientes domésticas foram agregadas em 12.177 conexões de tráfego virtuais de acordo com a cidade e o nó do backbone. Novamente, uma rede cliente, uma linha virtual em uma visualização e uma instituição não eram equivalentes.

Usados com cuidado, os números mostram várias formas de expansão: mais tráfego, mais rotas configuradas, mais alocações de endereços, mais redes clientes e maior alcance geográfico. Eles não provam que o financiamento do backbone sozinho causou todas as mudanças. A queda nos custos de equipamentos, a disseminação do software TCP/IP, o investimento regional, os serviços comerciais, a demanda dos campi, as redes internacionais e as novas aplicações contribuíram.

A alegação causal pode, portanto, permanecer modesta, mas importante. O investimento da NSF e o serviço liderado pela Merit forneceram um ambiente de rota compartilhado de alta capacidade que permitiu que grande parte desse crescimento se tornasse mutuamente alcançável. Ele não produziu todos os endereços alocados, e a correlação temporal entre o crescimento de endereços e o crescimento do backbone não estabelece que a Merit controlava a atribuição.

O T3 mudou a capacidade e as operações, não a autoridade dos identificadores

Em 1990, o sistema T1 estava novamente sob pressão. A atualização para T3 aumentou a transmissão nominal do backbone de 1,5 para 45 megabits por segundo e expandiu a arquitetura para 16 locais. Também mudou a organização operacional.

A Merit, a IBM e a MCI formaram a Advanced Network & Services, Inc., ou ANS, em setembro de 1990. O registro do Congresso de 1992 descreve a Merit como permanecendo responsável sob seu acordo cooperativo, enquanto subcontratava o gerenciamento e operação substanciais do backbone atualizado para a nova organização sem fins lucrativos. A história institucional final da Merit apresenta igualmente a ANS como o veículo operacional para grande parte do trabalho T3.

Os materiais públicos disponíveis estabelecem o contorno organizacional, mas não expõem todas as cláusulas operacionais do acordo Merit-ANS de 17 de setembro de 1990. Portanto, é mais seguro descrever a divisão observável do que atribuir direitos não documentados. A NSF permaneceu como financiadora e supervisora do programa. A Merit permaneceu responsável na cadeia do acordo cooperativo. A ANS assumiu extensa engenharia e operações T3. A IBM e a MCI continuaram a fornecer tecnologia, instalações, pessoal e suporte importantes.

A mudança para T3 não foi instantânea. A instalação de nós, o transporte inicial de tráfego, a migração de conexões regionais e a desativação da rede T1 foram eventos diferentes. O relato da Merit situa a conclusão do sistema T3 de 16 locais em 1991. As instalações T1 e T3 então coexistiram enquanto as conexões e rotas se moviam.

Um aviso operacional da Merit arquivado no registro NANOG de novembro de 1992 programou o desligamento do backbone T1 para quarta-feira, 2 de dezembro de 1992. Esse aviso datado fornece a distinção que faltava entre a chegada anterior do serviço de produção T3 e a posterior desativação do serviço T1 remanescente. O backbone T3 não se tornou totalmente exclusivo apenas porque os primeiros links T3 transportaram pacotes.

O sistema de rotas também se expandiu. A atualização de janeiro de 1993 relatando 8.997 redes T3 configuradas ilustra a quantidade de dados de política que as operações do backbone tinham que manter. Cada entrada representava uma rede e os caminhos de sistema autônomo esperados, não uma concessão de um endereço. O banco de dados operacionalizava relacionamentos já estabelecidos em outro lugar.

Esta fase, portanto, intensificou a comporta prática sem alterar sua identidade legal. Uma entrada de política T3 ausente ou incorreta poderia afetar a alcançabilidade em um serviço muito maior. Isso não tornou a ANS ou a Merit a IANA, e não transferiu a propriedade dos números registrados para a NSF.

A comercialização introduziu alternativas de forma desigual

Os serviços TCP/IP comerciais estavam surgindo antes mesmo da conclusão da transição para o T3. A AlterNet e a Performance Systems International comercializavam conectividade. As redes regionais atendiam algumas organizações de pesquisa industrial e buscavam receita além do apoio federal. O Commercial Internet Exchange oferecia interconexão fora das condições de tráfego do backbone apoiado pela NSF.

A ANS criou uma subsidiária com fins lucrativos, a ANS CO+RE, em 1991 para fornecer serviço comercial. O arranjo tornou-se controverso porque a ANS também operava a infraestrutura usada para o serviço apoiado pelo governo federal. Os participantes da audiência da Câmara de 1992 contestaram a alocação de custos, consulta, interconexão e vantagem competitiva.

O testemunho não sustenta a conversão de cada alegação em uma conclusão. Os críticos argumentaram que a estrutura favorecia um caminho e confundia os limites do apoio público. A Merit e a NSF argumentaram que o arranjo incentivava o investimento privado, protegendo ao mesmo tempo o serviço de pesquisa e educação. A audiência estabelece a presença de uma séria disputa institucional, não uma conspiração comprovada ou reivindicação de propriedade.

Para o valor do endereço, a comercialização era importante porque tornava cada vez mais possível um pareamento alternativo: um número registrado válido poderia ser roteado através de um provedor comercial em vez do NSFNET. Um cliente poderia adquirir serviço, providenciar um circuito e pedir ao provedor que representasse sua rede.

Essa possibilidade permanecia condicional. Um provedor precisava de presença geográfica ou um ponto de presença alcançável. O cliente precisava de um circuito de última milha, equipamento, equipe, um contrato de serviço e aceitação de roteamento. A existência de um backbone comercial nos Estados Unidos não provava que todas as universidades pudessem comprar serviço comparável localmente ou de forma acessível.

Os materiais remanescentes da Kent State não fornecem uma cotação contemporânea da AlterNet, PSI ou outra comercial cobrindo a localização da Kent, elegibilidade, instalação e custo total. Eles não mostram que a BITNET, a NASA Science Internet ou uma rede regional vizinha estivesse disponível como um substituto geral de trânsito IP. Portanto, seria especulativo afirmar que um serviço alternativo específico era viável para a Kent em 1988 ou atribuir-lhe um preço comparativo.

O que o registro mais amplo mostra é uma mudança no mercado ao longo do tempo. No início dos anos 1990, as organizações tinham mais upstreams possíveis e mais locais para trocar tráfego. As múltiplas conexões da BARRNet demonstram que os sistemas regionais podiam usar o NSFNET juntamente com caminhos de agências e locais. A RFC 1092 já havia contemplado representações primárias, secundárias e “backdoor”. O crescimento comercial expandiu essas possibilidades técnicas em opções de serviço, embora de forma desigual.

A autoridade prática do NSFNET, consequentemente, enfraqueceu antes que o serviço terminasse formalmente. Permaneceu altamente importante, mas uma rede registrada era menos dependente de um único caminho nacional subsidiado uma vez que provedores comerciais e relacionamentos de troca podiam entregar destinos comparáveis.

O registro seguiu um cronograma separado

A administração de identificadores passou por sua própria mudança institucional enquanto o backbone T3 estava em operação.

A solicitação de março de 1992 da NSF,NSF 92-24, dividiu os serviços de informação de rede em funções de registro, diretório e banco de dados, e informações. A partir de 1º de janeiro de 1993, oAcordo Cooperativo NCR-9218742 da NSF com a Network Solutionsestabeleceu serviços de registro não militares sob o que se tornou a estrutura InterNIC.

A declaração de trabalho cobria o registro de domínios da Internet, atribuição de números de rede e atribuição de números de sistema autônomo em coordenação com a IANA e os documentos de política relevantes. Não atribuiu à Network Solutions a responsabilidade de operar roteadores NSFNET ou selecionar provedores de trânsito comercial.

ARFC 1400documentou a transição operacional do DDN-NIC para a InterNIC. Estabeleceu 1º de abril de 1993 como o ponto efetivo para que as solicitações de registro não-DDN fossem transferidas para o novo serviço. O registro militar permaneceu em seu caminho separado.

Essa sequência é importante porque ocorreu antes do desligamento do antigo backbone. Em 1993, uma universidade poderia direcionar uma solicitação de número ou sistema autônomo para a InterNIC enquanto sua rede regional continuava a usar o serviço T3 operado pela ANS. O banco de dados de políticas de roteamento e o banco de dados de registro eram administrativamente distintos, mesmo quando compartilhavam identificadores e informações de contato.

O registro preciso ainda afetava o roteamento. Os operadores precisavam saber qual organização detinha uma rede e quem contatar quando um anúncio era contestado. Mas o registro do registro não ativava uma interface de backbone. Da mesma forma, uma rota válida no NSFNET não transferia a função de registro subjacente para o operador do backbone.

A transição de 1993–1995 redistribuiu a autoridade de acesso

A solicitação da NSF de maio de 1993,NSF 93-52, propôs quatro áreas de projeto distintas: Pontos de Acesso à Rede (Network Access Points), um Árbitro de Roteamento (Routing Arbiter), apoio a redes regionais e um Serviço de Rede de Backbone de Velocidade Muito Alta (vBNS) para pesquisa avançada.

A estrutura evitou deliberadamente substituir o antigo serviço NSFNET por um único backbone comercial. Os provedores de serviços de rede comerciais transportariam o tráfego geral e se interconectariam nos Pontos de Acesso à Rede. As redes regionais adquiririam serviço upstream desses provedores, com assistência transitória da NSF. A coordenação de roteamento continuaria através de um projeto de Árbitro de Roteamento. O vBNS atenderia aos requisitos de pesquisa avançada, em vez de atuar como o único sucessor universal.

Adecisão do GAO referente ao desafio da Sprint à concessão do vBNSconfirma que a NSF 93-52 contemplava vários acordos cooperativos e que a MCI foi selecionada para o projeto vBNS em fevereiro de 1994. A decisão também reforça a necessidade de distinguir esse serviço de pesquisa do trânsito comercial que substituiu o antigo backbone.

A cadeia de acesso mudou de acordo:

Um relatório de transição da Merit datado de 30 de setembro de 1994 mostra por que o registro sozinho não poderia concluir a migração. Ele acompanhou cinco dependências operacionais: Pontos de Acesso à Rede funcionando, conexão do NSFNET a esses pontos, novas conexões de provedores, serviços do Árbitro de Roteamento e a conexão de cada rede regional ao seu provedor escolhido. Uma falha em qualquer uma dessas áreas poderia deixar uma instituição com identificadores válidos, mas com alcançabilidade incompleta.

A transição final foi encenada em vez de cerimonial. O aviso da Merit de 14 de abril de 1995 relatou que apenas sete organizações haviam cortado completamente seu antigo relacionamento com o NSFNET. Muitas estavam usando novos provedores, mantendo o NSFNET como backup.

As sessões restantes foram programadas para um desligamento de teste em 21 de abril para revelar redes inalcançáveis. A restauração temporária permanecia possível enquanto os problemas fossem corrigidos. O aviso então pedia o encerramento permanente das sessões restantes em 28 de abril, seguido pelo término do serviço de backbone em 30 de abril.

Um comunicado da NSF datado de 15 de maio confirmou que o Serviço de Backbone NSFNET havia sido desativado à meia-noite de 30 de abril de 1995.

O desligamento ilustra fortemente a separação entre registro de endereços e serviço de backbone, mas não prova que todos os prefixos individuais migraram sem interrupção. Demonstrar a continuidade para o131.123da Kent State, por exemplo, exigiria observações de roteamento antes e depois correspondentes, além da entrada de registro. Os avisos de transição disponíveis mostram um sistema projetado para preservar a alcançabilidade enquanto os serviços mudavam; eles não fornecem um rastro específico de prefixo para a Kent.

O que se pode afirmar com confiança é que o término do antigo backbone não aboliu o sistema de identificadores. As funções da InterNIC e da IANA continuaram. As redes regionais compraram trânsito substituto. Os provedores trocaram rotas em novos pontos de interconexão. O valor operacional dos endereços persistiu apenas porque esses novos atores transportaram e aceitaram as rotas.

Testando os dois eixos sem inventar alternativas

A distinção pode ser testada através de vários cenários delimitados.

Um identificador válido sem trânsito externo utilizável

Suponha que uma universidade possuísse um número de rede registrado globalmente único, mas não tivesse uma conexão regional funcional ou um upstream aceitável.

Ela poderia usar o número internamente sem colidir com outra rede registrada. Poderia operar serviços TCP/IP locais e trocar tráfego por qualquer caminho bilateral que concordasse em transportá-lo. O registro permaneceria significativo.

O que lhe faltaria seria o alcance externo geral. A universidade precisaria de uma conexão regional, um provedor comercial, um caminho de agência elegível ou um par dedicado. Cada opção exigia seu próprio acordo e instalações físicas. O registro não obrigaria nenhum deles a fornecer serviço.

Para a Kent State, o registro histórico não estabelece qual substituto, se houvesse, atendia a todas essas condições em 1988. Os vários gateways posteriores da OARnet provam a topologia, não um direito independente a serviço para a Kent. A existência da BITNET por si só não forneceria trânsito IP geral. Provedores comerciais tornaram-se mais plausíveis após 1990, mas nenhum registro completo de preço ou disponibilidade específico para a Kent foi recuperado.

A conclusão justificada é, portanto, limitada: um endereço registrado poderia sobreviver sem o NSFNET, mas sua utilidade externa dependia da obtenção de outra operadora e rota aceita. Se isso era viável ou acessível para a Kent em uma data específica permanece desconhecido.

Acesso físico sem um identificador público válido

Inverta as condições. Uma rede regional poderia ter um circuito disponível e estar disposta a conectar um campus, mas o campus poderia não ter um número de rede válido para uso geral na Internet.

O circuito poderia transportar tráfego sob um plano de endereçamento local ou outro arranjo tecnicamente coordenado. As possibilidades genéricas de engenharia incluíam o uso de espaço de endereçamento controlado por provedor válido ou o adiamento do anúncio público até que o registro fosse resolvido. Os materiais remanescentes da OARnet não estabelecem qual solução ela teria oferecido à Kent, portanto, nenhuma deve ser apresentada como política da OARnet.

O que o campus não poderia fazer com segurança era selecionar o número público de outra organização e esperar que o roteamento global funcionasse. A numeração duplicada poderia direcionar mal os pacotes ou fazer com que os filtros rejeitassem o anúncio. O maquinário de política do NSFNET foi projetado especificamente para comparar as informações de rede e sistema autônomo com a representação esperada.

A solução começaria do lado do identificador: obter ou corrigir uma atribuição legítima e garantir que os contatos responsáveis e a representação fossem precisos. Abrir uma porta de backbone não poderia tornar único um identificador duplicado.

Uma rota legítima que um par se recusou a transportar

Um destino poderia estar devidamente registrado, conectado a uma rede regional e aceito pelo NSFNET, permanecendo inalcançável através de outro provedor.

Cada par ou backbone controlava sua própria política de roteamento. A escala do NSFNET tornava suas informações influentes, mas não podia ordenar que todas as agências, operadores comerciais ou internacionais propagassem uma rede. Um endereço roteado era, portanto, uma evidência de aceitação ao longo de algum caminho, não uma prova de aprovação universal.

A solução apropriada era o diagnóstico de rota e a coordenação entre operadores. O registro poderia ajudar a identificar contatos, mas não podia obrigar o transporte. A Merit poderia corrigir seu próprio banco de dados de políticas, mas não podia configurar todas as redes remotas.

Conectividade elegível com tráfego que exigia outro caminho

Um campus também poderia possuir um identificador válido e uma rota funcional enquanto algum tráfego era inelegível para o backbone com apoio federal. Essa era uma questão de política de tráfego, não o cancelamento do endereço ou a negação da associação física.

A instituição poderia precisar rotear o tráfego relevante através de outro provedor ou demonstrar que ele atendia ao propósito permitido de pesquisa e educação. O ponto importante aqui é institucional: a conformidade com o uso aceitável era outra condição no caminho, não a autoridade que criou o número.

Esses cenários evitam a falsa simetria. Suas consequências não eram idênticas e as soluções disponíveis diferiam. A falha de registro ameaçava a unicidade e a representação estável. A falha regional ameaçava a conexão local. A falha do backbone ameaçava o transporte inter-regional. A rejeição de pares ameaçava o alcance além do provedor imediato. O conflito de política de tráfego afetava quais usos podiam atravessar um determinado caminho apoiado.

Para um usuário do campus, todos podiam produzir o mesmo sintoma: um destino remoto não respondia. A análise de governança precisa reconstruir a camada em que a falha ocorreu.

Onde residiam a autoridade e a consequência

A NSF governava diretamente o programa que financiava. Selecionou e supervisionou a estrutura de acordos cooperativos, apoiou a conectividade regional, revisou o desempenho, aprovou mudanças e, posteriormente, projetou a transição para Pontos de Acesso à Rede, provedores de serviços comerciais, um Árbitro de Roteamento e o vBNS.

A Merit gerenciou e coordenou o backbone sob seu acordo com a NSF. Suas responsabilidades incluíam operações de rede, serviços de informação, ligação regional e os dados de política necessários para manter um sistema roteado crescente coerente.

A IBM e a MCI forneceram contribuições técnicas e de comunicações distintas. Elas não eram autoridades de associação universitária nem registros de números da Internet. Durante a fase T3, a ANS assumiu extenso trabalho de engenharia e operação, enquanto a Merit permaneceu na cadeia do acordo com a NSF.

As redes regionais controlavam a camada voltada para o campus. Elas decidiam a quem poderiam atender, como os circuitos e equipamentos seriam organizados, quais taxas e condições locais se aplicavam e como o roteamento interno funcionava. Suas estruturas eram heterogêneas, e as consequências da geografia ou da escolha limitada de operadoras variavam substancialmente.

A função IANA, o trabalho de Internet Registry do DDN-NIC e, posteriormente, os serviços de registro da InterNIC controlavam identificadores e registros através de uma sequência separada. Esses registros eram importantes porque números duplicados ou atribuídos erroneamente não podiam suportar um roteamento global confiável. As autoridades de identificadores não operavam o circuito DS1 da Kent State ou selecionavam seu caminho upstream.

Os operadores de campus, regionais, de backbone e pares convertiam esses relacionamentos em alcançabilidade. Eles configuravam roteadores, trocavam informações de roteamento, validavam representantes esperados, restauravam sessões com falha e decidiam quais rotas propagar. Seu trabalho determinava se um número registrado era utilizável em um dado momento.

A proposição de que o NSFNET amplificou o poder dos endereços, portanto, é válida apenas em um sentido distribuído. A conectividade financiada pela NSF tornou a Internet mais útil. Quanto mais destinos o backbone e seus pares conectavam, mais valioso se tornava possuir um identificador que fosse corretamente representado por meio desse ambiente.

Esse efeito também aumentou as consequências das decisões de admissão regional e de políticas de roteamento. Um registro no cadastro de números era necessário, mas insuficiente. Um circuito regional sem um identificador legítimo também era insuficiente. Nenhum eixo sozinho produzia alcançabilidade geral.

O investimento público não deve ser tratado como incidental para esse resultado. O NSFNET criou interoperabilidade nacional em uma velocidade e escala que as universidades individuais dificilmente reproduziriam separadamente. Ele compartilhou custos fixos, desenvolveu operações, apoiou o crescimento regional e deu aos pesquisadores acesso a recursos distantes. Seu sucesso é parte da explicação de seu poder: a dependência seguiu a utilidade.

Tampouco a dependência deve ser confundida com um monopólio formal sobre os endereços. Serviços comerciais, redes de agências, pares diretos e backdoors regionais existiram ou surgiram em momentos diferentes. Sua disponibilidade era desigual e sua existência não garantia uma alternativa viável para todas as instituições. Mas demonstram que o valor da rota poderia migrar sem exigir que o identificador fosse recriado.

A transição de 1995 tornou essa separabilidade visível em escala de sistema. O antigo backbone terminou. O registro continuou. As redes regionais mudaram de provedores. As rotas se moveram através de redes comerciais e pontos de troca. A coordenação de roteamento persistiu em novas organizações.

Isso não foi prova de que toda migração foi perfeita. Foi uma evidência de que a identidade da Internet e o transporte da Internet poderiam sobreviver à substituição institucional porque nunca haviam sido a mesma função.

A NSF não era proprietária dos endereços transportados pelo NSFNET. A Merit não decidia toda a admissão global à Internet. A ANS não se tornou a IANA ao operar o serviço T3. O DDN-NIC e a InterNIC não forneciam circuitos de campus. As redes regionais não controlavam todos os pares além de suas fronteiras.

No entanto, suas decisões se alinhavam de forma tão estreita que os usuários podiam experimentá-las como uma única comporta. O significado de governança do NSFNET reside nesse alinhamento. O acesso ao backbone moldou o poder dos endereços não absorvendo a autoridade dos identificadores, mas determinando se um identificador legítimo poderia participar de um dos ambientes de roteamento mais valiosos de sua época.

Fontes

• U.S. House Subcommittee on Science,Management of NSFNET, 12 March 1992
• Merit Network,NSFNET: A Partnership for High-Speed Networking, Final Report 1987–1995
• The Strategic Future of the Mid-Level Networks
• RFC 1092,EGP and Policy Based Routing in the New NSFNET Backbone
• RFC 1093,The NSFNET Routing Architecture
• RFC 1166,Internet Numbers
• RFC 1174,IAB Recommended Policy on Distributing Internet Identifier Assignment and Connected Status
• RFC 1192,Commercialization of the Internet Summary Report
• RFC 1246,Experience with the OSPF Protocol
• RFC 1366,Guidelines for Management of IP Address Space
• RFC 1400,Transition and Modernization of the Internet Registration Service
• Merit,T1 NSFNET Backbone Shutdown Schedule, November 1992 archive
• Merit, NSFNET policy-routing update reporting 8,997 configured T3 networks, January 1993 archive
• NSF 92-24,Network Information Services Manager(s) for NSFNET and the NREN
• NSF and Network Solutions, Cooperative Agreement NCR-9218742, 1 January 1993
• NSF 93-52,Network Access Point Manager, Routing Arbiter, Regional Network Providers, and Very High Speed Backbone Network Services Provider, 6 May 1993
• U.S. GAO,Sprint Communications Company, L.P., B-256586 and B-256586.2, 9 May 1994
• CAIDA Internet Atlas Gallery, NSFNET December 1994 traffic and aggregation data
• Merit,Update on Transition from the NSFNET Backbone Service, 30 September 1994
• Merit,Final Transition Steps, 14 April 1995
• National Science Foundation,NSFNET Backbone Decommissioned, 15 May 1995