IGMP - Internet Group Management Protocol
Pela referencia ao Wikipedia
IGMP é uma sigla para o inglês Internet Group Management Protocol é um protocolo participante do protocolo IP e sua função é controlar os membros de um grupo de multicast IP, gerenciando os grupos de multicast controlando a entrada e a saída de hosts deles.
Este protocolo pode ser utilizado para aproveitar melhor os recursos de uma rede de modo a informar roteadores a enviar o multicast apenas para os hosts pertencentes aos grupos. Pode ser usado para jogos em rede ou distribuição de vídeo pela rede.
Por questões de segurança, pode ser desativado pois pode permitir alguns ataques.
Fonte: http://pt.wikipedia.org/wiki/Internet_Group_Management_Protocol
Resumo baseado em um documento do CBPF
A entrega Multicast IP é seletiva: apenas estações interessadas podem receber tráfego dirigido a um dado grupo. Almejando implementar essas árvores de distribuição seletiva, que apenas atingem os membros do grupo, torna-se básico que os membros devem informar os routers onde estão, e que grupo(s) lhe(s) interessa(m).
Como é sabido, os grupos multicast são dinâmicos, a constituição dos grupos é variável, o status de cada grupo deve ser conhecido por quem tem de entregar os pacotes multicast: os routers.
O IGMP - Internet Group Management Protocol, permite às estações agregarem-se e abandonar grupos multicast. Enviando um relatório de associação ou parceria (membership report) ao router de vizinhança imediata, uma estação informa o router que deseja fazer parte de um grupo multicast. Os routers transmitem periodicamente mensagens com interrogações de parceria (membership query) para determinar quais os "host groups" que têm membros nas suas redes diretamente conectadas.
Um host responde com um membership report para cada grupo ao qual pertence. Para limitar o número membership reports, cada estação inicia uma espera de tempo aleatório depois de ter recebido o membership query.
As estações "vasculham" o meio tomando conhecimento dos relatórios de parceria enviados ao router; se um relatório é submetido para o grupo ao qual a estação pertence o seu tempo de espera expira, e cancela o seu relatório para o grupo. Este mecanismo assegura apenas um membership report é gerado por cada grupo. Baseado nas informações das constituições dos grupos fornecidas através do IGMP, os routers estão capacitados para determinar que tráfego multicast (se houver algum) se deve encaminhar para as redes interligadas.
Figura 1 - Mensagem de interrogação.
Quando o software aplicacional pede ao software de rede da estação para esta se
juntar a um grupo multicast, uma mensagem IGMP é enviada ao router mais próximo
(se o host não for já um membro do grupo). Ao mesmo tempo, o endereço multicast de
classe D do grupo ao qual se junta é mapeado como um endereço de baixo nível e a
interface da rede é programada para aceitar pacotes para esse endereço.
Por exemplo, se uma estação passa a integrar um grupo num interface Ethernet, os 23
bits mais baixos do endereço de classe D são mapeados aos 23 bits mais baixo do
endereço Ethernet. Devido a esta filtragem de endereços multicast por hardware, um
router não necessita manter uma lista detalhada das estações que pertencem a cada
endereço de grupo, mas apenas esse membro, pelo menos, do grupo, está presente na
sub-rede à qual se encontra vinculado.
IGMP v1
Uma das fraquezas da primeira versão do IGMP era a latência elevada
associada com o término de sessões multicast. Depois do último membro de um grupo
multicast numa sub-rede ter abandonado o grupo, os outros routers não são
imediatamente notificados para deter a propagação de tráfego para o grupo. Esta demora
era causada pelo IGMP esperando até que várias interrogações indicassem que não
restavam membros na sub-rede, de um grupo em particular. No entanto,
indesejavelmente, tráfego desnecessário seria encaminhado para a sub-rede. O custo
deste envio inútil podia ser elevado, particularmente num segmento da Internet com
largura de banda constrangida.
IGMP v2
A versão 2 do IGMP, apresenta alguns refinamentos que ajudaram a reduzir o overhead do protocolo. As mensagens de interrogação dirigidas a grupos
específicos (Group Specific Query Message) permitem ao router interrogar grupos
específicos nas redes onde estão diretamente vinculados em vez de serem forçados a
interrogar todos os grupos indiscriminadamente. Começando com a versão 2, o término
de uma sessão multicast já não é feito de forma passiva. O último host de uma sub-rede
a deixar o grupo multicast, transmite uma mensagem de saída de grupo (Leave Group)
ao router na qual é indicado qual o grupo abandonado. Depois de verificar a partida
com uma mensagem de interrogação dirigida a esse grupo específico, o router notifica
outros routers para cessarem o encaminhamento de tráfego para a sub-rede dirigido ao grupo.
IGMP v3
A versão 3 do IGMP vai mais longe na redução do overhead. A largura de banda
será conservada pela mensagem Group-Source Report que permitirá às estações receber
tráfego de fontes específicas de um grupo multicast. Em versões prévias do IGMP, o
tráfego de todas as fontes tinha de ser encaminhado para uma sub-rede mesmo se as
estações estivessem apenas interessadas em receber tráfego de fontes específicas. As
mensagens Leave-Group apresentadas em primeira instância pela versão 2 foram
também aperfeiçoadas para permitir às estações largar um grupo inteiro ou para
especificar a fonte a que queriam renunciar.
Levando-se em conta que as versões recentes do IGMP podem reduzir o tráfego
desnecessário, otimizando a utilização deste protocolo, deve ser favorecida a sua
utilização em detrimento das anteriores.
Pelos métodos acima mencionados, os routers multicast estão habilitados a
manter, por interface, uma tabela atualizada contendo os grupos cujo tráfego tem
interesse para a sub-rede pela qual, após a recepção de pacotes multicast, os mrouters
sabem para que interfaces os pacotes devem ser encaminhados.
Possibilidades de erros
Como não existe nenhum mecanismo de alocação de endereço multicast pode
ocorrer de existirem dois grupos distintos utilizando o mesmo endereço. A única
solução para este fato é confiar na probabilidade baixíssima de que dois grupos
sejam formados no mesmo instante, com o mesmo endereço em locais próximos.
Como um host vai descobrir o endereço para onde estão sendo enviados os pacotes
de um grupo, já que os endereços são alocados dinamicamente ? A solução é
implementar um mecanismo onde as sessões multicast sejam anunciadas e esta
informação seja espalhada pela Internet.
Nem todos os roteadores IP dão suporte a multicast Com isso, se um roteador
que não suporta multicast receber um pacote com o endereço destino da classe D,
ele não encontrará um caminho para enviar este pacote e então será descartado.
Observações importantes
Observar que quando um pacote destinado a um endereço multicast chega em uma
LAN, o tratamento dado a ele é o mesmo que no caso de um pacote com endereço
broadcast. Porém, ao invés de todos os usuários lerem aquele único pacote que está
circulando na rede, somente as estações que desejarem recebe-lo o armazenarão
(figura 2). Com isso È possÌvel observar que a economia não é realizada somente na
subrede de comunicação, mas sim também na rede local porque se não existisse este
mecanismo, vários pacotes com a mesma informação deveriam ser replicados para
cada estação que desejasse recebe-lo.
Figura 3 – circulação de mensagem Mbone
Para monitorarmos o tráfego IGMP na rede, bastaria digitar:
%tcpdump ip proto igmp
As estatísticas IGMP podem ser obtidas pelo comando “netstat –p igmp”.
Referências Bibliográficas
[1] Claudio G. Mello, Gustavo H. M. B. Carneiro, Paulo R. Lira Gondim – Implantação de
um nó mbone do IME
[2] Sérgio Alipi Domingues Deusdado – Integração adaptativa de aplicações multicast para
conferencia multimídia
[3] http://mesonpi.cat.cbpf.br/mcast
Fonte: http://www.cbpf.br/~sun/pdf/igmp.pdf
Artigo do site da CISCO que abrange sobre o IGMP Multicast
