Resumo

  • Em 1991, a BARRNet registrava 1.816 rotas externas. A implantação inicial do OSPF revelou um salto adicional para parte do tráfego da NSFNET e pressão de memória nos roteadores menores.
  • O RFC relaciona esses limites a dois recursos do OSPFv2: endereços de encaminhamento e áreas stub. É um caso operacional específico, não a explicação única da evolução do protocolo.

Em abril de 1990, a BARRNet colocou o OSPF versão 1 em operação numa rede de pesquisa do norte da Califórnia. Em novembro, já executava a versão 2. Quando John Moy documentou a rede em julho do ano seguinte, não se limitou a registrar um adotante precoce. O relatório descreveu uma rota que fazia um desvio desnecessário e roteadores sem memória suficiente para guardar todas as rotas que chegavam de fora. Essas duas limitações aparecem como motivo para dois recursos adicionados ao OSPFv2. O caso é concreto: operadores podiam apontar o tráfego e os equipamentos que mostravam o que faltava ao protocolo. RFC 1246, §§6.0, 6.2.1–6.2.2

A BARRNet não era uma rede de um único campus. O relato de 1991 diz que atendia cerca de 80 locais membros, de Sacramento a Monterey, com conexões de 9,6 kbps a um T1 completo. Havia universidades, órgãos públicos e empresas entre os membros. A rede regional se conectava à NSFNET em Stanford por enlaces T1 e T3; também alcançava a ESnet em Lawrence Livermore, a DDN pelo Federal Internet Exchange da NASA Ames e as redes universitárias estaduais da Califórnia. A BARRNet precisava transportar o alcance local enquanto trocava rotas com vários sistemas maiores. RFC 1246, §6.2

O núcleo tinha 14 roteadores Proteon. Seis formavam um anel redundante, com circuitos T1 completos entre os locais centrais. Os sites membros se ligavam atrás desses roteadores, em sua maioria numa estrela centrada em Stanford. Essa topologia importa porque os gateways externos e os roteadores que tratavam o tráfego ocupavam pontos distintos da mesma rede regional. O RFC conta 1.816 rotas externas no sistema OSPF naquele momento. A maioria vinha da NSFNET; as demais incluíam rotas de NSN, de roteadores da BARRNet que ainda usavam outros protocolos e da ESnet. A BARRNet importava rotas RIP e EGP para OSPF, aplicava métricas externas de Tipo 1 e usava etiquetas para controlar a readvertência via EGP. Não houve uma substituição limpa de um protocolo por outro: OSPF teve de coexistir com as conversas de roteamento já existentes. RFC 1246, §§6.2.1–6.2.2

Um diretório de redes de 1990 também descreve a BARRNet como uma rede regional formada por circuitos alugados, enlaces de micro-ondas e diversos tipos de conexão aos locais atendidos. Uma retrospectiva posterior da Internet2 afirma que a propriedade e a manutenção dos roteadores eram bastante descentralizadas entre as universidades membros. Essas fontes ajudam a separar o sistema de roteamento compartilhado de quem possuía ou mantinha cada equipamento; não mostram que essa organização tenha causado o salto extra ou a falta de memória. O RFC 1245 registra testes de interoperabilidade do OSPF e o RFC 1131 oferece a especificação da versão inicial: norma, implementações e experiência de campo evoluíam lado a lado. The User’s Directory of Computer Networks (1990); retrospectiva da Internet2; RFC 1245; RFC 1131

O primeiro problema estava na borda. Apenas os roteadores BR5 e BR6 trocavam informações EGP com o sistema que o RFC chama de NSS. Sem um endereço de encaminhamento separado no anúncio externo do OSPF, o tráfego da NSFNET tratado por BR10, BR16 e BR28 seguia primeiro para o gateway que anunciava a rota, mesmo quando o próximo salto externo podia ser alcançado diretamente. Um roteador a mais entrava no caminho. O campo de endereço de encaminhamento do OSPFv2 permitia que o anúncio apontasse o próximo roteador para aquele destino, de modo que os roteadores internos usassem o caminho direto. A especificação explica a função com um exemplo genérico; o relatório de Moy a relaciona aos roteadores identificados da BARRNet. Como a fonte não expande “NSS”, mantemos a sigla. RFC 1246, §6.2.2; RFC 1247, §§2.2, 12.4.4

O segundo problema era memória. Alguns roteadores não conseguiam manter todas as rotas externas. A BARRNet usava quatro áreas stub, cada uma composta por uma única LAN sem roteadores OSPF internos. Essas áreas excluíam anúncios externos e reduziam as informações que os roteadores precisavam armazenar. O relato apresenta o recurso como tentativa de fazer o OSPF funcionar em equipamentos com pouca memória, não como garantia para qualquer aparelho limitado. Não informa capacidade de memória nem medições antes e depois. O projeto aceitava uma visão menos completa das rotas externas em troca de reduzir o estado de roteamento mantido dentro da área. RFC 1246, §§6.2.1–6.2.2; RFC 1247, §3.6

Moy apresentou a BARRNet como um entre vários casos iniciais. O mesmo relatório também lista a NASA Science Internet e a OARnet; a implantação do OSPF na Internet começara na primavera de 1990. O primeiro uso não revelou falhas do protocolo, embora tenha mostrado recursos desejáveis. A importância da BARRNet é mais específica que uma alegação de primazia: o relatório identifica o desvio de rota e o limite de memória ligados a dois recursos da versão 2. O RFC 1247 também diz que as versões 1 e 2 não eram interoperáveis, o que tornava a mudança de versão uma fronteira operacional. O relatório registra as datas de uso da BARRNet, mas não traz uma cronologia de migração por roteador nem prova de uma troca simultânea. RFC 1246, §§6.0, 6.2.2; RFC 1247, apêndice F

Esse limite das fontes mantém a história proporcional. A especificação dizia como os roteadores deveriam agir; a rede em operação mostrou onde o modelo acrescentava um trecho de trânsito ou exigia mais estado do que um equipamento podia guardar. O registro não afirma que a topologia da BARRNet ou o OSPF, sozinhos, resolveram os problemas da Internet. Mostra dois pedidos operacionais concretos: anunciar o próximo salto que realmente seria usado e permitir que uma área com poucos recursos armazenasse menos rotas externas.

Fontes