Resumo

  • Uma HNA associa um gateway OLSR a um endereço de rede, máscara e prazo de validade. O recebimento comprova a chegada de uma declaração; não cria o direito de originar o prefixo nem confirma o estado do domínio externo.
  • A importação responsável exige identidade, autorização por escopo, frescor, política de retirada, rota instalada, observação do pacote e confirmação da aplicação. A cobertura MPR só sustenta uma parte da distribuição do controle.

Uma declaração externa ganhou um próximo salto

Um nó possui uma interface dentro da MANET e outra ligada a uma rede externa. Ele emite uma Host and Network Association com um par de endereço e máscara. Outros nós aceitam a mensagem, registram uma associação com prazo e podem criar uma rota apontando para aquele gateway.

O mecanismo resolve uma necessidade real: sem ele, a rede ad hoc não saberia como alcançar destinos fora do próprio domínio. Mas a facilidade de criar a rota também revela uma fronteira de autoridade. O protocolo sabe dizer quem originou a HNA, qual prefixo foi escrito e até quando a tupla permanece. Ele não sabe, apenas a partir desses campos, se o emissor foi autorizado a falar pelo prefixo.

RFC 3626 foi publicado em outubro de 2003 como protocolo Experimental para redes móveis ad hoc; não é um padrão da Internet. Ele define o Optimized Link State Routing Protocol, uma abordagem proativa que reduz a difusão de controle por meio de multipoint relays. Essa condição histórica importa: o texto descreve regras de protocolo, não uma implantação atual, uma validação universal de origem ou um resultado medido.

Na distinção de Heng Lu, o registro pode ser fiel sem ser autor da realidade. A HNA pode registrar com exatidão a afirmação do gateway. A legitimidade da afirmação precisa vir de um principal que o registro não inventa.

HELLO estabelece o alcance local da confiança

Antes de uma HNA viajar, o OLSR forma sua base local com HELLO. A mensagem é transmitida na interface e nunca encaminhada. Ela sustenta detecção de links, vizinhança de um e dois saltos, willingness e sinalização de quem foi escolhido como MPR.

Um link simétrico é um estado produzido por mensagens aceitas e limitado por tempo. O nó mantém a tupla até o vencimento ou uma mudança posterior. A margem é deliberada: o tempo de retenção deve exceder o intervalo de atualização para tolerar perdas comuns.

Essa estabilidade tem preço. A condição física pode mudar antes da expiração. Portanto, “vizinho simétrico válido” quer dizer válido sob o contrato temporal do protocolo, e não observado continuamente no ar.

O comprovante deve guardar interface, origem do HELLO, instante de recepção, validade e idade. Quando uma rota HNA depende desse vizinho, a dependência temporal precisa permanecer visível. Caso contrário, uma afirmação externa parece atual mesmo quando a cadeia local que a sustenta está envelhecendo.

O MPR cobre dois saltos, não o domínio externo

Cada nó escolhe MPRs entre vizinhos simétricos de um salto. A união das vizinhanças desses relays deve cobrir todos os vizinhos estritos e simétricos de dois saltos. Quanto menor o conjunto, menor tende a ser a sobrecarga. MPR_COVERAGE pode buscar redundância adicional.

Essa é uma propriedade do grafo local relatado. Não prova independência física, largura de banda ou encaminhamento unicast. Dois relays podem compartilhar interferência, energia ou falha de software. Mais cobertura cria mais oportunidades descritas, não mais recibos de entrega.

O próprio RFC explicita uma ruptura crítica: um nó pode encaminhar corretamente mensagens de controle em broadcast e ainda assim não encaminhar tráfego de dados unicast. Logo, nem a participação como MPR nem a propagação de uma HNA certificam o caminho que os pacotes usarão.

A autoridade do MPR deve ser formulada de modo estreito: retransmitir controles selecionados segundo uma visão local. A autoridade de importar prefixo e a prova de entregar tráfego ficam em outros controles.

HNA e TC envelhecem de formas diferentes

As mensagens TC divulgam pelo menos os links aos nós que selecionaram o emissor como MPR. O Advertised Neighbor Sequence Number ajuda a ordenar mudanças no conjunto anunciado. Uma retirada incrementa o ANSN e pode cancelar a visão anterior.

A HNA funciona de outro modo. Cada associação contém gateway, rede, máscara e tempo de expiração. A informação some quando vence; não existe o mesmo efeito de cancelamento do ANSN de TC. Isso aumenta a importância do prazo e da retirada operacional.

Se um anúncio externo deixa de ser verdadeiro logo após a emissão, receptores podem continuar utilizando-o até a expiração. Reduzir a validade diminui essa janela, mas aumenta sensibilidade a perdas. A decisão é um compromisso explícito, não um detalhe escondido.

Uma implantação séria registra o início e o fim esperados, as atualizações recebidas, os nós que aceitaram a associação e todas as rotas dependentes. Uma retirada urgente precisa de mecanismo operacional além da espera passiva pelo prazo.

Autenticar o gateway não valida a origem

RFC 3626 não especifica medidas especiais de segurança. Ele recomenda autenticação porque nós defeituosos ou maliciosos podem inventar HELLO, TC ou HNA, fingir outra origem, alterar mensagens, deixar de retransmitir ou reproduzir controles antigos.

