Visão geral multicast

Comparando o Multicast com a Unicast

O processo de protocolo de roteamento do sistema operacional Junos® (Junos OS) oferece suporte a uma ampla variedade de protocolos de roteamento. Esses protocolos de roteamento transportam informações de rede entre dispositivos de roteamento não apenas para fluxos de tráfego unicast enviados entre um par de clientes e servidores, mas também para fluxos de tráfego multicast que contêm vídeo, áudio ou ambos, entre uma única fonte de servidor e muitos receptores clientes. Os protocolos de roteamento usados para multicast diferem de muitas maneiras principais dos protocolos de roteamento unicast.

As informações são fornecidas em uma rede por três métodos básicos: unicast, broadcast e multicast.

As diferenças entre unicast, broadcast e multicast podem ser resumidas da seguinte forma:

• Unicast: Um a um, de uma fonte a um destino.

• Broadcast: Um a todos, de uma fonte a todos os destinos possíveis.

• Multicast: Um a muitos, de uma fonte a vários destinos expressando interesse em receber o tráfego.

  Nota:

  Esta lista não inclui uma categoria especial para muitos aplicativos, como jogos online ou videoconferência, onde existem muitas fontes para o mesmo receptor e onde os receptores muitas vezes dobram como fontes. Muitos para muitos é um modelo de serviço que emprega repetidamente um a muitos multicast e, portanto, não requer nenhum protocolo único. A especificação multicast original, RFC 1112, oferece suporte tanto ao modelo multicast de qualquer fonte (ASM) de muitas para muitos quanto ao modelo multicast (SSM) específico de fonte específica (SSM).

Com o tráfego unicast, muitos fluxos de pacotes IP que viajam por redes fluem de uma única fonte, como um servidor de site, para um único destino, como um PC cliente. O tráfego Unicast ainda é a forma mais comum de transferência de informações em redes.

O tráfego de broadcast flui de uma única fonte para todos os possíveis destinos que podem ser alcançados na rede, que normalmente é uma LAN. A radiodifusão é a maneira mais fácil de garantir que o tráfego chegue aos seus destinos.

As redes de televisão usam a radiodifusão para distribuir vídeo e áudio. Mesmo que a rede de televisão seja um sistema de televisão a cabo (CATV), o sinal de origem chega a todos os destinos possíveis, que é a principal razão pela qual o conteúdo de alguns canais é mexido. A radiodifusão não é viável na Internet devido à enorme quantidade de informações desnecessárias que chegariam constantemente ao dispositivo de cada usuário final, às complexidades e ao impacto dos problemas de privacidade relacionados.

O tráfego multicast está entre os extremos da unicast (uma fonte, um destino) e broadcast (uma fonte, todos os destinos). Multicast é um método "uma fonte, muitos destinos" de distribuição de tráfego, o que significa apenas os destinos que indicam explicitamente sua necessidade de receber as informações de uma determinada fonte receber o fluxo de tráfego.

Em uma rede IP, porque os destinos (clientes) não costumam se comunicar diretamente com fontes (servidores), os dispositivos de roteamento entre a origem e o destino devem ser capazes de determinar a topologia da rede da perspectiva unicast ou multicast para evitar o roteamento do tráfego por acaso. Dispositivos de roteamento multicast replicam pacotes recebidos em uma interface de entrada e enviam as cópias em várias interfaces de saída.

No IP multicast, a origem e o destino são quase sempre hosts e não dispositivos de roteamento. Os dispositivos de roteamento multicast distribuem o tráfego multicast pela rede da fonte aos destinos. O dispositivo de roteamento multicast deve encontrar fontes multicast na rede, enviar cópias de pacotes em várias interfaces, evitar loops de roteamento, conectar destinos interessados com a fonte adequada e manter o fluxo de pacotes indesejados ao mínimo. Os protocolos de roteamento multicast padrão oferecem a maioria desses recursos, mas algumas arquiteturas de roteador não podem enviar várias cópias de pacotes e, portanto, não suportam a multicasting diretamente.

Usos de IP Multicast

