Resumo

  • O RFC 2370 colocou dados específicos de aplicações em LSAs opacas dos tipos 9, 10 e 11, com escopos de inundação limitados ao enlace, à área e ao sistema autônomo.
  • O bit O, a confirmação de retransmissão e a entrada na LSDB comprovavam capacidade e transporte no protocolo, mas não interpretação, atualidade, cálculo de caminho, instalação de encaminhamento ou entrega real.

Uma extensão de protocolo costuma tentar fazer duas coisas ao mesmo tempo: definir os bytes e declarar o que esses bytes significam. O RFC 2370 escolheu uma arquitetura mais disciplinada. Ele deu ao OSPF um recipiente padronizado para transportar um corpo que o próprio mecanismo de inundação não precisava entender.

“Opaco” não queria dizer sigiloso ou criptografado. A LSA mantinha idade, opções, tipo, Link State ID, roteador anunciante, número de sequência, checksum e comprimento. Depois vinha informação específica da aplicação, alinhada em 32 bits. O OSPF conhecia a identidade e o ciclo de vida do envelope; outro software conhecia a linguagem do conteúdo.

Essa separação preservava uma camada comum estreita. OSPF oferecia identidade, alcance, distribuição, retransmissão, confirmação, envelhecimento e armazenamento. A especificação da extensão e a implementação local decidiam como analisar o corpo, quem tinha autoridade para produzi-lo e se ele deveria causar alguma mudança operacional.

O número do tipo delimitava onde o custo podia chegar

Uma LSA opaca de tipo 9 tinha escopo local ao enlace. A implementação precisava associá-la à interface correta e impedir que saísse por outra. O tipo 10 permanecia na área OSPF em que havia sido originado ou recebido. O tipo 11 alcançava o AS, seguindo restrições semelhantes às LSAs externas, sem atravessar para áreas stub.

O escopo, portanto, não era um rótulo descritivo. Era uma regra executável. Um objeto com checksum correto continuava proibido fora do seu limite. Um tipo 11 recebido dentro de uma área stub violava o contrato de distribuição e precisava ser descartado. Remetente e receptor dividiam a responsabilidade de não transformar uma afirmação local em uma afirmação global.

O Link State ID também separava funções. Os oito bits superiores formavam o Opaque Type; os outros 24 identificavam uma instância dentro daquela família. A combinação permitia despachar extensões. Ela não certificava a verdade do corpo, a competência material do anunciante nem o resultado de qualquer ação.

O bit O descrevia o carregador, não todos os leitores

No início da troca de banco de dados, um roteador anunciava capacidade opaca com o bit O em pacotes Database Description. Vizinhos capazes recebiam LSAs opacas na lista de resumo e nas listas de retransmissão; vizinhos não capazes não as recebiam por esse caminho. Um multicast ainda podia ser ouvido por um equipamento incapaz, que descartava o tipo desconhecido.

Esse sinal respondia a uma pergunta limitada: o vizinho aceita receber e encaminhar o mecanismo opaco? Ele não declarava quais Opaque Types tinham consumidores locais. Um roteador podia transportar corretamente uma extensão que não interpretava. Uma aplicação instalada podia, ao mesmo tempo, enxergar uma topologia incompleta porque uma fronteira de capacidade interrompeu parte da inundação.

Por isso, sincronização da LSDB e convergência da aplicação exigiam registros distintos. No nível do OSPF, uma LSA válida e dentro do escopo era armazenada e confirmada. No nível da aplicação, o consumidor selecionava o tipo, analisava o corpo, avaliava origem e atualidade, reconciliava outros estados e aplicava política. Uma linha na LSDB era o recibo do transportador, não o recibo do intérprete.

Uma sequência nova podia carregar um fato antigo

As LSAs opacas herdaram sequência, checksum, LS age, MaxAge, MinLSInterval, MinLSArrival, retransmissão e confirmação. Cada mecanismo resolvia um problema real, mas nenhum deles certificava o conjunto inteiro. O checksum protegia bytes, não semântica. A sequência ordenava instâncias, não datava a medição original. A confirmação provava recepção pelo vizinho, não uso posterior.

O caso mais claro apareceu no tipo 11. O RFC 5250 substituiu o RFC 2370 em 2008 porque roteadores fora da área do originador podiam continuar usando por até cerca de uma hora informações de um originador que já havia saído de serviço. A revisão reutilizou a alcançabilidade de ASBR: o emissor de informação opaca de escopo AS precisava tornar sua presença rastreável, e o receptor devia parar de usar suas LSAs quando ele se tornasse inalcançável.

O mecanismo original podia obedecer às regras de inundação e idade enquanto a aplicação ainda consumia um fato obsoleto. Maior alcance não produzia maior verdade. A existência atual de quem fez a afirmação precisava ser outro elemento da decisão.

A engenharia de tráfego mostrou a utilidade e o limite

O RFC 3630 usou LSAs opacas de tipo 10 para atributos de engenharia de tráfego. Roteadores sem lógica TE podiam continuar inundando o objeto opaco, enquanto consumidores capazes montavam uma base de dados TE. Essa reutilização evitava criar um protocolo de distribuição para cada nova aplicação.

Mas receber a LSA não executava a engenharia de tráfego. Uma alteração atualizava a base TE sem exigir um cálculo SPF normal. A instanciação do caminho permanecia separada, e participação parcial podia deixar buracos na topologia estendida. LSA sincronizada, visão completa, caminho calculado, estado instalado e tráfego observado eram cinco evidências diferentes.

O RFC 7684 mais tarde reutilizou o canal para atributos estendidos de prefixo e enlace. O registro atual da IANA preserva os tipos 9, 10 e 11 e os espaços derivados. Ele comprova que os identificadores foram atribuídos, não que uma rede específica os implantou ou obteve resultado.

Autenticação também não fechava a cadeia. OSPF podia autenticar a troca, e o RFC 5709 acrescentou HMAC-SHA. Isso ajudava a identificar um participante de protocolo sob uma chave configurada. A aplicação ainda precisava decidir se aquele participante tinha autoridade para a afirmação, se o conteúdo era coerente e atual e se a política autorizava agir. Muitas LSAs distintas ainda podiam consumir memória e processamento mesmo em uma sessão autenticada.

A arquitetura corresponde à primazia do código em execução e à especificação inicial mínima de Heng Lu. A camada comum define somente o que precisa ser compartilhado para interoperar. Extensões posteriores tornam-se reais por implementação, adoção e observação. Publicar um formato cria uma possibilidade; não cria uma rota nem um resultado.

Fontes