O endereço não era o caminho: o limite que a RFC 2333 impôs ao NHRP

Resumo

• A RFC 2333 tratava o NHRP como resolução de endereço apoiada numa decisão anterior de roteamento, não como protocolo de rota ou teste fim a fim.
• A conveniência de um atalho dependia da topologia, do custo, da necessidade da aplicação, da cobertura NHRP e das condições de segurança contra loops.
• Um ACK de registro, uma resposta autoritativa e uma entrada de cache tinham escopos próprios, definidos por procedência, política, tempo de retenção e possibilidade de expurgo.
• Em ATM, obter o endereço ainda deixava a conexão virtual por estabelecer; depois vinham o plano de dados, o caminho de volta, o serviço remoto e a aplicação.
• A operação segura precisava verificar cada transição e manter o encaminhamento roteado como continuidade, sem promovê-lo ou rebaixá-lo com base apenas no cache.

Uma linha de estado podia parecer maior do que era

O NHRP produzia informações muito concretas.

Um endereço de protocolo apontava para um endereço NBMA. A resposta podia ser autoritativa. A entrada podia ter idade e tempo restante. Em uma tela operacional, esses campos sugerem que o próximo salto já está “de pé”.

A RFC 2333 começou de outra pergunta: em que circunstâncias o NHRP era aplicável ao transporte de datagramas IP sobre redes NBMA como ATM, SMDS e X.25?

Essa pergunta separava adequação de execução.

Uma rede podia satisfazer as condições para usar NHRP sem que nenhum atalho estivesse ativo. Um cliente podia ter uma resposta correta sem que o meio orientado a conexão tivesse aceitado um circuito. Um circuito podia existir sem encaminhamento IP nos dois sentidos. E a pilha de rede podia funcionar enquanto a aplicação remota falhava.

O cache era evidência de uma etapa. Não era um resumo mágico das etapas seguintes.

O roteamento escolhia antes da resolução

O NHRP não substituía os protocolos de roteamento.

A estação de origem determinava o próximo salto pela tabela e pela política de rede. Quando essa direção usava uma interface NBMA e faltava um mapeamento, o cliente podia emitir uma Resolution Request. Para um destino dentro da mesma rede NBMA lógica, a resposta podia indicar o próprio destino. Para um destino externo, indicava o roteador de saída corrente.

Se um algoritmo dinâmico alimentava o NHRP, a saída refletia a escolha desse algoritmo.

O resultado não certificava que a saída era ótima sob qualquer métrica. Menos saltos no caminho IP original não garantia menor latência, menor congestionamento, menor custo ou melhor isolamento de falhas.

Também não congelava a época de roteamento. Mudanças rápidas podiam tornar o atalho efêmero. No uso entre roteadores, a perda de informação necessária para impedir loops podia produzir encaminhamento persistente em círculo.

Resolver o endereço era consumir uma decisão de rota, não adquirir autoridade para mantê-la.

O atalho precisava compensar seu custo

No modelo Classical IP over ATM, uma LIS definia o alcance da resolução ATMARP. Estações em LIS diferentes passavam por um roteador IP, embora o tecido ATM pudesse permitir uma conexão virtual direta.

O NHRP fornecia resolução entre LIS dentro de uma rede NBMA lógica e podia remover esses saltos intermediários. O ganho podia ser relevante, inclusive para aproveitar características de QoS do meio.

Mas a RFC 2333 não presumia que todo fluxo merecia esse estado.

Criar um atalho consumia sinalização, memória e capacidade de interface. Uma transação curta, sem requisito especial, podia acabar antes de recuperar esse custo. Por isso, a decisão era ligada às necessidades da aplicação e à política do operador.

“NHRP é apropriado aqui” era uma conclusão sobre o ambiente. “Este fluxo deve criar um atalho agora” continuava sendo uma escolha.

A autoridade para iniciar evitava multiplicação

Antes do atalho, um pacote podia atravessar vários roteadores. Se todos reagissem, cada ponto poderia criar seu próprio caminho direto.

A RFC 2333 sugeriu limitar a iniciativa ao host de origem, ao primeiro roteador cujo próximo salto fosse alcançável pela interface NBMA ou a um roteador de política obrigatório.

Essa regra distribuía autoridade e custo.

Ela não dizia que o solicitante teria sucesso. Dizia quem podia acionar a criação de mapeamentos e conexões para evitar que uma otimização gerasse estado redundante ao longo do percurso.

O caso roteador-roteador exigia recusa

Comunicações host-host, host-roteador e roteador-host cabiam no uso geral. Entre roteadores, o NHRP básico podia perder contexto de roteamento indispensável à supressão de loops.

Uma situação mais segura existia quando o host de destino era diretamente adjacente à interface não NBMA do roteador de saída e essa adjacência era estável.

