Resumo

  • O multicast Receiver RLOC expressa o grupo em que o ETR deseja receber o fluxo; RFC 9798 permite seu uso apenas quando o underlay do núcleo LISP suporta multicast e deixa a escolha do grupo como decisão local do ETR.
  • Para cada mapeamento multicast de underlay único, o ITR raiz cria uma entrada OIF. Para rastrear quais ETRs enviaram joins, usa a origem IP do Join/Prune, que deve ser um RLOC de ETR.
  • Autenticação do pedido não demonstra alocação do grupo, suporte do caminho, presença de membros ou entrega de pacotes.

Um endereço de grupo não responde “quem?”

Quando Transport vale zero e o Receiver RLOC contém um endereço multicast, o ETR está solicitando transporte multicast por um grupo específico. O valor não codifica uma coleção de ETRs. RFC 9798 separa explicitamente o rastreamento: se o ITR precisa manter a lista de ETRs dos quais recebeu joins, deve consultar o endereço origem do PIM Join/Prune, e esse endereço deve ser um ETR RLOC.

Há, portanto, pelo menos três perguntas. Qual grupo foi solicitado? Qual ETR originou o controle? Que receptores observaram dados? A primeira vem do atributo, a segunda do cabeçalho e de sua validação, e a terceira do plano de dados no lado receptor. Somá-las em um único campo “receiver” destrói a trilha de auditoria.

RFC 9798 foi publicado em junho de 2025 como Experimental e atualiza RFC 8059. Ele não altera a sintaxe ou a semântica do Transport Attribute e restringe a mudança ao valor zero, multicast. A definição de Receiver RLOC passa a abranger endereço unicast para fluxo encapsulado unicast ou endereço multicast para fluxo encapsulado multicast. O uso multicast só é permitido quando o underlay do núcleo LISP oferece esse transporte.

O requisito não é uma atestação. Depois de decidir pelo underlay multicast, o ETR escolhe um grupo ao qual consegue ingressar, determina o site LISP a montante onde a árvore deve ter raiz e monta o Join/Prune conforme RFC 8059. A escolha é local e fica fora do escopo do documento. Operadores precisam guardar a política de faixa, o teste de capacidade e a configuração que justificaram a decisão.

A cardinalidade transfere estado e replicação

RFC 6831 descreve o estado (S-EID,G) dentro dos sites e o estado (S-RLOC,G) no núcleo. O ITR encapsula o tráfego e o underlay pode replicá-lo antes de o ETR receptor desencapsular e conferir o estado interno.

RFC 9798 admite três arranjos: vários fluxos overlay em um único fluxo underlay; um fluxo overlay em vários fluxos underlay; e correspondência um a um. No many-to-one, menos árvores do núcleo atendem mais fontes, porém RFC 6831 mostra que um site pode receber tráfego de uma fonte que não solicitou e descartá-lo somente depois da desencapsulação. No one-to-many, faixas distintas de xTRs podem ser respeitadas, mas a raiz faz mais cópias. Um a um aumenta a separação e o consumo de estado.

A unidade de responsabilidade do ITR é cada mapeamento único. Ele aloca uma nova entrada na lista de interfaces de saída e pode impor política local de limitação sobre a quantidade de cópias. O RFC não define a cota. Um recibo de capacidade deve conter a chave do mapeamento, a OIF, cópias pedidas e admitidas e a razão da limitação.

As faixas importam em fronteiras PxTR: as interfaces voltadas ao site podem usar grupos diferentes dos usados no núcleo LISP externo. Restrições de hardware também podem reduzir a janela de endereços multicast. A validade operacional de um grupo depende da fronteira, da plataforma e da versão de política, e não apenas de sua forma.

Suporte presumido não é descoberta de capacidade

RFC 5384 fornece o envelope de PIM Join Attributes e observa que atributos capazes de alterar a árvore exigem um domínio cooperante onde se saiba previamente que os roteadores entendem a codificação. No PIM comum, uma opção Hello evita o envio a vizinhos incompatíveis.

RFC 8059 informa que xTRs LISP não trocam PIM Hellos. Não existe opção Hello para negociar esses atributos; sistemas que suportam replicação unicast na origem são presumidos compatíveis. Transport e Receiver RLOC são não transitivos. RFC 9798 leva o mecanismo ao underlay multicast sem criar descoberta universal de capacidade nem autoridade global de grupos.

Isso deixa uma sequência clara de provas. Bytes aceitos mostram o sinal. Política de faixa mostra intenção. Entrada OIF mostra estado de controle. Estado multicast e contadores mostram execução. Desencapsulação e observação da aplicação mostram resultado. O padrão define a ligação entre algumas etapas, não autoriza substituir uma pela outra.

Autenticar reduz uma dúvida, não todas

RFC 8059 afirma que os atributos herdam a segurança do pacote PIM. RFC 9798 considera joins numerosos com grupos diferentes ou sobrepostos, capazes de interferir no tráfego e consumir recursos de replicação. O texto diz que mecanismos de RFC 5796 poderiam validar pedidos e sugere rastreamento ou limites de grupos por RLOC origem.

RFC 5796 trata de proteção IPsec de mensagens PIM-SM locais ao enlace. Com associações de segurança e chaves corretamente operadas, há evidência de origem e integridade. Não há prova automática de que o emissor controla o grupo, de que o caminho inteiro suporta multicast ou de que dados chegaram.

Por isso, o registro final deve correlacionar Join/Prune bruto, atributos analisados, autenticação e associação de segurança, RLOC origem, decisão do ETR, raiz, cardinalidade, OIF, limitação, estado do núcleo, contadores, desencapsulação e recepção. Um estado único “válido” é insuficiente.

Fontes