Merit Network e o NSFNET: quando o acesso ao backbone determinava o poder dos endereços

Resumo

• O registro de endereços e o acesso à rede eram relacionados, mas distintos. Um número de rede Internet válido garantia unicidade e um rastro administrativo; ele não fornecia circuito, adesão regional, elegibilidade ao NSFNET nem rota aceita pelos outros operadores.
• A NSF financiava e supervisionava o programa backbone, a Merit o gerenciava, a IBM fornecia tecnologias de comutação de pacotes e engenharia, a MCI fornecia as instalações de transmissão, e mais tarde a ANS operava grande parte da infraestrutura T3. As redes regionais, universidades, autoridades de identificadores e operadores pares mantinham decisões diferentes.
• O sistema de roteamento do NSFNET transformava relações institucionais em alcance operacional ao validar números de rede, identificadores de sistema autônomo e a representação regional autorizada. Isso tornava os registros de roteamento tão importantes quanto os registros de registro sem tornar a Merit a alocadora de endereços Internet.
• O investimento público gerou benefícios consideráveis de interoperabilidade: enlaces nacionais mais rápidos, operações compartilhadas, acesso universitário ampliado e um sistema de roteamento que conectava milhares de redes. A dependência desse alcance subsidiado, no entanto, deu às decisões regionais e de backbone consequências que ultrapassavam seus mandatos formais.
• A transição de 1993–1995 demonstrou a separação dos dois eixos. O registro passou para a InterNIC enquanto as redes regionais compravam trânsito comercial, as rotas migravam para vários provedores e pontos de troca, e o antigo serviço backbone NSFNET terminou em 30 de abril de 1995.

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

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

O registro de números Internet de julho de 1990 publicado sob a referênciaRFC 1166listava131.123comoKENT-STATEna categoria pesquisa. Esta entrada estabelece que o número estava registrado em nome da Kent State nessa data. Ela não revela a solicitação original, a data em que o número foi solicitado pela primeira vez, o raciocínio que levou à sua aprovação nem as condições sob as quais a universidade obtinha sua conectividade externa.

Um relato operacional distinto de 1991,RFC 1246, descrevia a posição da Kent State dentro do Ohio Academic Resources Network, ou OARnet. Ele relatava um circuito DS1 entre Kent State e o ponto de presença da OARnet em Akron, bem como uma conexão de 56 kilobits representada por131.187.36.0. Este último número pertencia à infraestrutura da OARnet, e não à rede131.123registrada pela Kent State. O documento também descrevia um caminho de backup indireto passando por Cleveland quando os enlaces preferidos estavam indisponíveis.

Trata-se de duas observações autênticas: um instantâneo do registro e um instantâneo operacional posterior da rede regional. Elas não provam as condições iniciais de adesão da Kent State, sua primeira declaração de rota externa bem-sucedida, nem o caminho exato percorrido por um pacote em um dado dia. A reinicialização da OARnet descrita na RFC 1246 dizia respeito à convergência das rotas para os endereços de infraestrutura da OARnet. Não deve ser interpretada erroneamente como uma captura de ponta a ponta de uma rota para131.123.

O exemplo limitado expõe, no entanto, o mecanismo de governança. A Kent State precisava de um identificador que não entrasse em conflito com outra rede. Precisava de uma vinculação à OARnet. A OARnet precisava de conexões externas funcionais e de autorização para representar as redes que abrigava. Os roteadores de backbone e pares precisavam então aceitar as informações de alcançabilidade correspondentes. Uma falha em qualquer uma dessas etapas poderia tornar um destino inalcançável, mesmo que os outros registros permanecessem intactos.

A distinção importa porque o resultado podia parecer unitário do campus. O usuário via apenas se um host remoto estava ou não acessível. Por trás desse resultado estavam decisões de um registro, de uma universidade, de uma rede regional, de operadores de backbone, de provedores de circuitos e de pares distantes. Seus poderes interagiam, mas não eram intercambiáveis.

O que a NSF encomendou – e o que os arquivos públicos comprovam

O primeiro instrumento da cadeia backbone não era uma política de alocação de endereços. Era a solicitação de propostas lançada em 1987 pela National Science Foundation para a gestão e operação de um backbone NSFNET ampliado.

O relato 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 dos Representantes em 1992,Management of NSFNET, reproduz passagens importantes da solicitação. Ele descreve o sistema proposto como uma hierarquia de três níveis: um backbone transcontinental, redes de segundo nível administradas de forma autônoma e redes de campus conectadas abaixo. O texto reproduzido também convidava os proponentes a sugerir arquiteturas ou métodos alternativos que pudessem ser mais apropriados, econômicos ou eficazes.

