MBONE - Parte III

Reinaldo Penno Filho <rpenno@nortelnetworks.com>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
Suporte ao envio de datagramas Multicast em IP
Suporte total ao tráfego Multicast em IP
IGMP replay
Conclusão
Sites relacionados

Este artigo retoma um assunto há muito iniciado neste boletim: o MBONE. Aqui, são tratados o suporte ao envio de datagramas multicast no IP e em Ethernet, e a tecnologia conhecida como IGMP Relay, que popularizou-se muito nos últimos anos.

Introdução

Depois de um longo período ausente deste diferenciado periódico, estou de volta. Entretanto, muitas coisas interessantes aconteceram nesse meio tempo com relação à tecnologia multicast no Brasil. Dentre elas, podemos destacar duas: o Grupo de Trabalho de Engenharia de Redes ( GT-ER ) fez talvez a maior transmissão pública multicast de um evento no Brasil (9^a reunião do GT-ER), e o Comitê Gestor aprovou o documento “Recomedação para Implementação Inicial de um Backbone IP-Multicast.” O GT-ER, ainda no seu papel de catalisador de tecnologias, também transmitiu, ao vivo, a 10^a reunião do Grupo de Trabalho de Engenharia de Redes e se comprometeu a transmitir reuniões vindouras e a apoiar transmissão de eventos que utilizem esta tecnologia.

Isso fez com que a tecnologia multicast (e suas aplicações) deixassem de ser algo restrito aos meios acadêmicos e fosse difundida entre os provedores e backbones comercias. Hoje em dia palavras como “túnel”, “mrouted”, “sdr”, “DVMRP”, etc. já não soam tão estranhamente entre os provedores de serviço Internet e backbones comerciais.

Revendo os artigos anteriores da série, notei que faltou uma discussão mais aprofundada sobre o suporte ao envio de datagramas multicast no IP e em Ethernet. Apesar de algumas seções que tratam desse tema serem parecidas com aquelas de artigos anteriores, resolvi mantê-las para que a continuidade do texto não fosse sacrificada.

O novo tema explorado neste artigo é a tecnologia de IGMP Relay, que ficou muito popular no último ano. Foi dada uma visão bem abrangente do que é o IGMP Relay, como funciona e suas vantagens.

Suporte ao envio de datagramas Multicast em IP

EXTENSÕES DA INTERFACE DO SERVIÇO IP

Datagramas do tipo multicast em IP são transmitidos da mesma forma que datagramas unicast em IP; a única diferença é que uma camada superior especifica um endereço de grupo IP ao invés de um endereço de nó IP no campo destino. Todavia algumas extensões se fazem necessárias.

Primeiramente, a Interface de Serviço deve prover uma maneira para que um protocolo de camada superior especifique um time-to-live IP para um datagrama musticast que está sendo enviado, se tal capacidade já não existir. Se a camada superior não especificar um time-to-live, deve ser usado o valor de 1 como default para todos os datagramas IP multicast. Dessa forma, fica garantida a necessidade de uma escolha explícita para que o multicast se estenda além dos domínios da rede local em questão.

Em segundo lugar, para hosts que estejam conectados a mais de uma rede, a Interface de Serviço deve prover uma maneira para que a camada superior possa identificar qual a interface de rede a ser usada para uma determinada transmissão multicast. Somente uma interface deve ser usada para a transmissão; a responsabilidade pela transmissão para outras redes, se necessária, deve ser toda do(s) roteadore(s) multicast local(is). Se a camada superior não especificar a interface que deve ser utilizada, uma interface default deve ser adotada.

A terceira extensão se faz necessária apenas para hosts de nível 2. No caso do host ser ele mesmo um membro do grupo para o qual um datagrama está sendo enviado, a interface de serviço deve prover uma maneira para que a camada superior possa inibir uma entrega local do datagrama, já que, por default, uma cópia do datagrama é devolvida em loopback. Esta é uma otimização de desempenho para protocolos de camada superior que restrinjam a participação em um grupo, para um processo por host.

EXTENSÕES DO MÓDULO IP

Para suportar o envio de datagramas IP multicast, o módulo IP deve ser estendido de forma a reconhecer endereços IP de grupo quando do roteamento de datagramas a serem enviados. Abaixo, é ilustrada uma implementação IP típica:

Se (Destino-IP está na mesma rede) envie o datagrama localmente para o destino IP

Senão envie o datagrama localmente para o roteador (Destino-IP)

