Resumo

  • Demand RIP trocou atualizações WAN periódicas por intercâmbios disparados, confirmados e retransmitidos. Assim circuitos ociosos podiam fechar, enquanto rotas aprendidas por resposta disparada normalmente não expiravam com o silêncio.
  • Uma tentativa real de abrir o circuito podia falhar e levar o gerenciador a declarar o próximo salto indisponível; só então começavam envelhecimento, hold-down e remoção. O ACK provava recebimento da mensagem, não veracidade da rota nem sucesso do tráfego.
  • RFC 1581 relatou uma implementação concluída, testada contra ela mesma em X.25 e ISDN. RFC 1264 tratava implementações independentes e testes entre elas como evidência adicional, não presumida.

O pulso de roteamento impedia o circuito de dormir

RFC 1582, datado de fevereiro de 1994 em seu registro oficial, partia da lógica de redes públicas orientadas a conexão. Um circuito virtual surgia quando havia dados e podia ser liberado quando a atividade acabasse. O uso efetivo entre duas localidades podia ser curto e esporádico.

RIP tradicional repetia a tabela mesmo sem alteração. O que era uma emissão no meio compartilhado de uma LAN virava uma sequência de mensagens separadas na WAN. O documento calculava N × (N - 1) atualizações por ciclo para N roteadores, distribuídas entre N × (N - 1) / 2 conexões. E o número de canais simultâneos podia ser menor que o de vizinhos; uma interface ISDN básica oferecia apenas dois no exemplo.

Aumentar o intervalo economizava dinheiro e fila, mas atrasava mudanças. Mantê-lo impedia a ociosidade. Demand RIP preferiu mudar a causa da transmissão: pedido explícito, alteração no banco de rotas ou aviso de recuperação emitido pelo gerenciador do circuito.

O silêncio passou a conservar a afirmação anterior

O relatório companheiro RFC 1581, classificado como Informational em seu registro, condensava a troca. Na WAN, atualizações só seriam disparadas quando necessárias e retransmitidas até a confirmação. A informação recebida não caducaria no curso normal.

RFC 1582 separava duas classes de entrada. Uma rota aprendida de anúncios de LAN era temporária e expirava sem renovação. Uma rota recebida de resposta disparada na WAN era normalmente permanente.

Permanente não significava correta para sempre. Significava conservar o último estado aceito até um evento reconhecido contradizê-lo: anúncio explícito de infinito, ausência numa resposta completa, interface caída, trocas sem confirmação ou falha do gerenciador ao tentar abrir o circuito para tráfego real.

“Não ouvi atualização” deixou de ser teste de falha porque o protocolo havia decidido não enviar atualização. Também não se tornou prova positiva. Era simplesmente uma regra de persistência. A autoridade para iniciar a retirada saiu do relógio periódico e passou a eventos nomeados.

O gerenciador do circuito ganhou efeito sobre a rota

RFC 1582 colocava o gerenciador abaixo de IP, IPX e suas aplicações de roteamento. Ele relacionava o endereço lógico do próximo salto ao endereço físico da chamada, abria um circuito virtual para dados ou atualizações e o fechava após ociosidade.

Se a tentativa falhasse durante a operação normal, enviava circuit down ao processo de rotas. As entradas permanentes por aquele vizinho começavam a envelhecer, eram anunciadas como inalcançáveis durante hold-down e podiam ser apagadas. Recuperação anterior ao vencimento permitia restabelecê-las; depois do vencimento, era necessário pedir o banco completo.

circuit up também era uma afirmação limitada. O gerenciador havia conseguido contato conforme seu procedimento, mas não havia validado toda rota antiga. Por isso, os pares reabasteciam suas bases. Chamada estabelecida, rota presente, encaminhamento selecionado, pacote entregue e aplicação funcionando permaneciam resultados diferentes.

O próprio método de recuperação ficou fora do escopo. Falta de canal, mapeamento errado, recusa remota e ruptura física podiam resultar na mesma indicação interna. Ela autorizava uma ação segura sem determinar sozinha a causa.

A confirmação fechava a entrega, não a realidade