O Multicast permite que uma rede IP ofereça suporte mais do que apenas ao modelo unicast de entrega de dados que prevaleceu nos estágios iniciais da Internet. A Multicast, originalmente definida como uma extensão de host na RFC 1112 em 1989, fornece um método eficiente para a entrega de fluxos de tráfego que podem ser caracterizados como um para muitos ou muitos para muitos.

O tráfego Unicast não se limita estritamente a aplicativos de dados. Conversas telefônicas, sem fio ou não, contêm amostras de áudio digital e podem conter fotografias digitais ou até mesmo vídeo e ainda fluir de uma única fonte para um único destino. Da mesma forma, o tráfego multicast não se limita estritamente a aplicativos multimídia. Em alguns aplicativos de dados, o fluxo de tráfego é de uma fonte única para muitos destinos que exigem os pacotes, como em um serviço de notícias ou ticker de estoque entregue a muitos PCs. Por essa razão, o termo receptor é preferido para ouvir destinos multicast, embora ambos os termos sejam comuns.

Os aplicativos de rede que podem funcionar com unicast, mas são mais adequados para multicast, incluem groupware colaborativo, teleconferência, entrega periódica ou "push" de dados (cotações de ações, pontuações esportivas, revistas, jornais e anúncios), replicação de servidores ou sites e simulação interativa distribuída (DIS), como simulações de guerra ou realidade virtual. Qualquer rede IP preocupada em reduzir a sobrecarga de recursos de rede para aplicativos de dados ou multimídia de um a muitos ou muitos com múltiplos receptores se beneficia do multicast.

Se o unicast fosse empregado por serviços de rádio ou notícias, cada rádio ou PC teria que ter uma sessão de tráfego separada para cada ouvido ou espectador em um PC (este é, na verdade, o método para alguns serviços baseados na Web). A carga de processamento e a largura de banda consumidas pelo servidor aumentariam linearmente à medida que mais pessoas "sintonizassem" o servidor. Isso é extremamente ineficiente ao lidar com a escala global da Internet. A Unicast coloca a carga da duplicação de pacotes no servidor e consome cada vez mais largura de banda de backbone à medida que o número de usuários cresce.

Se a broadcast fosse usada, a fonte poderia gerar um único fluxo de pacotes IP usando um endereço de destino de broadcast. Embora a broadcast elimine o problema da duplicação de pacotes de servidor, esta não é uma boa solução para IP, porque as transmissões IP podem ser enviadas apenas para uma única sub-rede, e os dispositivos de roteamento IP normalmente isolam as sub-redes IP em interfaces separadas. Mesmo que um fluxo de pacotes IP pudesse ser endereçado para literalmente ir a todos os lugares, e não houvesse necessidade de "ajustar" qualquer fonte, a transmissão seria extremamente ineficiente devido à tensão da largura de banda e à necessidade de hosts não interessados descartarem um grande número de pacotes. A broadcast coloca o fardo da rejeição de pacotes em cada host e consome a quantidade máxima de largura de banda do backbone.

Para tráfego de emissoras de rádio ou notícias, o multicast fornece o resultado mais eficiente e eficaz, sem nenhuma das desvantagens e todas as vantagens dos outros métodos. Uma única fonte de pacotes multicast encontra seu caminho para todos os receptores interessados . Como acontece com a transmissão, o host transmissor gera apenas um único fluxo de pacotes IP, de modo que a carga permaneça constante, independentemente de haver um receptor ou um milhão. Os dispositivos de roteamento de rede replicam os pacotes e entregam os pacotes aos receptores adequados, mas apenas a função de replicação é nova para dispositivos de roteamento. Os links que levam a sub-redes que consistem em receptores totalmenteinteressados não têm tráfego multicast. O Multicast minimiza a carga colocada no remetente, rede e receptor.

O IP Multicast, Omissão

A Multicast tem seu próprio conjunto particular de termos e siglas que se aplicam a dispositivos e redes de roteamento IP multicast. A Figura 1 mostra alguns dos termos comumente usados em uma rede IP multicast.