Para permitir transmissões multicast, esta lógica deveria ser trocada para:

Se (Destino-IP está na mesma rede local)

ou (Destino-IP é um endereço de grupo multicast)

Envie o datagrama localmente para o Destino-IP

Senão

Envie o datagrama localmente para o roteador (Destino IP)

O endereço de origem do datagrama enviado deve ser um dos endereços individuais correspondentes à interface de saída. Um endereço de grupo multicast jamais deve ser usado como endereço de origem em um datagrama IP.

EXTENSÕES DA INTERFACE DE SERVIÇO DE REDE LOCAL

Não se faz necessária nenhuma alteração na Interface de Serviço de Rede Local para o suporte ao envio de datagramas multicast em IP. O módulo IP simplesmente especifica um endereço de grupo multicast como endereço de destino, ao invés de um endereço IP de nó individual quando invoca sua operação “Envie Local”.

EXTENSÕES PARA O MÓDULO DE REDE LOCAL ETHERNET

A IANA teve alocada para si uma porção do espaço de endereçamento multicast da camada MAC IEEE-802 (FDDI, Ethernet, etc.). Os endereços do bloco reservado à IANA começam com 01-00-5E (hex). Um procedimento bastante simples foi desenvolvido para mapeamento de endereços classes D neste bloco de endereços reservados. Isto permite que o multicast em IP tome vantagem do suporte ao multicast oferecido, a nível de hardware, pelas interfaces de rede e dispensa a necessidade da criação de um protocolo específico para resolução de endereços multicast (como o ARP para unicast).

Um endereço de grupo IP é mapeado em um endereço Ethernet, inserindo-se os 28 bits de mais baixa ordem do mesmo nos 23 bits de mais baixa ordem ordem do bloco de endereços reservado à IANA. A Figura 1 mostra como o endereço de grupo multicast IP 224.10.8.5 (E0-0A-08-05) seria mapeado em um endereço multicast Ethernet (IEEE 802).

Figura 1: Mapeamento entre Endereços IP Multicast e IEEE802.3

O mapeamento da figura simplesmente colocou os 23 bits de mais baixa ordem do datagrama IP multicast nos 23 bits de mais baixa ordem do endereço Ethernet. Como os cinco bits de mais alta ordem do endereço multicast IP são ignorados no mapeamento, até 32 endereços de grupo IP podem ser mapeados no mesmo endereço Ethernet. Por exemplo, os endereços multicast IP 224.138.8.5 (E0-8A-08-05) e 225.10.8.5 (E1-0A-08-05) seriam mapeados no mesmo endereço Ethernet mostrado no exemplo (01-00-5E-0A-08-05). Se, por uma coincidência muito grande, dois ou mais grupos na mesma LAN tiverem endereços de grupo IP que sejam mapeados no mesmo endereço MAC, os membros desses grupos receberão tráfego não desejado. Neste caso, ficará por conta da camada IP decidir que pacotes devem, ou não, ser descartados.

EXTENSÕES PARA MÓDULOS DE OUTRAS REDES LOCAIS

Outras redes locais que suportem multicast diretamente, como token-ring ou token-bus, devem ser tratadas da mesma maneira que a Ethernet para o envio de datagramas multicast IP.

Em uma rede local que suporte broadcast, mas não multicast, todos os endereços de grupos multicast IP devem ser mapeados em um único endereço broadcast (ao custo de aumento de tráfego desnecessário). Para um link ponto-a-ponto unindo dois hosts (ou um host e um roteador multicast), o tráfego multicast deve ser transmitido exatamente como o unicast. Para uma rede store-and-forward como a X-25 pública, todos os endereços de grupos IP devem ser mapeados para um endereço local pré-estabelecido de um roteador multicast IP. Nessas redes, o roteador multicast tomará para si toda a responsabilidade pelo complemento de entrega, tanto dentro da rede, como entre redes.

Suporte total ao tráfego Multicast em IP

EXTENSÕES DA INTERFACE DE SERVIÇO IP

Datagramas multicast em IP são recebidos pelos módulos de protocolos das camadas superiores usando a mesma operação “Receber IP” usada para datagramas unicast. A seleção de um protocolo de camada superior é feita com base no campo protocolo do cabeçalho IP, independentemente do endereço IP de destino. Todavia, antes que qualquer datagrama destinado a um determinado grupo possa ser recebido, um protocolo de camada superior deve solicitar ao módulo IP que se junte a esse grupo. Logo, a interface de serviço IP deve ser estendida para prover duas novas operações:

