Resumo

  • Um L2-LinkStatusChanged.indication pode refletir uma medição real e ainda produzir a ação errada: a RFC 5184 registra handovers de pingue-pongue e diz que limiares e abstrações de qualidade dependem da implementação.
  • O controle seguro separa observação, decisão, L2-LinkConnect.confirm(Ack), conclusão do enlace, convergência IP e tráfego verificado; ele também conserva tempo e autoridade para cancelar o movimento.

O sinal caiu abaixo do limiar e o controlador mudou para o segundo ponto de acesso. Antes de o estado IP se estabilizar, a média móvel voltou a favorecer o primeiro. O segundo comando também recebeu Ack. Duas solicitações foram aceitas, duas máquinas de estado fizeram exatamente o que lhes foi pedido e a sessão perdeu mais tráfego do que perderia se tivesse permanecido onde estava.

O incidente não nasceu de uma falha binária do rádio. Nasceu da promoção de um indicador local a ordem irreversível. A RFC 5184 dá nomes diferentes à observação, ao pedido, à confirmação e ao evento posterior. Ao preservar essa ordem, ela oferece a disciplina que um painel com um único estado verde não consegue expressar.

A gramática não transforma uma estimativa em autoridade

A RFC 5184 é Experimental e registra o consenso do grupo de pesquisa MobOpts; não é um Padrão da Internet da IETF. Ela define nove primitivas para que a camada 3 consulte a camada 2, registre interesse em eventos e solicite ações. Request pede informação ou serviço. Confirm responde ao pedido. Indication relata um evento assíncrono. Response pode acusar o recebimento da indicação.

As primitivas de Tipo 1 consultam o presente. L2-LinkStatus devolve interface, ponto de conexão e Condition; L2-PoAList enumera candidatos. As de Tipo 2 registram eventos como PoAFound, PoALost, LinkUp, LinkDown e LinkStatusChanged. As de Tipo 3, LinkConnect e LinkDisconnect, solicitam ação e devolvem imediatamente Ack ou Nack em Confirm.

Essa separação tem consequência operacional. Um evento de qualidade não toma a decisão. Um Request não comprova a execução. Um Ack informa que a operação pode começar, não que terminou. O LinkUp posterior tem significado definido pela tecnologia do enlace. A convergência IP e a primeira troca de dados bem-sucedida vêm depois.

“EXCELLENT” não é uma unidade portátil

Condition comprime largura de banda e qualidade de enlace em EXCELLENT, GOOD, FAIR, BAD ou NONE. O algoritmo depende do hardware e do software. A própria RFC alerta que os níveis de um dispositivo são independentes dos de outros dispositivos, que decisões baseadas neles estão sujeitas a erro e que não há garantia de escolha do enlace ótimo.

Um limiar pode ser adequado a uma antena, janela de média e ambiente, mas instável em outro conjunto. Histerese insuficiente, amostras esparsas ou atraso de varredura mudam o ponto em que a indicação aparece. O momento das Indications está fora do escopo da especificação e depende do mecanismo de busca e da implementação.

Por isso, o registro de auditoria não pode guardar apenas “GOOD caiu para FAIR”. Deve conservar a métrica bruta, a unidade, a janela de cálculo, o limiar e sua versão, a interface, o driver, o ponto de conexão e o relógio monotônico. Sem isso, uma palavra humana legível esconde a diferença entre deterioração persistente e ruído em torno de uma fronteira administrativa.

O pingue-pongue é um problema de controle, não de vocabulário

Os experimentos da RFC observaram pingue-pongue entre pontos de acesso. O texto reconhece que limiares variam conforme a implantação e que configuração inadequada pode gerar indicações enganosas. Também diz que L2-LinkStatusChanged às vezes não é confiável porque a abstração da qualidade é difícil; uma indicação inválida pode causar um handover redundante.

A saída prevista é reavaliar. A camada IP pode consultar de novo L2-LinkStatus e cancelar o handover se o ponto atual continuar sendo o mais adequado. A RFC 4907 formula o princípio de modo ainda mais direto: uma indicação de enlace deve ser tratada como indício consultivo, validado antes de comandar uma consequência.

