Resumo
- Grupos dinâmicos, diferentes criadores de estado e objetivos conflitantes levaram o RFC 2102 a deixar fora do núcleo de Nimrod tanto a geração da rota multicast quanto o mecanismo de encaminhamento.
- A interoperabilidade passou a depender da estrutura do estado instalado: árvores compartilhadas ou enraizadas na fonte podiam coexistir se todos entendessem da mesma forma seus relacionamentos de encaminhamento.
- Uma entrada de filho provava uma replicação local, não membros atuais, autorização, cobertura completa, caminho mínimo, reserva ou entrega.
O ponto de encontro entre dois algoritmos multicast não precisava ser a fórmula que escolheu a árvore. Podia ser o momento em que um roteador recebia um flow-id, encontrava um pai e uma lista de filhos e sabia exatamente onde replicar o pacote. Essa foi a aposta arquitetural do RFC 2102.
Diversidade antes do pacote
Multicast, como unicast, separa geração de rota e encaminhamento. Nimrod definia modos de encaminhamento unicast e deixava o cálculo para o agente. No multicast, deixou ambos abertos.
Havia razões concretas. A associação do grupo muda com entradas e saídas. O estado pode ser iniciado pela fonte, pelo receptor ou pelos roteadores. E as heurísticas trocam custo por atraso, velocidade de cálculo por optimalidade e menor estado por caminhos menos diretos.
DVMRP formava árvores de fonte por reverse path forwarding. CBT usava uma árvore compartilhada em torno de um core e reduzia estado, mas podia alongar caminhos. PIM combinava árvore compartilhada e árvore específica de fonte. MOSPF calculava a partir de estado de enlace e membros. IDPR deixava a fonte escolher uma rota de política e instalar duplicação intermediária.
Cada método distribuía conhecimento, cálculo e autoridade de forma diferente.
O acordo mínimo estava na tabela
O RFC 2102 dizia que a árvore de entrega é definida pela natureza da informação de encaminhamento nos roteadores, e não pelo mecanismo que criou essa informação. Se a estrutura e a interpretação fossem comuns, várias implementações poderiam coexistir.
No exemplo Nimpim, um Join para um fluxo existente acrescenta o nó anterior à child list. Um fluxo novo instala parent, child e target e continua para o pai. Um Prune remove um filho; só apaga o fluxo quando não resta nenhum. O pacote carrega o flow-id, e o forwarding agent replica segundo esse estado.
Assim, um receptor pode ligar uma nova ramificação a uma árvore criada pela fonte sem que a fonte refaça o cálculo. Uma árvore compartilhada pode migrar para uma árvore de fonte. O RFC admite técnicas simultâneas e mudanças conforme a distribuição dos membros, desde que o estado continue uniformemente interpretável.
O que uma ramificação não diz
A child list não é uma lista de membros. O RFC 1112 coloca a manifestação IGMP na rede diretamente conectada, sujeita a temporização e agregação. A entrada de encaminhamento é uma projeção posterior.
Também não é permissão. Restrições por destino podem exigir árvores diferentes para partes disjuntas do mesmo grupo. A linha não mostra quem ficou de fora nem se a política ainda vale.
Não prova o melhor caminho. CBT pode desviar pelo core; o caminho reverso de PIM depende da simetria das métricas. Recursos e qualidade são afirmações separadas: o documento quer saber quais recursos podem ser compartilhados e se cada caminho atende às restrições, mas a entrada não comprova reserva, atraso ou jitter.
Por fim, estado instalado não confirma emissão da fonte, continuidade do restante da árvore, cópia no último salto ou consumo pela aplicação. Como o RFC não discute segurança, a entrada tampouco autentica membro ou autorização.
Uma fronteira, não uma vitória de implantação
O RFC 1992 já aceitava mapas e modos de encaminhamento diferentes; o RFC 1753 separava estado do usuário e do serviço. O RFC 2102 aplicou a mesma disciplina ao multicast: tornar comum apenas a semântica necessária para execução conjunta.
A Minimum Initial Specification de Lu Heng oferece uma linguagem posterior para essa escolha, e Running-Code Primacy impede que publicação seja confundida com adoção. A semelhança é interpretativa, não causal. O RFC 2102 é Informational e não comprova implantação de Nimrod.
Seu legado é um limite de prova. A técnica pode variar; o significado da execução não. Uma ramificação prova uma ramificação, e nada além dela sem evidência adicional.
Fontes
- RFC 2102: Multicast Support for Nimrod
- RFC 1992: The Nimrod Routing Architecture
- RFC 1753: requisitos IPng do Nimrod
- RFC 1075: DVMRP
- RFC 1112: extensões de host para multicast IP
- RFC 1584: MOSPF
- RFC 2201: aplicabilidade do RSVP
- Lu Heng, Running-Code Primacy
- Lu Heng, Minimum Initial Specification
- Lu Heng, On Reality Layers
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