O texto separa a autenticidade da mensagem inteira da autenticidade de cada link anunciado. A mesma separação vale para o prefixo. Uma assinatura válida pode provar qual credencial protegeu os bytes. Ela não prova que o titular dessa credencial recebeu autoridade sobre a rede externa.

Também não resolve frescor sozinha. Uma HNA antiga e corretamente autenticada pode ser repetida. São necessários dados temporais e uma política que reconheça o replay. E mesmo uma HNA autêntica, autorizada e fresca não comprova que o enlace fora da MANET está funcionando naquele instante.

O controle deve responder a quatro perguntas separadas: quem falou, tinha direito de falar por este escopo, quando a afirmação ainda era válida e o caminho observado entregou tráfego? Misturá-las transforma identidade em soberania técnica.

O conjunto de duplicados não é confirmação coletiva

Para reduzir repetições, o OLSR mantém um duplicate set com origem e sequência da mensagem. Uma correspondência mostra que aquele nó já registrou a mesma identidade durante a vida da entrada e pode evitar trabalho repetido.

Não mostra que todos os receptores necessários viram a HNA ou o TC. Uma ramificação pode ter recebido, outra pode ter perdido. Um nó pode processar e não retransmitir conforme a relação de seletor, interface e estado de duplicação.

Contadores de duplicados indicam sobreposição local, não fechamento da difusão. O monitoramento precisa correlacionar recepção, decisão de retransmitir e recepção a jusante em pontos representativos. A ausência de duplicado também exige contexto: mensagem nova, perda ou expiração.

Otimizar é eliminar transmissões que o modelo considera dispensáveis. Auditar é verificar se as restantes chegaram onde precisavam.

TC produz uma topologia derivada

Os nós selecionados como MPR emitem TC. Receptores mantêm tuplas por uma validade e calculam rotas a partir da topologia aceita e da vizinhança local. O ANSN ordena versões, inclusive na volta do contador.

Uma versão mais recente só é mais recente em relação a outra. Ela pode envelhecer enquanto viaja. Além disso, limites de tamanho permitem repartir um conjunto anunciado em vários TC; um pacote isolado não é necessariamente o inventário completo.

O recibo de topologia deve unir origem, ANSN, fragmentos, interfaces de recepção, validade e decisão de aceitação. Depois deve ligar essa versão ao cálculo de rota. Sem o vínculo, a equipe vê uma tabela mas não consegue reconstruir quais afirmações a produziram.

OLSRv2 mais tarde separou flooding MPRs e routing MPRs. A comparação é esclarecedora: levar controle adiante e selecionar material para rotas são funções distintas. Nenhuma delas observa o resultado da aplicação.

A tabela do sistema é uma instrução intermediária

RFC 3626 afirma expressamente que OLSR não encaminha pacotes de dados. Ele mantém a tabela do sistema operacional, que se presume responsável pelo encaminhamento.

O cálculo pode ser coerente e a gravação no kernel falhar. A rota pode existir e a resolução do próximo salto falhar. O vizinho pode tratar broadcasts e descartar unicast. O host pode receber e a aplicação não responder.

Uma prova completa preserva a versão topológica, o resultado do cálculo, a transação no kernel, a entrada ativa, a resolução do vizinho, os contadores de interface, a observação de pacote na entrada e saída, perda, duplicação, ordem e latência. A aplicação oferece o recibo final.

Para uma HNA, é preciso testar também a passagem pela borda externa. Um ping dentro da MANET não prova o prefixo importado, e a presença da rota não prova retorno.

A ordem correta pode continuar velha

Números de sequência impedem que informações fora de ordem substituam registros mais novos e tratam a volta do valor máximo para zero. Eles resolvem ordenação, não atualidade física.

O painel deveria mostrar idade do último HELLO, TC e HNA, prazo restante, atualizações perdidas e rotas dependentes. Sem isso, há incentivo para alongar retenções e produzir estabilidade visual, ao custo de agir por mais tempo sobre informação obsoleta.

O objetivo não é escolher entre estabilidade e frescor em abstrato. É tornar a escolha explícita e medir o impacto no serviço.

A fronteira precisa de um principal nomeado

Uma política de importação HNA deve dizer quais identidades podem anunciar quais prefixos, por quais interfaces, durante quanto tempo e com qual evidência externa. Deve definir sobreposição, preferência, revogação, quarentena e rollback.

Essa política não deve nascer de mera participação no protocolo. Ser vizinho, MPR ou gateway funcional não concede automaticamente mandato sobre um ativo de numeração ou um domínio externo. O principal precisa existir fora do pacote e ser verificável.

O segundo efeito de uma política fraca é o bloqueio. Outros serviços passam a depender da rota e a retirada fica cara. O terceiro é a normalização: um anúncio aceito muitas vezes passa a ser tratado como direito permanente. Preservar autorização e prazo impede que hábito vire autoridade.

Propagação é só o começo da prova

O OLSR oferece uma cadeia elegante: HELLO forma vizinhança, MPR reduz difusão, TC distribui topologia, HNA injeta redes externas e o cálculo produz rotas. Cada elo tem valor operacional.

Cada elo também responde a uma pergunta menor. A HNA recebida prova a declaração. A autorização prova o direito. A rota ativa prova a instrução. O pacote prova o caminho percorrido. A aplicação prova o serviço.

Quando essas respostas ficam separadas, a automação pode ser rápida sem fingir certeza. O prefixo pode entrar pela HNA. A autoridade e o resultado precisam entrar por suas próprias portas.

Fontes