Essa linguagem estabelece a separação prevista entre a gestão do backbone nacional e a administração regional. Ela não estabelece cada cláusula do acordo final. Um conjunto completo e autenticado contendo o acordo de cooperação executado NCR-8720904, todas as suas emendas, cada arranjo com a IBM e a MCI, e o instrumento de operação subsequente entre a Merit e a ANS não está disponível nos arquivos públicos citados. Qualquer afirmação sobre cláusulas não publicadas excederia as evidências.

O encadeamento institucional mais restrito é bem fundamentado. A Merit propôs um backbone T1 de 1,5 megabit por segundo com a IBM e a MCI em agosto de 1987. A NSF anunciou um acordo de cooperação de cinco anos com a Merit em novembro. Depoimentos contemporâneos ao 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 de backbone. A IBM forneceu o hardware, o software e a engenharia de comutação de pacotes. A MCI forneceu as instalações de transmissão de longa distância. O Estado de Michigan forneceu apoio adicional.

Essas contribuições não criaram um ator único, corporativo ou federal, chamado de «NSFNET». A NSF era a financiadora e supervisora do programa. A Merit era a detentora do acordo de cooperação e a gestora do backbone. Os engenheiros da IBM contribuíam com sistemas e roteamento. A MCI fornecia os circuitos e a expertise em comunicações. As universidades e redes regionais permaneciam administradas separadamente. A função IANA e o registro Internet gerenciam os identificadores por outra cadeia institucional.

A distinção entre um acordo de cooperação e uma simples compra também é pertinente, embora não resolva a questão central do artigo. A NSF exercia um envolvimento contínuo em um programa de infraestrutura cujo projeto e operação dependiam das contribuições de várias organizações. Ela podia supervisionar a alocação, examinar o desempenho, aprovar modificações e decidir se estendia ou não o apoio. Ela não adquiria a propriedade de todos os endereços cujo tráfego mais tarde transitava pelo 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 megabit por segundo. O depoimento da NSF ao Congresso em 1992 usava uma linha de base diferente, descrevendo o novo backbone como transportando tráfego a partir de agosto de 1988 e apresentando um crescimento de cerca de 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 diferentes datas de relatório, observações mensais parciais ou 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 em julho e a NSF usando posteriormente uma base de cerca de 200 milhões de pacotes no início do serviço.

Essa ressalva não diminui o sucesso. O sistema de treze nós substituiu um dispositivo de 56 kilobits saturado por um backbone de produção, apoiou a interconexão regional e deu às universidades acesso a recursos computacionais e informacionais remotos sem exigir que cada campus construísse uma rede nacional.

O sistema T1 combinava várias barreiras

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

A estrutura financeira aumentava a importância prática do alinhamento entre essas barreiras.RFC 1192, um relatório de um workshop de comercialização de 1990, estimava os custos anuais do backbone em cerca de 10 milhões de dólares, dos quais a NSF pagava menos de 3 milhões. Ele atribuía grande parte do saldo ao Estado de Michigan e aos serviços fornecidos pela IBM e pela MCI. O mesmo relatório estimava que a NSF financiava cerca de 40% dos custos das redes de nível intermediário que apoiava, embora sinalizasse uma faixa de zero a 75%.

Tratava-se de estimativas de workshop, não de uma taxa uniforme ou de uma grade tarifária. Elas mostram, no entanto, por que uma rota apoiada pela NSF podia ter mais valor do que um simples endereço. Os fundos federais, o apoio estadual, as contribuições empresariais, as taxas regionais, as despesas universitárias e a engenharia em espécie se combinavam para criar um serviço nacional cujo custo total não era cobrado de cada campus como um trânsito comercial de longa distância.

A vantagem era coletiva. Uma universidade não precisava negociar um circuito dedicado para cada centro de supercomputação ou cada outra rede regional. Protocolos comuns e um backbone operado permitiam que uma única vinculação alcançasse um conjunto crescente de destinos. Os efeitos de rede resultantes aumentavam o valor de cada rota utilizável.

A dependência era o reverso dessa vantagem. Uma vez que pesquisadores, bibliotecas, administradores e departamentos de TI dos campi contavam com a conectividade remota, um atraso em um enlace regional ou uma entrada de política de backbone impunha um custo real aos usuários. No entanto, a localização do remédio dependia da falha. Uma entrada de registro incorreta era de responsabilidade dos administradores de identificadores. Uma linha alugada com falha era de responsabilidade do campus, da rede regional ou da operadora. Um anúncio não autorizado era de responsabilidade das operações de roteamento.

A rejeição por um par distante não podia ser corrigida pela NSF simplesmente declarando o destino 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 ramos administrativos idênticos da NSF ou da Merit.