Sem nova rodada periódica, perder uma mudança era mais grave. Um datagrama podia sumir porque não havia circuito livre, a fila encheu, uma chamada foi preterida ou o quadro corrompeu. RFC 1582 acrescentou requisição, resposta, confirmação e retransmissão.

Uma resposta grande era dividida em fragmentos. Cada um recebia ACK próprio; o receptor só alterava a base depois de reunir todos. Se o intervalo acabasse, descartava o conjunto incompleto e solicitava novamente o estado total. Um número de sequência novo substituía a montagem antiga.

Esses mecanismos davam recibos com escopo definido. ACK mostrava que uma resposta ou fragmento chegou. Reassemblagem completa mostrava que havia um conjunto aplicável. Sequência distinguia versões. Nada disso provava que a rede anunciada realmente funcionava, que o FIB instalara aquela escolha, que o pacote do usuário passara ou que o serviço respondera.

A lista de pares definia envio e aceitação; mensagem fora dela devia ser descartada. RIP-2 podia autenticar o remetente. Ainda assim, um remetente autorizado podia divulgar uma informação errada. Identidade, integridade, conteúdo e resultado operacional não eram sinônimos.

A economia da chamada virou dívida de estado

Rotas permanentes não podiam depender do esquecimento. RFC 1582 exigia guardar alternativas, ou manter um subconjunto e registrar que outras haviam sido descartadas, pedindo-as antes que as últimas opções desaparecessem. O refresco periódico reconstruía conhecimento; agora a memória e a requisição deliberada precisavam substituí-lo.

Menos tráfego criou uma máquina de estado mais exigente: retirada precisa, retransmissão, montagem completa, coordenação entre camadas e recuperação de reinício. O custo visível da linha caiu enquanto crescia uma obrigação menos visível de coerência.

O RFC também tratou da vida independente dos componentes. Na implementação descrita, gerenciador e aplicação estavam fortemente ligados. Num Unix, o primeiro podia morar no kernel e a segunda num processo; outro equipamento poderia usar uma placa separada. Quando um podia morrer sem o outro, keepalive e ressincronização eram necessários. Sobrevivência local não provava que ambos compartilhavam o mesmo estado.

Um teste de si mesmo continuava sendo apenas esse teste

RFC 1581 dizia que se conhecia uma implementação completa. A de Spider Systems suportava IP RIP-1, IPX RIP e IPX SAP, mas ainda não RIP-2. Foi testada contra ela mesma em X.25 e ISDN, e operou ao lado de implementações comuns em Ethernet. Duas versões apenas para Novell estavam em desenvolvimento.

Era evidência de código e de dois meios WAN. Não era evidência de que uma segunda implementação independente tratasse fragmentos, tempos, reinícios e sinais da mesma forma.

RFC 1264, com seu registro oficial, explicava a cautela. Protocolos de roteamento são algoritmos distribuídos em tempo real. Um programa funcionando num ambiente não garante vários fabricantes em outro. Implementações independentes, testes de todas as funções e demonstração dos controles de segurança eram requisitos de evidência separados.

“Implementado” não deve virar “interoperável”, e autoensaio não deve virar ausência de prova. O registro vale porque declara exatamente o que ocorreu.

RFC 2091 reduziu a carga sem abolir a presunção

Em janeiro de 1997, RFC 2091, segundo seu registro, propôs vantagens sobre RFC 1582. Depois da troca total, enviava apenas alterações, reduzia memória e tráfego e eliminava o limite de 255 fragmentos por não usar a montagem anterior.

Mas rotas recebidas por atualização disparada continuavam normalmente permanentes. O gerenciador continuava informando down e up. Mensagens ainda exigiam ACK e retransmissão. Ausência prolongada de confirmação podia transformar a presunção em inalcançável. Recuperação e reinício ainda exigiam flush e troca completa.

A publicação posterior não prova adoção nem substitui uma observação de tráfego. Ela mostra outra realização da mesma fronteira. Quando o silêncio é esperado, estado retido, evento de revogação, entrega da atualização, encaminhamento e resultado de serviço precisam continuar separados.

Fontes