Spä­tes­tens seit dem großen Erfolg von Streaming-Diensten wie Netflix oder Spotify ist IP-Mul­ti­cas­ting als Über­tra­gungs­me­tho­de für das Internet und Heim­netz­wer­ke kaum mehr weg­zu­den­ken. Dies tech­ni­sche Verfahren er­mög­licht es dem Sender von Daten nämlich, Da­ten­strö­me gezielt an ganze Emp­fän­ger­grup­pen zu schicken, wodurch dieser Transport- und Rou­ting­ka­pa­zi­tä­ten optimal nutzen kann. Ohne diese Über­tra­gungs­me­tho­de müsste er separate Da­ten­pa­ke­te an jedes Emp­fän­ger­ge­rät ver­schi­cken, was eine enorme Band­brei­te erfordern und so schnell zu einer Über­las­tung führen würde. Damit wäre es praktisch unmöglich, den an­ge­bo­te­nen Dienst dauerhaft verfügbar zu halten.

Ein Protokoll, das bei der Or­ga­ni­sa­ti­on der genannten Multicast-Emp­fän­ger­grup­pen in IPv4-Netz­wer­ken eine wichtige Rolle spielt, ist das Internet Group Ma­nage­ment Protocol (IGMP).

Was ist das Internet Group Ma­nage­ment Protocol?

Das Internet Group Ma­nage­ment Protocol ist ein Kom­mu­ni­ka­ti­ons­pro­to­koll der TCP/IP-Familie, das an der Stanford Uni­ver­si­ty ent­wi­ckelt und 1989 in RFC 1112 erstmals spe­zi­fi­ziert wurde. Auf diese erste Pro­to­koll­ver­si­on IGMPv1 folgten die Über­ar­bei­tun­gen IGMPv2 (RFC 2236) und IGMPv3 (RFC 3376; RFC 4604). Die Versionen sind dabei immer rück­wärts­kom­pa­ti­bel, wodurch ein IGMPv3-Gerät au­to­ma­tisch auch Version 1 und 2 un­ter­stützt. Das Internet Group Ma­nage­ment Protocol ist aus­schließ­lich für IPv4-Netzwerke zuständig – in IPv6-Netzen übernimmt das ähnlich Multicast Listener Discovery (MLD) seine Funktion.

Die grund­le­gen­de Aufgabe von IGMP ist es, dy­na­mi­sche Gruppen für IP-Multicast-Über­tra­gun­gen zu verwalten, wobei diese Ver­wal­tung nicht über das Sen­de­ge­rät selbst, sondern über die ein­ge­bun­de­nen Router läuft. Diese nehmen ei­ner­seits von den Emp­fän­ger­ge­rä­ten (oder auch von den je­wei­li­gen un­ter­ge­ord­ne­ten Routern) Anfragen zur Aufnahme in eine bestimmte Multicast-Gruppe entgegen. An­de­rer­seits leiten sie IGMP-Nach­rich­ten an die ent­spre­chen­den über­ge­ord­ne­ten Router weiter, wenn sie passende Multicast-Da­ten­pa­ke­te erhalten. Die Sen­de­sta­ti­on erhält dabei keinerlei In­for­ma­tio­nen, welche und wie viele End­sta­tio­nen ein ver­schick­tes Paket erreicht, da sie lediglich ein einziges Da­ten­pa­ket an ihren über­ge­ord­ne­ten Router wei­ter­lei­tet.

De­fi­ni­ti­on IGMP

IGMP (Internet Group Ma­nage­ment Protocol) ist ein Kom­mu­ni­ka­ti­ons­pro­to­koll der In­ter­net­pro­to­koll­fa­mi­lie (TCP/IP). Es wurde erstmals im Jahr 1989 in RFC 1112 spe­zi­fi­ziert und ist auf der Netz­werk­schicht des OSI-Modells aktiv. Dort ist IGMP für die Or­ga­ni­sa­ti­on von Multicast-Gruppen zuständig, die den Versand von IP-Da­ten­strö­men an mehrere Empfänger er­mög­li­chen. Damit ist das Internet Group Ma­nage­ment Protocol au­to­ma­tisch auch auf allen Hosts im­ple­men­tiert, die IP-Mul­ti­cas­ting un­ter­stüt­zen.

