Funcionamento do processo de multicast IPv6 em LANs usando o protocolo de controle Multicast Listener Discovery

Luciano Martins <lmartins@cpqd.com.br>
Gilmara Restani <gilmara@cpqd.com.br>
Laura V. Guerrero <laura@cpqd.com.br>
Marcos César Ide <mcide@cpqd.com.br>
Marcel Tokarski <marcel@cpqd.com.br>

GPS
CPqD
Rede Nacional de Ensino e Pesquisa (RNP)

Resumo
1. Introdução
3. O protocolo de controle de grupos MLD
4. Descrição do protocolo MLD
5. Exemplos das funcionalidades do MLD
6. Considerações finais
Referências bibliográficas

Resumo

Este artigo tem como objetivo apresentar o protocolo de controle de grupos MLD (Multicast Listener Discovery) do IPv6, que substituirá o protocolo IGMP (Internet Group Management Protocol) do IPv4, fazendo um paralelo entre os dois protocolos.

^

1. Introdução

Quando o protocolo IP foi projetado, para que houvesse comunicação entre dois hosts na rede surgiram os endereços unicast de classe A (1.0.0.0 a 126.255.255.255), B (128.0.0.0 a 191.255.255.255) e C (192.0.0.0 a 223.255.255.255). Unicast é um tipo de endereçamento com a função de identificar uma única interface da rede, representado no IPv4 pelos endereços de classe A, B e C. No protocolo IPv6 não existe o conceito de classes de endereços, porém a função de seus endereços unicast é exatamente a mesma do IPv4. Entre os diversos tipos de endereços unicast do IPv6, podem-se citar o link-local (fe80::0/10), site-local (fec0::0/10) e aggregatable-global (3ffe:2b00:0000::0/40 por exemplo, para os PoPs da RNP). Artigos anteriores do NewsGeneration fornecem maiores detalhes sobre este assunto [7][8][9].

No IPv4, juntamente com os endereços unicast, existe o tipo de endereçamento broadcast, cuja função é endereçar todas as interfaces de determinado enlace na rede e é utilizado, por exemplo, por protocolos de controle como o ARP. Broadcast não existe mais no IPv6 e a função de endereçar todos os nós, quando necessário, poderá ser realizada com o endereço multicast do IPv6.

O multicast tem a função de endereçar um grupo de uma ou mais interfaces na rede, e no protocolo IPv4 é representado pelos endereços classe D (224.0.0.0 a 239.255.255.255). Os endereços multicast no IPv6 são representados por ff::0/8.

O endereçamento anycast é uma novidade do protocolo IPv6, cuja representação é semelhante aos endereços unicast, porém com funcionalidade diferente. Anycast endereça diversas interfaces em um grupo, porém, apenas uma interface irá receber os pacotes em uma transmissão, geralmente aquela que estiver mais próxima da origem, segundo as métricas do protocolo de roteamento.

Cada um dos tipos de endereços é útil para casos diferentes de comunicações, sendo que o multicast possui vantagens para conexões que necessitem de economia de largura de banda e tenham diversos ouvintes que irão receber os mesmos dados simultaneamente. Um bom exemplo é a transmissão de vídeo para diversas localidades [6].

Quando se pensa no assunto multicast, tem-se que ter em mente dois fatos. O primeiro é a necessidade de um protocolo de controle que gerencie a entrada e saída de ouvintes de um grupo em uma LAN e o segundo é a necessidade de um protocolo de roteamento multicast para que o tráfego multicast possa atingir redes externas (WAN).

O protocolo de controle de grupos do protocolo IPv4 é o Internet Group Management Protocol (IGMP) que, no IPv6, foi substituído pelo protocolo Multicast Listener Discovery (MLD). Em relação aos protocolos de roteamento multicast, existem diversos que usam IPv4, tais como o Distance Vector Multicast Routing Protocol (DVMRP), Protocol Independent Multicast Dense Mode (PIM-DM) e Sparse-Mode (PIM-SM), dentre outros. Para o IPv6, os protocolos de roteamento multicast são semelhantes ao IPv4, porém com as devidas modificações para suportar o endereçamento IPv6 de 128 bits. Um exemplo é o PIM versão 6 (PIMv6).

