Appendix I. Internet Group Management Protocol (Internet-Gruppenverwaltungsprotokoll)

Das Internet Group Management Protocol (Internet-Gruppenverwaltungsprotokoll, IGMP) wird von IP-Hosts verwendet, um ihre Hostgruppenmitgliedschaften allen unmittelbar benachbarten Multicast-Routern zu melden. IGMP ist ein asymmetrisches Protokoll und wird hier aus der Sicht eines Hosts und nicht aus der Sicht eines Multicast-Routers spezifiziert. (IGMP kann auch symmetrisch oder asymmetrisch zwischen Multicast-Routern verwendet werden. Eine solche Verwendung wird hier nicht spezifiziert.)

Wie ICMP ist IGMP ein integraler Bestandteil von IP. Es muss von allen Hosts implementiert werden, die Level 2 der IP-Multicasting-Spezifikation entsprechen. IGMP-Nachrichten werden in IP-Datagrammen gekapselt, mit einer IP-Protokollnummer von 2. Alle IGMP-Nachrichten, die Hosts betreffen, haben das folgende Format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Type  |    Unused     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version

Dieses Memo spezifiziert Version 1 von IGMP. Version 0 ist in RFC-988 spezifiziert und ist jetzt veraltet.

Type (Typ)

Es gibt zwei Arten von IGMP-Nachrichten, die Hosts betreffen:

1 = Host Membership Query (Hostmitgliedschaftsabfrage)
2 = Host Membership Report (Hostmitgliedschaftsbericht)

Unused (unbenutzt)

Unbenutztes Feld, beim Senden auf null gesetzt, beim Empfang ignoriert.

Checksum (Prüfsumme)

Die Prüfsumme ist das 16-Bit-Einerkomplement der Einerkomplement-Summe der 8-Oktett-IGMP-Nachricht. Zur Berechnung der Prüfsumme wird das Prüfsummenfeld auf null gesetzt.

Group Address (Gruppenadresse)

In einer Host Membership Query-Nachricht wird das Gruppenadressfeld beim Senden auf null gesetzt und beim Empfang ignoriert.

In einer Host Membership Report-Nachricht enthält das Gruppenadressfeld die IP-Hostgruppenadresse der gemeldeten Gruppe.

Informelle Protokollbeschreibung

Multicast-Router senden Host Membership Query-Nachrichten (nachfolgend Queries genannt), um herauszufinden, welche Hostgruppen Mitglieder in ihren angeschlossenen lokalen Netzwerken haben. Queries werden an die All-Hosts-Gruppe (Adresse 224.0.0.1) adressiert und tragen eine IP-Time-to-Live von 1.

Hosts antworten auf eine Query, indem sie Host Membership Reports (nachfolgend Reports genannt) generieren und jede Hostgruppe melden, der sie auf der Netzwerkschnittstelle angehören, von der die Query empfangen wurde. Um eine "Implosion" gleichzeitiger Reports zu vermeiden und die Gesamtzahl der übertragenen Reports zu reduzieren, werden zwei Techniken verwendet:

Wenn ein Host eine Query empfängt, sendet er nicht sofort Reports, sondern startet einen Berichtverzögerungs-Timer für jede seiner Gruppenmitgliedschaften auf der Netzwerkschnittstelle der eingehenden Query. Jeder Timer wird auf einen unterschiedlichen, zufällig gewählten Wert zwischen null und D Sekunden gesetzt. Wenn ein Timer abläuft, wird ein Report für die entsprechende Hostgruppe generiert. So werden Reports über ein D-Sekunden-Intervall verteilt, anstatt alle gleichzeitig aufzutreten.
Ein Report wird mit einer IP-Zieladresse gesendet, die der gemeldeten Hostgruppenadresse entspricht, und mit einer IP-Time-to-Live von 1, sodass andere Mitglieder derselben Gruppe im selben Netzwerk den Report mithören können. Wenn ein Host einen Report für eine Gruppe hört, der er in diesem Netzwerk angehört, stoppt der Host seinen eigenen Timer für diese Gruppe und generiert keinen Report für diese Gruppe. Im Normalfall wird also nur ein Report für jede im Netzwerk vorhandene Gruppe generiert, und zwar vom Mitgliedshost, dessen Verzögerungs-Timer zuerst abläuft. Beachten Sie, dass die Multicast-Router alle IP-Multicast-Datagramme empfangen und daher nicht explizit adressiert werden müssen. Beachten Sie außerdem, dass die Router nicht wissen müssen, welche Hosts zu einer Gruppe gehören, sondern nur, dass mindestens ein Host in einem bestimmten Netzwerk zu einer Gruppe gehört.