Em uma rede multicast, o componente chave é o dispositivo de roteamento, que é capaz de replicar pacotes e, portanto, é capaz de multicast. Os dispositivos de roteamento na rede ip multicast, que tem exatamente a mesma topologia que a rede unicast em que se baseia, usam um protocolo de roteamento multicast para construir uma árvore de distribuição que conecta receptores (preferindo as implicações multimídia dos ouvidos, mas os ouvidos também são usados) às fontes. Em multicast, a árvore de distribuição está enraizada na fonte (a raiz da árvore de distribuição é a fonte). A interface no dispositivo de roteamento que leva à fonte é a interface upstream , embora os termos menos precisos de entrada ou interface de entrada também sejam usados. Para manter o uso de largura de banda ao mínimo, é melhor que apenas uma interface upstream no dispositivo de roteamento receba pacotes multicast. A interface do dispositivo de roteamento que leva aos receptores é a interface downstream , embora os termos menos precisos de saída ou interface de saída também sejam usados. Pode haver interfaces de 0 a N1 downstream em um dispositivo de roteamento, onde N está o número de interfaces lógicas no dispositivo de roteamento. Para evitar loops, a interface upstream nunca deve receber cópias de pacotes multicast downstream.

Figura 1: Firewall multicast em uma rede IP

Os loops de roteamento são desastrosos em redes multicast devido ao risco de pacotes replicados repetidamente. Uma das complexidades dos protocolos de roteamento multicast modernos é a necessidade de evitar loops de roteamento, pacote por pacote, muito mais rigorosamente do que em protocolos de roteamento unicast.

Encaminhamento reverso para a prevenção de loops

O estado de encaminhamento multicast do dispositivo de roteamento funciona mais logicamente com base no caminho inverso, desde o receptor até a raiz da árvore de distribuição. No RPF, todos os pacotes multicast recebidos devem passar por uma verificação de RPF antes que ele possa ser replicado ou encaminhado em qualquer interface.

Quando um roteador recebe um pacote multicast em uma interface, o roteador verifica o source endereço. Em seguida, o roteador verifica se o mesmo endereço pode ser usado como destination endereço para voltar à fonte por uma rota unicast. Se a interface de saída encontrada na tabela de roteamento unicast for a mesma interface em que o pacote multicast foi recebido, o pacote passa a verificação de RPF.

Os pacotes multicast que falham na verificação de RPF são descartados, porque a interface de entrada não está no caminho mais curto de volta à fonte. Os dispositivos de roteamento podem construir e manter tabelas separadas para fins de RPF.

Árvore de caminho mais curto para a prevenção de loops

A árvore de distribuição usada para multicast está enraizada na fonte e é a árvore de caminho mais curto (SPT), mas esse caminho pode ser longo se a fonte estiver na periferia da rede. Fornecendo um shared tree backbone enquanto a árvore de distribuição localiza a fonte multicast de forma mais centralizado na rede. Árvores de distribuição compartilhadas com raízes na rede central são criadas e mantidas por um dispositivo de roteamento multicast que opera como um ponto de encontro (RP), um recurso de protocolos multicast de modo esparso.

Escopo administrativo para prevenção de loops

A escopo limita os dispositivos de roteamento e interfaces que podem encaminhar um pacote multicast. O escopo multicast é administrative no sentido de que uma variedade de endereços multicast está reservada para fins de escopo, conforme descrito na RFC 2365, Administratively Scoped IP Multicast. Os dispositivos de roteamento no limite devem filtrar pacotes multicast e garantir que os pacotes não se desviem além do limite estabelecido.

O Leaf multicast e o Branch Domy

Cada sub-rede com hosts no dispositivo de roteamento que tem pelo menos um receptor interessado é uma folha na árvore de distribuição. Os dispositivos de roteamento podem ter várias folhas em diferentes interfaces e devem enviar uma cópia do pacote IP multicast em cada interface com um leaf. Quando uma nova sub-rede leaf é adicionada à árvore (ou seja, a interface da sub-rede do host anteriormente não recebeu cópias dos pacotes multicast), um novo ramo é construído, a folha é juntada à árvore e pacotes replicados são enviados na interface. O número de folhas em uma interface específica não afeta o dispositivo de roteamento. A ação é a mesma para uma folha ou cem.

