Resumo

  • O experimento de RFC 1477 ligou falha de gateway e mudança de política de trânsito a anúncios, desmontagem de caminho, cálculo de alternativa e continuidade da sessão Telnet em um anel de quatro domínios.
  • A evidência terminava no escopo do protótipo: política de origem e gateways múltiplos entre domínios foram excluídos, o mapeamento foi injetado por tabelas e os números de desempenho não apareceram no RFC.

A volta pelo outro lado

No cenário principal de RFC 1477, quatro domínios administrativos formam um anel. S abriga a origem, D o destino, e T1 e T2 são domínios de trânsito. Há, assim, dois percursos interdomínio possíveis.

Uma sessão Telnet faz o agente de caminho em S pedir uma rota de política ao servidor de rotas. O servidor devolve a rota, o agente inicia o estabelecimento e a sessão começa. Para produzir uma falha, os pesquisadores encerram os processos IDPR em um gateway do caminho ativo por T1. Os vizinhos detectam a perda, distribuem a nova conectividade e desmontam as seções que sobraram. S pede outra rota, recebe um caminho por T2 e a conversa Telnet permanece intacta.

Depois de restaurar T1, a equipe muda uma condição lógica. A política de T2 passa a impedir tráfego de S para D. A mudança é anunciada, o caminho deixa de ser aceitável, é desmontado e a alternativa por T1 assume. Novamente, o relatório diz que a sessão ficou intacta.

Não era apenas uma observação na tela. O software registrava mudanças de conectividade, alterações de política de trânsito, transmissão e recepção de estado de enlaces, geração da rota, mensagens de controle e mudanças no estado do caminho. Isso permitia confrontar o comportamento observado com o comportamento esperado.

Mesmo assim, “intacta” não fornece quantidade de pacotes perdidos, distribuição de convergência ou repetição estatística. A frase comprova aquela continuidade relatada. Não autoriza uma garantia para toda aplicação, escala ou sequência de falhas.

O corte escolhido para chegar ao código executável

O próprio RFC afirma que o protótipo continha a maior parte da funcionalidade IDPR, não toda. Para produzir software funcionando rapidamente, o grupo deixou de fora suporte a políticas de origem e a múltiplos gateways de política ligando dois domínios.

Política de trânsito e política de origem não são dois nomes para o mesmo filtro. O domínio atravessado define condições para uso de seus recursos. A origem expressa exigências de serviço e preferências de percurso para o seu tráfego. Alterar a política de T2 demonstrou a primeira superfície. O código da segunda não estava no protótipo.

Também há diferença entre duas grandes alternativas ao redor do anel e vários gateways na mesma fronteira interdomínio. O segundo caso exige escolhas e reparos locais que o artefato simplificado não implementou. A sobrevivência diante de T1 ou T2 não preenche automaticamente essa lacuna.

O corte fazia sentido. Uma implementação mínima produz aprendizado e dados antes que toda a arquitetura esteja pronta. A honestidade do relatório está em nomear o corte. A desonestidade começaria se um leitor posterior transferisse o sucesso para as partes retiradas.

Um laboratório distribuído e uma topologia legível

O trabalho de protótipo começou no verão de 1990, e os testes do software concluído em fevereiro de 1991. A USC montou SPARC1+ em Ethernet com topologia reconfigurável. A SAIC usou Sun3 em Sparta e MITRE, conectados pela Alternet com um enlace SLIP de 9,6 kb/s e por um caminho X.25 no ambiente DCA EDN. A BBN conectou SPARC1+ na BBN e na ISI sobre DARTnet e TWBnet.

Máquinas e redes do período deram materialidade ao experimento. Ao mesmo tempo, o anel de quatro domínios mantinha a pergunta pequena. Os dois domínios de trânsito começaram sem restrições de acesso.

Outra simplificação apareceu no mapeamento. Em vez de servidores de mapeamento, cada gateway recebeu tabelas configuradas de endereço para domínio. A tabela entregava a resposta necessária ao cálculo. Não demonstrava descoberta, distribuição, atualização ou resolução de inconsistências de um serviço dinâmico.

Um fixture correto permite testar o componente seguinte. Ele não é recibo de execução do componente substituído.

O referente de “todas as funções principais”

RFC 1477 chama os experimentos de simples e diz que cobriram todas as funções principais do protótipo. A conclusão é compatível com o inventário. O software detectou vizinhos, distribuiu informações, calculou rota, montou caminho, percebeu falha, retirou estado antigo e desviou tráfego. Reagiu também à mudança de política de trânsito.

A palavra decisiva é “protótipo”. A arquitetura em RFC 1478 e o protocolo em RFC 1479 descrevem uma superfície maior. Um requisito no papel não deixa log de execução num programa que declarou não o incluir.

Respeitar esse limite não rebaixa o trabalho. Ao contrário, torna a alegação resistente: os mecanismos implementados responderam a duas mudanças e preservaram a sessão observada. O resto continua como pergunta identificada.

Uma avaliação cujo quadro não veio junto

Participantes da USC e da SAIC mediram o processamento do estabelecimento de caminhos e do encaminhamento. Compararam IDPR com encapsulamento IP ao encaminhamento IP comum e examinaram o custo sem cálculo de integridade/autenticação e com RSA/MD4.

O texto chama os resultados de animadores, mas não publica os números. Indica contatos para obtê-los e adverte contra extrapolação cega para outras implementações, pois o protótipo recebeu pouca otimização.

O registro permite dizer o que foi medido e como os autores avaliaram o resultado. Não permite fabricar latência, vazão ou sobrecarga. A cautela anexada à medição faz parte do resultado tanto quanto o adjetivo positivo.

gated reduziu a barreira, não provou adoção

Em 1992, SRI juntou-se a SAIC e BBN para integrar IDPR ao processo UNIX gated. RFC 1477 diz que a versão trazia funcionalidade completa, uma interface de configuração e maior eficiência por funcionar como processo único. Estava disponível gratuitamente para a comunidade, permitindo que uma máquina UNIX experimentasse IDPR sem novo esforço de implementação.

Isso mudou o próximo teste possível. O objetivo declarado passou a ser ganhar experiência em redes operacionais, com restrições reais e tráfego com requisitos reais. Na data do documento, um piloto e uma demonstração estavam em andamento em locais selecionados.

Disponível não quer dizer instalado; instalado não quer dizer habilitado; habilitado não conta quais fluxos passaram; piloto iniciado não significa piloto concluído. O RFC não contém um censo posterior.

O título tampouco resolve o estado. O registro de RFC 1477 classifica o memorando como Informational, apesar de “Proposed Standard” no nome. Os registros de RFC 1478 e RFC 1479 preservam a situação documental da arquitetura e do protocolo. RFC 2026 explica o vocabulário do processo. Documento e processo em execução continuam sendo evidências diferentes.

A lacuna é parte do resultado

RFC 1102 tratou da construção da rota de política; RFC 1104 separou roteamento, tratamento de pacotes, alocação de recursos e contabilidade. RFC 1477 oferece um recorte próprio: mostra como um conceito virou software e quais partes ficaram fora do primeiro executável.

As notas de Heng Lu sobre primazia do código em execução, especificação inicial mínima e adoção voluntária e camadas de realidade fornecem a disciplina: execução vale mais que intenção, mas não pode testemunhar sobre código ausente.

O melhor elogio ao protótipo não é ampliar sua vitória. É preservar a topologia, os eventos, as omissões e as incertezas que fizeram daquela vitória um fato verificável.

Fontes