Von: Joachim Zubke, Stefan Bohnert
Börsendienste, Online-Newsletter oder Radioprogramme über das Internet zu empfangen, ist für viele Nutzer des "Netzes der Netze" mittlerweile eine Selbstverständlichkeit. Diese Anwendungen haben eines gemeinsam: Die Daten werden von einem Server oder einer Serverfarm aus an viele Empfänger übermittelt. Stand der Technik war bislang, dass jeder Empfänger seine eigene Kopie der Daten erhielt. Dieses Verfahren beansprucht allerdings unnötig viel Bandbreite und erhöht die Übertragungszeiten. Das bereitet nicht nur Internet-Serviceprovidern oder Online-Diensten Kopfzerbrechen, sondern auch Unternehmen, die regelmäßig große Datenmengen über Intra- oder Extranets an Mitarbeiter oder Partner versenden. Dabei kann es sich um Preislisten oder Produktinformationen handeln. Sind dabei Weitverkehrsstrecken im Spiel, kommen zu den Performance-Verlusten, bedingt durch die mehrfache Datenübertragung, die Gebühren für die Übertragungsleitung hinzu.
Aus diesem Grunde wurde IP-Multicasting entwickelt. Bei diesem Verfahren speist der Sender die Daten nur einmal in das Netz ein. Die Router duplizieren dann die Pakete und leiten sie zu den Adressaten in den jeweiligen Netzsegmenten weiter. Die Daten fließen also nur einmal über die Verbindungsstrecke von Server zu Router und von Router zu Router. IP-Multicasting ist nicht auf Ethernet-Netze beschränkt, sondern eignet sich ebenso für ATM, Frame Relay, SMDS und Satelliten-Verbindungen.
Folgende Komponenten bilden die Grundlage des Verfahrens:
- die Adressierung: Auf der Netzwerkebene des OSI-Referenzmodells muss eine Adressierungsmöglichkeit für eine Gruppe von Empfängern im Unterschied zu einzelnen Empfängern bestehen. Dies setzt voraus, dass sich diese Adresse einer Multicast-Adresse auf der Verbindungsebene (Data Link Layer) des OSI-Modells zuordnen lässt. Beim Empfänger bewerkstelligen das der IP-Protokollstack und die Netzwerkkarten. Die Empfänger filtern also anhand der auf der Netzwerkkarte eingestellten MAC-Multicast-Adresse die für sie bestimmten Daten-Frames heraus und geben sie an die nächsthöhere Protokollebene weiter.
- Dynamische Registrierung: Ein Host muss jederzeit einer Multicast-Gruppe beitreten und diese verlassen können. Ohne diese Möglichkeit können die Router nicht entscheiden, welche Subnetze die Daten für eine Multicast-Gruppe empfangen sollen. Das "Internet Group Member-ship Protocol" (IGMP) legt fest, auf welche Weise ein Host dem Netzwerk mitteilt, dass er einer bestimmten Multicast-Gruppe angehört. Der Host-Rechner informiert den lokalen Router, wenn er Daten empfangen möchte, die an eine bestimmte Multicast-Gruppe adressiert sind. Die Router ihrerseits prüfen in regelmäßigen Abständen, ob die Gruppenmitglieder im LAN noch aktiv sind. Anhand der Gruppentabellen kann der Router dann entscheiden, welche Multicast-Pakete in welche Zweige seiner Subnetze weiterzuleiten sind.
- Multicast-Routing: Die Router müssen in der Lage sein, "Multicast-Bäume" aufzubauen. Mit ihrer Hilfe kann ein Host an alle Empfänger Pakete verteilen. Die Multicast-Bäume sollen in erster Linie sicherstellen, dass jedes Paket nur einmal in einem Subnetz vorhanden ist. Wenn in einem Zweig mehrere Empfänger existieren, darf ein Multicast-Paket also nur einmal in diesen Zweig eingespeist werden. Um Multicast-Datagramme transportieren zu können, müssen die Router mindestens ein Multicast-Routing-Protokoll unterstützen. Die drei wichtigsten Multicast-Routing-Protokolle sind "Protocol Independent Multicast" (PIM), das "Distance Vector Multicast Routing Protocol " (DVMRP) und "Multicast Open Shortest Path First" (MOSPF). Zusätzlich kommt das "Resource Reservation Protocol" (RSVP) zum Einsatz, um beispielsweise Echtzeitapplikationen eine bestimmte Dienstgüte (Quality of Service, QoS) zur Verfügung zu stellen.
Um eine Punkt-zu-Mehrpunkt-Kommunikation aufzubauen, stehen mehrere Alternativen zur Auswahl. Eine ist das Unicast-Modell. Dazu folgendes Beispiel: Host 1 möchte Daten an die Hosts 2, 3 und 4 senden. Dazu muss er die IP-Adressen aller drei Empfänger kennen. Mit der Zahl der Empfänger steigt auch die Zahl der Pakete linear an, die Host 1 übermitteln muss. Hier wird ein Pferdefuß des Verfahrens deutlich: Sind beispielsweise Echtzeit-Video- oder -Audiodaten an wenige Empfänger zu übertragen, kommt das Unicast-Modell durchaus in Frage; steigt jedoch die Zahl der Empfänger, erhöht sich auch die Belastung des Host-Rechners. Das wiederum führt möglicherweise dazu, dass die Verzögerungszeiten (Delay) zwischen einzelnen Paketen zu stark anwachsen und die Kommunikation erheblich beeinträchtigt wird. Auch der Quell-Router kann sich zum Flaschenhals entwickeln.
Ein weiteres Problem ist, dass der Sender die IP-Adresse jedes Empfängers kennen muss. Das bedeutet, kein Empfänger kann einer Gruppe dynamisch beitreten oder sie verlassen.
Die zweite Alternative ist das Broadcast-Modell: Der Sender übermittelt die Daten in diesem Fall nur einmal an alle potenziellen Empfänger. Die Vorteile: Jeder Host im lokalen Subnetz erhält die Informationen, und jedes Paket muss nur einmal gesendet werden.
Broadcasting und Multicasting
Doch auch dieses Verfahren hat seine Tücken. Das erste Problem besteht darin, dass die Netzlast in denjenigen Segmenten sehr hoch werden kann, für welche die Daten nicht bestimmt sind. Hinzu kommt, dass jeder Host den Broadcast-Verkehr auf Layer 2 verarbeiten muss, um nachzuprüfen, ob die Daten auch an ihn adressiert wurden. In diesem Fall ist es erforderlich, das IP-Paket aus dem Frame zu entpacken. Da auch die Ziel-IP-Adresse einen Broadcast darstellt, müssen zusätzlich der UDP- oder TCP-Teil aus dem IP-Paket herausgeschält und weitergegeben werden. Daten, auf die eine Anwendung wartet, laufen zur Anwendungsebene (Application Layer) weiter; anderenfalls werden sie weggeworfen. Das heißt allerdings: Jeder Host, der mit diesen Paketen nichts anfangen kann, vergeudet Prozessorzeit.
Das Multicasting-Modell vermeidet die Nachteile von Broadcasting und Unicasting. Es benötigt dazu allerdings zwei neue Adresstypen: eine IP-Multicast- und eine MAC-Multicast-Adresse. Die IP-Multicast-Adresse kennzeichnet eine Empfängergruppe, die den Verkehr empfangen möchte. Weil alle IP-Pakete in Frames verpackt sind, ist zusätzlich eine MAC-Multicast-Adresse erforderlich. Damit das Multicast-Modell auch korrekt funktioniert, sollten Hosts sowohl Unicast- als auch Multicast-Verkehr empfangen können. Die Host-Systeme verfügen also über unterschiedliche IP- und MAC-Adressen für Uni- und Multicast.
Ein Host benötigt nur dann eine Multicast-Adresse, wenn er entsprechende Daten empfangen möchte. Für jede Multicast-Gruppe, welcher der Empfänger beitritt, ist dagegen eine MAC- und IP-Multicast-Adresse erforderlich. Unicast-Adressen sind im Gegensatz zu Multicast-Adressen auf jedem Host eindeutig.
Ein wesentliches Merkmal von Multicasting ist die dynamische Mitgliedschaft in Gruppen. Das bedeutet zum einen, dass ein Host Daten für bestimmte Multicast-Gruppen nur dann empfangen sollte, wenn eine aktive Anwendung diese benötigt. Zum anderen ist es wünschenswert, dass ein Host Multicast-Gruppen nach Belieben beitreten und verlassen kann. Die Router müssen wissen, ob sie Multicast-Verkehr zu den Gruppenmitgliedern weiterleiten sollen. Sie benötigen dazu Informationen über die Gruppenmitglieder und Multicast-taugliche Routing-Protokolle (siehe dazu Beitrag in der kommenden Ausgabe 4/2000 von NetworkWorld).
Die Adressierung von Multicast-Daten
Multicast-Adressen sind IP-Adressen der Klasse D. Sie sind intern nicht strukturiert, verfügen also über keine Subnetzmaske. Wie Unicast-Adressen müssen auch die auf der Netzwerkschicht (Network Layer) angesiedelten Multicast-Adressen auf Multicast-Adressen der Verbindungsschicht (Data Link Layer) abgebildet werden. IP-Multicast-Adressen werden also auf MAC-Adressen abgebildet und umgekehrt.
IEEE-802-LANs benutzen eine 48-Bit-MAC-Adresse. Ist das M-Bit nicht gesetzt (M=0), handelt es sich um eine Unicast-Adresse, anderenfalls (M=1) um eine Multicast-Adresse. Das L-Bit ist das "Universal/Local Bit". Hat es den Wert 0, repräsentiert es eine weltweit einzigartige MAC-Adresse. Bei Multicast-MAC-Adressen muss also das M-Bit auf 1 und das L-Bit auf 0 stehen. Weil bei Multicast kein ARP Request (Address Resolution Protocol) oder vergleichbarer Mechanismus vorhanden ist, haben alle MAC-Layer für Multicast-Adressen dieselbe Struktur. DasIEEE gab mit 0x01-00-5E einen fes-ten "Organizationally Unique Identifier" (OUI) vor. Das darauf folgende Bit ist reserviert und steht immer auf 0. Deshalb bleiben nur 23 Bit für das Mapping der IP-Adresse übrig.
Problematisch ist, dass der Adressraum von Multicast-MAC-Adressen kleiner ist als der von Multicast-IP-Adressen. Bei letzteren sind die ersten vier Bit des höchstwertigen Byte auf den Wert "1110" gesetzt, die anderen 28 Bit stehen zur Kennzeichnung einer Gruppe zur Verfügung. Bei den MAC-Adressen sind es lediglich 23 Bit. Deshalb lassen sich beide Adresstypen nicht exakt aufeinander abbilden. In der Praxis werden deshalb die ersten fünf Bit der Gruppenkennung einer Multicast-IP-Adresse ignoriert und die folgenden 23 Bit berücksichtigt.
Fehlleitung von Multicast-Paketen durch MAC-Adresse
Die Folge ist, dass zumindest theoretisch 25, also 32 unterschiedliche Class-D-Adressen eine gemeinsame Multicast-MAC-Adresse verwenden. Endsysteme können deshalb Multicast-Pakete empfangen, die eigentlich nicht für sie bestimmt sind - nämlich dann, wenn sich ihre IP-Multicast-Adressen nur in den wegfallenden fünf Bit unterscheiden. Diese Multicast-Pakete passieren die Verbindungsschicht (Data Link Layer), werden jedoch auf der Netzwerkschicht (Network Layer) verworfen, weil keine Anwendung die IP-Multicast-Adresse angefordert hat oder verarbeiten kann. Der ganze Vorgang geht jedoch auf Kosten der Rechenleistung.
In der nächsten Ausgabe gehen wir auf Multicast-Protokolle ein, insbesondere Group-Management-Protokolle und Multicast-Routing-Protokolle, wie etwa "Protocol Independent Multicast" (PIM) und das "Distance Vector Multicast Routing Protocol" (DVMRP). (re)Joachim Zubke
studierte an der Fachhochschule Hamburg Elektrotechnik, Fachrichtung Nachrichtentechnik. Seit Herbst 1999 ist er bei der Firma Netsprint Consulting in Hamburg als zertifizierter Netzwerk-Trainer für Cisco Systems tätig.
Zur Person
Joachim Zubke
studierte an der Fachhochschule Hamburg Elektrotechnik, Fachrichtung Nachrichtentechnik. Seit Herbst 1999 ist er bei der Firma Netsprint Consulting in Hamburg als zertifizierter Netzwerk-Trainer für Cisco Systems tätig
Stefan Bohnert
absolvierte ebenfalls in Hamburg ein Studium im Fach Elektrotechnik. Wie Zubke ist Stefan Bohner bei Netsprint als Netzwerktrainer tätig.