O relato operacional da OARnet de 1991 descrevia uma rede atendendo ao ensino superior de Ohio e permitindo conexões para empresas envolvidas em pesquisa, desenvolvimento de produtos ou ensino. Ela usava TCP/IP e DECnet, conectava diretamente 29 locais e operava uma topologia na qual 13 roteadores funcionavam como roteadores de fronteira de sistema autônomo.

Sua principal relação de roteamento externo no relato da RFC 1246 passava por uma rede desmilitarizada em Columbus conectada à CICNet. Algumas partes da OARnet geravam uma rota padrão quando a sessão externa correspondente estava disponível, em vez de transportar todas as informações EGP externas para dentro. A OARnet também possuía gateways para outros sistemas, incluindo o NASA Science Internet.

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

Os enlaces da Kent State relatados mostram o que a topologia regional modificava. O circuito DS1 oferecia um caminho preferido mais rápido. A conexão de 56 kilobits e o caminho mais longo passando por Cleveland constituíam uma alternativa menos atraente durante uma reinicialização. À medida que os enlaces eram restaurados, o OSPF recalculava as rotas. O evento demonstra a convergência e a resiliência regionais; não mostra que o prefixo externo de Kent mudava nem prova que todo o tráfego externo usava o NSFNET.

Outras redes regionais usavam arranjos organizacionais e técnicos diferentes. O estudoThe Strategic Future of the Mid-Level Networksdescrevia 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 terceirizava muitas funções para uma operadora. A NorthwestNet usava a Boeing Computer Services, enquanto a NEARnet usava a BBN.

A abrangência 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 às instalações NSFNET T1 quanto T3 e também possuía enlaces para a ESnet, as redes de defesa e os sistemas universitários californianos. Não era a mesma topologia, o mesmo mercado nem o mesmo ambiente institucional que a OARnet.

Consequentemente, o «acesso ao NSFNET» não podia ser reduzido a uma única solicitação nacional de campus. Uma universidade geralmente precisava de uma organização regional disposta e capaz de conectá-la, de um circuito alugado apropriado, de equipamentos, de pessoal técnico e de um arranjo de roteamento. A organização regional podia receber apoio federal, mas também podia contar com créditos estaduais, taxas institucionais, membros corporativos, contratos com operadoras ou contribuições em espécie.

Um campus atrasado não estava necessariamente proibido da Internet por um decreto federal. Ele podia, em vez disso, não ter um circuito de última milha acessível, não se enquadrar na categoria de adesão de uma rede regional ou não conseguir atender a um requisito de equipamento. A existência de outra rota dependia da geografia, da presença de provedores, da elegibilidade e da interconexão.

Esse limite probatório é importante para a Kent State. Os documentos preservados não fornecem o acordo de conexão inicial de Kent à OARnet, nem as taxas, nem a data de instalação, nem os orçamentos de serviços alternativos. Portanto, eles não permitem afirmar que um provedor substituto específico estava disponível para Kent em 1988 a um preço conhecido. As conexões da OARnet com a CICNet e a NASA não estabelecem que Kent poderia ter comprado esses caminhos independentemente ou usá-los se sua vinculação à OARnet tivesse sido negada.

A admissão regional era uma verdadeira barreira. Não era uma barreira padronizada em nível nacional, e os arquivos disponíveis sobre Kent não preservam nenhuma recusa, apelo ou alternativa cifrada.

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

O sistema de identificadores carregava traços da política anterior de interconexão. A RFC 1166 distinguia as redes entidade da Internet de pesquisa e operacional das redes IP independentes. As redes independentes eram marcadas com um asterisco e exigiam autorização separada para se interconectar. O131.123da Kent State e o131.187da OARnet apareciam como redes de pesquisa sem essa marca.

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

RFC 1174, publicada em agosto de 1990, explica tanto a divisão institucional quanto a insuficiência crescente do «status conectado». Ela identificava a função IANA como sendo desempenhada pelo Information Sciences Institute da USC. Ela identificava a SRI International como o registro Internet encarregado de reunir e registrar as informações sobre os identificadores de rede e de sistema autônomo atribuídos.

O documento descrevia uma história na qual os números foram primeiro atribuídos a organizações entidade da Internet de pesquisa, depois a redes governamentais ou apoiadas pelo governo autorizadas a se interconectar. À medida que o TCP/IP se espalhava para redes privadas, o registro atribuía números globalmente únicos mesmo quando uma organização não tinha intenção de se conectar à Internet subsidiada pelo governo federal. O «status conectado» tornou-se uma tentativa de distinguir entre a posse de um identificador e a autorização governamental para se interconectar.