A Figura 1 ilustra os dois níveis de protocolos:

Figura 1 - Níveis de protocolos para multicast

Em [1][2][3] há discussões do protocolo IGMP versão 1 e IGMP versão 2, além de informar o que é necessário para se realizar uma comunicação utilizando endereçamento multicast, onde fica claro que é possível uma comunicação multicast sem a existência de um roteador executando um protocolo de roteamento, sendo suficiente, para isto, máquinas conectadas em um enlace e habilitadas a "ouvirem" endereços multicast.

Como exemplo, suponha que uma instituição possua uma Intranet com apenas uma rede e queira realizar comunicação multicast com diversas máquinas, como ilustrado na Figura 2 (nos exemplos deste artigo, os hosts das figuras representarão ouvintes de grupo(s) multicast; supostamente estas redes teriam outras máquinas "não-ouvintes").

Figura 2 - Cenário de Intranet com uma rede para comunicação multicast

Neste caso, para que o multicast aconteça, o roteador não terá papel importante no processo, já que apenas as máquinas internas da rede irão se comunicar. Os hosts teriam suporte a multicast, possuindo um sistema operacional que implemente o protocolo IGMP (para IPv4), ou MLD (para IPv6).

No caso da Intranet possuir diversas sub-redes, será necessário um roteador com um protocolo de roteamento multicast para transmitir o fluxo multicast para as sub-redes que possuírem ouvintes de grupos e com um protocolo de controle para gerenciar os endereços de grupos multicast que estão ativos no enlace, além das máquinas munidas do protocolo de controle. No caso da transmissão multicast ocorrer entre máquinas de várias Intranets através da Internet, a necessidade de roteadores com capacidades para multicast será de fundamental importância. A Figura 3 ilustra este cenário:

Figura 3 - Cenário de comunicação multicast com diversas redes diferentes

O foco deste artigo está no protocolo de controle MLD, que gerencia grupos multicast em um enlace e algumas diferenças entre ele e seu antecessor IGMP. A apresentação de protocolos de roteamento multicast do IPv6 será feita em artigos futuros.

^

3. O protocolo de controle de grupos MLD

No IPv4, existe o protocolo de controle de grupos IGMP, que é executado nos roteadores e hosts de uma determinada rede local. Com a chegada do protocolo IPv6, o IGMP deu lugar a um novo protocolo chamado Multicast Listener Discovery (MLD), que possui diversas semelhanças e é derivado das versões 1 e 2 de seu antecessor [10][11].

O MLD é utilizado por um roteador IPv6 para descobrir a presença de nós que desejam receber pacotes multicast (ouvintes multicast) e estejam no mesmo enlace do roteador. Além disso, é utilizado por hosts, para anunciarem a necessidade de receber um fluxo de pacotes multicast de determinado endereço de grupo [12].

A principal diferença entre o MLD e o IGMP se encontra no formato das mensagens e no formato do endereçamento. O MLD utiliza mensagens ICMPv6 (Internet Control Management Protocol version 6), ao contrário do IGMP, que possui mensagens independentes do protocolo ICMP [12].

No protocolo IGMP versão 1, o formato das mensagens é ilustrado na Figura 4 [2]:

Figura 4 - Formato das mensagens IGMP versão 1

Nesta versão, o campo TYPE poderá conter apenas duas opções de mensagens:

• Type = 1: Host Membership Query
• Type = 2: Host Membership Report
  

O campo GROUP ADDRESS será zerado se Type = "1" e conterá um endereço classe D se Type = "2".

Na versão 2 do IGMP, o formato das mensagens serão como ilustrado na Figura 5 [2]:

Figura 5 - Formato das mensagens IGMP versão 2

Percebe-se que os campos VERSION e TYPE da versão 1 foram combinados em um único campo TYPE na versão 2. O campo UNUSED foi substituído pelo campo MAX RESPONSE TIME, que terá significado para as mensagens Host Membership Query. Além destas, são significantes as seguintes diferenças entre o protocolo IGMP versão 1 e 2:

• Um novo tipo de mensagem foi criado, a Leave Group Message, que permitirá que um host, explicitamente, informe aos seus companheiros de grupo e ao roteador que não quer mais receber pacotes endereçados a determinado endereço multicast;
• O processo de eleição de um roteador Querier (que realiza buscas de informações sobre grupos multicast) foi padronizado, criando-se um mecanismo que permite apenas um Querier por rede;
• Novos valores para TYPE:
  
  • Type = 11: Host Membership Query (General Query e Group-Specific Query);
  • Type = 16: Host Membership Report Version 2;
  • Type = 17: Leave Group

Dada uma visão geral das diferenças entre o protocolo IGMPv1 e IGMPv2, iniciaremos um detalhamento do protocolo MLD, que é muito semelhante ao protocolo IGMPv2.

O protocolo MLD utiliza o formato de mensagens do ICMPv6, como ilustra a Figura 6 [13]:

Figura 6 - Formato das mensagens MLD

Existem três tipos de mensagens MLD:

• Multicast Listener Query (type = 130): Semelhante à mensagem Host Membership Query do IGMPv2. Usada pelo roteador para buscar ouvintes multicast em um enlace. Possui dois tipos:
  • General Query: usado para aprender quais endereços multicast têm ouvintes no enlace;
  • Multicast-Address-Specific Query: usada para aprender se um endereço multicast particular tem algum ouvinte em um enlace;
• Multicast Listener Report (type = 131): Semelhante à mensagem Host Membership Report version 2 do IGMPv2. Usada por ouvintes multicast para reportarem interesse em receber o tráfego multicast para endereços específicos, ou para responderem a uma query;
• Multicast Listener Done (type = 132): Semelhante à mensagem Leave Group do IGMPv2. Usada por um ouvinte que queira deixar de receber tráfego de certo endereço multicast.

O campo CODE da mensagem ICMPv6 do MLD deve ser "0".

O campo MAXIMUM RESPONSE DELAY é significativo apenas em mensagens Query e especifica o máximo de atraso permitido antes que um ouvinte envie um Report, em milisegundos. Em todas as outras mensagens, é configurado para "0" pelo emissor e ignorado pelos receptores.

O campo GROUP ADDRESS IPv6, em uma mensagem Query, é configurado como "::" quando é General Query e configurado com um endereço IPv6 multicast específico quando envia uma Multicast-Address-Specific Query. Em uma mensagem Report ou Done, este campo deve conter um endereço multicast específico de um grupo que o emissor está ouvindo ou está parando de ouvir, respectivamente.

Uma visualização resumida das principais características e diferenças entre o IGMPv1, IGMPv2 e MLD é mostrada na tabela a seguir:

Tabela 1 - Diferenças entre IGMPv1, IGMPv2 e MLD

^

4. Descrição do protocolo MLD

Cada roteador mantém uma lista, para cada enlace, dos endereços multicast que possuem ouvintes naquele enlace, e um timer associado a cada um dos endereços. O roteador precisa aprender apenas se os ouvintes de algum endereço multicast existem ou não, sendo desnecessário o aprendizado da identidade (endereço unicast) dos ouvintes, ou quantos ouvintes estão presentes [12][13].

Para cada enlace conectado, o roteador seleciona um de seus endereços unicast link-local para ser usado como endereço de origem em todos os pacotes MLD que forem transmitidos naquele enlace.

Para cada interface executando o protocolo MLD, o roteador deve configurar a interface para ouvir todos os endereços multicast de camada de enlace que possam ser gerados pelos endereços multicast IPv6. No caso do Ethernet, o endereço iniciará com o hexadecimal 0x3333.

Um roteador pode ser, ou não, um pesquisador (Querier), existindo, geralmente, um Querier por enlace. Todos os roteadores, assim como no IGMPv2, iniciam sendo um Querier. Caso este roteador receba uma mensagem Query de outro roteador com endereço IPv6 numericamente menor, se tornará Non-querier. Um roteador Non-querier terá a função de "espelho" do Querier, que se tiver algum problema e parar de enviar mensagens Query, será substituído pelo roteador Non-querier.