Quando uma filial não contém folhas porque não há hosts interessados na interface do dispositivo de roteamento que leve a essa sub-rede IP, a filial é podada da árvore de distribuição, e nenhum pacote multicast é enviado para fora dessa interface. Os pacotes são replicados e enviados várias interfaces apenas onde a árvore de distribuição se ramifica em um dispositivo de roteamento, e nenhum link nunca carrega um fluxo duplicado de pacotes.

Coleções de hosts que recebem o mesmo fluxo de pacotes IP, geralmente da mesma fonte multicast, são chamados de grupos. Em redes ip multicast, o tráfego é entregue a grupos multicast com base em um endereço IP multicast ou endereço em grupo. Os grupos determinam a localização das folhas, e as folhas determinam as filiais na rede multicast.

Endereçamento IP multicast

O Multicast usa a faixa de endereço IP classe D (224.0.0.0 a 239.255.255.255.255). Os endereços classe D são comumente referidos como endereços multicast porque todo o conceito de endereço com classe é obsoleto. Os endereços multicast nunca podem aparecer como o endereço de origem em um pacote IP e só podem ser o destino de um pacote.

Os endereços multicast geralmente têm um comprimento de prefixo de /32, embora outros comprimentos de prefixo sejam permitidos. Os endereços multicast representam agrupamentos lógicos de receptores e não coleções físicas de dispositivos. Blocos de endereços multicast ainda podem ser descritos em termos de comprimento de prefixo na notação tradicional, mas apenas para conveniência. Por exemplo, o endereço multicast varia de 232.0.0.0 a 232.255.255.255 pode ser escrito como 232.0.0.0/8 ou 232/8.

Os provedores de serviços de Internet (ISPs) normalmente não alocam endereços multicast para seus clientes porque os endereços multicast se relacionam com o conteúdo, não com dispositivos físicos. Os receptores não recebem seus próprios endereços multicast, mas precisam saber o endereço multicast do conteúdo. As fontes precisam ser atribuídas a endereços multicast apenas para produzir o conteúdo, não para identificar seu lugar na rede. Cada fonte e receptor ainda precisa de um endereço IP unicast comum.

O endereçamento multicast costuma fazer referência aos receptores, e a fonte de conteúdo multicast geralmente não é nem mesmo um membro do grupo multicast para o qual produz conteúdo. Se a fonte precisar monitorar os pacotes que produz, o monitoramento pode ser feito localmente e não há necessidade de fazer com que os pacotes percorram a rede.

Muitos aplicativos receberam uma variedade de endereços multicast para uso próprio. Esses aplicativos atribuem endereços multicast às sessões criadas por esse aplicativo. Você normalmente não precisa atribuir estaticamente um endereço multicast, mas pode fazê-lo.

Endereços multicast

Os endereços do grupo de host multicast são definidos como endereços IP cujos quatro bits de alta ordem são 1110, oferecendo um intervalo de endereços de 224,0,0,0 a 239.255.255.255, ou simplesmente 224.0.0.0/4. (Esses endereços também são chamados de endereços classe D.)

A Autoridade de Números Atribuídos à Internet (IANA) mantém uma lista de grupos ip multicast registrados. O endereço base 224.0.0.0 está reservado e não pode ser atribuído a nenhum grupo. O bloco de endereços multicast de 224.0.0.1 a 224.0.0.255 está reservado para uso local de fios. Grupos nessa faixa são designados para vários usos, incluindo protocolos de roteamento e mecanismos de descoberta local.

A faixa de 239.0.0.0 a 239.255.255.255 está reservada para endereços de escopo administrativo. Como os pacotes endereçados a endereços multicast de escopo administrativo não cruzam limites administrativos configurados e, como os endereços multicast de escopo administrativo são atribuídos localmente, esses endereços não precisam ser exclusivos entre os limites administrativos.

Quadros de camada 2 e endereços multicast IPv4