JoinHostGroup (Endereço de Grupo, Interface)

LeaveHostGroup (Endereço de Grupo, Interface)

A operação JoinHostGroup solicita que o host se torne um membro do grupo multicast identificado pelo endereço “Endereço de Grupo” numa dada interface de rede. A operação LeaveHostGroup solicita que o host deixe de participar do grupo multicast identificado pelo endereço “Endereço de Grupo”. Se o host suportar apenas uma interface, o argumento interface pode ser omitido.

É permissível se juntar ao mesmo grupo em mais de uma interface. Neste caso, datagramas multicast duplicados serão recebidos. Também é permissível que mais de um protocolo de camada superior solicite participação no mesmo grupo.

EXTENSÕES DO MÓDULO IP

Para suportar a recepção de datagramas multicast em IP, o módulo IP deve ser estendido para manter uma lista de participações em grupos associadas com cada interface de rede. Um datagrama destinado a um desses grupo é processado da mesma forma que datagramas destinados a um dos endereços IP individuais do host.

Datagramas destinados a grupos a que o host não pertença devem ser descartados sem geração de relatórios de erro. No caso de hosts com mais de uma interface, se um datagrama chegar através de uma interface, destinado a um grupo ao qual o host pertence apenas em outra interface, o datagrama deve ser descartado. (Esses casos devem acontecer apenas em decorrência de uma filtragem multicast inadequada por parte do módulo de rede local).

Um datagrama não é rejeitado por possuir um time-to-live IP igual a 1 (o time-to-live não deve ser decrementado automaticamente para datagramas de entrada que não forem passados adiante). Um datagrama com um endereço IP de grupo no seu campo “Endereço de Origem” deve ser descartado.

A lista de participações em grupos é atualizada em função de solicitações do tipo JoinHostGroup e LeaveHostGroup provenientes dos protocolos de camada superior. Cada entrada referente à participação em um grupo deve ter associada a si um mecanismo contador para lidar com solicitações múltiplas de entrada e saída de um mesmo grupo. O módulo de rede local de uma interface só deve ser notificado quando a primeira solicitação de adesão ou a última de saída de um determinado grupo for recebida.

O módulo IP também deve ser estendido para oferecer suporte ao IGMP, que é usado para manter os roteadores multicast vizinhos informados das participações em grupos multicast presentes em uma rede local em particular. Para suportar o IGMP, todos host nível 2 deve se juntar ao grupo “todos os hosts” (endereço 224.0.0.1) em cada interface de rede durante sua inicialização e deve assim permanecer enquanto o host estiver ativo.

Para o propósito do IGMP a participação no grupo “todos os hosts” só se faz realmente necessária enquanto o host pertencer a pelo menos um grupo multicast. Todavia é especificado que um host deve sempre permanecer membro do grupo “todos os hosts” por três razões:

Simplicidade;
O overhead inerente à recepção de interrogações IGMP desnecessárias será muito pequeno, pois a freqüência dessas indagações é muito baixa;
O endereço “todos os hosts” pode vir a ter outros propósitos, como advertência sobre a existência de gateways ou resolução de endereços locais.

EXTENSÕES DA INTERFACE DE SERVIÇO DE REDE LOCAL

Pacotes multicast são entregues ao módulo IP usando a mesma operação “Receber Local” utilizada para pacotes unicast. Para permitir ao módulo IP especificar quais pacotes multicast deverão ser aceitos, a Interface de Serviço de Rede Local deve ser estendida para suportar duas novas operações:

JoinLocalGroup (Endereço de Grupo)

LeaveLocalGroup (Endereço de Grupo)

Onde o “Endereço de Grupo” é o endereço IP do grupo em questão. A operação JoinLocalGroup solicita que o Módulo de Rede Local aceite pacotes destinados a esse endereço de grupo IP. A operação LeaveLocalGroup solicita que o Módulo de Rede Local pare de passar para a camada superior pacotes destinados ao endereço especificado. O Módulo de Rede Local deve mapear o endereço de grupo IP para um endereço de rede local para atualização de seu filtro de recepção multicast. Se um módulo de Rede Local for incapaz de filtrar pacotes, ele estará livre para ignorar mensagens do tipo LeaveLocalGroup e passar para a camada superior pacotes destinados a mais endereços do que aqueles especificados nas solicitações JoinLocalGroup.