Um Querier envia periodicamente, em um enlace, uma mensagem General Query para solicitar informações para todos os endereços multicast de interesse naquele enlace. No startup, um roteador deve enviar mensagens General Query para todos os enlaces conectados para que, rapidamente, descubra a presença de ouvintes multicast naqueles enlaces. As mensagens General Query são enviadas para o endereço multicast all-nodes do enlace (FF02::1), com o campo GROUP ADDRESS IPv6 com valor "::" e com um tempo de atraso para a resposta do ouvinte no campo MAXIMUM RESPONSE DELAY.

Quando um nó recebe uma mensagem General Query, ele configura um timer de atraso para cada endereço de multicast que está ouvindo na interface, excluindo os endereços all-nodes de escopo local e qualquer endereço de escopo "0" (reservado) ou "1" (node-local). Cada timer é configurado com um valor aleatório diferente, selecionado do intervalo [0, MAXIMUM RESPONSE DELAY].

Quando um nó recebe uma mensagem Multicast-Address-Specific Query, se ele estiver ouvindo tal endereço na interface, irá configurar um timer de atraso para este endereço. Se um timer para o endereço já estiver executando, é configurado para o novo valor aleatório apenas se o MAXIMUM RESPONSE DELAY for menor que o valor corrente.

Se um timer em uma interface expirar, para um endereço multicast em particular, o nó transmite um Report para aquele endereço. O endereço sendo reportado é carregado nos endereços IPv6 de destino e no campo GROUP ADDRESS IPv6 do pacote Report.

Se um nó tiver um timer executando para determinado endereço IPv6 multicast e receber um Report de outro nó para o mesmo endereço naquela interface, ele pára seu timer e não envia Report para aquele endereço, evitando duplicação deste tipo de mensagens no enlace.

Quando um roteador receber um Report de um nó no enlace, se o endereço reportado já não estiver presente na lista de endereços multicast com ouvintes do roteador, será adicionado à lista. Além disso, seu timer será configurado para o valor "Multicast Listener Interval" e notificará os protocolos de roteamento multicast sobre o novo endereço inserido. Se o endereço reportado já existir na lista, o timer para aquele endereço é re-configurado com o valor "Multicast Listener Interval". Se o timer do endereço expirar, assume-se que não existem mais ouvintes para o endereço apresentado no enlace e é apagado da lista e o protocolo de roteamento multicast é avisado.

Quando um nó começa a ouvir um endereço multicast em uma interface, ele deve imediatamente transmitir um Report não solicitado para aquele endereço, e este processo deve se repetir uma ou duas vezes em curto intervalo de tempo, para não haver problema de perda deste Report.

Quando um nó parar de ouvir um endereço multicast em uma interface, ele deve enviar uma mensagem Done para o endereço multicast all-routers do enlace, carregando no campo Multicast Address o endereço em que se está deixando de ouvir. No caso deste nó ter recebido um Report de outro nó, a implementação não necessita enviar uma mensagem Done, já que é muito provável que ainda haja ouvinte para aquele endereço no enlace.

Se um roteador for um Querier e receber uma mensagem Done de um nó e o endereço multicast identificado na mensagem estiver na lista do roteador, ele enviará uma mensagem Multicast-Address-Specific Query para verificar se ainda existe algum ouvinte daquele endereço no enlace. Se após um certo intervalo, o roteador não receber Report de nenhum nó, ele assumirá que não há mais ouvintes para aquele endereço, e apagará a entrada de sua lista. O protocolo de roteamento multicast terá conhecimento disto também.

^

5. Exemplos das funcionalidades do MLD

Nesta seção serão apresentados alguns exemplos, através de gráficos, das principais funcionalidades do protocolo de controle MLD.

Escolha de um roteador Querier:

1. Em uma rede com 2 roteadores no enlace, um roteador é ligado e outro está desligado. Ao ser ligado, o Querier envia uma mensagem General Query.	2. O segundo roteador é ligado, e possui um endereço IPv6 de valor numericamente menor . Este envia uma General Query, e quando o roteador Querier receber esta mensagem e perceber que o endereço de origem é menor que o seu, passará para o estado Non-querier. Assim, o roteador que foi ligado será, agora, o novo Querier.

General Query periódica :

1. O roteador Querier envia, de tempos em tempos, segundo um timer, General Queries em busca de endereços multicast que possuem ouvintes no enlace.