A multicasting em uma LAN é um bom lugar para iniciar uma investigação de multicasting na Camada 2. Na Camada 2, o multicast lida com quadros e endereços de controle de acesso ao meio (MAC) em vez de pacotes e endereços IPv4 ou IPv6. Considere uma única LAN, sem dispositivos de roteamento, com uma fonte multicast enviando para um determinado grupo. Os demais hosts são receptores interessados no conteúdo do grupo multicast. Assim, o host de origem multicast gera pacotes com seu endereço IP unicast como fonte, e o endereço de grupo multicast como destino.

Quais endereços MAC são usados no quadro que contém este pacote? O endereço de origem do pacote — o endereço IP unicast do host que origina o conteúdo multicast — se traduz facilmente e diretamente no endereço MAC da fonte. Mas e o endereço de destino do pacote? Este é o endereço de grupo IP multicast. Qual endereço MAC de destino para o quadro corresponde ao endereço de grupo multicast do pacote?

Uma opção é que as LANs simplesmente usem o endereço MAC de transmissão lan, que garante que o quadro seja processado por todas as estações da LAN. No entanto, esse procedimento derrota toda a finalidade do multicast, que é limitar a circulação de pacotes e quadros aos hosts interessados. Além disso, os hosts podem ter acesso a muitos grupos multicast, o que multiplica a quantidade de tráfego para destinos não interessados. Não faz sentido transmitir quadros no nível de LAN para oferecer suporte a grupos multicast.

No entanto, existe uma maneira fácil de usar efetivamente os quadros de Camada 2 para fins multicast. O endereço MAC tem um pouco que está definido para 0 para unicast (o termo LAN é endereço individual) e definido para 1 para indicar que este é um endereço multicast. Alguns desses endereços estão reservados para grupos multicast de fornecedores específicos ou protocolos de nível MAC. Os aplicativos multicast de Internet usam o intervalo 0x01-00-5E-00-00-00 a 0x01-00-5E-FF-FF-FF-FF. Os receptores multicast (hosts em execução TCP/IP) ouvem quadros com um desses endereços quando o aplicativo se junta a um grupo multicast. O host deixa de ouvir quando o aplicativo termina ou o host deixa o grupo na camada de pacotes (Camada 3).

Isso significa que 3 bytes, ou 24 bits, estão disponíveis para mapear endereços multicast IPv4 em endereços multicast de Camada 3 a MAC na Camada 2. No entanto, todos os endereços IPv4, incluindo endereços multicast, têm 32 bits de comprimento, deixando 8 bits de endereço IP restantes. Qual método de mapeamento de endereços multicast IPv4 para endereços multicast MAC minimiza a chance de "colisões" (ou seja, dois grupos multicast IP diferentes no mapeamento da camada de pacotes para o mesmo endereço MAC multicast na camada de quadros)?

Primeiro, é importante perceber que todos os endereços multicast IPv4 começam com os mesmos 4 bits (1110), portanto, existem apenas 4 bits de preocupação, não 8. Uma LAN não deve soltar os últimos bits do endereço IPv4 porque estes são quase garantidos como bits de host, dependendo da máscara de sub-rede. Mas os bits de alta ordem, os bits de endereço mais esquerdos, são quase sempre bits de rede, e há apenas uma LAN (por enquanto).

Um outro bit dos 24 bits de endereço MAC restantes está reservado (um 0 inicial indica um endereço multicast da Internet), de modo que os 5 bits seguintes ao 1110 inicial no endereço IPv4 são descartados. Os 23 bits restantes são mapeados, um por um, nos últimos 23 bits do endereço MAC. Um exemplo desse processo é mostrado na Figura 2.

Figura 2: Conversão de endereços MAC em endereços multicast

Observe que esse processo significa que existem 32 (2⁵) endereços multicast IPv4 que poderiam ser mapeados para os mesmos endereços multicast MAC. Por exemplo, os endereços IPv4 multicast 224.8.7.6 e 229.136.7.6 se traduzem no mesmo endereço MAC (0x01-00-5E-08-07-06). Isso é uma preocupação real, e como o host pode estar interessado em quadros enviados para ambos esses grupos multicast, o software IP deve rejeitar um ou outro.