Em 1990, esse campo binário não descrevia mais a rede com precisão. Os sistemas regionais acolhiam membros variados. Redes comerciais estavam surgindo. Redes internacionais não podiam razoavelmente ser reduzidas à aprovação de um patrocinador americano. Uma rede podia transportar parte de seu tráfego por um caminho apoiado pela NSF e outra parte por um par ou backbone diferente.

A RFC 1174 recomendava, portanto, que o registro Internet removesse o status conectado dos formulários e bancos de dados, em vez disso coletasse informações sobre acesso e políticas de trânsito, e permitisse que qualquer rede registrada entrasse no sistema de nomes de domínio sem consideração ao status conectado. Ela indicava que o registro deveria administrar o espaço de números enquanto os administradores de rede aplicavam a política de tráfego.

Esse documento era uma recomendação do IAB, não uma norma técnica nem a prova de que todo formulário, banco de dados e roteador mudou imediatamente. Sua cronologia não deve ser comprimida em uma reforma da noite para o dia. O que ele estabelece claramente é que os formuladores de políticas reconheciam o registro e a interconexão como funções diferentes e buscavam remover a aplicação do acesso da camada de atribuição de nomes e identificadores.

Não se tratava de uma distinção puramente teórica. Uma organização podia precisar de um número único para uma rede TCP/IP privada sem ter trânsito externo. Inversamente, um campus podia ter acesso físico a uma rede regional enquanto precisava de um espaço de endereçamento legítimo e não conflitante antes de poder ser representado com segurança na Internet ampliada.

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

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

NaRFC 1092, Jacob Rekhter descrevia uma limitação do protocolo de gateway externo usado entre o novo backbone e as redes regionais. O EGP sozinho não podia impedir que uma rede regional reivindicasse um destino pertencente a outra. Também não podia expressar uma hierarquia confiável de caminhos preferido e de backup em um ambiente malhado com enlaces «backdoor» adicionais.

O remédio proposto era tanto institucional quanto técnico. Uma rede escolheria um ou mais representantes regionais por meio de arranjos bilaterais. As informações sobre os representantes primários e secundários escolhidos seriam comunicadas ao centro de operações da rede NSFNET e inseridas no banco de dados de política de roteamento. O backbone ignoraria um anúncio proveniente de uma rede regional que não estava autorizada a representar esse destino.

RFC 1093descrevia a arquitetura correspondente. Os backbones regionais deveriam usar números de sistema autônomo únicos. Os nós do backbone verificavam tanto os números de rede quanto o número de sistema autônomo de origem. Os caminhos preferidos eram derivados de informações fornecidas pelos backbones regionais e pelos campi vinculados. As redes regionais podiam gerar rotas padrão internas, enquanto o backbone mantinha alcançabilidade explícita para as redes vinculadas e pares.

A rota dependia, portanto, do acordo entre registros provenientes de diferentes autoridades:

1. Um número de rede devia ser único e corretamente registrado.
2. Um campus devia ter uma relação de vinculação com uma rede regional.
3. O campus e a rede regional deviam concordar com uma representação e uma preferência de caminho.
4. Os dados de política do backbone deviam autorizar o sistema autônomo regional a anunciar esse destino.
5. O circuito e as sessões de roteador correspondentes deviam estar operacionais.
6. Os outros operadores deviam aceitar e propagar a rota se a alcançabilidade além do NSFNET fosse necessária.

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

É aqui que o acesso ao backbone moldava o poder dos endereços. O banco de dados de política do NSFNET não era o registro de endereços, mas a inclusão em um sistema de roteamento amplamente utilizado tornava um número registrado mais útil. À medida que a rede alcançável se expandia, uma representação correta por meio do backbone adquiria maior valor prático.

O mesmo sistema limitava as reivindicações unilaterais de rota. Uma rede regional não podia simplesmente anunciar o número de rede de outra organização com uma métrica preferida e esperar que o backbone acreditasse. Os registros de política e a validação do sistema autônomo transformavam uma relação administrativa em permissão de roteamento.

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

O que os números de crescimento medem

A expansão do NSFNET é uma prova tangível da utilidade pública, mas suas estatísticas descrevem populações diferentes.

O número de 152 milhões de pacotes mensais da Merit em julho de 1988 e a base de cerca de 200 milhões da NSF no início do serviço dizem respeito ao tráfego. Eles não contam os endereços nem as instituições. O depoimento da NSF relatava cerca de 11 bilhões de pacotes por mês em março de 1992, uma medida do uso em forte crescimento, e não um censo das organizações conectadas.

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