2. Cada host inicializa um timer para cada um dos endereços de grupo que está unido, e quando este timer expira, o host enviará um MLD Report para tal endereço. As máquinas que ouvirem e pertencerem a este grupo irão parar o timer referente a este grupo para evitar duplicação, e os roteadores irão atualizar suas tabelas. Na figura abaixo, o timer do grupo 2 (G2) "zerou" e o host enviou um Report. Conseqüentemente, os outros hosts que também recebem as mensagens deste grupo, páram o timer deste endereço. Os roteadores atualizam a entrada referente a este endereço, re-configurando seu timer.

Host entrando em um grupo:

1.Um host envia um Report para todos os elementos do grupo, anunciando o desejo de começar a receber pacotes de um endereço de um grupo 4 (G4), por exemplo.	2. Os roteadores atualizam sua tabela de grupos e anunciam ao protocolo de roteamento multicast a entrada do novo endereço.

Host saindo de um grupo:

1. Um host envia uma mensagem Done para todos do grupo.	2. O roteador Querier envia uma mensagem Multicast Address Specific Query e inicia um timer esperando um Report de algum host no enlace.
3. Como, neste exemplo, não há mais hosts unidos ao grupo 2 (G2), nenhum Report em resposta à query é enviado pelos hosts. Assim, o timer esgotado e os roteadores apagam entrada da tabela.

^

6. Considerações finais

O protocolo de controle de grupos multicast no IPv6, o MLD, é muito semelhante ao protocolo IGMPv2 do IPv4. A grande diferença se encontra no formato das mensagens e no formato do endereçamento, e tais diferenças foram citadas neste artigo. O MLD utiliza mensagens do ICMPv6, e não próprias do protocolo, como acontece no IGMPv2.

Em relação à funcionalidade propriamente dita, percebe-se que não houve grandes modificações entre MLD e IGMPv2. Este artigo teve como principal objetivo mostrar o funcionamento do protocolo MLD, fazendo algumas comparações com seus antecessores IGMPv1 e IGMPv2.

Por fim, a funcionalidade de multicasting em uma rede é bastante importante e, segundo os padrões sendo desenvolvidos pelo IETF (Internet Enginnering Task Force) e contempladas nas RFCs (Request for Comments), percebe-se que o IPv6 pretende que dispositivos de rede tenham um maior desempenho, inclusive no que diz respeito ao multicasting.

^

Referências bibliográficas

[1] Reinaldo Penno Filho, O que existe por trás da Tecnologia MBONE? NewsGeneration, vol.1, n.4, setembro de 1997.

[2] Reinaldo Penno Filho, Internet Group Management Protocol - versão 1 e 2 e Real Time Protocol (RTP, NewsGeneration, vol.2, n.1, janeiro de 1998.

[3] Reinaldo Penno Filho, MBone Parte III , NewsGeneration, vol.4, n.2, março de 2000.

[4] Fabiano Bachmann et all, Endereçamento Multicast e Aplicações Multimídia Distribuídas na RMAV-FLN , NewsGeneration, vol.4, n.4, julho de 2000.

[5] Valter Roester, Transmissão Multimídia em redes de computadores: um relato para redes locais e Internet 2 , NewsGeneration, vol.4, n.4, julho de 2000.

[6] Elvis Melo Vieira et. all, Experiência de transmissão multicast inter-domínio no XIX SBRC , NewsGeneration, vol.5, n.4, julho de 2001.

[7] Adailton J.S. Silva, O que vai mudar na vida com o IPv6 , NewsGeneration, vol.1, n.2, junho de1997.

[8] Frank Ned, A nova geração de protocolos IP , NewsGeneration, vol.2, n.8, novembro de 1998.

[9] Adailton J.S. Silva e Marcel R. Faria, Hierarquia de Endereços IPv6 , NewsGeneration, vol.5, n.2, março de 2001.

[10] S.Deering, Host Extensions for IP Multicasting, RFC 1112, agosto de 1989.

[11] W Fenner, Internet Group Management Protocol Version 2, RFC 2236, novembro de 1997.

[12] S.Deering e Conta, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 2463, dezembro de 1998.

[13] S.Deering et all, Multicast Listener Discovery (MLD) for IPv6, RFC 2710, outubro de 1999.

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004