Assim que o endereço MAC do grupo multicast for determinado, o sistema operacional do host essencialmente ordena que a placa de interface de LAN se junte ou deixe o grupo multicast. Uma vez juntado a um grupo multicast, o host aceita quadros enviados para o endereço multicast, bem como o endereço unicast do host e ignora os quadros de outros grupos multicast. É possível que um host participe e receba conteúdo multicast de mais de um grupo ao mesmo tempo, é claro.

Listas de interface multicast

Para evitar loops de roteamento multicast, todos os dispositivos de roteamento multicast devem estar sempre cientes da interface que leva à fonte desse conteúdo de grupo multicast pelo caminho mais curto. Esta é a interface upstream (de entrada), e os pacotes nunca devem ser encaminhados de volta para uma fonte multicast. Todas as outras interfaces são interfaces de downstream (saída) potenciais, dependendo do número de galhos na árvore de distribuição.

Os dispositivos de roteamento monitoram de perto o status das interfaces de entrada e saída, um processo que determina o estado de encaminhamento multicast. Um dispositivo de roteamento com um estado de encaminhamento multicast para um determinado grupo multicast é essencialmente "ativado" para o conteúdo desse grupo. Interfaces na lista de interface de saída do dispositivo de roteamento enviam cópias dos pacotes do grupo recebidos na lista de interface de entrada para esse grupo. As listas de interface de entrada e saída podem ser diferentes para diferentes grupos multicast.

O estado de encaminhamento multicast em um dispositivo de roteamento geralmente é escrito em notação (S,G) ou (*,G). Estes são pronunciados "ess vírgula gee" e "estrela vírgula", respectivamente. Em (S,G), o S refere-se ao endereço IP unicast da fonte para o tráfego multicast, e o G refere-se ao endereço IP de grupo multicast específico para o qual S é a fonte. Todos os pacotes multicast enviados dessa fonte têm S como endereço de origem e G como endereço de destino.

O asterisco (*) na notação (*,G) é um curinga indicando que o estado se aplica a qualquer fonte de aplicativo multicast que envie ao grupo G. Assim, se duas fontes estiverem originando exatamente o mesmo conteúdo para o grupo multicast 224.1.1.2, um dispositivo de roteamento pode usar (*.224.1.1.2) para representar o estado de um dispositivo de roteamento que encaminha tráfego de ambas as fontes para o grupo.

Protocolos de roteamento multicast

Os protocolos de roteamento multicast permitem que uma coleção de dispositivos de roteamento multicast crie (junte- se) árvores de distribuição quando um host em uma sub-rede diretamente anexada, tipicamente uma LAN, deseja receber tráfego de um determinado grupo multicast, podar filiais, localizar fontes e grupos e evitar loops de roteamento.

Existem vários protocolos de roteamento multicast:

• Protocolo de roteamento multicast de vetor de distância (DVMRP) — o primeiro dos protocolos de roteamento multicast e dificultado por uma série de limitações que tornam esse método pouco atraente para o uso de Internet em grande escala. DVMRP é um protocolo somente de modo denso, e usa o método de junção de inundação e podar ou implícito para entregar tráfego em todos os lugares e, em seguida, determinar onde estão os receptores não interessados. A DVMRP usa árvores de distribuição baseadas na origem na forma (S,G) e constrói suas próprias tabelas de roteamento multicast para verificações de RPF.

• OSPF multicast (MOSPF) — estende o OSPF para uso multicast, mas apenas para modo denso. No entanto, o MOSPF tem uma mensagem de junção explícita, para que os dispositivos de roteamento não precisem inundar todo o seu domínio com tráfego multicast de todas as fontes. O MOSPF usa árvores de distribuição baseadas na origem na forma (S,G).