As declarações ao Congresso em 1992 faziam referência a cerca de 5.000 redes, incluindo cerca de 1.500 fora dos Estados Unidos, conectadas ao sistema global. 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 relatava 8.997 redes configuradas no banco de dados de política T3. Essa contagem representava as entradas de rede configuradas e seus caminhos de sistema autônomo preferidos. Não se tratava de uma contagem de organizações únicas. Uma mesma instituição podia deter várias redes de classe, e uma entrada configurada podia ter representações primária e de backup.

Os totais de alocação naRFC 1366mediam outra coisa. Em 1992, o documento relatava 49 números de classe A alocados, 7.354 de classe B e 44.014 de classe C. Eram unidades de alocação no sistema de endereçamento por classes, 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 superior a uma classe C.

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

Usados com cautela, esses 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 causou sozinho cada mudança. A queda nos custos dos equipamentos, a disseminação do software TCP/IP, os investimentos regionais, os serviços comerciais, a demanda dos campi, as redes internacionais e novos aplicativos contribuíram para isso.

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

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

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

A Merit, a IBM e a MCI criaram a Advanced Network & Services, Inc., ou ANS, em setembro de 1990. O relato da audiência de 1992 no Congresso descreve a Merit como permanecendo responsável sob seu acordo de cooperação, enquanto subcontratava uma parte substancial da gestão e operação do backbone aprimorado para a nova organização sem fins lucrativos. O relato institucional final da Merit apresenta da mesma forma a ANS como o veículo operacional para grande parte do trabalho no T3.

Os documentos públicos disponíveis estabelecem os contornos organizacionais, mas não revelam cada cláusula operatória do acordo Merit-ANS de 17 de setembro de 1990. É, portanto, mais prudente descrever a divisão observável do que atribuir direitos não documentados. A NSF permanecia como financiadora e supervisora do programa. A Merit permanecia responsável na cadeia do acordo de cooperação. A ANS empreendia importantes trabalhos de engenharia e operação do T3. A IBM e a MCI continuavam a fornecer tecnologias, instalações, pessoal e apoio significativos.

A transição para o T3 não foi instantânea. A instalação dos nós, o transporte inicial de tráfego, a migração das vinculações regionais e a desativação da rede T1 foram eventos distintos. 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 vinculações e rotas migravam.

Um aviso operacional da Merit arquivado nos registros NANOG de novembro de 1992 previa a desativação do backbone T1 na quarta-feira, 2 de dezembro de 1992. Esse aviso datado traz a distinção que faltava entre a chegada anterior do serviço de produção T3 e a desativação posterior do serviço T1 restante. O backbone T3 não se tornou totalmente exclusivo simplesmente porque os primeiros enlaces T3 transportavam 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 precisavam manter. Cada entrada representava uma rede e os caminhos de sistema autônomo esperados, não a concessão de um endereço. O banco de dados operacionalizava relações já estabelecidas em outro lugar.

Essa fase, portanto, intensificou a barreira prática sem mudar sua identidade jurídica. Uma entrada de política T3 ausente ou incorreta podia afetar a alcançabilidade em um serviço muito maior. Isso não tornava a ANS ou a Merit a IANA, nem transferia 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 que a transição T3 fosse concluída. A AlterNet e a Performance Systems International comercializavam conectividade. As redes regionais atendiam algumas organizações de pesquisa industrial e buscavam receitas 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. As entidades na audiência da Câmara de 1992 contestavam a alocação de custos, a consulta, a interconexão e a vantagem competitiva.

Os depoimentos não permitem transformar cada alegação em conclusão. Os críticos sustentavam que a estrutura favorecia um caminho e confundia os limites do apoio público. A Merit e a NSF sustentavam que o arranjo incentivava o investimento privado enquanto protegia o serviço de pesquisa e educação. A audiência estabelece a existência de uma séria disputa institucional, não uma conspiração comprovada nem uma reivindicação de propriedade.

Para o valor dos endereços, a comercialização importava porque tornava um par alternativo cada vez mais possível: um número registrado válido podia ser roteado por meio de um provedor comercial em vez do NSFNET. Um cliente podia adquirir serviço, mandar instalar um circuito e solicitar ao provedor que representasse sua rede.

Essa possibilidade permanecia condicional. Um provedor precisava ter presença geográfica ou um ponto de presença acessível. O cliente precisava ter um circuito de última milha, equipamentos, pessoal, um contrato de serviço e a aceitação do roteamento. A existência de um backbone comercial nos Estados Unidos não provava que cada universidade podia comprar um serviço comparável localmente ou a um preço acessível.

Os documentos preservados sobre a Kent State não fornecem orçamento contemporâneo da AlterNet, da PSI ou de outro provedor comercial cobrindo a localização de Kent, elegibilidade, instalação e custo completo. Eles não mostram que a BITNET, o NASA Science Internet ou uma rede regional vizinha estava disponível como substituto geral de trânsito IP. Seria, portanto, especulativo afirmar que um serviço alternativo específico era viável para Kent em 1988 ou atribuir-lhe um preço comparativo.