Wie funk­tio­niert IGMP?

Es ist bereits zur Sprache gekommen, dass die Gruppen-Ver­wal­tung via IGMP nicht im Ver­ant­wor­tungs­be­reich des Pa­ket­sen­ders liegt. Dieser Aus­gangs­hosts muss aber – wie im Übrigen alle anderen in­vol­vier­ten Stationen des Netzwerks (inklusive des Emp­fän­gers) – Multicast-Ver­bin­dun­gen un­ter­stüt­zen. Die Ent­ge­gen­nah­me von Client-Anfragen zur Aufnahme in eine bestimmte Multicast-Gruppe sowie die Be­nach­rich­ti­gung der Clients im Falle ein­ge­hen­der Multicast-Da­ten­strö­me wird von den einzelnen Netzwerk-Routern über­nom­men, die auf dem Weg zwischen Sender und Empfänger liegen.

Zu diesem Zweck bietet das Internet Group Ma­nage­ment Protocol ei­ner­seits Funk­tio­nen, über die eine Station dem ihr zu­ge­ord­ne­ten Router mitteilen kann, dass die Aufnahme in eine Multicast-Gruppe erfolgen soll. An­de­rer­seits befähigt es die Router dazu, sich aus­ge­hen­de Schnitt­stel­len der­je­ni­gen Emp­fän­ger­ge­rä­te zu merken, die bestimmte IP-Multicast-Da­ten­strö­me erhalten sollen, um dann gezielt Be­nach­rich­ti­gun­gen (Reports) schicken zu können, sobald ent­spre­chen­de Daten empfangen werden. Multicast-Gruppen zeichnen sich dabei durch ihre spe­zi­fi­schen Adressen aus dem Bereich 224.0.0.x aus. In den meisten Fällen ist die erste An­lauf­stel­le eines Geräts der heimische Internet-Router, der das Bei­tritts­ge­such empfängt und an den nächsten Netz­werk­kno­ten, ty­pi­scher­wei­se den Router des In­ter­net­dienst­an­bie­ters, wei­ter­lei­tet. Diese Kom­mu­ni­ka­ti­ons­ket­te endet bei dem Router des Da­ten­strom­sen­ders, der das IP-Paket sei­ner­seits bei Bedarf du­pli­ziert, wenn er mehrere aus­ge­hen­de Schnitt­stel­len zu bedienen hat.

Hinweis

Soll ein zweites bzw. ein weiteres Endgerät in einem privaten Netzwerk der gleichen Multicast-Gruppe beigefügt werden, kann der Internet-Router dem Bei­tritts­ge­such un­ver­züg­lich statt­ge­ben, woraufhin bereits emp­fan­ge­ne Da­ten­strö­me direkt wei­ter­ge­lei­tet werden. Die Über­tra­gung der Daten endet erst dann, wenn das letzte dieser Geräte die Gruppe verlassen hat.

Wie un­ter­schei­den sich die einzelnen IGMP-Versionen?

Die drei ver­öf­fent­lich­ten Versionen des Internet Group Ma­nage­ment Protocols zeichnen sich zahl­rei­che Ge­mein­sam­kei­ten aus. IGMPv2 und IGMPv3 haben den Vorgänger nämlich in erster Linie um Funk­tio­nen erweitert, während die grund­sätz­li­chen Merkmale wie die Grup­pen­adres­se für generelle Anfragen (0.0.0.0) un­ver­än­dert über­nom­men wurden. Doch wie sehen die je­wei­li­gen Er­wei­te­run­gen im Detail aus?

