Resumo

  • O controle RREQ vai da origem ao alvo, mas a rota descoberta carrega dados do alvo para a origem; o RREP volta e produz a rota de dados no outro sentido.
  • DODAGID, InstanceIDs locais e Delta mantêm uma descoberta coerente sem atestar presença atual no forwarding plane.
  • Um resultado bidirecional exige recibos separados de cada rota, observação de pacotes nos dois sentidos e uma solicitação/resposta correlacionada.

A volta pode precisar de outros retransmissores

Rádio é uma relação direcional. Potência, interferência, taxa e agenda podem permitir A ouvir B sem que B tenha a mesma qualidade para falar com A. O RFC 9854 incorpora essa realidade ao AODV-RPL: quando OrigNode precisa enviar e as rotas existentes não atendem à aplicação, inicia-se descoberta reativa.

A RREQ-Instance nasce com raiz em OrigNode; seus RREQ-DIO avançam ao TargNode. Porém o estado aponta para a raiz e serve aos dados TargNode → OrigNode. O RREP-DIO percorre o sentido inverso e, quando há assimetria, forma outra DODAG com raiz no TargNode para dados OrigNode → TargNode. A direção da mensagem de controle não é a direção da entrega que ela prepara.

O bit S começa em um e só continua assim quando o sentido oposto de cada enlace também satisfaz a Objective Function. Com S=1 no alvo, RREP pode voltar por unicast e a DODAG RREP não precisa ser formada. Com S=0, o alvo cria RREP-Instance e envia multicast; outros pais e outros nós podem formar o caminho. O critério de simetria não é fixado pelo RFC: ETX/RSSI é exemplo, não obrigação. S descreve uma avaliação, não uma medição eterna.

O que Delta realmente garante

RPLInstanceID é local. Descobertas concorrentes podem usar OFs distintas e origens diferentes podem escolher o mesmo número. A identidade RREQ junta valor e endereço de OrigNode; a identidade RREP junta valor e endereço de TargNode.

Se o valor esperado para RREP já pertence a uma instância ativa com o mesmo DODAGID, o alvo escolhe outro. O Delta de seis bits informa o incremento aplicado ao valor RREQ, com retorno a zero depois de 255. O receptor subtrai Delta para registrar a referência RREQ na rota ao alvo. Isso evita casar resposta com pedido ou OF errados.

Mas pareamento é disciplina de identidade. Não mostra que todos os nós instalaram a rota, que ambos os lados continuam dentro da validade, que pertencem ao mesmo instante ou que algum pacote os utilizou.

Três dimensões, três registros

Rank não é custo fim a fim. O RFC 6550 o define como posição relativa em uma versão da DODAG e adverte que ele não é necessariamente distância ou custo até a raiz; RFC 9854 repete esse limite. O RFC 6551 trata métricas e restrições separadamente. Um Rank menor não comprova latência, perda ou consumo melhores.

Orig SeqNo e Dest SeqNo ordenam gerações das rotas. Uma entrada velha para a mesma origem, destino e instância deve ser removida. Essa freshness lógica não é recibo de hardware ou de link.

O campo L governa a permanência na instância temporária. A vida da rota é independente, vem da configuração DODAG e pode ser estendida pelo uso. “Instância viva”, “entrada não expirada” e “pacote recente” não compartilham automaticamente o mesmo relógio.

Hop-by-hop e source routing

Com H=1, cada roteador constrói entrada com origem, instância, destino, next hop, lifetime e sequence. No sentido ao alvo, um caso assimétrico usa o preferred parent da RREP DODAG. A prova precisa identificar nó e direção.

Com H=0, Address Vector leva o caminho. Em RREP assimétrico, ele registra a segunda propagação; em caso simétrico, retorna o vetor RREQ sem alteração. Detectar endereço repetido reduz loop, mas o vetor não confirma a disponibilidade atual de cada interface.

Ao receber RREP, OrigNode pode começar a transmitir dados. Essa permissão não é uma confirmação. Ainda faltam instalação efetiva, pacote entregue, processamento no alvo, resposta criada e retorno antes do prazo.

Cinco recibos

O primeiro congela identidade, endpoints, DODAGIDs, InstanceIDs, Delta, OF, H/S, sequências, relógios e observador. O segundo comprova TargNode → OrigNode; o terceiro, OrigNode → TargNode, cada qual por entradas ou vetor.

O quarto observa pacotes com janela, denominador, resets e contexto. Um sentido não comprova o outro; dois testes em horários diferentes não comprovam coexistência. O quinto é da aplicação: request ID, aceitação pelo alvo, geração de resposta e recebimento pela origem dentro de um limite.

O framework opcional de segurança RPL e o RFC 7416 não eliminam esse limite. Um roteador malicioso com a chave ainda pode anunciar estado falso; vetor ou G-RREP forjado pode causar loop ou negação de serviço. Autenticação não é resultado de aplicação.

O registro IANA RPL conserva MOP 4 e os códigos RREQ/RREP/ART. A página RFC Editor e o Datatracker estabelecem status e história; a consulta de errata não encontrou registro correspondente na revisão. Nada disso mede implantação.

A Running-Code Primacy de Heng Lu exige fatos do sistema em execução. A Minimum Initial Specification e adoção voluntária mantém o comum estreito e verificável. As camadas de realidade separam a ordem simbólica do par da execução efetiva do percurso.

Fontes