O que os arquivos mais amplos mostram é uma mudança do mercado ao longo do tempo. No início dos anos 1990, as organizações tinham mais provedores upstream 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 em paralelo com caminhos de agências e locais. A RFC 1092 já previa representações primária, secundária e «backdoor». O crescimento comercial transformou essas possibilidades técnicas em escolhas de serviços, embora de forma desigual.

A autoridade prática do NSFNET, portanto, enfraqueceu antes que o serviço terminasse formalmente. Permaneceu muito importante, mas uma rede registrada era menos dependente de um único caminho nacional subsidiado, uma vez que os provedores comerciais e as relações de troca podiam oferecer destinos comparáveis.

O registro continuou em um calendário distinto

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

A solicitação de propostas da NSF de março de 1992,NSF 92-24, dividia os serviços de informação de rede em funções de registro, diretório e banco de dados, e informação. A partir de 1º de janeiro de 1993, oacordo de cooperação NCR-9218742 da NSF com a Network Solutionsestabeleceu serviços de registro não militares no âmbito do que se tornou o arranjo InterNIC.

O escopo cobria o registro de domínios Internet, a atribuição de números de rede e a atribuição de números de sistema autônomo em coordenação com a IANA e os documentos de política pertinentes. Ele não atribuía à Network Solutions a responsabilidade de operar os roteadores NSFNET nem de escolher provedores de trânsito comercial.

RFC 1400documentava a transição operacional do DDN-NIC para a InterNIC. Ela fixava em 1º de abril de 1993 a data a partir da qual as solicitações de registro não-DDN deveriam ser endereçadas ao novo serviço. O registro militar permanecia em seu caminho distinto.

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

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

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

A solicitação de propostas da NSF de maio de 1993,NSF 93-52, propunha quatro áreas de projeto distintas: pontos de acesso à rede, um árbitro de roteamento, apoio a redes regionais e um serviço de rede backbone de altíssima velocidade para pesquisa avançada.

A estrutura evitava deliberadamente substituir o antigo serviço NSFNET por um backbone comercial único. Os provedores de serviços de rede comerciais transportariam o tráfego geral e se interconectariam nos pontos de acesso à rede. As redes regionais comprariam serviço upstream desses provedores, com ajuda transitória da NSF. A coordenação de roteamento continuaria por meio de um projeto de árbitro de roteamento. O vBNS atenderia às necessidades de pesquisa avançada, em vez de servir como sucessor universal único.

Adecisão do GAO sobre a contestação da Sprint à adjudicação do vBNSconfirma que a NSF 93-52 previa vários acordos de cooperação e que a MCI foi selecionada para o projeto vBNS em fevereiro de 1994. A decisão também enfatiza a necessidade de distinguir esse serviço de pesquisa do trânsito comercial que substituía o antigo backbone.

A cadeia de acesso mudou em consequência:

Um relatório de transição da Merit datado de 30 de setembro de 1994 mostra por que o registro sozinho não podia concluir a migração. Ele acompanhava cinco dependências operacionais: pontos de acesso à rede funcionais, a vinculação do NSFNET a esses pontos, as novas vinculações dos provedores, os 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 podia deixar uma instituição com identificadores válidos, mas alcançabilidade incompleta.

A transição final ocorreu em etapas, em vez de cerimonialmente. O aviso da Merit de 14 de abril de 1995 sinalizava que apenas sete organizações haviam rompido completamente sua antiga relação com o NSFNET. Muitas usavam novos provedores enquanto mantinham o NSFNET como backup.

As sessões restantes deveriam passar por uma parada de teste em 21 de abril para revelar as redes inalcançáveis. Uma restauração temporária ainda era possível durante a correção dos problemas. O aviso previa então a parada definitiva das sessões restantes em 28 de abril, seguida pela desativação do serviço backbone em 30 de abril.

Um comunicado da NSF datado de 15 de maio confirmava que o serviço backbone NSFNET havia sido desativado à meia-noite de 30 de abril de 1995.

A desativação ilustra fortemente a separação entre o registro de endereços e o serviço backbone, mas não prova que cada prefixo individual migrou sem interrupção. Demonstrar a continuidade para o131.123da Kent State, por exemplo, exigiria observações de roteamento pareadas antes e depois, além da entrada de registro. Os avisos de transição disponíveis mostram um sistema projetado para preservar a alcançabilidade durante a mudança de serviços; eles não fornecem um rastro específico para o prefixo de Kent.