IGMPv1: Die Basis des Internet Group Ma­nage­ment Protocols

IGMPv1 zeichnet sich als erste ver­öf­fent­lich­te Version des Kom­mu­ni­ka­ti­ons­pro­to­kolls durch einige grund­le­gen­de Merkmale aus, von denen viele auch in ak­tu­el­le­ren Varianten zu finden sind. So sind bei IGMPv1bereits 0.0.0.0 als Grup­pen­adres­se sowie 224.0.0.1 als Ziel­adres­se für generelle IGMP-Anfragen definiert. Das Standard-Intervall für diese au­to­ma­tisch durch den Router ge­stell­ten Anfragen liegt dabei bei 60 Sekunden. IGMPv1 er­mög­licht allen un­ter­stüt­zen­den Hosts den Beitritt in passende Multicast-Gruppen – Bei­tritts­ge­su­che werden in Form von Reports an die ent­spre­chen­den IP-Multicast-Adressen gesendet. Im Gegensatz zu den Nach­fol­ge­pro­to­kol­len fehlt IGMPv1 al­ler­dings noch eine Funktion, die es den Hosts er­mög­licht, Gruppen auf eigene Faust zu verlassen – erst ein Timeout entfernt den je­wei­li­gen Host aus be­tre­te­nen Gruppen.

Alle IGMP-Nach­rich­ten werden in einfachen IP-Paketen mit der IP-Pro­to­koll­num­mer 2 (Hex: 0x02) trans­por­tiert. Der IGMP-Header der ersten Pro­to­koll­ver­si­on sieht dabei fol­gen­der­ma­ßen aus:

Der IGMP-Header hat also eine Ge­samt­län­ge von 64 Bit. Die ersten 8 Bits geben dabei immer zunächst die Pro­to­koll­ver­si­on IGMPv1 sowie den Typ der Nachricht an. Für dieses Feld (Type) gibt es die beiden Mög­lich­kei­ten „1“ (für Bei­tritts­an­fra­gen) und „2“ (für Be­nach­rich­ti­gun­gen über Multicast-Da­ten­strö­me). Es folgen die Bits 8 bis 15, die keinerlei Funktion haben und lediglich aus Nullen bestehen. Den Abschluss des ersten 32-Bit-Blocks bildet eine Prüfsumme. Handelt es sich um ein IGMP-Be­nach­rich­ti­gungs­pa­ket, schließt sich nun die 32 Bit lange Grup­pen­adres­se an. Bei­tritts­an­fra­gen hängt hingegen ein Abschnitt an, der aus­schließ­lich Nullen enthält (Grup­pen­adres­se 0.0.0.0).

Die Ori­gi­nal­ver­si­on der Protokoll-Linie gibt selbst nicht vor, welcher Router für die Multicast-Abfragen genutzt werden soll (wird durch das Multicast Routing Protocol geregelt).

IGMPv2: Ein­füh­rung der Leave-Message und eines grup­pen­spe­zi­fi­schen Nach­rich­ten­typs

Die IGMPv2-Spe­zi­fi­ka­ti­on stammt aus dem Jahr 1997, womit die erste Über­ar­bei­tung des Standards rund 8 Jahre nach der Erst­ver­öf­fent­li­chung des Pro­to­kolls er­schie­nen ist. Während Gruppen- (0.0.0.0) und Ziel­adres­se (224.0.0.1) für die au­to­ma­ti­schen Anfragen un­ver­än­dert blieben, ist die Dauer des Standard-In­ter­valls auf 125 Sekunden erhöht worden. Die wich­tigs­te Neuerung von IGMPv2 ist al­ler­dings die Be­schleu­ni­gung des Ab­mel­de­pro­zes­ses: Der in der ersten Pro­to­koll­va­ri­an­te vor­aus­ge­setz­te Timeout wird durch einen vom Host in­iti­ier­ten Ab­mel­de­pro­zes­ses via „Leave“-Message ersetzt. Als Ziel­adres­se für diesen Nach­rich­ten­typ ist die Adresse 224.0.0.2 definiert.

