Von: Joachim Zubke, Stefan BohNert
In Multicast-Netzen kommen zwei Arten von Protokollen zum Einsatz. Group-Management- und Routing-Protokolle. Vertreter der ersten Gruppe sind beispielsweise das "Internet Group Management Protocol" (IGMP) oder das proprietäre "Cisco Group Management Protocol" (CGMP). Diese Protokolle arbeiten auf der Ebene zwischen Host und Router. IGMP ist ein fester Bestandteil von IP und verwendet IP-Datagramme, die aus einem 20 Byte großen Header und einer IGMP-Message von 8 Byte bestehen. Zur Klasse der Multicast-Routing-Protokolle zählen unter anderem "Protocol Independent Multicast" (PIM) und das "Distance Vector Multicast Routing Protocol" (DVMRP). Sie transportieren den Multicast-Verkehr zwischen den Routern.
IGMP ist ein Protokoll, mit dem Host-Rechner die Router darüber informieren, welchen Multicast-Gruppen sie beitreten oder welche sie verlassen möchten. Das bedeutet, dieses Protokoll muss auf allen Host-Systemen implementiert sein, die IP-Multicasts empfangen wollen. Die Mitgliedschaft in einer Multicast-Gruppe ist "dynamisch", das heißt die Hosts können sie jederzeit erneuern oder beenden. Multicast-Router stellen über IGMP fest, ob sich Mitglieder von Multicast-Gruppen in einem der angeschlossenen Netze befinden. Bei IGMP handelt es sich um eine Erweiterung von IP. Deshalb ist das Protokoll auch auf der Netzwerkschicht (Network Layer) des OSI-Referenzmodelles angesiedelt.
Empfängt ein Router Verkehr für eine Multicast-Gruppe, muss er wissen über welche Schnittstelle er die Daten weiterleiten soll. Für die Entscheidung ist maßgebend, ob Gruppenmitglieder oder weitere Router mit Gruppenmitgliedern im Subnetz vorhanden sind. Im Beispiel in Bild 1 empfängt ein Multicast-Router Verkehr für die Gruppe 239.255.134.7. In Subnetz 1 ist kein Gruppenmitglied vorhanden, so dass der Router die Daten dorthin nicht weiterleiten muss. In Subnetz 2 ist dagegen Host 3 Mitglied der Multicast-Gruppe 239.255.134.7, also wird der Multicast-Verkehr in Subnetz 2 übermittelt. Der Router muss nur wissen, dass mindestens ein Gruppenmitglied im Subnetz existiert. Für ihn ist irrelevant, wie viele Mitglieder die Gruppe hat, ob eines oder 100.
Der aktuelle Standard IGMPv2 wird durch den Internet-Draft "Internet Group Management Protocol, Version 3" erweitert. IGMPv3 unterstützt unter anderem "Group Source Report PDUs" (Protocol Data Units), die ein Filtern von Paketen nach Quellen erlauben. Bei IGMPv1 oder v2 ist dagegen nur der Empfang von allen Sendern für eine Multicast-Gruppe möglich. IGMPv3 ist zwar in der Entwicklung schon recht weit vorangeschritten, aber trotzdem lässt sich nur schwer einschätzen, welche Funktionen die endgültige Version enthalten wird. So gibt es unterschiedliche Auffassungen darüber, ob die Report-PDUs an die "All-Routers Multicast"-Adresse (224.0.0.2) statt die Gruppenadresse gesendet werden sollen.
Voraussetzung: Spanning-Tree-Struktur
Beim Multicast-Routing steht ein Sender einer Gruppe von Empfängern gegenüber, deren Zusammensetzung sich ständig ändern kann. Im Gegensatz zu einem einzelnen Pfad zwischen Sender und Empfänger, wie bei Unicasting, erfordert Multicast-Routing grundsätzlich eine Spanning-Tree-Struktur. Die Router greifen dabei auf die Unicast-Routing-Tabellen zurück. Spezielle Multicast-Routing-Tabellen sind nicht notwendig. Ein Spanning Tree lässt sich auf zwei Arten aufbauen:
- als Source-based Tree oder
- als Shared-based Tree.
Der Source-based Tree geht davon aus, dass jeder Host ein potenzieller Empfänger einer Multicast-Session ist. Daher werden beim ersten Aufbau des Spanning Tree die Multicast-Pakete flächendeckend in jedes Subnetz geleitet. Das "Reverse Path Multicasting"-Verfahren (RPM) berücksichtigt das dynamische An- und Abmelden der Empfänger und verhindert, dass Datenpakete mehrfach weitergeleitet werden. Um das sicherzustellen, werden die Pakete nur über Schnittstellen weitergeleitet, über die das Zielsystem auf dem kürzesten Weg zu erreichen ist. Außerdem laufen keine Daten über Interfaces, von denen der Router selbst die Informationen erhalten hat. Bei RPM wird also jedes Subnetz über eine eigene Route angebunden, so dass keine Schleifen entstehen können.
Eine Pruning-PDU hat die Aufgabe, redundante Zweige im Spanning Tree zu deaktivieren und die Netzlast möglichst niedrig zu halten. Auf inaktiven Zweigen werden die Daten nicht weitergeleitet. Um auf Veränderungen im Netz reagieren zu können, löschen die Router die Pruning-Vermerke nach einer gewissen Zeit, Systeme von Cisco beispielsweise nach drei Minuten. Der Zweig ist dann wieder aktiv. Um inaktive Segmente schneller wieder aufzunehmen, wird eine Graft-PDU gesendet. Diesen Vorgang kann ein neuer Empfänger starten.
Bild 2 zeigt einen Spanning Tree: Im Subnetz 1 sind Empfänger vorhanden, also werden die Daten dorthin weitergeleitet. In Subnetz 2 nimmt ein neuer Empfänger an der Multicast-Session teil, und zwar mittels IGMP-Report-PDU und auf Router-Ebene mit Hilfe einer Graft-PDU. In Subnetz 3 wird ein redundanter Zweig per Pruning-PDU im Spanning Tree deaktiviert. Für den Einsatz in großen Netzen, speziell dem Internet, eignet sich das Verfahren allerdings nicht. Das regelmäßige flächendeckende Weiterleiten der Datenpakete in alle Teilnetze geht stark zu Lasten der Bandbreite.
Außerdem müssen die Router - bedingt durch das Pruning - Zustandsinformationen über Sender und Gruppen vorhalten. Das ist nur dann praktikabel, wenn wenige Gruppen und Sender vorhanden sind. Andernfalls müssen die Router zu viele Ressourcen dafür reservieren, was die Leistung mindert. Im Unterschied zum Source-based Tree werden bei Bäumen auf Grundlage des Shared-based Tree Datenpakete nicht flächendeckendweitergeleitet. Das Verfahren beruht auf "Rendezvous-Stellen" (Rendevous-Points = RP) im Netz. Diese Punkte wissen stets, wer welcher Gruppe angehört. Es handelt sich also um ein An- und Abmelde-Modell, bei dem sich die Zwischensysteme jeweils beim RP bemerkbar machen. Bei der Weitergabe der erforderlichen Information werden alle Router durchlaufen, die zwischen dem neuen Mitglied (Bild 3) und der Rendezvous-Stelle liegen.
Diese können dabei die für sie wichtigen Informationen extrahieren, etwa die Gruppenzugehörigkeit. Ein Router wird also lediglich die Information speichern, die Auskunft über die Gruppenzugehörigkeit der nachfolgenden Empfänger gibt.
Das Basisverfahren für solche Bäume erfordert zunächst die Auswahl einer Rendezvous-Stelle für eine Gruppe. Die Gruppenmitglieder melden sich dann bei dieser Stelle an, indem sie entsprechende PDUs senden. Router auf dem Pfad zwischen Gruppenmitglied und Rendezvous-Stelle leiten die PDU in Richtung Rendezvous-Stelle weiter. Sie benötigen dazu lediglich eine Information pro Gruppe. Im Gegensatz dazu verlangt Source-based Tree eine Information pro Gruppe und Sender.
Bei Bäumen mit Rendezvous-Stellen müssen Datenquellen, also die Sender, nicht Mitglieder der Gruppe sein. Der Grund ist, dass sie sich lediglich mit der Weiterleitung, also mit dem Ziel der Kommunikation, befassen. Es wird also ein Spanning Tree pro Gruppe etabliert, und nicht einer pro Sender.
Einer der Vorteile von Verfahren mit Rendezvous-Stellen ist, dass sie die Verbreitung von Daten auf die Gruppenmitglieder begrenzen. Außerdem ist der Aufwand für die Zustandshaltung in den Routern relativ gering; es sind lediglich die Gruppen zu identifizieren, nicht aber die zusammengehörigen Kommunikationspartner. Zu den Nacheilen zählt die Konzentration des Verkehrs um die Rendezvous-Stellen herum. Außerdem ist ein RP ein "Single Point of Failure", das heißt, die Ausfallsicherheit ist nicht besonders hoch. Hier können Varianten mit mehreren Rendezvous-Stellen pro Gruppe Abhilfe schaffen, was allerdings wiederum den Verwaltungsaufwand erhöht.
Eingesetzte Routing-Protokolle
Die Routing-Protokolle verwenden die unter der Baumstruktur verwendeten Verfahren, so dass auch sie in Source-based Tree und Shared-based Tree eingeteilt werden können.
Nach dem Source-based Tree Verfahren arbeiten:
- Protocol Independent Multicast - Dense Mode (PIM-DM),
- das Distance Vector Multicast Routing Protocol (DVMRP) und
- Multicast Open Shortest Path First (MOSPF).
Nach dem Shared-based-Tree-Verfahren arbeitet das "Protocol Independent Multicast - Sparse Mode" (PIM-SM). PIM wird als protokollunabhängig bezeichnet, weil es nicht auf ein bestimmtes Unicast-Routing-Protokoll, wie RIP, IGRP oder OSPF, festgelegt ist. Im Gegensatz dazu basiert DVMRP auf dem Unicast-Routing-Protokoll RIP, ebenso wie MOSPF auf OSPF.
Wer sein Netz IP-Multicast-tauglich machen will, sollte sicherstellen, dass alle Layer-2-Switches Multicast-Flooding begrenzen können. Zusätzlich müssen die Netzwerkkomponenten für ein Routing-Protokoll ausgelegt sein, das Sparse-Mode-Multicasting unterstützt. Drittens ist auf den Clients und Server ein TCP/IP-Protokoll-Stack gemäß RFC 1112 oder 2236 erforderlich, und schließlich müssen auch die Applikationen Multicasts unterstützen.
Im Mittelpunkt des letzten Artikels der Multicast Reihe stehen Quality of Service (QoS) und Multicast-Backbones. (re)