O que se pode afirmar com confiança é que a desativação 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 de substituição. Os provedores trocaram rotas nos novos pontos de interconexão. O valor operacional dos endereços persistiu apenas porque esses novos atores transportavam e aceitavam as rotas.

Testando os dois eixos sem inventar alternativas

A distinção pode ser testada por meio de vários cenários limitados.

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

Suponha que uma universidade possua um número de rede registrado globalmente único, mas não tenha uma vinculação regional funcional ou um provedor upstream aceitável. Ela poderia usar o número internamente sem entrar em conflito com outra rede registrada. Poderia operar serviços TCP/IP locais e trocar tráfego em qualquer caminho bilateral que aceitasse transportá-lo. O registro permaneceria significativo. O que lhe faltaria seria uma alcançabilidade externa geral. A universidade precisaria de uma conexão regional, de um provedor comercial, de um caminho de agência elegível ou de um par dedicado.

Cada opção exigiria seu próprio acordo e suas próprias instalações físicas. O registro não obrigaria nenhum deles a fornecer serviço. Para a Kent State, os arquivos históricos não estabelecem qual substituto, se houver, preenchia todas essas condições em 1988. Os múltiplos gateways posteriores da OARnet comprovam a topologia, não um direito a um serviço independente para Kent. A existência da BITNET não forneceria por si só um trânsito IP geral. Os provedores comerciais tornaram-se mais plausíveis após 1990, mas nenhum registro completo do preço ou disponibilidade específica para Kent foi encontrado.

A conclusão justificada é, portanto, limitada: um endereço registrado podia sobreviver sem o NSFNET, mas sua utilidade externa dependia da obtenção de outro transportador e de uma rota aceita. A viabilidade ou acessibilidade para Kent em uma data específica permanece desconhecida.

Um acesso físico sem identificador público válido

Invertamos 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 de acordo com um plano de endereçamento local ou outro arranjo tecnicamente coordenado. As possibilidades técnicas genéricas incluiriam o uso de um espaço de endereçamento válido controlado pelo provedor ou o adiamento do anúncio público até a resolução do registro.

Os documentos preservados sobre a OARnet não estabelecem qual solução ela teria oferecido a Kent, portanto nenhuma deve ser apresentada como política da OARnet. O que o campus não podia fazer com segurança era escolher o número público de outra organização e esperar que o roteamento global funcionasse. Um endereçamento duplicado podia direcionar mal os pacotes ou fazer com que os filtros rejeitassem o anúncio. Os mecanismos de política do NSFNET foram especificamente projetados para comparar as informações de rede e de sistema autônomo com a representação esperada.

A solução começaria pelo lado dos identificadores: obter ou corrigir uma atribuição legítima e garantir que os contatos e a representação responsáveis estivessem corretos. A abertura de uma porta backbone não podia tornar um identificador duplicado único.

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

Um destino poderia estar corretamente registrado, vinculado a uma rede regional e aceito pelo NSFNET, mas ainda assim permanecer inalcançável por meio 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 ele não podia ordenar que cada operador governamental, comercial ou internacional propagasse uma rede. Um endereço roteado era, portanto, evidência de aceitação ao longo de um certo caminho, não evidência de aprovação universal. O remédio apropriado era o diagnóstico de rota e a coordenação entre operadores.

O registro podia ajudar a identificar contatos, mas não podia impor o transporte. A Merit podia corrigir seu próprio banco de dados de política, mas não podia configurar cada rede remota.

Uma conectividade elegível com tráfego exigindo outro caminho

Um campus também podia possuir um identificador válido e uma rota funcional enquanto parte do tráfego era inelegível para o backbone apoiado pelo governo federal. Era um problema de política de tráfego, não um cancelamento do endereço nem uma recusa de adesão física. A instituição poderia precisar encaminhar o tráfego relevante por meio de outro provedor ou demonstrar que ele servia ao propósito autorizado de pesquisa e educação. O ponto importante aqui é institucional: a conformidade com o uso aceitável era uma condição adicional no caminho, não a autoridade que criava o número.

Esses cenários evitam uma falsa simetria. Suas consequências não eram idênticas e os remédios disponíveis diferiam. A falha de registro ameaçava a unicidade e a representação estável. A falha regional ameaçava a vinculação local. A falha do backbone ameaçava o transporte interregional. A rejeição por um par ameaçava o alcance além do provedor imediato. O conflito de política de tráfego afetava os usos que podiam usar um caminho apoiado específico. Para o usuário do campus, todos podiam produzir o mesmo sintoma: um destino distante não respondia. A análise de governança deve reconstituir a camada na qual a falha ocorreu.

Onde se situavam a autoridade e as consequências