Eine weitere Neuheit der zweiten Version des Kom­mu­ni­ka­ti­ons­pro­to­kolls: Man kann den Emp­fangs­sta­tus für eine bestimmte Multicast-Adresse über grup­pen­spe­zi­fi­sche Nach­rich­ten ermitteln.

Auch für IGMPv2-Nach­rich­ten gilt, dass sie in einfachen IP-Paketen mit der IP-Pro­to­koll­num­mer 2 gekapselt versendet werden. Am IGMP-Header wurden jedoch kleinere An­pas­sun­gen vor­ge­nom­men:

Die Kopfzeile beginnt ähnlich wie in der ersten Pro­to­koll­fas­sung, ohne al­ler­dings die Ver­si­ons­num­mer anzugeben. Die möglichen Type-Codes sind „0x11“ (für Anfragen), „0x16“ (für Be­nach­rich­ti­gun­gen) und „0x17“ (für Leave-Messages). Im Rahmen der Rück­wärts­kom­pa­ti­bi­li­tät gibt es zudem den Code „0x12“ für IGMPv1-Be­nach­rich­ti­gun­gen. Die Bits 8 bis 15 erhalten in IGMPv2 eine konkrete Funktion – zumindest bei Bei­tritts­an­fra­gen – und de­fi­nie­ren die maximal erlaubte Ant­wort­zeit. Es folgen Prüfsumme (16 Bit) und die Grup­pen­adres­se (32 Bit), die bei ge­ne­rel­len Anfragen wiederum die pro­to­koll­ty­pi­sche Form 0.0.0.0 hat.

IGMPv2 gibt die Regel vor, dass der Router mit der nied­rigs­ten IP-Adresse im Subnetz für die Multicast-Abfragen ein­ge­setzt wird.

IGMPv3: Erhöhte Si­cher­heit dank gezielt aus­wähl­ba­rer Multicast-Quellen

IGMPv3, die dritte Version des Internet Group Ma­nage­ment Protocols, gibt es seit Oktober 2002. Auch in dieser über­ar­bei­ten­den Aus­füh­rung des Pro­to­kolls sind 0.0.0.0 als Gruppen- und 224.0.0.1 als Ziel­adres­se für generelle Anfragen vor­ge­se­hen. Hin­sicht­lich des Standard-In­ter­valls ori­en­tiert sich die Pro­to­koll­ver­si­on mit 125 Sekunden an dem direkten Vorgänger. Eine Neuerung ist die Option, die Quelle des Multicast-Streams gezielt aus­zu­wäh­len. Dieses so­ge­nann­te quel­len­spe­zi­fi­sche Mul­ti­cas­ting (source-specific multicast) senkt die An­for­de­run­gen an das Netzwerk enorm und sorgt zudem auch für mehr Si­cher­heit bei der Über­tra­gung, da nicht einfach beliebige und/oder un­be­kann­te Quellen zum Einsatz kommen.

Der IGMP-Header ist auch in IGMPv3 in IP-Pakete (Pro­to­koll­num­mer 2) ein­ge­bun­den, fällt al­ler­dings we­sent­lich komplexer aus als bei den beiden Vor­gän­ger­pro­to­kol­len, was ins­be­son­de­re auf die mögliche Angabe der Quell­adres­se zu­rück­zu­füh­ren ist. Zudem gibt es konkrete Un­ter­schie­de zwischen Anfragen und Be­nach­rich­ti­gun­gen. Die Kopfzeile für IGMPv3-Grup­pen­an­fra­gen sieht dabei fol­gen­der­ma­ßen aus:

Die ersten zwei 32-Bit-Sequenzen sind identisch mit denen des IGMPv2-Headers – Type, maximale Ant­wort­zeit, Prüfsumme und Grup­pen­adres­se. Auch IGMPv3 bietet an dieser Stelle die Mög­lich­keit des Aus­tauschs mit älteren Pro­to­koll­ver­sio­nen: Hierfür stehen den Hosts die Codes „0x12“ für Version 1 und „0x16“ für Version 2 zur Verfügung. Im Anschluss an die Grup­pen­adres­se beginnt der IGMPv3-Query-spe­zi­fi­sche Header-Teil, dessen erste 32 Bit sich fol­gen­der­ma­ßen zu­sam­men­set­zen:

  • Res.: re­ser­vier­tes 4-Bit-Feld, das keinerlei Funk­tio­nen hat und nur Nullen enthält.
  • S (Suppress Router-Side Pro­ces­sing): S-Flag, das den Routern auf Wert „1“ gesetzt. si­gna­li­siert, dass sie normale Updates beim Empfangen einer Anfrage un­ter­drü­cken sollen. Ist der Wert „0“, ist das Feld inaktiv.
  • QRV (Querier’s Ro­bust­ness Variable): 3 Bit, die den Wert „Ro­bust­heits­va­ria­ble“ enthalten können, der von an­fra­gen­den Hosts genutzt wird.
  • QQIC (Querier’s Query Interval Code): 8-Bit-Feld, über das sich das Intervall für IGMPV3-Anfragen spe­zi­fi­zie­ren lässt.
  • Anzahl der Quell­adres­sen: Anzahl der Quell­adres­sen, die nach­fol­gend auf­ge­führt werden.

Nach diesen sehr spe­zi­fi­schen Angaben folgt die Quell­adres­se bzw. eine Auf­lis­tung der einzelnen Quell­adres­sen (jeweils 32 Bit), sofern mehrere Quellen definiert werden sollen.

Tipp

Inwiefern sich der Header des zweiten Nach­rich­ten­typs (IGMPv3-Be­nach­rich­ti­gun­gen) von der hier prä­sen­tier­ten Kopfzeile der IGMPv3-Anfragen un­ter­schei­det, ist in Kapitel 4.2 des RFCs 3376 nach­zu­le­sen.

Im Gegensatz zu seinem Vorgänger er­mög­licht es IGMPv3 einem Host, in einer einzigen Trans­ak­ti­on einer Gruppe bei­zu­tre­ten und eine andere zu verlassen – IGMPv2 benötigt hierfür noch zwei separate Nach­rich­ten.

Wo kommt das Internet Group Ma­nage­ment Protocol zur Anwendung?

Die Rolle von IGMP ist klar definiert: Das Kom­mu­ni­ka­ti­ons­pro­to­koll kommt immer dort zur Anwendung, wo Multicast-Über­tra­gun­gen in IPv4-Netz­wer­ken wie dem Internet benötigt werden. Klas­si­sche Ein­satz­sze­na­ri­en sind also Echt­zeit­ap­pli­ka­tio­nen, die über Mehr­punkt­ver­bin­dun­gen laufen – also bei­spiels­wei­se Web­kon­fe­renz-Tools oder Live-Streaming-Dienste. Dabei soll nicht jeder Client einzeln mit dem be­nö­tig­ten Da­ten­strom versorgt werden müssen, da dies schnell zu einer Über­las­tung des Aus­gangs­ser­vers und der in­vol­vier­ten Netz­werk­kno­ten führen würde.

Hinweis

Viele Switches und Internet-Router bieten die Mög­lich­keit, den Multicast-Da­ten­ver­kehr in Netz­wer­ken zu filtern, um die Netz­werk­leis­tung zu op­ti­mie­ren. Hierfür greifen die Geräte auf das so­ge­nann­te IGMP-Snooping zurück, das ebenfalls durch das Internet Group Ma­nage­ment Protocol er­mög­licht wird.

Zum Hauptmenü