O amortecimento precisa ser explícito. Pode incluir histerese, permanência mínima, concordância entre amostras, custo de troca, limite de frequência e um prazo após o qual a observação envelhece. Nenhum desses mecanismos torna o sinal universalmente verdadeiro. Eles apenas impedem que uma fronteira ruidosa receba autoridade ilimitada.

Aceitar o comando ainda não conclui a troca

No Tipo 3, o Confirm retorna imediatamente. Para L2-LinkConnect, a operação de conexão começa depois de Ack. Para L2-LinkDisconnect, a desconexão também começa depois do aceite. Portanto, liberar o enlace anterior nesse instante é transformar o início de um trabalho em ponto de commit.

O exemplo da RFC mantém os passos separados: após Confirm, a camada 2 começa o handover; quando ele termina, envia L2-LinkUp.indication; só então a camada 3 executa sua parte. Em IEEE 802.11, o exemplo associa LinkUp ao estabelecimento da associação com o AP. Isso ainda não prova configuração de endereço, rota, binding ou continuidade de aplicação.

A RFC 4907 adverte que LinkUp não garante condições simétricas, perda baixa ou configuração IP. A RFC 4957 mostra outra variante: portadora Ethernet pode existir antes de uma ponte terminar o estado de forwarding. Um evento verdadeiro na camada correta pode ser insuficiente para a afirmação feita pelo painel.

Um candidato falso também pode gerar uma indicação válida

A seção de segurança descreve beacons forjados que fazem surgir L2-PoAFound.indication. O nó pode então pedir associação com um ponto malicioso. Variações artificiais entre RSSI forte e fraco podem alternar PoAFound e PoALost, criando negação de serviço.

A primitiva não precisa estar corrompida para o fluxo ser perigoso: ela relata o que a implementação local observou. Proveniência, autenticação e autorização pertencem à política que decide o passo seguinte. Uma lista de candidatos é evidência de descoberta, não um rol de destinos aprovados.

O mesmo mecanismo de amortecimento que reduz pingue-pongue acidental ajuda contra oscilação induzida, mas não substitui autenticação. O controlador precisa vincular cada candidato à origem da descoberta, ao estado do driver, às credenciais do enlace e à política local antes de conceder autoridade ao Request.

O placar operacional deve conservar a ordem parcial

Um modelo útil exibe pelo menos: observação recebida; observação validada ou contestada; decisão tomada; Request enviado; Confirm Ack, Nack ou erro; operação de enlace em andamento; LinkUp ou LinkDown; autenticação concluída; IP pronto; tráfego bidirecional verificado; ou recuperação em curso.

O objeto de evidência deve reter identificador imutável da operação, interface e tecnologia, versão do código, medições e limiares, sequência da indicação, decisão e justificativa, pedido exato, significado limitado do Confirm, eventos de início e fim, estado de associação, endereço e rota, perda e latência, cancelamentos e rollback.

Isso aplica as camadas de realidade de Heng Lu: a palavra que resume uma medição, o aceite de um comando, o estado executado e o resultado para o usuário não são a mesma coisa. O código em execução e os recibos posteriores têm precedência sobre a etiqueta.

O handover rápido não exige apagar essas fronteiras. Pelo contrário: preparação paralela e decisão local ficam mais seguras quando cada passo informa apenas o que sabe. A lentidão evitável vem de esperar em série; a falsa certeza vem de chamar o primeiro Ack de conclusão.

Fontes

  1. RFC 5184 — HTML
  2. RFC 5184 — texto simples
  3. Página informativa do RFC Editor
  4. Página do documento no IETF Datatracker
  5. Histórico no IETF Datatracker
  6. Referências no IETF Datatracker
  7. Errata da RFC 5184
  8. RFC 4907 — implicações arquiteturais de indicações de enlace
  9. Página informativa da RFC 4907
  10. RFC 4957 — notificações de eventos da camada de enlace
  11. RFC 5568 — handovers rápidos no Mobile IPv6
  12. Página informativa da RFC 5568
  13. RFC 5944 — mobilidade IP para IPv4
  14. RFC 6275 — mobilidade em IPv6
  15. RFC 4140 — Mobile IPv6 hierárquico
  16. RFC 3819 — recomendações para projetistas de sub-redes
  17. RFC 4968 — análise de modelos de enlace IPv6
  18. Heng Lu — camadas de realidade
  19. Heng Lu — especificação mínima e adoção voluntária
  20. Heng Lu — o código em execução é primário