A NSF governava diretamente o programa que financiava. Ela escolheu e supervisionou a estrutura de acordo de cooperação, apoiou a conectividade regional, examinou o desempenho, aprovou modificações 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 no âmbito de 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 a coerência de um sistema roteado em expansão.

A IBM e a MCI forneceram contribuições técnicas e de comunicação distintas. Elas não eram autoridades de adesão universitária nem registros de números Internet. Durante a fase T3, a ANS assumiu extensos trabalhos de engenharia e operação, enquanto a Merit permanecia na cadeia de acordo com a NSF. As redes regionais controlavam a camada orientada ao campus. Elas decidiam quem podiam 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 de uma escolha limitada de operadoras variavam consideravelmente. A função IANA, o trabalho de registro Internet do DDN-NIC e posteriormente os serviços de registro da InterNIC controlavam os identificadores e registros por uma sequência distinta. Esses registros importavam porque números duplicados ou mal atribuídos não podiam sustentar um roteamento global confiável. As autoridades de identificadores não operavam o circuito DS1 da Kent State nem escolhiam seu caminho upstream.

Os operadores de campus, regionais, de backbone e pares convertiam essas relações em alcançabilidade. Eles configuravam roteadores, trocavam informações de roteamento, validavam os 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 determinado momento. A proposição de que o NSFNET amplificava o poder dos endereços só se sustenta, portanto, em um sentido distribuído. A conectividade financiada pela NSF tornava a Internet mais útil.

Quanto mais destinos o backbone e seus pares conectavam, mais valioso se tornava possuir um identificador corretamente representado nesse ambiente. Esse efeito também aumentava as consequências das decisões de admissão regional e de política de roteamento. Um registro no registro de números era necessário, mas insuficiente. Um circuito regional sem um identificador legítimo também era insuficiente. Nenhum dos dois eixos produzia sozinho uma alcançabilidade geral. O investimento público não deve ser considerado acessório a esse resultado.

O NSFNET criou uma interoperabilidade nacional em uma velocidade e escala que as universidades individuais dificilmente reproduziriam separadamente. Ele compartilhou os custos fixos, desenvolveu operações, apoiou o crescimento regional e deu aos pesquisadores acesso a recursos remotos. Seu sucesso explica em parte seu poder: a dependência seguiu a utilidade. A dependência também não deve ser confundida com um monopólio formal sobre os endereços. Serviços comerciais, redes de agências, pares diretos e «backdoors» regionais existiam ou surgiam em diferentes momentos.

Sua disponibilidade era desigual e sua existência não garantia uma alternativa viável para cada instituição. Mas eles demonstram que o valor das rotas podia migrar sem que o identificador precisasse ser 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 migraram para redes comerciais e pontos de troca. A coordenação de roteamento persistiu em novas organizações. Não era a prova de que cada migração ocorreu sem problemas.

Era a prova de que a identidade Internet e o transporte Internet podiam sobreviver a uma substituição institucional porque nunca haviam sido a mesma função. A NSF não possuía os endereços transportados no NSFNET. A Merit não decidia todas as admissões à Internet mundial. 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 cada par além de suas fronteiras. No entanto, suas decisões se alinhavam de forma suficientemente estreita para que os usuários pudessem senti-las como uma única barreira.

A importância do NSFNET em termos de governança reside nesse alinhamento. O acesso ao backbone moldava o poder dos endereços não ao absorver a autoridade sobre os identificadores, mas ao determinar se um identificador legítimo podia participar de um dos ambientes de roteamento mais valiosos de sua época.

Fontes

• Subcomitê de Ciência da Câmara dos Representantes dos Estados Unidos,Management of NSFNET, 12 de março de 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,programa de desativação do backbone T1 NSFNET, arquivos de novembro de 1992
• Merit, atualização da política de roteamento NSFNET relatando 8.997 redes T3 configuradas, arquivos de janeiro de 1993
• NSF 92-24,Network Information Services Manager(s) for NSFNET and the NREN
• NSF e Network Solutions, acordo de cooperação NCR-9218742, 1º de janeiro de 1993
• NSF 93-52,Network Access Point Manager, Routing Arbiter, Regional Network Providers, and Very High Speed Backbone Network Services Provider, 6 de maio de 1993
• U.S. GAO,Sprint Communications Company, L.P., B-256586 e B-256586.2, 9 de maio de 1994
• Galeria do Atlas Internet da CAIDA, dados de tráfego e agregação NSFNET de dezembro de 1994
• Merit,Update on Transition from the NSFNET Backbone Service, 30 de setembro de 1994
• Merit,Final Transition Steps, 14 de abril de 1995
• National Science Foundation,NSFNET Backbone Decommissioned, 15 de maio de 1995