• Modo PIM bidirecional — uma variação do PIM. O PIM bidirecional constrói árvores compartilhadas bidirecionais que estão enraizadas em um endereço de ponto de encontro (RP). O tráfego bidirecional não muda para árvores de caminho mais curtas como no PIM-SM e, portanto, é otimizado para o tamanho do estado de roteamento em vez do comprimento do caminho. Isso significa que a latência de ponta a ponta pode ser mais longa em comparação com o modo esparso PIM. As rotas de PIM bidirecional são sempre rotas de origem curinga (*,G). O protocolo elimina a necessidade de rotas (S,G) e eventos desencadeados por dados. As árvores de grupo bidirecional (*,G) transportam tráfego tanto upstream de stores em direção à RP, quanto downstream da RP até os receptores. Como conseqüência, as rígidas regras baseadas em encaminhamento de caminho reverso (RPF) encontradas em outros modos de PIM não se aplicam ao PIM bidirecional. Em vez disso, o PIM bidirecional (*,G) encaminha o tráfego de todas as fontes e rp. Os dispositivos de roteamento PIM bidirecional devem ter a capacidade de aceitar tráfego em muitas interfaces de entrada em potencial. O PIM bidirecional escala bem porque não precisa de um estado de origem específica (S,G). O PIM bidirecional é recomendado em implantações com muitas fontes dispersas e muitos receptores dispersos.

• Modo denso PIM — Neste modo de PIM, a suposição é que quase todas as sub-redes possíveis têm pelo menos um receptor querendo receber o tráfego multicast de uma fonte, de modo que a rede é inundada com tráfego em todas as filiais possíveis, depois podada de volta quando as filiais não expressam interesse em receber os pacotes, explicitamente (por mensagem) ou implicitamente (silêncio de tempo livre). Este é o modo denso de operação multicast. As LANs são redes apropriadas para a operação de modo denso. Alguns protocolos de roteamento multicast, especialmente os mais antigos, oferecem suporte apenas à operação de modo denso, o que os torna inapropriados para uso na Internet. Em contraste com DVMRP e MOSPF, o modo denso PIM permite que um dispositivo de roteamento use qualquer protocolo de roteamento unicast e realiza verificações de RPF usando a tabela de roteamento unicast. O modo denso pim tem uma mensagem de junção implícita, de modo que os dispositivos de roteamento usam o método de inundação e podar para entregar tráfego em todos os lugares e, em seguida, determinar onde estão os receptores não interessados. O modo denso PIM usa árvores de distribuição baseadas na fonte na forma (S,G), assim como todos os protocolos de modo denso. O PIM também oferece suporte ao modo esparso e denso, com grupos esparsos e densos mistos, mas não há notação especial para esse modo operacional. Se o modo denso esparso for suportado, o protocolo de roteamento multicast permite que alguns grupos multicast sejam esparsos e outros grupos sejam densos.

• Modo esparso de PIM — Neste modo de PIM, a suposição é que muito poucos dos possíveis receptores desejam pacotes de cada fonte, de modo que a rede estabelece e envia pacotes apenas em filiais que têm pelo menos uma leaf indicando (por mensagem) um interesse no tráfego. Este protocolo multicast permite que um dispositivo de roteamento use qualquer protocolo de roteamento unicast e realiza verificações de encaminhamento de caminho reverso (RPF) usando a tabela de roteamento unicast. O modo esparso PIM tem uma mensagem de junção explícita, de modo que os dispositivos de roteamento determinam onde estão os receptores interessados e enviam mensagens de junção upstream para seus vizinhos, construindo árvores dos receptores até o ponto de encontro (RP). O modo esparso PIM usa um dispositivo de roteamento de RP como fonte inicial de tráfego de grupo multicast e, portanto, cria árvores de distribuição na forma (*,G), assim como todos os protocolos de modo esparso. O modo esparso PIM migra para uma árvore baseada em origem (S,G) se esse caminho for mais curto do que através da RP para o tráfego de um determinado grupo multicast. As WANs são redes apropriadas para operação de modo esparso, e de fato uma diretriz multicast comum é não executar um modo denso em uma WAN em nenhuma circunstância.

