IGPM Snooping - Tratamento de tráfego de pacotes multicast.
Autor: Pierre Ruoccolo | Publicado: 2009-11-29T13:53:00-02:00

INTRODUÇÃO

O multicast foi criado com objetivo de otimizar a&nbsp;transmissão de&nbsp;dados de um host A para N hosts sem a necessidade de que o host A repita a mensagem para cada um dos&nbsp;hosts destinatários e também de uma forma que o host A não precise propagar&nbsp;a mensagem para todos os hosts da rede.

Com isso, o formato da mensagem multicast possui como destino um IP a ser consumido pelo&nbsp;grupo de hosts interessados na informação produzida (1).
As principais&nbsp;aplicações para o tráfego multicast são as transmissões de vídeo e audio, onde&nbsp;o&nbsp;host que está gerando a informação não necessariamente precisa definir quem estará recebendo.&nbsp;Ele envia&nbsp;os dados a um endereço IP de multicast, que será&nbsp;divulgado para várias rotas sem&nbsp;que o conteúdo seja transmitido. Nas rotas onde&nbsp;houver&nbsp;host interessado em consumir esse dado,&nbsp;ele sinaliza e a partir&nbsp;dessa solicitação&nbsp;os roteadores e switches encaminham essa informação ao mesmo.
É importante destacar que para o switch direcionar o tráfego multicast, este também deve possuir a funcionalidade para tratamento IGPM Snooping, recebendo as informações dos grupos muticast do roteador e encaminhando corretamente o tráfego, conforme demonstrado na Figura 1.


Figura 1: Diagrama de representação do tráfego multicast com switch de Layer 3 e Layer 2. Fonte: Wikipedia

O USO DO MULTICAST &nbsp;EM PROTOCOLOS INDUSTRIAIS

Com a utilização das redes IP para aplicações de controle industriais, alguns protocolos passaram a utilizar essa funcionalidade para adaptar o conceito de produtor/consumidor para as redes IP.
Um exemplo disso é o protocolo EthertNet/IP® da ODVA, onde as mensagens do tipo produtor/consumidor sobre redes IP utilizam o método de multicast para transmissão, dispensando dessa forma a repetição da mensagem para cada destinatário, otimizando o trafego e até mesmo o processamento da CPU.

O PROBLEMA

Se a rede onde o dispositivo gerador de tráfego multicast não for&nbsp;preparada para essa finalidade, os switches ou bridges podem transformar esse tráfego em broadcast, repetindo a mensagem para todos os elementos da rede, perdendo dessa forma a eficiência buscada pelo protocolo, do ponto de vista da rede.
Outro fator relevante é que a maioria das redes industriais são confinadas a um único domínio de broadcast, muitas vezes não possuindo roteadores ou switches de Layer 3 para identificar os grupos de mensagens multicast através do IGPM poll.
É&nbsp;bom&nbsp;lembrar que o&nbsp;tráfego multicast seria normalmente tratado pelos roteadores ou switches de Layer 3 em redes IP segmentadas, como é o caso da Internet, ambiente para qual o multicast foi idealizado.

A SOLUÇÃO

Com objetivo de tratar essa anomalia, diversos switches de mercado são fornecidos com funcionalidade para tratamento do multicast através do IGPM Snooping, porém,&nbsp;se a rede não possuir um dispositivo de&nbsp;Layer 3, para identificar os grupos multicast,&nbsp;o switches&nbsp;deve oferecer&nbsp;suporte a&nbsp;IGMP querier mode (3), &nbsp;pelo menos em redes Ethernet industriais que utlizam EtherNet/IP® por exemplo, que adota IGMPv1.
Dessa forma cumpre-se a misão do&nbsp;IGPM Snooping que tem o propósito de evitar&nbsp;a inundação de tráfego multicast para todas as portas do switch, alterando&nbsp;dinâmicamente o comportametno das portas que recebem multicast. (2)
Mas não é tão simples. A implementação do multicast em redes industriais deve ser monitorada com analizador de rede para detectar possiveis ocorrências de flood - difusão indesejada&nbsp;para todas as portas do switch, afim de buscar a melhor configuração para a rede.


Bibliografia: 

(1) IANA Guidelines for IPv4 Multicast Address Assignments - 
http://tools.ietf.org/html/rfc3171&nbsp;- Acesso em 28 de novembro de 2009.

(2)&nbsp;"Ethernet Switch Features Important to EtherNet/IP" - www.ab.com/networks/get/EIP_SwitchFeatures.ppt&nbsp;- Acesso em 14 de novembro de 2009.

(3) "Hirschmann Networking Interoperability in a Rockwell Automation Environment" -www.industrialnetworking.com/pdf/Rockwell.pdf - Acesso em 28 de novembro de 2009.
Texto traduzido e adaptado por Pierre Leandro.

Viu algo que está errado ou não gostou? Colabore enviando o comentário.
Até a próxima.