O módulo de Rede Local não deve entregar à camada superior pacotes multicast que forem transmitidos do próprio módulo. O processo de loopback de multicasts deve ser implementado na camada IP ou superior

EXTENSÕES PARA O MÓDULO DE REDE LOCAL ETHERNET

Para suportar a recepção de datagramas multicast em IP, um módulo Ethernet deve ser capaz de receber pacotes destinados a endereços multicast Ethernet que correspondam aos endereços IP de grupos dos quais o host participe. É altamente recomendado que se aproveite qualquer facilidade de filtragem de endereços que o hardware das redes Ethernet possa ter, de modo que os hosts recebam apenas aqueles pacotes que realmente são de seu interesse

Algumas interfaces Ethernet possuem um limite pequeno com relação ao número de endereços que o hardware pode ser configurado para reconhecer. Todavia, uma implementação deve ser capaz de “ouvir” um número arbitrário de endereços multicast Ethernet, o que pode significar um abertura total do filtro para aceitação de qualquer pacote multicast durante os períodos em que o número de endereços exceda o limite do filtro.

Para as interfaces que apresentem a limitação de filtragem citada acima, pode ser preferível (por questões de desempenho) realizar a filtragem de endereços Ethernet pelo software do módulo Ethernet.No entanto, isto não é obrigatório, pois o módulo IP realiza sua própria filtragem baseada nos endereços IP de destino.

EXTENSÕES PARA MÓDULOS DE OUTRAS REDES LOCAIS

Outras redes locais multicast, podem ser lidadas da mesma forma que a Ethernet no que diz respeito ao recebimento de datagramas IP multicast. Para redes locais que são baseadas puramente em broadcasts, todos os pacotes broadcast de entrada devem ser aceitos e passados ao módulo IP para filtragem a nível IP. Em redes ponto-a-ponto e store-and-forward, datagramas multicast em IP chegarão como unicasts provenientes da rede local, logo nenhuma mudança será necessária ao Módulo de Rede Local.

IGMP replay

O suporte a multicast se tornou uma importante característica, tanto de redes corporativas, como de provedores de serviço Internet. O Internet Group Mangement Protocol (IGMP) Relay (IGMP-R) oferece aos usuários as funcionalidades do roteamento multicast sem a complexidade da escolha e configuração de um protocolo de roteamento multicast como MOSPF, DVMRP, PIM, etc.

Um dispositivo que implementa IGMP-R representa as estações finais nas fronteiras da rede. O dispositivo IGMP-R se comporta logicamente como um host conectado diretamente a um dispositivo que efetivamente executa um protocolo de roteamento multicast. Ele é usado para repassar informações de grupo e encaminhar pacotes multicast entre o roteador e as estações finais.

Um dispositivo IGMP-R localiza-se fisicamente entre os hosts IGMP e os roteadores multicast que ele suporta. Considera-se que os hosts se localizam a favor do fluxo (downstream) em relação ao dispositivo IGMP-R e o roteador multicast contra o fluxo (upstream) .

Figura 2: O IGMP-R nas Fronteiras da Rede

A figura acima ilustra o IGMP-R usado nas fronteiras da rede onde nenhum roteamento multicast ocorre.

ENTENDENDO O IGMP RELAY

O dispositivo que implementa IGMP-R representa as estações a ele conectadas. O dispositivo IGMP-R se comporta logicamente como um host conectado diretamente a um roteador multicast. O roteador upstream conectado ao dispositivo IGMP-R também deve implementar as funcionalidades necessárias para implementar protocolos de roteamento multicast específicos.

Figura 3: Diagrama de Suporte ao IGMP-R

O diagrama acima ilustra o passo-a-passo necessário para suportar IGMP-R.

Quando uma estação final executa uma aplicação multicast, ela notifica seu roteador local (IGMP-R) do endereço classe D que ela estará usando, através de um IGMP Host Membership Report para o endereço multicast reservado “todos os roteadores” (224.0.0.2). O dispositivo IGMP-R, por sua vez, enviará um Host Membership Report não solicitado para o roteador multicast.

Quando recebe pacotes multicast, o roteador multicast instala uma rota e os envia para a interface de downstream que o conecta ao dispositivo IGMP-R. O dispositivo IGMP-R encaminhará os dados para a interface correta em direção ao sistema final que se associou àquele grupo multicast.