Quando uma solicitação com bit Q vinha de um roteador sem essa condição, a saída podia responder com NAK. O tráfego continuava pelo caminho roteado.

Essa negativa não equivalia a indisponibilidade. Ela preservava conectividade ao rejeitar uma otimização cuja segurança não estava demonstrada.

O significado operacional de um NAK, portanto, dependia do que foi negado. Um atalho recusado podia coexistir com um serviço IP saudável.

O ACK de registro tinha objeto limitado

Pela RFC 2332, um NHRP Client registrava seu mapeamento no NHS que o servia.

O servidor verificava erros e aplicava política. Podia recusar um endereço fora de seu alcance, falta de recursos, proibição administrativa ou conflito de unicidade.

Um Registration Reply positivo provava aceitação do mapeamento naquele serviço e naquele momento.

Não verificava a aplicação remota. Não criava automaticamente um circuito ATM fim a fim. Não garantia que outros servidores já estivessem sincronizados. Não assegurava que a rota seguinte usaria o mesmo domínio lógico.

Além disso, o registro tinha Holding Time. O cliente precisava renová-lo com antecedência, inclusive para tolerar perdas. O próprio protocolo reconhecia que a autoridade do dado envelhecia.

Autoritativo não significava universal

O NHRP distinguia respostas autoritativas de respostas não autoritativas derivadas de cache.

O cliente podia pedir uma resposta do NHS responsável pelo destino. Um NHS de trânsito, quando autorizado, podia responder com informação armazenada. Saber qual caso ocorreu ajudava a estimar procedência.

Mesmo assim, a autoridade dizia respeito ao mapeamento.

Ela não prometia recursos para criar SVC, não testava filtros ou grupos fechados, não validava o caminho de volta e não consultava a saúde do serviço de aplicação.

Uma resposta podia ser a melhor afirmação disponível sobre “qual endereço NBMA tentar”. Ela continuava incapaz de responder “o que a tentativa entregou”.

O cache reunia histórias diferentes

Um NHS podia formar cache a partir de registro, solicitações e respostas, tabelas pré-configuradas, ARP ou mecanismos externos. Um NHC podia aprender de uma resposta, de configuração manual ou de outra origem.

RFC 2677 permitia observar tipo, fonte, uso, MTU negociada e validade do Holding Time. Uma entrada aprendida devia desaparecer quando o tempo restante chegasse a zero. Uma entrada administrativa podia ter tempo indefinido por estar respaldada em configuração persistente.

Essas diferenças mudavam a decisão.

Um mapeamento manual podia sobreviver à mudança de um endpoint. Uma resposta autoritativa recente trazia outra cadeia de responsabilidade. Uma resposta negativa em cache reduzia carga de consultas, mas não provava impossibilidade permanente. Uma cópia SCSP podia estar consistente com os pares e ainda estar desatualizada em relação ao mundo.

Presença sem procedência era uma simplificação perigosa.

Servidores sincronizados não eram uma sonda distribuída

SCSP e a especificação distribuída da RFC 2335 permitiam sincronizar informações entre NHSs.

Isso resolvia uma necessidade interna: evitar que servidores do mesmo grupo respondessem de maneira incoerente sobre os mapeamentos que deveriam compartilhar.

Replicar não observava o endpoint novamente.

Se a fonte já estivesse antiga, vários servidores poderiam concordar perfeitamente com uma realidade passada. O acordo provava o funcionamento da sincronização, não a entrega de pacotes.

A RFC 2332 também definiu Purge e erros para loop, endereço de protocolo inalcançável, resposta inválida, falha de autenticação e excesso de saltos. O estado era desenhado para ser recusado e revogado quando as condições mudassem.

Endereço e conexão eram ações distintas

Em uma rede NBMA orientada a conexão, como ATM, a origem podia precisar estabelecer uma conexão com a largura desejada depois da resolução.

Logo, “resolvido” não era sinônimo de “conectado”.

A sinalização podia falhar por política ou recurso. A conexão podia surgir com parâmetros inadequados. O circuito podia transportar dados em uma direção e falhar no retorno. O host podia responder na camada IP enquanto o serviço de aplicação estava parado.

Cada resultado pertencia a um componente e a um instante diferentes.

O caminho roteado preservava continuidade

Enquanto esperava uma resposta, a origem podia descartar, reter ou encaminhar o pacote pelo caminho normal. A RFC 2332 recomendava o encaminhamento roteado como padrão, pois os dados ainda poderiam chegar durante a resolução.

Da mesma forma, um roteador sem NHRP podia descartar silenciosamente a solicitação. O atalho não era criado, mas a comunicação salto a salto podia continuar.

Esse comportamento separava otimização de serviço básico.

Falha no NHRP não implicava falha da aplicação. Estado NHRP saudável também não implicava sucesso da aplicação. A observabilidade precisava manter as duas dimensões.