Grundlagen des Multicast-Einsatzes
Quo vadis, Internet?
Neue webbasierte Anwendungen wie das digitale Fernsehen oder Videotelefonie und -konferenzen über IP stehen in den Startlöchern. Sie erfordern den Einsatz von Protokollen zur Verwaltung von Teilnehmern und zum effizienten Routen der Daten. Die Internet Engineering Task Force (IETF) hat dieses Jahr einen überarbeiteten Standard für ein protokollunabhängiges Multicasting herausgegeben.
Die Anwendungen, die den TCP/IP-Protokollstapel nutzen, entwickeln sich stetig weiter. Die
nächste Generation dieser Anwendungen nutzt Video- und Audioinformationen, übermittelt in Echtzeit
Aktienkurse, überträgt Firmennachrichten wie zum Beispiel Aktionärsversammlungen an alle oder an
ausgewählte Mitarbeiter und unterstützt webbasierte Fernlehrgänge (Interactive Video Distance
Learning). IP Multicasting – die Fähigkeit, IP-Pakete gleichzeitig an mehrere Stationen in einer
logischen Gruppe zu senden – ist ein wichtiger Baustein für Anwendungen wie Video over IP.
Videokonferenzen zum Beispiel erfordern die Fähigkeit, Videoinformationen gleichzeitig an mehrere
Teilnehmer zu schicken. Wird ein IP-Multicast-Data-gramm mit Videoinformationen an mehrere
Teilnehmer gleichzeitig übertragen, spart dies deutlich Bandbreite im Netz und optimiert die
Zeitsynchronisation.
Unterschiedliche Protokolle kommen hier zum Einsatz: IGMP (Internet Group Management Protocol)
dient dazu, die verschiedenen Hosts, die zu einer Multicast-Gruppe zusammengefasst sind, im
Internet zu lokalisieren und zu verwalten (join/leave multicast groups). Das von Cisco entwickelte
proprietäre CGMP (Cisco Group Management Protocol) erlaubt es Cisco-Catalyst-Switches, die Existenz
von Multicast-Clients an den Ports der Router und Layer-3-Switches zu erlernen.
Es existieren zwei Kategorien von Multicast-Routing-Protokollen: Dense Mode und Sparse Mode.
Beim Dense Mode geht man davon aus, dass fast alle Router Multicast-Verkehr im LAN weiterleiten.
Ein Beispiel: Der Chef eines Unternehmens möchte gelegentlich eine Nachricht an alle Mitarbeiter
der Hauptverwaltung senden. Die Bandbreite sollte für diese Anwendung ausreichend zur Verfügung
stehen. Zum Einsatz kommen hier:
Protocol Independent Multicast – Dense Mode (PIM-DM, RFC 3973 von 1/2005),
Distance Vector Multicast Routing Protocol (DVMRP, RFC 1075) und
Multicast Open Shortest Path First (MOSPF, RFC 1584).
Der Sparse Mode eignet sich für Anwendungen, bei denen die Teilnehmer über einen größeren
Bereich (WAN) verteilt sind, nur wenige Router den Multicast-Verkehr verarbeiten und Bandbreite
knapp bemessen ist. Die Protokolle für diese Betriebsweise sind:
Core-based Tree (CBT, RFC 2201) und
Protocol Independent Multicast – Sparse Mode (PIM-SM, RFC 2362).
Multicast-Datenverkehr nutzt auf dem OSI-Layer 4 (Transportschicht) das User Datagram Protocol
(UDP). Dies bedeutet, dass die Reihenfolge und die Korrektheit der Daten nicht gewährleistet
ist.
Unicast versus Multicast
In einem Netz mit Unicast-Datenverkehr schickt der Server jedem Client mit einer Unicast-Adresse
die Kopie eines Pakets. Bei größerem Datenverkehr ist die Bandbreite für jeden Empfänger
entsprechend zu dimensionieren. Der Netzwerkmanager muss zwei Kriterien besonders beachten: die
Zahl der Teilnehmerverbindungen und die der Unicast-Übertragungen. Bei Broadcast-Übertragungen
sendet die Anwendung nur eine Kopie jedes Pakets an alle Broadcast-Adressen. Dieser Datenverkehr
wird entweder an der Broadcast-Domain-Grenze (Layer 3) aufgehalten oder erreicht das gesamte Netz.
Stationen, die nicht am Broadcast-Verkehr teilnehmen wollen, erhalten diese Daten dennoch: Alle
Stationen nutzen die Broadcast-Adresse.
Für das Weiterleiten größerer Datenmengen ist Multicast die effizientere Methode: Nur Stationen
mit einer Multicast-Adresse, die in die Multicast-Gruppe eingetragen sind, erhalten die Daten.
Durch die Einrichtung mehrere Multicast-Gruppen lassen sich Daten dediziert an spezielle Gruppen
versenden, zum Beispiel an alle Führungskräfte im Unternehmen. Mit größerer Client-Anzahl steigt
der Datendurchsatz beim Multicast-Verkehr nicht.
Adressierung bei IP Multicast
Beim IP Multicasting ist die Gruppe von Hosts durch eine gemeinsame IP-Adresse identifiziert.
Die IP-Multicast-Adressen sind als Class D bei den 32-Bit-Internet-Adressen durch die IANA
(Internet Assigned Numbers Authority) als "well-known addresses" spezifiziert. Im LAN wird die
48-Bit-MAC-Adresse zu verwenden sein. Die IANA hat eine Gruppe von MAC-Adressen dafür reserviert.
Die OUI (Vendor Code oder Prefix) der MAC-Adresse ist im Bereich 01:00:5e:00:00:00 bis
01:00:5e:ff:ff:ff festgelegt. Der zweite Teil einer Ethernet-Multicast-Adresse wird aus der
Multicast-IP-Adresse entnommen. Der Sender von Multicast-Daten wird immer mit seiner
Unicast-Adresse senden und braucht nicht Mitglied einer Multicast-Gruppe zu sein.
Ein Beispiel:
IP-Adresse = 224.1.10.10 Class D
MAC-Adresse = 0100.5E04.0302
Gesucht: Multicast-MAC-Adresse
Ergebnis: 0100.5E01.0A0A
Funktionsweise
Die erste Aufgabe des Netzmanagers ist die Zuordnung, welche Station im Netz Multicast-Daten
empfängt und in welche Multicast-Gruppe kommt. Mittels IGMP zum Beispiel ist die Verwaltung dieser
Zuordnungen automatisch steuerbar. Am Router aktiviert der Administrator die Funktion Multicast.
Ein Query-Aufruf fragt die Stationen ab, die am Multicast-Verkehr teilnehmen wollen. Dieser Aufruf
erfolgt jetzt alle 60 Sekunden. Bei IGMPv2 antwortet nur eine Station der Multicast-Gruppe
(Response Suppression). Mit Erhalt einer Query-Message setzt eine Station einen Countdown-Timer auf
einen zufälligen Zeitwert zwischen null und zehn Sekunden. Dieser Wert wird heruntergezählt. Bei
null sendet die Station einen Membership Report. Sieht die Station, bevor sie auf null
heruntergezählt hat, einen Membership Report, löscht sie ihren Countdown-Timer. Für jede
eingetragene Gruppe führen die Stationen einen eigenen Timer.
Stationen, die sich bei der Multicast-Gruppe eintragen wollen, brauchen nicht auf ein Query zu
warten. Mit einer Report Message melden sich die für Multicast eingerichteten Stationen. Bei IGMPv1
gibt es keine spezielle Funktion für das Verlassen einer Gruppe. Durch die Query Message bleibt der
Router relativ gut informiert. Bei IGMPv2 schicken die Stationen Leave-Messages an alle
224.0.0.2-Multicast-Router. Diese Funktion verkürzt die Zeit zur Aktualisierung der Tabelle für die
Gruppenmitglieder. Der Eintrag "TTL = 1" (Time to Live) im IP-Header vermeidet, dass die
Query-Nachricht über den nächsten Router in andere Netze gelangt. In der Multicast Membership Query
Message vom Router wird bei IGMPv1 die Gruppenadresse auf 0 gesetzt. Der Router schickt die Query
also an alle Hosts mit der Multicast-Adresse 224.0.0.1.
IGMP
IGMPv1 (RFC 1112) benutzt das in Bild 3 gezeigte Rahmenformat. IGMPv2 (RFC 2236) erweitert
Version 1 zum Beispiel um Leave-Messages.
Für IGMPv2 ist neben der General Query (allgemeinen Abfrage) auf der Multicast-Adresse 224.0.0.1
eine gruppenspezifische Query auf eine spezielle Multicast-Gruppe implementiert. IGMPv2 kennt vier
Message-Typen:
0x11 Membership Query,
0x12 V1 Membership Report,
0x16 V2 Membership Report und
0x17 Leave Report.
IGMPv2 definiert ein Verfahren zur Auswahl des Routers im gleichen Netz, der die Queries senden
soll: Der Router mit der kleinsten IP-Adresse sendet die Abfragen. Sieht ein Router ein Query mit
einer kleineren IP-Adresse als seine eigene, stellt er selbst das Senden von Queries ein. Empfängt
ein IGMPv2-Router eine Leave Message, wird er sofort eine Query Message senden, um zu prüfen, ob
noch ein anderes Multicast-Gruppenmitglied an dieser Schnittstelle aktiv ist.
Windows XP und einige Unix-Betriebssysteme unterstützen IGMPv3 (RFC 3376 von 10/2002, Bild 4).
Mit dieser Version ist es einer vorbestimmten Multicast-Gruppe von Hosts (Empfängern) möglich,
Daten von dedizierten Hosts (Sendern – source specific) zu empfangen. Alle Rechner in der
Multicast-Gruppe antworten auf IGMPv3-Queries. Die Multicast-Adresse 224.0.0.22 wurde speziell für
IGMPv3-Router eingerichtet.
Fünf Typen von IGMP-Messages sind in Version 3 implementiert:
0x11 Membership Query (modifiziert),
0x12 V.1 Membership Report (RFC 1112),
0x16 V.2 Membership Report (RFC 2236),
0x17 Leave Report (RFC 2236) und
0x22 V.3 Membership Report (neu).
Routing von Multicast-Verkehr
Für eine effiziente Übertragung von Multicast-Daten bilden bestimmte Router mithilfe von
Multicast-Routing-Protokollen eine schleifenfreie Baumstruktur. Diese verbindet alle Stationen im
Netz, die zu einer Multicast-Gruppe gehören. Nachrichten erreichen nur dann eine Schnittstelle am
Router, wenn dort Stationen aktiv sind, die am Multicast-Verkehr teilnehmen. Zwei grundlegende
Techniken kommen für die Bildung einer Baumstruktur zum Einsatz: der Source-Distribution- und der
Shared-Distribution-Baum.
Der Source-Distribution-Baum legt für jede Multicast-Gruppe den kürzesten Weg zwischen Sender
und Empfänger fest (Shortest Path Tree, SPT), um eine minimale zeitliche Verzögerung für die
Empfänger zu erreichen. Die Methode für den Source-Distribution-Baum heißt Reverse Path Forwarding
(RPF). Dies reduziert die unnötige Duplizierung von Paketen. Zu den Protokollen für diese Technik
zählen DVMRP und MOSPF.
Das Verfahren für den Shared-Distribution-Baum bietet den geringsten Overhead bei der
Übertragung. Diese Methode ist auch als Rendezvous Point Tree (RPT) oder Center-specific Tree
bekannt. Während beim Source-Distribution-Baum für jeden Sender (für jede Multicast-Gruppe) ein
eigener schleifenfreier Baum gebildet wird, dient beim Shared-Distribution-Baum ein gemeinsamer
Baum allen Mitgliedern der Multicast-Gruppen. Protokolle dieser Methode sind CBT und PIM-SM.
PIM-SM wurde jüngst überarbeitet und wird in diesem Jahr als RFC herausgegeben. PIM-Router
senden periodisch Multicast Hello Messages, um benachbarte PIM-Router zu erkennen. Der Router mit
der größten Network-Layer-Adresse (IP-Adresse) dient als Designated Router (DR). Hello-Nachrichten
werden als Multicast-Messages mit der Adresse 224.0.0.13 gesendet. Ein Hold-Time-Feld in den
Optionen definiert, wie lange diese Information gültig ist. Die Router senden kein ACK auf diese
Hello-Message. Anders als bei anderen Routing-Protokollen, zum Beispiel bei DVMRP, bedeutet der
Empfang einer Hello-Message nicht automatisch, dass der Router die Empfangsschnittstelle in die
Liste der Multicast-Schnittstelle aufnimmt. PIM-SM benutzt ein explizites "Join Model": Ein
Downstream-Empfänger muss einer Gruppe von Multicast-Nachrichtenempfängern vor Empfang einer
Multicast-Nachricht beitreten.
Die Felder im PIM-SM-Header weisen folgende Inhalte auf:
"Ver" ist die PIM-Version (4 Bits),
"Type" ist die Kennzeichnung der speziellen Control-Message (4 Bits, Tabelle 1
auf Seite 65),
"Reserved" wird auf 0 gesetzt (8 Bits),
"Checksum" ist das 16-Bit-Einerkomplement der vollständigen PIM-Message (ohne
den Datenteil in der Register-Message) (16-Bit).
Der Designated Router (DR) ist für die Übertragung von Multicast-Join/Prune-Messages zum
Rendezvous Point (RP) für jede Gruppe verantwortlich. Der RP ist die Wurzel der
Shared-Distribution-Baumstruktur. Die Konfiguration des RPs erfolgt entweder manuell oder
automatisch, wie bei Cisco. Die Router senden die Join/Prune-Messages zu den Upstream-Routern und
zu den RPs. Die Router nutzen Joins zur Bildung der schleifenfreien Baumstrukturen für die
entsprechende Gruppe.
Der Sender schickt die Multicast-Informationen an seinen DR. Dieser packt die Daten in eine
Unicast-Register-Message und überträgt sie zum RP für diese Gruppe. Der RP entpackt sie und leitet
die extrahierten Daten zu den Downstream-Mitgliedern am RPT. Mit der Register-Stop-Message
informiert der RP den DR über den Empfang von Multicast-Daten. Der DR stellt nun das Packen der
Daten in die Register-Message ein und sendet normale Multicast-Daten.
Lesen Sie mehr zum Thema