Es gibt zwei Ausnahmen vom oben beschriebenen Verhalten. Erstens, wenn bereits ein Berichtverzögerungs-Timer für eine Gruppenmitgliedschaft läuft, wenn eine Query empfangen wird, wird dieser Timer nicht auf einen neuen Zufallswert zurückgesetzt, sondern darf mit seinem aktuellen Wert weiterlaufen. Zweitens wird für die Mitgliedschaft eines Hosts in der All-Hosts-Gruppe (224.0.0.1) nie ein Berichtverzögerungs-Timer gesetzt, und diese Mitgliedschaft wird nie gemeldet.

Wenn ein Host einen Pseudozufallszahlengenerator verwendet, um die Berichtverzögerungen zu berechnen, sollte eine der eigenen individuellen IP-Adressen des Hosts als Teil des Seeds für den Generator verwendet werden, um die Chance zu verringern, dass mehrere Hosts dieselbe Verzögerungssequenz generieren.

Ein Host sollte bestätigen, dass ein empfangener Report die gleiche IP-Hostgruppenadresse in seinem IP-Zielfeld und seinem IGMP-Gruppenadressfeld hat, um sicherzustellen, dass der eigene Report des Hosts nicht durch einen fehlerhaft empfangenen Report abgebrochen wird. Ein Host sollte jede IGMP-Nachricht eines anderen Typs als Host Membership Query oder Host Membership Report stillschweigend verwerfen.

Multicast-Router senden Queries regelmäßig, um ihr Wissen über in einem bestimmten Netzwerk vorhandene Mitgliedschaften zu aktualisieren. Wenn nach einigen Queries keine Reports für eine bestimmte Gruppe empfangen werden, gehen die Router davon aus, dass diese Gruppe keine lokalen Mitglieder hat und dass sie keine ferngesteuerten Multicasts für diese Gruppe an das lokale Netzwerk weiterleiten müssen. Queries werden normalerweise selten gesendet (nicht mehr als einmal pro Minute), um den IGMP-Overhead auf Hosts und Netzwerken sehr niedrig zu halten. Wenn ein Multicast-Router jedoch startet, kann er mehrere eng getaktete Queries ausgeben, um sein Wissen über lokale Mitgliedschaften schnell aufzubauen.

Wenn ein Host einer neuen Gruppe beitritt, sollte er sofort einen Report für diese Gruppe übertragen, anstatt auf eine Query zu warten, falls er das erste Mitglied dieser Gruppe im Netzwerk ist. Um die Möglichkeit abzudecken, dass der erste Report verloren geht oder beschädigt wird, wird empfohlen, ihn nach kurzen Verzögerungen ein- oder zweimal zu wiederholen. (Eine einfache Möglichkeit, dies zu erreichen, besteht darin, so zu handeln, als ob eine Query nur für diese Gruppe empfangen worden wäre, und den zufälligen Berichtverzögerungs-Timer der Gruppe zu setzen. Das unten stehende Zustandsübergangsdiagramm veranschaulicht diesen Ansatz.)

Beachten Sie, dass in einem Netzwerk ohne vorhandene Multicast-Router der einzige IGMP-Verkehr die ein oder mehrere Reports sind, die gesendet werden, wenn ein Host einer neuen Gruppe beitritt.

Zustandsübergangsdiagramm

Das IGMP-Verhalten wird formeller durch das unten stehende Zustandsübergangsdiagramm spezifiziert. Ein Host kann sich in Bezug auf eine einzelne IP-Hostgruppe auf einer einzelnen Netzwerkschnittstelle in einem von drei möglichen Zuständen befinden:

Non-Member state (Nicht-Mitgliedszustand): wenn der Host nicht zur Gruppe auf der Schnittstelle gehört. Dies ist der Anfangszustand für alle Mitgliedschaften auf allen Netzwerkschnittstellen. Er erfordert keine Speicherung im Host.
Delaying Member state (Verzögertes-Mitgliedszustand): wenn der Host zur Gruppe auf der Schnittstelle gehört und ein Berichtverzögerungs-Timer für diese Mitgliedschaft läuft.
Idle Member state (Inaktives-Mitgliedszustand): wenn der Host zur Gruppe auf der Schnittstelle gehört und kein Berichtverzögerungs-Timer für diese Mitgliedschaft läuft.

