Resumo

  • No RFC 3353, um LSP multicast acionado por tráfego podia ficar preso: o ramo precisava do primeiro pacote como gatilho, mas esse pacote não chegaria por L2 enquanto o ramo não existisse.
  • Encaminhamento misto L2/L3 ou iniciativa do LSR upstream ofereciam uma partida, sem transformar observação do pacote, estado multicast, sinalização, programação de réplica e entrega em uma única prova.

Um fluxo já atende a um receptor. Outro receptor entra no grupo por um segundo ramo. A rede quer construir o novo LSP somente se houver tráfego, preservando espaço de rótulos. O roteador downstream deveria observar o primeiro pacote e então pedir a ligação necessária.

O pacote, porém, não atravessa em L2 o caminho que ainda não existe. O RFC 3353 chamou a situação de problema do ovo e da galinha. A expressão identifica uma falha concreta de sequência: quem observa a demanda está depois do recurso cuja criação depende dessa observação.

Publicado em agosto de 2002 como Informational, o RFC não especificava um protocolo obrigatório nem apresentava medições de implantação. Ele organizava as escolhas necessárias para colocar árvores de multicast IP em um ambiente MPLS. Uma rota unicast tende a apontar para um próximo salto. Uma árvore multicast tem uma entrada e várias saídas, muda com os membros e pode carregar estado compartilhado ou por origem.

No estado (*,G), um grupo compartilha a árvore; em (S,G), cada origem tem a sua. A árvore compartilhada poupa rótulos, mas pode exigir fusão e caminhos multiponto-a-multiponto. A árvore por origem evita parte dessa fusão e multiplica o estado. Limitações do enlace — espaço de rótulos, capacidade de merge e tratamento de TTL — também mudavam a resposta. O documento não escolheu um vencedor universal.

Protocolos flood-and-prune tornavam a árvore volátil. A chegada de dados criava estado; ramos sem interesse eram podados; temporizadores de inatividade removiam entradas. Espelhar cada alteração em L2 aumentava a sinalização. Preestabelecer todos os caminhos gastava rótulos sem tráfego. Esperar os dados transferia o custo para o primeiro pacote.

O RFC separou três gatilhos. Request-driven usava mensagens de controle, como Join, Prune ou reserva. Topology-driven copiava para L2 a árvore existente na tabela multicast, mesmo vazia. Traffic-driven esperava dados. Os nomes descreviam onde ficava o custo: acoplamento de protocolos, estado ocioso ou latência e ambiguidade de partida.

Uma saída era fazer o LSR upstream tomar a iniciativa. Como ele já via o pacote, podia solicitar um rótulo ao downstream ou anunciar um rótulo atribuído a montante, conforme o modo. A observação e a ação passavam a ocorrer do mesmo lado da lacuna. Por isso a tabela de combinações do RFC condicionava alguns sentidos de distribuição ao tipo de gatilho.

A outra saída era o encaminhamento misto L2/L3. O nó continuava comutando em L2 o ramo pronto e roteava temporariamente em L3 o ramo novo. O primeiro pacote chegava pelo caminho IP, provocava estado e permitia a criação do LSP. Depois de programado e verificado, o ramo podia migrar. A mistura preservava uma ponte reversível durante a mudança.

Essa ponte precisava evitar duplicatas. A parte L3 não podia encaminhar para interfaces já atendidas pela réplica L2. Sem capacidade mista, um downstream não conseguiria iniciar pelo tráfego; a solicitação teria de partir do upstream. Gatilho e direção de distribuição não eram opções isoladas de configuração.

Cada etapa também tinha um alcance probatório. Um pacote visto upstream prova sua presença naquele ponto. Um cache miss prova a ausência de uma entrada local. Uma linha na tabela multicast prova estado de controle local. Uma troca de rótulos prova uma etapa do protocolo. Uma entrada no hardware prova programação em um equipamento. Nenhum desses fatos, sozinho, prova que todos os receptores receberam dados.

O exemplo do Multicast Forwarding Cache em Unix torna a reconciliação ainda mais clara. O primeiro pacote causava um cache miss e o daemon multicast fornecia a rota. Quando L2 passava a comutar os pacotes, a camada IP deixava de vê-los. Um temporizador L3 alimentado apenas por seus próprios contadores poderia expirar um fluxo vivo.

O texto sugeria atualizar os contadores L3 com medições L2. Era necessário, mas alterava o significado da medida. O número deixava de representar somente pacotes processados por IP e passava a carregar uma projeção de outra camada. Origem da medição, janela, reinício e associação com o ramo precisavam ser preservados.

PIM-SM criava outra transição. Estados (*,G) e (S,G) podiam coexistir durante a troca da árvore compartilhada para a árvore da origem. Por algum tempo, o mesmo tráfego podia chegar por duas entradas. L3 sabia descartar a cópia inadequada segundo o estado. L2 podia tolerar duplicação, criar rótulos específicos ou devolver parte do fluxo a L3. O rótulo executava; o estado multicast ainda decidia.

Encapsulamento marcava uma fronteira dura. Uma origem podia tunelar até a raiz compartilhada, que desencapsulava o pacote. Essas operações eram L3; um único LSP L2 não atravessava esse ponto sem interpretação. Era possível rotular o túnel ou outros ramos, mas não apagar a mudança de camada.

O piggy-backing de rótulos em mensagens multicast também trocava vantagens. Sincronizava rota e label e economizava mensagens separadas. Em compensação, exigia extensão para cada protocolo, excluía certos gatilhos e podia trocar a confiabilidade de LDP sobre TCP por anúncios periódicos de soft state. Receber o anúncio não certificava a réplica no plano de dados.

Em redes multiacesso, vários LSRs downstream precisavam aceitar o mesmo rótulo. Podiam memorizar todas as atribuições, dividir faixas ou eleger um alocador. Atribuição upstream aproveitava a existência de um único nó acima da árvore, mas uma mudança de topologia podia substituí-lo. Atribuição downstream resistia melhor a essa troca, porém exigia conciliar propostas múltiplas. O RFC deixou a decisão ao contexto operacional.

Documentos posteriores tornaram a árvore mais concreta. O RFC 4461 registrou requisitos de estabelecimento, remoção, falha e escala para LSPs P2MP TE. O RFC 4875 definiu, com RSVP-TE, um LSP composto por vários sub-LSPs de origem a folha, combinados em nós de ramificação. Ele separou explicitamente ramificação de sinalização e réplica de dados: a primeira podia existir sem a segunda.

O RFC 5332 corrigiu uma expectativa histórica. O uso original de codepoints separados para MPLS unicast e multicast, citado no ambiente de 2002, nunca foi implantado; o segundo codepoint foi redefinido para rótulos atribuídos upstream em meios multiacesso. O RFC 6513, por sua vez, ainda mostrava em VPNs multicast a escolha entre árvores de distribuição e replicação de ingresso por túneis unicast. Mudar o lugar da réplica não eliminava seu custo.

O valor histórico do RFC 3353 está em não esconder o primeiro passo. Antes do ramo rotulado havia um pacote, uma passagem L3 temporária ou uma decisão upstream. Depois da sinalização ainda vinham programação, replicação e verificação. O sistema não era um estado verde; era essa cadeia.

Fontes