1. Introduzione (Introduction)

Lo standard IEEE sui bridge [BRIDGE] specifica come i pacchetti LAN siano «instradati tramite bridge», o, come oggi è più comune dire, commutati tra i segmenti LAN. Il comportamento di uno switch nei confronti dei pacchetti multicast può essere riassunto così: nell'elaborare un pacchetto la cui indirizzo MAC di destinazione è un indirizzo multicast, lo switch inoltra una copia del pacchetto a ciascuna delle restanti interfacce di rete che si trovano nello stato di inoltro, conformemente a [BRIDGE]. L'algoritmo spanning tree garantisce che l'applicazione di questa regola da parte di ciascuno switch della rete renda il pacchetto accessibile a tutti i nodi connessi alla rete.

Questo comportamento funziona bene per i pacchetti broadcast destinati a essere visti o elaborati da tutti i nodi connessi. Nel caso dei pacchetti multicast, tuttavia, questo approccio può portare a un utilizzo meno efficiente della banda della rete, in particolare quando il pacchetto è destinato solo a un piccolo numero di nodi. I pacchetti verranno inondati in segmenti di rete in cui nessun nodo ha manifestato interesse a riceverli. Sebbene i nodi difficilmente sosterranno un carico di elaborazione per filtrare i pacchetti indirizzati a indirizzi di gruppo non richiesti, essi non sono in grado di trasmettere nuovi pacchetti sul mezzo condiviso per la durata dell'inondazione del pacchetto multicast. In generale, una quantità significativa di banda può essere sprecata per l'inondazione.

Negli ultimi anni, diversi fornitori commerciali hanno immesso sul mercato prodotti descritti come «switch con IGMP snooping». Tali dispositivi non aderiscono al modello concettuale che prevede una rigida separazione delle funzionalità tra i diversi livelli di comunicazione del modello ISO, e utilizzano invece le informazioni contenute nelle intestazioni dei protocolli di livello superiore come fattori considerati nell'elaborazione di livello inferiore. Ciò è analogo al modo in cui un router può agire come firewall esaminando il tipo di intestazione del protocollo di trasporto prima di consentire a un pacchetto di essere inoltrato al proprio indirizzo di destinazione.

Nel caso del traffico IP multicast, uno switch con IGMP snooping presenta il vantaggio di preservare la banda sui segmenti della rete in cui nessun nodo ha manifestato interesse a ricevere i pacchetti indirizzati all'indirizzo di gruppo. Ciò contrasta con il normale comportamento di uno switch, in cui il traffico multicast viene generalmente inoltrato su tutte le interfacce.

Molte schede tecniche degli switch indicano il supporto per l'IGMP snooping, ma ad oggi non esiste alcuna raccomandazione. Gli autori sperano che le informazioni presentate in questo documento forniscano tale base.

Le raccomandazioni qui presentate si basano sulle seguenti fonti di informazione: le specifiche IGMP [RFC1112], [RFC2236] e [IGMPv3], documentazione tecnica fornita dai produttori [CISCO], segnalazioni di bug [MSOFT], discussioni con persone coinvolte nella progettazione di switch con IGMP snooping, discussioni sulla mailing list MAGMA, nonché sulle risposte dei produttori di switch a un questionario di implementazione.

I problemi di interoperabilità che sorgono tra le diverse versioni di IGMP non rientrano nell'ambito di questo documento. I lettori interessati sono invitati a consultare [IGMPv3] per una descrizione approfondita delle aree problematiche.

I suggerimenti di questo documento si basano su IGMP, che si applica solo a IPv4. Per IPv6, deve essere utilizzata invece la Multicast Listener Discovery [MLD]. Poiché MLD è basata su IGMP, non ripetiamo la descrizione completa e le raccomandazioni per gli switch con MLD snooping. Indichiamo invece i pochi casi in cui esistono differenze rispetto a IGMP.

Si noti che la funzione di IGMP snooping dovrebbe essere applicata solo ai multicast IPv4. Altri pacchetti multicast, come IPv6, potrebbero essere eliminati dall'IGMP snooping se non viene posta ulteriore cura nell'implementazione, come menzionato nella sezione delle raccomandazioni.