• Árvores baseadas em núcleo (TCC) — Compartilha todas as características do modo esparso PIM (modo esparso, junção explícita e árvores compartilhadas (*,G), mas é dito ser mais eficiente em encontrar fontes do que o modo esparso de PIM. A TCC raramente é encontrada fora das discussões acadêmicas. Não há implantações em grande escala de TCC, comerciais ou não.

• SSM (Source-Specific Multicast, multicast específico para fonte) PIM — Aprimoramento ao modo esparso PIM que permite que um cliente receba tráfego multicast diretamente da fonte, sem a ajuda de um RP. Usado com o IGMPv3 para criar uma árvore de caminho mais curto entre o receptor e a fonte.

• IGMPv1 — O protocolo original definido em RFC 1112, extensões de host para multicasting IP. O IGMPv1 envia uma mensagem de junção explícita ao dispositivo de roteamento, mas usa um tempo limite para determinar quando os hosts saem de um grupo. Três versões do Internet Group Management Protocol (IGMP) são executadas entre hosts receptores e dispositivos de roteamento.

• IGMPv2 — Definido em RFC 2236, Protocolo de gerenciamento de grupos de Internet, versão 2. Entre outros recursos, o IGMPv2 adiciona uma mensagem de licença explícita à mensagem de junção.

• IGMPv3 — Definido em RFC 3376, Protocolo de gerenciamento de grupos de Internet, versão 3. Entre outros recursos, o IGMPv3 otimiza o suporte para uma única fonte de conteúdo para um grupo multicast, ou multicast específico de origem (SSM). Usado com o PIM SSM para criar uma árvore de caminho mais curto entre o receptor e a fonte.

• Bootstrap Router (BSR) e Auto-Rendezvous Point (RP) — permitem que protocolos de roteamento de modo esparso encontrem RPs dentro do domínio de roteamento (sistema autônomo ou AS). Os endereços RP também podem ser configurados estaticamente.

• Multicast Source Discovery Protocol (MSDP) — permite que grupos localizados em um domínio de roteamento multicast encontrem RPs em outros domínios de roteamento. O MSDP não é usado em uma RP se todos os receptores e fontes estiverem localizados no mesmo domínio de roteamento. Normalmente é executado no mesmo dispositivo de roteamento que o MODO PIM esparso RP. Não é apropriado se todos os receptores e fontes estiverem localizados no mesmo domínio de roteamento.

• Protocolo de anúncio de sessão (SAP) e protocolo de descrição de sessão (SDP) — exibir nomes de sessões multicast e correlacionar os nomes com tráfego multicast. SDP é um protocolo de diretório de sessão que anuncia sessões de conferência multimídia e comunica informações de configuração aos participantes que desejam participar da sessão. Um cliente geralmente usa o SDP para anunciar uma sessão de conferência multicasting periodicamente de um pacote de anúncio em um endereço multicast e porta multicast bem conhecido usando SAP.

• Multicast geral pragmático (PGM)— camada de protocolo especial para tráfego multicast que pode ser usada entre a camada IP e o aplicativo multicast para adicionar confiabilidade ao tráfego multicast. O PGM permite que um receptor detecte informações ausentes em todos os casos e solicite informações de substituição se o aplicativo receptor exigir.

As diferenças entre os protocolos de roteamento multicast são resumidas na Tabela 1.

É importante perceber que as retransmissões devido a uma alta taxa de erro de bit em um link ou dispositivo de roteamento sobrecarregado podem tornar a multicast tão ineficiente quanto a unicast repetida. Portanto, há uma compensação em muitos aplicativos multicast em relação ao suporte de sessão fornecido pelo Protocolo de Controle de Transmissão (TCP) (mas o TCP sempre acaba perdendo segmentos), ou a estratégia simples de drop-and-continue do serviço de datagram protocol (UDP) do usuário (mas a reordenação pode se tornar um problema). O multicast moderno usa UDP quase exclusivamente.

Desempenho multicast do roteador da Série T

Os roteadores de núcleo da Série T da Juniper Networks lidam com requisitos extremos de replicação de pacotes multicast com um mínimo de carga do roteador. Cada componente de memória replica um pacote multicast duas vezes no máximo. Mesmo no pior cenário envolvendo o fan-out máximo, quando 1 porta de entrada e 63 portas de saída precisam de uma cópia do pacote, a plataforma de roteamento da Série T copia um pacote multicast apenas seis vezes. A maioria das árvores de distribuição multicast são muito mais esparsas, por isso, em muitos casos, apenas duas ou três replicações são necessárias. Em nenhum caso, a arquitetura da Série T tem impacto no desempenho multicast, mesmo com os maiores requisitos de fan-out multicast.