Introduction
Estamos falando de IP Multicast. Este mês vou começar a cobrir o modo PIM Sparse Mode. Artigos anteriores que possam ser de interesse:
- Os Protocolos do IP Multicast
- Modo Denso PIM
Modo Denso Separar Versus
Recorde que o Modo Denso PIM é usado (em princípio) quando o multicast é desejado na maioria dos locais. Assim os pacotes multicast iniciais são inundados em toda parte, com a poda cortando o tráfego para locais que não precisam da alimentação de multicast. Até recentemente, o Modo Denso do PIM sofria de inundações periódicas a cada 3 minutos, mas em 12.1(5)T, o recurso de Atualização do Estado do Modo Denso do PIM aliviou isso. Com este recurso, o Modo Denso do PIM é indiscutivelmente adequado para a implementação simples de multicast. Especialmente onde o controle adicional do Modo Esperto do PIM não é necessário, e onde inundações “acidentais” ocasionais não seriam muito prejudiciais.
PIM Modo Esperto usa uma abordagem de pedido explícita, onde um roteador tem que pedir a alimentação de multicast com uma mensagem PIM Join. O Modo Esperto PIM é indicado quando você precisa de um controle mais preciso, especialmente quando você tem grandes volumes de tráfego IP multicast comparado à sua largura de banda. O PIM Sparse Mode escalona bastante bem, porque os pacotes só vão onde são necessários, e porque cria estado nos roteadores apenas quando necessário. Por causa disso, ele foi escrito como um Protocolo Experimental da Internet.
O preço que pagamos por esse controle extra é uma complexidade extra leve. O PIM Sparse Mode utiliza um router especial chamado Rendezvous Point (RP) para ligar a fonte de fluxo ou árvore multicast ao router junto ao aspirante a receptor. O RP é normalmente utilizado apenas temporariamente, como veremos abaixo.
Pode haver RP’s diferentes para diferentes grupos multicast, o que é uma forma de espalhar a carga. Há normalmente um RP por grupo multicast. Redundância de RP’s é um tópico avançado, e requer um pouco mais de conhecimento. Uma maneira de fazer isso é com o protocolo MSDP (possível artigo posterior na série).
Recordar que uma mensagem PIM Join é enviada para uma Fonte (ou para PIM-SM, possivelmente para uma RP), com base no roteamento unicast. A mensagem Join diz na verdade “precisamos de uma cópia dos multicasts aqui”. Ela conecta o remetente do Join e os roteadores intervenientes a qualquer árvore multicast existente, até o destino do Join, se necessário. Uma mensagem de ameixa diz na verdade “não precisamos mais disto aqui”. Um roteador que recebe uma Poda vê se ele tem outras interfaces que requerem o fluxo multicast, e se não tiver, envia sua própria mensagem de Poda. Uma técnica avançada é organizar uma cópia separada e talvez diferente das informações de roteamento unicast apenas para fins de multicast. Isto permite o “direcionamento” das mensagens de Join. MultiProtocol BGP, MBGP, para multicast, é uma maneira de fazer isso (possível artigo posterior na série).
Basic Rendezvous Point (RP)
Vimos até agora que o PIM-SM usa um Rendezvous Point (RP), para conectar fonte e receptores. Só pode haver um RP por grupo multicast, e a implementação mais simples utiliza um RP para todos os grupos multicast.
Vamos falar sobre o básico de como o RP é utilizado. Vamos assumir que a fonte começa a ser enviada antes de qualquer receptor. Se as coisas acontecem ao contrário, alguns dos detalhes mudam ligeiramente, mas não é muito diferente.
Então: o código fonte multicast começa a enviar. Como já notamos, não há protocolo ou qualquer coisa para registrar fontes com IP multicast. A fonte envia e cabe ao(s) roteador(es) vizinho(s) fazer a coisa certa. Com o PIM-SM, o roteador vizinho sabe sobre o RP. O roteador vizinho encaminha os dados multicast para o RP encapsulando-os em uma ou mais mensagens de registro unicast. O roteador normal entrega o Register para o RP. O RP descapitula o multicast e encaminha cópias para baixo de qualquer árvore compartilhada (há um pré-construído se houvesse receptores Juntados antes de a Fonte começar a enviar). Se houver receptores (Shared Tree state outbound interfaces), o RP envia um PIM Join de volta para a Origem. Isto liga a Fonte à RP com uma Árvore de Origem, a (S, G) árvore de caminho mais curto (SPT). Uma vez que o RP recebe multicasts ao longo deste SPT, ele envia um Register-Stop para avisar o roteador pelo Source para parar de enviar pacotes de Register. A razão para este comportamento é que nenhum pacote multicast é perdido, se já houver receptores presentes.
Por sinal, se não houver receptores presentes, a mensagem Register-Stop é enviada. Então quando um receptor posteriormente aparece (IGMP para roteador vizinho, PIM Join do roteador vizinho de volta para RP), então o RP envia o PIM Join para o Source naquele momento.
A figura a seguir assume que existe um receptor de origem e um receptor ativo (não mostrado). O receptor mostrado envia um relatório IGMP para o roteador D. O roteador D então envia um PIM Join para o RP. Como existem outros receptores, o RP já está unido à árvore de origem (mostrada em azul) e está recebendo o fluxo multicast. Ele passa os pacotes de fluxo da Árvore de Origem através da Árvore Compartilhada, mostrada em verde.
Bem, agora temos os pacotes indo da Árvore de Origem para o RP ao longo da Árvore de Origem (Shortest Path Tree, SPT), e do RP para o receptor ao longo da Árvore Compartilhada. Quando a taxa de bits de pacotes agregados (*, G) (de todas as fontes) excede um limite em Kbps, isso aciona o roteador mais próximo do receptor para tentar se juntar à Árvore de Origem. Ele envia um Join em direção à fonte do fluxo multicast. Note que o Join anterior enviado foi em direção ao RP. O Join em direção à fonte vai roteador por roteador em direção à Fonte até encontrar um roteador que já está na Árvore de Origem. Isto adiciona o roteador perto do receptor à Árvore de Origem. Quando um pacote é realmente recebido ao longo dessa árvore, uma ameixa é enviada em direção à RP. Na verdade, “obrigado, mas agora estou recebendo meu multicast por atacado, não por varejo”, pois este processo corta a RP no meio.
A figura a seguir mostra como isso funciona. As setas vermelhas superiores esquerdas mostram o Join em direcção à Fonte. Isto faz com que o fluxo azul superior se mova, os pacotes são encaminhados ao longo da Árvore de Origem. As setas vermelhas inferiores direitas então são as Ameixas, já que o fluxo da Árvore Compartilhada não é mais necessário (mostrado como linha tracejada verde). Note que os pacotes da Árvore de Origem chegam ao Receptor por um caminho mais direto, geralmente com menor latência.
Pelo caminho, nós controlamos o limite. Ele é configurável. O padrão é zero Kbps: receba um pacote, e mude para a árvore de origem. Se tivermos muitas fontes para um grupo multicast em particular (pense conference call, VoIP), então há uma entrada (S, G) Source Tree para cada uma. Se definirmos o limite para nunca ativar, então todos os pacotes passam pelo RP (uma espécie de ponte de chamada em conferência), usando apenas a (*, G) Árvore Compartilhada. O limiar também é usado para switchback, bem como para switchover. Baixa taxa (S, G) As árvores de origem são trocadas de volta para a Árvore Compartilhada. O volume de tráfego é verificado a cada minuto.
Se um receptor deseja entrar, e seu roteador vizinho está no SPT (Árvore de Origem), então a entrada da interface de saída Árvore Compartilhada é copiada para a entrada da Árvore de Origem, que protege contra ter que enviar tráfego para o RP e depois “voltar” para o roteador no SPT.
Por falar nisso, você pode estar se perguntando, qual é a vantagem de ter o RP aqui? Devido ao mecanismo de limiar, o RP nos dá uma maneira de usar a árvore compartilhada, e controlar a criação explosiva de informação de estado nos roteadores se muitos receptores se juntarem ao mesmo tempo.
Árvores Originais Partilhadas em Versus
PIM Sparse Mode (PIM-SM) pode usar tanto Árvores Compartilhadas (passando através do RP) quanto Árvores Originais (para entrega direta eficiente ao longo do caminho “mais curto” da origem para o receptor). Tipicamente, pode usar ambos. Se a entrega eficiente é menos importante para você, e diminuir a quantidade de informações de estado mantidas pelos roteadores é mais importante, então o PIM pode ser configurado para usar apenas uma Árvore Compartilhada.
Quando um roteador PIM-SM recebe um pacote multicast, ele verifica a Árvore de Origem para aquele endereço de origem e endereço de grupo multicast (destino) em particular. Se não houver nenhuma entrada presente, ele verifica se há uma entrada em Árvore Compartilhada (*, G) para o grupo multicast. Se houver entradas para as duas árvores, a interface de entrada informa ao roteador qual árvore utilizar. Se ambas as árvores tiverem a mesma interface de entrada, então o bit RP para uma entrada (S, G) evita pacotes duplicados: isso indica que a interface RPF fica ao longo da Árvore Compartilhada.
Para um fluxo multicast com pelo menos um receptor ativo, o caminho entre a origem e a RP fará parte da Árvore de Origem. (Note que “o caminho entre” é um pouco vago aqui, estou a tentar ficar longe de dar demasiados detalhes.)
As entradas da Árvore Partilhada irão ligar o RP a alguns dos receptores. A interface RPF para a (*, G) Árvore Compartilhada é a interface na direção do RP, não a fonte do grupo multicast. Por isso existe a possibilidade da (S, G) Fonte e (*, G) Árvores Compartilhadas terem diferentes interfaces RPF.
A Árvore Compartilhada (*, G) mostra interfaces onde um join para a RP foi recebido, ou interfaces com membros do grupo diretamente conectados (configurados ou IGMP recebidos). As entradas da Árvore de Origem (S, G) mostram onde um Join ou uma Poda ou um Registro foi recebido.
Configurando o modo Sparse PIM
A parte básica do que você precisa é:
ip multicast-routing
interface ethernet 0
ip endereço 10.1.1.1 255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
Precisa também dizer a cada roteador o RP, seja para todos os grupos ou para grupos selecionados (usando listas de acesso para especificar qual RP para quais grupos). Isto pode ser feito estaticamente com:
ip pim rp-address 1.2.3.4
Vamos olhar para as outras opções de gestão de RP no próximo artigo.
Em Conclusão
Próximo mês vamos dar uma olhada nas várias formas de trabalhar com os Rendezvous Points. Também podemos tocar levemente em alguns outros tópicos mais avançados de multicast IP.