Resumo

  • No RFC 2117, um receptor aparecia primeiro no roteador de último salto por meio do IGMP; só então o PIM-SM estendia uma árvore compartilhada (*,G) em direção ao Rendezvous Point (RP).
  • O envio de Join/Prune não gerava recibo: o estado era flexível, expirava e precisava ser renovado periodicamente.
  • Fontes se apresentavam ao RP com Register; o RP podia responder com Register-Stop, criar estado (S,G) e permitir que o tráfego migrasse para uma árvore de caminho mais curto indicada pelo bit SPT.
  • A especificação separava sinais observáveis de entrega comprovada. Uma entrada na tabela demonstrava estado recente, não uma confirmação fim a fim.

A árvore começava na borda, não no núcleo

O RFC 2117, publicado como Experimental em junho de 1997, descrevia o Protocol Independent Multicast—Sparse Mode (PIM-SM) para domínios em que os membros de um grupo estavam dispersos. “Protocol independent” não significava ausência de dependências: o PIM usava a tabela de roteamento unicast para decidir a direção de retorno, mas não exigia um protocolo unicast específico.

O primeiro fato operacional vinha do IGMP. Um host declarava interesse em um grupo ao roteador local. Esse roteador de último salto então enviava um PIM Join em direção ao RP do grupo. Cada salto criava estado (*,G): qualquer fonte, grupo G. O resultado era uma árvore compartilhada centrada no RP, construída apenas onde havia demanda conhecida.

Esse encadeamento define uma fronteira de evidência. O relatório IGMP dizia que havia interesse local. O estado (*,G) dizia que um roteador havia aceitado e mantido uma direção de encaminhamento. Nenhum dos dois dizia que cada pacote futuro chegaria a um receptor.

A fonte entrava por outro caminho

Quando uma fonte começava a transmitir, seu roteador designado encapsulava os primeiros pacotes em mensagens Register dirigidas ao RP. O RP podia desencapsular e encaminhar o tráfego pela árvore compartilhada. Ao mesmo tempo, podia iniciar um Join em direção à fonte e formar estado específico (S,G).

Depois de receber tráfego nativo pela nova direção, o RP enviava Register-Stop ao roteador da fonte. Esse sinal não era uma confirmação de entrega ao público; era uma instrução para parar o encapsulamento redundante. O RFC também descrevia a transição de um roteador receptor para uma árvore de caminho mais curto. O bit SPT marcava que o encaminhamento daquela entrada já seguia a árvore específica da fonte.

Assim, (*,G), Register, Register-Stop, (S,G) e SPT não eram etapas de uma única transação confirmada. Eram estados e sinais distintos, mantidos por equipamentos diferentes e com significados probatórios diferentes.

Join/Prune não prometia permanência

O ponto mais instrutivo do RFC 2117 é que mensagens Join/Prune não tinham confirmação. Perda de uma mensagem não acionava uma resposta positiva que fechasse a operação. Em vez disso, o protocolo dependia de renovação periódica. Temporizadores removiam estado que não fosse reafirmado; novas mensagens reconstruíam ou prolongavam o que ainda era necessário.

Isso tornava a árvore resiliente a falhas transitórias sem criar um livro-razão de recibos. Também impunha uma leitura disciplinada das tabelas: estado presente era evidência de informação recentemente renovada, e estado ausente podia significar expiração, mudança de topologia, perda de controle ou falta de interesse. A semântica vinha do conjunto mensagem–temporizador, não de uma linha isolada.