Es gibt fünf bedeutende Ereignisse, die IGMP-Zustandsübergänge verursachen können:

"join group" (Gruppe beitreten): tritt auf, wenn der Host beschließt, der Gruppe auf der Schnittstelle beizutreten. Kann nur im Non-Member-Zustand auftreten.
"leave group" (Gruppe verlassen): tritt auf, wenn der Host beschließt, die Gruppe auf der Schnittstelle zu verlassen. Kann nur in den Zuständen Delaying Member und Idle Member auftreten.
"query received" (Query empfangen): tritt auf, wenn der Host eine gültige IGMP Host Membership Query-Nachricht empfängt. Um gültig zu sein, muss die Query-Nachricht mindestens 8 Oktette lang sein, eine korrekte IGMP-Prüfsumme haben und eine IP-Zieladresse von 224.0.0.1 haben. Eine einzelne Query gilt für alle Mitgliedschaften auf der Schnittstelle, von der die Query empfangen wird. Sie wird für Mitgliedschaften im Non-Member- oder Delaying-Member-Zustand ignoriert.
"report received" (Report empfangen): tritt auf, wenn der Host eine gültige IGMP Host Membership Report-Nachricht empfängt. Um gültig zu sein, muss die Report-Nachricht mindestens 8 Oktette lang sein, eine korrekte IGMP-Prüfsumme haben und die gleiche IP-Hostgruppenadresse in ihrem IP-Zielfeld und ihrem IGMP-Gruppenadressfeld enthalten. Ein Report gilt nur für die Mitgliedschaft in der durch den Report identifizierten Gruppe auf der Schnittstelle, von der der Report empfangen wird. Er wird für Mitgliedschaften im Non-Member- oder Idle-Member-Zustand ignoriert.
"timer expired" (Timer abgelaufen): tritt auf, wenn der Berichtverzögerungs-Timer für die Gruppe auf der Schnittstelle abläuft. Kann nur im Delaying-Member-Zustand auftreten.

Alle anderen Ereignisse, wie das Empfangen ungültiger IGMP-Nachrichten oder von IGMP-Nachrichten außer Query oder Report, werden in allen Zuständen ignoriert.

Es gibt drei mögliche Aktionen, die als Reaktion auf die obigen Ereignisse durchgeführt werden können:

"send report" (Report senden): für die Gruppe auf der Schnittstelle.
"start timer" (Timer starten): für die Gruppe auf der Schnittstelle, unter Verwendung eines zufälligen Verzögerungswerts zwischen 0 und D Sekunden.
"stop timer" (Timer stoppen): für die Gruppe auf der Schnittstelle.

Im folgenden Diagramm ist jeder Zustandsübergangsbogen mit dem Ereignis beschriftet, das den Übergang verursacht, und (in Klammern) allen während des Übergangs durchgeführten Aktionen.

                          ________________
                         |                |
                         |                |
                         |                |
                         |                |
                   ----->|   Non-Member   |&lt;---------
                  |      |                |          |
                  |      |                |          |
                  |      |                |          |
                  |      |________________|          |
                  |               |                  |
                  | leave group   | join group       | leave group
                  | (stop timer)  |(send report,     |
                  |               | start timer)     |
          ________|________       |          ________|________
         |                 |&lt;-----          |                 |
         |                 |                |                 |
         |                 |&lt;---------------|                 |
         |                 |   query received   |                 |
         | Delaying Member |    (start timer)   |   Idle Member   |
         |                 |----------------->|                 |
         |                 |   report received  |                 |
         |                 |    (stop timer)    |                 |
         |_________________|----------------->|_________________|
                                timer expired
                                (send report)

Die All-Hosts-Gruppe (Adresse 224.0.0.1) wird als Sonderfall behandelt. Der Host startet im Idle-Member-Zustand für diese Gruppe auf jeder Schnittstelle, wechselt nie in einen anderen Zustand und sendet nie einen Report für diese Gruppe.

Protokollparameter

Die maximale Berichtverzögerung, D, beträgt 10 Sekunden.