1.13.2 IGMP - Internet Group Management Protocol

Es gibt nun mehrere Multicast-Gruppen mit unterschiedlichen Verbreitungsgebieten. Ein weiteres Merkmal ist die Dauer der Gruppenzugehörigkeit. Wir unterscheiden: Während man sich für permanente Gruppen noch vorstellen kann, daß die Verbreitung durch statische Einträge in den Routern realisiert wird, ist das spätestens bei den temporären Gruppen nicht mehr praktikabel.

Wir betrachten zunächst das Zusammenwirken von Endsystemen mit einem Router in einem multicast-fähigen Subnetz, wobei A, B und D derselben Multicast-Gruppe angehören:

Wenn jetzt z.B. D die Gruppe verläßt, wäre es sicherlich nicht geschickt, wenn der Router R1 weiterhin das rechte Netz mit den Paketen dieser Gruppe versorgt (oder einfach die Daten aller "beschaffbaren" Multicast-Gruppen in jedes Netz einspeist).

Das Internet Group Management Protocol (IGMP) erfült nun genau den Zweck, die "Interessenten" an bestimmten Gruppen festzustellen. IGMP-Nachrichten haben einen sehr einfachen Aufbau:

Das Typ-Feld unterscheidet

Üblicherweise sendet ein Router an einem multicast-fähigen Subnetz in nicht zu kleinen Zeitabständen (mindestens 60 Sekunden) eine Anfrage an die Multicast-Adresse 224.0.0.1. Alle multicast-fähigen Rechner werten diese Adresse aus und senden Reports, in denen sie die Multicast-Gruppen bekanntgeben, deren Daten sie erhalten möchten.

In einer Anfrage wird das Feld Gruppenadresse nicht verwendet (es ist dann 0.0.0.0), im Report steht dort die entsprechende IP-Multicast-Adresse.

Ein Rechner kann einen solchen Report auch unaufgefordert senden, wenn er gerade neu der Gruppe beitritt (damit der Nutzer nicht bis zum nächsten Abfragezyklus auf eine Reaktion warten muß).

In der im RFC 2236 spezifizierten Version 2 von IGMP (IGMPv2) gibt es eine erweiterte Form des Membership Report und eine Mitteilung über das Verlassen einer Host-Gruppe. Zur Zeit wird an Version 3 des Protokolls (IGMPv3) gearbeitet. Der jeweils aktuelle Stand ist in Internet-Drafts beschrieben. Eine wesentliche Neuerung bei IGMPv3 ist das sog. source filtering. Es gestattet einem System mitzuteilen, daß es nur an Multicast-Paketen interessiert ist, die in Abhängigkeit vom Filter-Modus (INCLUDE oder EXCLUDE) entweder bestimmte, von dem jeweiligen System spezifizierte Unicast-Absenderadressen haben oder die nicht von diesen angegebenen Adressen stammen.

Zwischen den Routern ist der Fall etwas komplizierter, weil es hier mehrere alternative Wege geben kann. Je nach Verteilung der "Interessenten" können deshalb unterschiedliche Wege "optimal" sein. Statische Multicast-Routen sind wegen der häufig wechselnden Gruppen-Zugehörigkeit kaum praktikabel, daher werden Multicast-Routing-Protokolle eingesetzt, mit denen sich die Router gegenseitig über Multicast-Routen informieren. Die folgende Liste nennt drei unterschiedliche Verfahren:

Nach unseren Erfahrungen spielen in der heutigen Praxis vor allem PIM und DVMRP-Varianten eine Rolle, wobei eine Tendenz zu PIM erkennbar ist.


Diskussion 1.13.2.1:
In einem Subnetz mit sehr vielen "Multicast-Interessenten" wird die IGMP-Anfrage vom Router möglicherweise sehr viele IGMP-Reports auslösen, was für die Netzlast nicht günstig ist. Kann man hier etwas verbessern, wenn man weiß, daß meist viele Rechner an derselben Gruppe interessiert sind?
Vertiefung:
S. Deering: Host Extensions for IP Multicasting (RFC 1112)
© Uwe Hübner 27.4.1998