Quando a estação final envia dados multicast, o dispositivo IGMP-R encaminha os pacotes para o dispositivo de roteamento multicast. Se existir alguma estação associada a este grupo em uma outra interface local downstream do dispositivo IGMP-R, os dados também serão encaminhados para esta interface.

O roteador multicast envia mensagens periódicas na rede que consistem de IGMP Host Membership Queries. O dispositivo IGMP-R, por sua vez, recebe essas mensagens e as repassa as as interfaces apropriadas. O IGMP-R também gera suas próprias mensagens Host Membership Queries.

O IGMP-R faz com que nao seja preciso configurar roteamento multicast nas fronteiras da rede, simplificando, portanto, o projeto, configuração e gerencimento da rede multicast.

FUNÇÕES DO IGMP RELAY

O IGMP-R funcionará como um IGMP Querier e enviará mensagens Membership Queries em todas suas interfaces de downstream. Em cada interface, será armazenado uma tabela com os grupos associados. Quando o IGMP-R receber uma mensagem IGMP através de uma interface downstream, ele atualizará a tabela de grupos de interface de acordo. Se a mensagem for um Group Membership Report para um novo grupo, o IGMP-R inserirá esta nova informação na tabela de grupos. Se a mensagem for uma Group Leave Message para um grupo existente, IGMP-R removerá o grupo da tabela depois enviar algumas mensagens (padrão=2) Last Membership Query Count para verificar se ainda há alguma estação associada a este grupo.

Em um roteador, normalmente, a tabela de grupos de um slot estará em sincronismo com todas as tabelas de grupos de interfaces no slot. Um grupo estará presente na tabela de grupos do slot se, e somente se, ele também estiver presente em alguma tabela de grupos de alguma interface downstream do slot.

A tabela global de grupos estará em sincronismo como todas as tabelas de grupos dos slots. Um grupo estará presente na tabela global se, e somente se, também estiver presente em alguma tabela de grupos de algum slot que contenha interfaces downstream.

O dispositivo IGMP-R, na visão do roteador multicast upstream, funciona como um host IGMP; e um roteador multicast na visão dos hosts. Uma boa associação para entender suas funções é considerá-lo como um Proxy-IGMP.

Se ele receber uma mensagem Membership Query do seu roteador multicast upstream, ele consulta sua tabela global de grupos para saber se deve enviar uma mensagem Membership Report em resposta. Por outro lado, o dispositivo IGMP-R enviará uma mensagem Membership Report não solicitada se um novo grupo for adicionado à tabela global de grupos, ou uma mensagem Group Leave se um grupo previamente existente for removido de sua tabela global.

O dispositivo IGMP-R não executa protocolos de roteamento multicast, o que permite que seja implementado em estações PC de baixo custo.

ENCAMINHAMENTO MULTICAST ATRAVÉS DE IGMP-R

Figura 4: Funcionamento do IGMP-R

Quando o dispositivo IGMP-R recebe um pacote proveniente do seu roteador upstream, ele o encaminhará àquelas interfaces downstream cujas tabelas de grupos contiverem o grupo destino. Entretanto, se o dispositivo IGMP-R determinar que o pacote multicast foi enviado de uma rede downstream, ele será descartado.

Assim, quando o dispositivo IGMP-R receber um pacote através de uma interface downstream, o endereço de origem será verificado. Se este endereço pertencer a uma rede diferente da rede da interface downstream onde ele foi recebido, o pacote será descartado. De outro modo, o dispositivo IGMP-R encaminhará o pacote para sua interface upstream e adicionalmente para àquelas interfaces downstream cujas tabelas de grupos contiverem o grupo destino.

Conclusão

Com este artigo, fechamos a parte introdutória das tecnologias multicast. Nos primeiros três artigos da série, apresentamos o que é multicast, quais as suas aplicações e o seu funcionamento básico em uma rede local. Nos próximos artigos, abordaremos como é montada a árvore de distribuição multicast através de redes WAN, mais especificamente os protoclos de roteamento multicast (DVMRP, PIM, MOSPF, CBT e BGMP). Como o assunto é complexo, haverá um artigo introdutório, dando uma visão geral do funcionamento dos algoritmos inerentes a cada um dos protocolos. Depois, virá um artigo mais profundo focado em cada um deles.

Sites relacionados

Grupo de Trabalho de Engenharia de Redes: http://www.gt-er.cg.org.br/sgt-multicast

MBONE Brasil: http://www.mbone.br

IPMI - IP Multicast Initiative: http://www.ipmulticast.com