Multicast – Überblick

Vergleich von Multicast und Unicast

Der Routing-Protokollprozess des Betriebssystems Junos® (Junos OS) unterstützt eine Vielzahl von Routing-Protokollen. Diese Routing-Protokolle übertragen Netzwerkinformationen zwischen den Routing-Geräten nicht nur für Unicast-Datenverkehrsströme , die zwischen einem Client- und Serverpaar gesendet werden, sondern auch für Multicast-Datenströme mit Video, Audio oder beidem zwischen einer einzelnen Serverquelle und vielen Clientempfängern. Die für Multicast verwendeten Routingprotokolle unterscheiden sich in vielerlei Hinsicht von Unicast-Routingprotokollen.

Informationen werden über ein Netzwerk mit drei grundlegenden Methoden bereitgestellt: Unicast, Broadcast und Multicast.

Die Unterschiede zwischen Unicast, Broadcast und Multicast lassen sich wie folgt zusammenfassen:

• Unicast: Eins-zu-eins, von einer Quelle zum Ziel.

• Broadcast: One-to-All, von einer Quelle zu allen möglichen Zielen.

• Multicast: Eins-zu-viele, von einer Quelle zu mehreren Zielen, die Interesse am Empfang des Datenverkehrs bekunden.

  Anmerkung:

  Diese Liste enthält keine spezielle Kategorie für Many-to-Many-Anwendungen, wie z. B. Online-Spiele oder Videokonferenzen, bei denen es viele Quellen für denselben Empfänger gibt und bei denen Empfänger häufig auch als Quellen fungieren. Many-to-Many ist ein Dienstmodell, das wiederholt Eins-zu-Viele-Multicast verwendet und daher kein eindeutiges Protokoll erfordert. Die ursprüngliche Multicast-Spezifikation, RFC 1112, unterstützt sowohl das Many-to-Many-Modell (ASM) als auch das Eins-zu-Viele-Modell (Source-Specific Multicast, SSM).

Beim Unicast-Datenverkehr fließen viele Ströme von IP-Paketen, die über Netzwerke übertragen werden, von einer einzigen Quelle, z. B. einem Website-Server, zu einem einzelnen Ziel, z. B. einem Client-PC. Unicast-Datenverkehr ist nach wie vor die häufigste Form der Informationsübertragung in Netzwerken.

Broadcast-Datenverkehr fließt von einer einzigen Quelle zu allen möglichen Zielen, die im Netzwerk erreichbar sind, was in der Regel ein LAN ist. Broadcasting ist der einfachste Weg, um sicherzustellen, dass der Datenverkehr seine Ziele erreicht.

Fernsehsender nutzen Broadcasting, um Video und Audio zu verbreiten. Selbst wenn es sich bei dem Fernsehnetz um ein Kabelfernsehsystem (CATV) handelt, erreicht das Quellsignal alle möglichen Ziele, was der Hauptgrund dafür ist, dass die Inhalte einiger Kanäle verschlüsselt werden. Die Übertragung im Internet ist aufgrund der enormen Menge unnötiger Informationen, die ständig auf dem Gerät jedes Endbenutzers ankommen würden, der Komplexität und der Auswirkungen der Verschlüsselung und der damit verbundenen Datenschutzprobleme nicht möglich.

Der Multicast-Datenverkehr liegt zwischen den Extremen von Unicast (eine Quelle, ein Ziel) und Broadcast (eine Quelle, alle Ziele). Multicast ist eine Methode der Datenverkehrsverteilung nach dem Motto "Eine Quelle, viele Ziele", d. h., nur die Ziele, die explizit angeben, dass sie die Informationen von einer bestimmten Quelle erhalten möchten, erhalten den Datenstrom.

Da in einem IP-Netzwerk Ziele (Clients) oft nicht direkt mit Quellen (Servern) kommunizieren, müssen die Routing-Geräte zwischen Quelle und Ziel in der Lage sein, die Topologie des Netzwerks aus der Unicast- oder Multicast-Perspektive zu bestimmen, um zu vermeiden, dass Datenverkehr willkürlich weitergeleitet wird. Multicast-Routing-Geräte replizieren Pakete, die auf einer Eingabeschnittstelle empfangen werden, und senden die Kopien an mehrere Ausgabeschnittstellen.

Beim IP-Multicast sind Quelle und Ziel fast immer Hosts und keine Routing-Geräte. Multicast-Routing-Geräte verteilen den Multicast-Datenverkehr über das Netzwerk von der Quelle zu den Zielen. Das Multicast-Routing-Gerät muss Multicast-Quellen im Netzwerk finden, Kopien von Paketen an mehreren Schnittstellen senden, Routing-Schleifen verhindern, interessierte Ziele mit der richtigen Quelle verbinden und den Fluss unerwünschter Pakete auf ein Minimum beschränken. Standard-Multicast-Routing-Protokolle bieten die meisten dieser Funktionen, aber einige Routerarchitekturen können nicht mehrere Kopien von Paketen senden und unterstützen daher Multicasting nicht direkt.

IP-Multicast-Anwendungen

Multicast ermöglicht es einem IP-Netzwerk, mehr als nur das Unicast-Modell der Datenübermittlung zu unterstützen, das in den frühen Stadien des Internets vorherrschte. Multicast, ursprünglich 1989 in RFC 1112 als Hosterweiterung definiert, bietet eine effiziente Methode zur Bereitstellung von Datenverkehrsströmen, die als eins-zu-viele oder viele-zu-viele charakterisiert werden können.

Der Unicastdatenverkehr ist nicht ausschließlich auf Datenanwendungen beschränkt. Telefongespräche, ob drahtlos oder nicht, enthalten digitale Audiobeispiele und können digitale Fotos oder sogar Videos enthalten und dennoch von einer einzigen Quelle zu einem einzigen Ziel fließen. Ebenso ist Multicast-Verkehr nicht streng auf Multimedia-Anwendungen beschränkt. In einigen Datenanwendungen erfolgt der Datenverkehrsfluss von einer einzigen Quelle zu vielen Zielen, die die Pakete benötigen, wie bei einem Nachrichten- oder Börsentickerdienst, der an viele PCs geliefert wird. Aus diesem Grund wird der Begriff Empfänger dem Listener für Multicastziele bevorzugt, obwohl beide Begriffe gebräuchlich sind.

Zu den Netzwerkanwendungen, die mit Unicast funktionieren können, aber besser für Multicast geeignet sind, gehören kollaborative Groupware, Telekonferenzen, periodische oder "Push"-Datenübermittlung (Aktienkurse, Sportergebnisse, Zeitschriften, Zeitungen und Anzeigen), Server- oder Website-Replikation und verteilte interaktive Simulationen (DIS) wie Kriegssimulationen oder virtuelle Realität. Jedes IP-Netzwerk, das den Overhead der Netzwerkressourcen für Eins-zu-Viele- oder Viele-zu-Viele-Daten- oder Multimedia-Anwendungen mit mehreren Empfängern reduzieren möchte, profitiert von Multicast.

Würde Unicast von Radio- oder Newsticker-Diensten eingesetzt, müsste jedes Radio oder jeder PC für jeden Hörer oder Zuschauer an einem PC eine eigene Verkehrssitzung haben (dies ist tatsächlich die Methode für einige webbasierte Dienste). Die Verarbeitungslast und die Bandbreite, die vom Server verbraucht werden, würden linear zunehmen, wenn sich mehr Personen auf den Server "einstellen". Das ist extrem ineffizient, wenn man es mit der globalen Skala des Internets zu tun hat. Unicast belastet den Server durch die Duplizierung von Paketen und verbraucht mit steigender Nutzerzahl immer mehr Backbone-Bandbreite.

Würde stattdessen Broadcast verwendet, könnte die Quelle einen einzelnen IP-Paketstrom mit einer Broadcast-Zieladresse generieren. Obwohl das Problem der Duplizierung von Serverpaketen durch Broadcast beseitigt wird, ist dies keine gute Lösung für IP, da IP-Broadcasts nur an ein einzelnes Subnetz gesendet werden können und IP-Routinggeräte IP-Subnetze normalerweise auf separaten Schnittstellen isolieren. Selbst wenn ein IP-Paketstrom so adressiert werden könnte, dass er buchstäblich überall hingeht, und es nicht nötig wäre, sich auf irgendeine Quelle "einzustellen", wäre die Übertragung aufgrund der Bandbreitenbelastung und der Notwendigkeit, dass uninteressierte Hosts eine große Anzahl von Paketen verwerfen, äußerst ineffizient. Broadcast belastet jeden Host durch die Paketablehnung und verbraucht die maximale Menge an Backbone-Bandbreite.

Für Radiosender oder Newsticker-Traffic bietet Multicast das effizienteste und effektivste Ergebnis, ohne die Nachteile und alle Vorteile der anderen Methoden. Eine Single Source of Multicast Packets findet den Weg zu jedem interessierten Empfänger. Wie beim Broadcast erzeugt der sendende Host nur einen einzigen Strom von IP-Paketen, sodass die Last konstant bleibt, unabhängig davon, ob es einen oder eine Million Empfänger gibt. Die Netzwerk-Routing-Geräte replizieren die Pakete und übermitteln die Pakete an die richtigen Empfänger, aber nur die Replikationsrolle ist eine neue Rolle für Routing-Geräte. Die Verbindungen, die zu Subnetzen führen, die aus völlig uninteressierten Empfängern bestehen, übertragen keinen Multicast-Datenverkehr. Multicast minimiert die Belastung von Sender, Netzwerk und Empfänger.

IP-Multicast-Terminologie

Multicast hat seine eigenen Begriffe und Akronyme, die für IP-Multicast-Routinggeräte und -Netzwerke gelten. Abbildung 1 zeigt einige der Begriffe, die in einem IP-Multicast-Netzwerk gebräuchlich sind.

In einem Multicast-Netzwerk ist die Schlüsselkomponente das Routing-Gerät, das in der Lage ist, Pakete zu replizieren und somit Multicast-fähig ist. Die Routing-Geräte im IP-Multicast-Netzwerk, das genau die gleiche Topologie wie das Unicast-Netzwerk aufweist, auf dem es basiert, verwenden ein Multicast-Routing-Protokoll, um eine Verteilungsstruktur aufzubauen, die Empfänger (bevorzugt für die Multimedia-Implikationen der Hörer, aber auch die Zuhörer werden verwendet) mit den Quellen verbindet. In der Multicastterminologie ist die Verteilungsstruktur an der Quelle verwurzelt (der Stamm der Verteilungsstruktur ist die Quelle). Die Schnittstelle auf dem Routing-Gerät, die zur Quelle führt, ist die Upstream-Schnittstelle, obwohl auch die weniger präzisen Begriffe Incoming- oder Inbound-Interface verwendet werden. Um die Bandbreitennutzung auf ein Minimum zu beschränken, empfiehlt es sich, wenn nur eine Upstreamschnittstelle auf dem Routinggerät Multicast-Pakete empfängt. Die Schnittstelle auf dem Routing-Gerät, die zu den Empfängern führt, ist die Downstream-Schnittstelle, obwohl auch die weniger präzisen Begriffe Outgoing- oder Outbound-Schnittstelle verwendet werden. Es kann 0 bis N–1 Downstream-Schnittstellen auf einem Routing-Gerät geben, wobei N die Anzahl der logischen Schnittstellen auf dem Routing-Gerät angegeben ist. Um Schleifen zu vermeiden, darf die Upstreamschnittstelle niemals Kopien von Downstream-Multicastpaketen empfangen.

Abbildung 1: Multicast-Terminologie in einem IP-Netzwerk

Routing-Schleifen sind in Multicast-Netzwerken katastrophal, da das Risiko wiederholt replizierter Pakete besteht. Eine der Komplexitäten moderner Multicast-Routing-Protokolle besteht darin, dass Routing-Schleifen Paket für Paket viel rigoroser vermieden werden müssen als bei Unicast-Routing-Protokollen.

Reverse-Path-Forwarding zur Schleifenvermeidung

Der Multicastweiterleitungsstatus des Routing-Geräts läuft logischer auf der Grundlage des umgekehrten Pfads vom Empfänger zurück zum Stamm der Verteilungsstruktur. In RPF muss jedes empfangene Multicast-Paket eine RPF-Prüfung bestehen, bevor es auf einer Schnittstelle repliziert oder weitergeleitet werden kann.

Wenn ein Router ein Multicast-Paket auf einer Schnittstelle empfängt, überprüft der Router die source Adresse. Der Router prüft dann, ob dieselbe Adresse auch als Adresse für den destination Rückweg zur Quelle über eine Unicastroute verwendet werden kann. Wenn es sich bei der ausgehenden Schnittstelle in der Unicast-Routing-Tabelle um dieselbe Schnittstelle handelt, auf der das Multicastpaket empfangen wurde, besteht das Paket die RPF-Prüfung.

Multicast-Pakete, die die RPF-Prüfung nicht bestehen, werden verworfen, da sich die eingehende Schnittstelle nicht auf dem kürzesten Weg zurück zur Quelle befindet. Routing-Geräte können separate Tabellen für RPF-Zwecke erstellen und verwalten.

Baum der kürzesten Pfade zur Schleifenvermeidung

Die für Multicast verwendete Verteilungsstruktur ist an der Quelle verwurzelt und ist die Struktur des kürzesten Pfads (SPT), aber dieser Pfad kann lang sein, wenn sich die Quelle an der Peripherie des Netzwerks befindet. Bereitstellung einer shared tree auf dem Backbone, da der Verteilungsbaum die Multicastquelle zentraler im Netzwerk lokalisiert. Gemeinsam genutzte Verteilungsstrukturen mit Wurzeln im Core-Netzwerk werden von einem Multicast-Routing-Gerät erstellt und verwaltet, das als Rendezvous Point (RP) fungiert (eine Funktion von Multicast-Protokollen mit geringer Verfügbarkeit).

Administrativer Umfang zur Schleifenvermeidung

Das Scoping schränkt die Routinggeräte und -schnittstellen ein, die ein Multicastpaket weiterleiten können. Multicast-Scoping bedeutet administrative in dem Sinne, dass ein Bereich von Multicastadressen für Scoping-Zwecke reserviert wird, wie in RFC 2365, Administratively Scoped IP Multicastbeschrieben. Routing-Geräte an der Grenze müssen Multicast-Pakete filtern und sicherstellen, dass Pakete den festgelegten Grenzwert nicht überschreiten.

Multicast Leaf- und Branch-Terminologie

Jedes Teilnetz mit Hosts auf dem Routing-Gerät, das über mindestens einen interessierten Empfänger verfügt, ist ein Blatt in der Verteilungsstruktur. Routing-Geräte können mehrere Leaves auf verschiedenen Schnittstellen haben und müssen eine Kopie des IP-Multicast-Pakets an jede Schnittstelle mit einem Leaf senden. Wenn der Struktur ein neues Leaf-Subnetz hinzugefügt wird (d. h., die Schnittstelle zum Host-Subnetz hat zuvor keine Kopien der Multicast-Pakete erhalten), wird ein neuer Branch erstellt, das Leaf wird mit der Struktur verbunden, und replizierte Pakete werden an die Schnittstelle gesendet. Die Anzahl der Leaves auf einer bestimmten Schnittstelle wirkt sich nicht auf das Routing-Gerät aus. Die Aktion ist für ein oder hundert Blätter die gleiche.

Wenn ein Zweig keine Blätter enthält, weil es keine interessierten Hosts auf der Schnittstelle des Routinggeräts gibt, die zu diesem IP-Teilnetz führt, wird der Zweig aus der Verteilungsstruktur entfernt , und es werden keine Multicastpakete an diese Schnittstelle gesendet. Pakete werden nur dort repliziert und über mehrere Schnittstellen gesendet, wo der Verteilungsbaum an einem Routing-Gerät abzweigt, und keine Verbindung führt jemals einen doppelten Paketstrom.

Sammlungen von Hosts, die alle denselben Strom von IP-Paketen empfangen, in der Regel von derselben Multicastquelle, werden als Gruppen bezeichnet. In IP-Multicast-Netzwerken wird der Datenverkehr basierend auf einer IP-Multicast-Adresse oder Gruppenadresse an Multicast-Gruppen weitergeleitet. Die Gruppen bestimmen die Position der Blätter, und die Blätter bestimmen die Verzweigungen im Multicastnetzwerk.

IP-Multicast-Adressierung

Multicast verwendet den IP-Adressbereich der Klasse D (224.0.0.0 bis 239.255.255.255). Adressen der Klasse D werden allgemein als Multicastadressen bezeichnet, da das gesamte Konzept der Classful-Adressen veraltet ist. Multicastadressen können niemals als Quelladresse in einem IP-Paket angezeigt werden und können nur das Ziel eines Pakets sein.

Multicastadressen haben in der Regel eine Präfixlänge von /32, obwohl andere Präfixlängen zulässig sind. Multicastadressen stellen logische Gruppierungen von Empfängern und keine physischen Sammlungen von Geräten dar. Blöcke von Multicastadressen können in der traditionellen Schreibweise immer noch in Bezug auf die Präfixlänge beschrieben werden, aber nur der Einfachheit halber. Beispielsweise kann der Multicast-Adressenbereich von 232.0.0.0 bis 232.255.255.255 als 232.0.0.0/8 oder 232/8 geschrieben werden.

Internet Service Provider (ISPs) weisen ihren Kunden in der Regel keine Multicastadressen zu, da sich Multicastadressen auf Inhalte und nicht auf physische Geräte beziehen. Den Empfängern werden keine eigenen Multicast-Adressen zugewiesen, sondern sie müssen die Multicast-Adresse des Inhalts kennen. Quellen müssen Multicastadressen nur zugewiesen werden, um den Inhalt zu erzeugen, nicht aber, um ihren Platz im Netzwerk zu bestimmen. Jede Quelle und jeder Empfänger benötigt weiterhin eine gewöhnliche Unicast-IP-Adresse.

Die Multicastadressierung verweist in den meisten Fällen auf die Empfänger, und die Quelle von Multicastinhalten ist in der Regel nicht einmal Mitglied der Multicastgruppe, für die sie Inhalte produziert. Wenn die Quelle die von ihr produzierten Pakete überwachen muss, kann die Überwachung lokal erfolgen, und es ist nicht erforderlich, dass die Pakete das Netzwerk durchqueren.

Vielen Anwendungen wurde eine Reihe von Multicastadressen für den eigenen Gebrauch zugewiesen. Diese Anwendungen weisen Sitzungen, die von dieser Anwendung erstellt wurden, Multicastadressen zu. Sie müssen eine Multicast-Adresse in der Regel nicht statisch zuweisen, können dies jedoch tun.

Multicast-Adressen

Multicast-Hostgruppenadressen sind definiert als IP-Adressen, deren vier Bits höherer Ordnung 1110 sind, was einen Adressbereich von 224.0.0.0 bis 239.255.255.255 oder einfach 224.0.0.0/4 ergibt. (Diese Adressen werden auch als Klasse-D-Adressen bezeichnet.)

Die Internet Assigned Numbers Authority (IANA) verwaltet eine Liste der registrierten IP-Multicast-Gruppen. Die Basisadresse 224.0.0.0 ist reserviert und kann keiner Gruppe zugewiesen werden. Der Block der Multicastadressen von 224.0.0.1 bis 224.0.0.255 ist für die lokale Verwendung reserviert. Gruppen in diesem Bereich werden für verschiedene Verwendungszwecke zugewiesen, einschließlich Routing-Protokolle und lokale Ermittlungsmechanismen.

Der Bereich von 239.0.0.0 bis 239.255.255.255 ist für Adressen mit administrativem Bereich reserviert. Da Pakete, die an Multicastadressen im administrativen Bereich adressiert sind, die konfigurierten Verwaltungsgrenzen nicht überschreiten und da Multicastadressen im administrativen Bereich lokal zugewiesen werden, müssen diese Adressen nicht über Verwaltungsgrenzen hinweg eindeutig sein.

Layer-2-Frames und IPv4-Multicast-Adressen

Multicasting in einem LAN ist ein guter Ausgangspunkt, um Multicasting auf Layer 2 zu untersuchen. Auf Layer 2 verarbeitet Multicast MAC-Frames und -Adressen (Media Access Control) anstelle von IPv4- oder IPv6-Paketen und -Adressen. Stellen Sie sich ein einzelnes LAN ohne Routing-Geräte mit einer Multicast-Quelle vor, die an eine bestimmte Gruppe sendet. Die restlichen Hosts sind Empfänger, die sich für den Inhalt der Multicast-Gruppe interessieren. Daher generiert der Multicast-Quellhost Pakete mit seiner Unicast-IP-Adresse als Quelle und der Multicastgruppenadresse als Ziel.

Welche MAC-Adressen werden in dem Frame verwendet, der dieses Paket enthält? Die Paketquelladresse – die Unicast-IP-Adresse des Hosts, von dem der Multicast-Inhalt stammt – lässt sich einfach und direkt in die MAC-Adresse der Quelle übersetzen. Aber wie sieht es mit der Zieladresse des Pakets aus? Dies ist die Adresse der IP-Multicast-Gruppe. Welche Ziel-MAC-Adresse für den Frame entspricht der Multicast-Gruppenadresse des Pakets?

Eine Möglichkeit besteht darin, dass LANs einfach die LAN-Broadcast-MAC-Adresse verwenden, die garantiert, dass der Frame von jeder Station im LAN verarbeitet wird. Dieses Verfahren vereitelt jedoch den gesamten Zweck von Multicast, der darin besteht, die Zirkulation von Paketen und Frames an interessierte Hosts zu beschränken. Außerdem können Hosts Zugriff auf viele Multicast-Gruppen haben, wodurch sich die Menge des Datenverkehrs zu nicht interessierten Zielen vervielfacht. Es macht keinen Sinn, Frames auf LAN-Ebene zu übertragen, um Multicast-Gruppen zu unterstützen.

Es gibt jedoch eine einfache Möglichkeit, Layer 2-Frames effektiv für Multicast-Zwecke zu verwenden. Die MAC-Adresse hat ein Bit, das für Unicast auf 0 gesetzt ist (der LAN-Begriff ist individuelle Adresse) und auf 1 gesetzt ist, um anzugeben, dass es sich um eine Multicast-Adresse handelt. Einige dieser Adressen sind Multicast-Gruppen bestimmter Anbieter oder Protokolle auf MAC-Ebene vorbehalten. Internetmulticastanwendungen verwenden den Bereich 0x01-00-5E-00-00-00 bis 0x01-00-5E-FF-FF-FF. Multicastempfänger (Hosts, auf denen TCP/IP ausgeführt wird) lauschen auf Frames mit einer dieser Adressen, wenn die Anwendung einer Multicastgruppe beitritt. Der Host hört nicht mehr zu, wenn die Anwendung beendet wird oder der Host die Gruppe auf der Paketschicht (Schicht 3) verlässt.

Das bedeutet, dass 3 Byte oder 24 Bit zur Verfügung stehen, um IPv4-Multicast-Adressen auf Layer 3 MAC-Multicast-Adressen auf Layer 2 zuzuordnen. Alle IPv4-Adressen, einschließlich Multicast-Adressen, sind jedoch 32 Bit lang, sodass 8 IP-Adressbits übrig bleiben. Welche Methode zum Zuordnen von IPv4-Multicast-Adressen zu MAC-Multicast-Adressen minimiert die Wahrscheinlichkeit von "Kollisionen" (d. h. zwei verschiedene IP-Multicast-Gruppen auf der Paketschicht, die derselben MAC-Multicast-Adresse auf der Frame-Ebene zugeordnet werden)?

Zunächst ist es wichtig zu erkennen, dass alle IPv4-Multicast-Adressen mit den gleichen 4 Bit (1110) beginnen, so dass es wirklich nur 4 Bits gibt, die von Belang sind, nicht 8. Ein LAN darf nicht die letzten Bits der IPv4-Adresse verwerfen, da es sich dabei je nach Subnetzmaske fast garantiert um Host-Bits handelt. Aber die Bits höherer Ordnung, die Adressbits ganz links, sind fast immer Netzwerkbits, und es gibt (vorerst) nur ein LAN.

Ein weiteres Bit der verbleibenden 24 MAC-Adressen-Bits ist reserviert (eine anfängliche 0 gibt eine Internet-Multicast-Adresse an), sodass die 5 Bits, die auf die anfängliche 1110 in der IPv4-Adresse folgen, gelöscht werden. Die 23 verbleibenden Bits werden nacheinander den letzten 23 Bits der MAC-Adresse zugeordnet. Ein Beispiel für diesen Prozess ist in Abbildung 2 dargestellt.

Abbildung 2: Konvertieren von MAC-Adressen in Multicast-Adressen

Beachten Sie, dass dieser Prozess bedeutet, dass es 32 (2,⁵) IPv4-Multicastadressen gibt, die denselben MAC-Multicastadressen zugeordnet werden können. Beispielsweise werden die Multicast-IPv4-Adressen 224.8.7.6 und 229.136.7.6 in dasselbe MAC-Adresse übersetzt (0x01-00-5E-08-07-06). Dies ist ein echtes Problem, und da der Host an Frames interessiert sein könnte, die an beide Multicast-Gruppen gesendet werden, muss die IP-Software die eine oder die andere ablehnen.

Sobald die MAC-Adresse für die Multicast-Gruppe ermittelt wurde, befiehlt das Betriebssystem des Hosts der LAN-Schnittstellenkarte im Wesentlichen, der Multicast-Gruppe beizutreten oder sie zu verlassen. Nach dem Beitritt zu einer Multicast-Gruppe akzeptiert der Host Frames, die an die Multicast-Adresse gesendet werden, sowie die Unicast-Adresse des Hosts und ignoriert die Frames anderer Multicast-Gruppen. Es ist natürlich möglich, dass ein Host Multicast-Inhalte von mehr als einer Gruppe gleichzeitig empfängt.

Multicastschnittstellenlisten

Um Multicast-Routingschleifen zu vermeiden, muss jedes Multicast-Routinggerät immer die Schnittstelle kennen, die auf dem kürzesten Weg zur Quelle des Multicastgruppeninhalts führt. Hierbei handelt es sich um die Upstream-Schnittstelle (eingehend), und Pakete dürfen niemals an eine Multicastquelle zurückgeleitet werden. Alle anderen Schnittstellen sind potentielle Downstream-Schnittstellen (ausgehende Schnittstellen), abhängig von der Anzahl der Zweige im Verteilungsbaum.

Routing-Geräte überwachen den Status der eingehenden und ausgehenden Schnittstellen genau. Dieser Prozess bestimmt den Status der Multicast-Weiterleitung. Ein Routinggerät mit einem Multicastweiterleitungsstatus für eine bestimmte Multicastgruppe ist im Wesentlichen für den Inhalt dieser Gruppe "eingeschaltet". Schnittstellen in der Ausgangsschnittstellenliste des Routing-Geräts senden Kopien der Pakete der Gruppe, die in der Eingangsschnittstellenliste für diese Gruppe empfangen wurden. Die Listen der eingehenden und ausgehenden Schnittstellen können für verschiedene Multicastgruppen unterschiedlich sein.

Der Multicast-Weiterleitungsstatus in einem Routing-Gerät wird in der Regel entweder in (S,G)- oder (*,G)-Notation geschrieben. Diese werden "ess comma gee" bzw. "star comma gee" ausgesprochen. In (S,G) bezieht sich das S auf die Unicast-IP-Adresse der Quelle für den Multicast-Datenverkehr, und das G bezieht sich auf die bestimmte Multicast-Gruppen-IP-Adresse, für die S die Quelle ist. Alle Multicastpakete, die von dieser Quelle gesendet werden, haben S als Quelladresse und G als Zieladresse.

Das Sternchen (*) in der Notation (*,G) ist ein Platzhalter, der angibt, dass der Status für jede Multicastanwendungsquelle gilt, die an Gruppe G sendet. Wenn also zwei Quellen genau den gleichen Inhalt für die Multicastgruppe 224.1.1.2 liefern, könnte ein Routing-Gerät (*,224.1.1.2) verwenden, um den Status eines Routing-Geräts darzustellen, das Datenverkehr von beiden Quellen an die Gruppe weiterleitet.

Multicast-Routing-Protokolle

Multicast-Routing-Protokolle ermöglichen es einer Sammlung von Multicast-Routing-Geräten, Verteilungsstrukturen zu erstellen (zu verknüpfen), wenn ein Host in einem direkt angeschlossenen Subnetz, in der Regel einem LAN, Datenverkehr von einer bestimmten Multicast-Gruppe empfangen, Verzweigungen beschneiden, Quellen und Gruppen lokalisieren und Routing-Schleifen verhindern möchte.

Es gibt mehrere Multicast-Routing-Protokolle:

• Distance Vector Multicast Routing Protocol (DVMRP): Das erste der Multicast-Routing-Protokolle wird durch eine Reihe von Einschränkungen behindert, die diese Methode für die groß angelegte Internetnutzung unattraktiv machen. DVMRP ist ein Nur-Dense-Mode-Protokoll, das die Flood-and-Prune- oder implizite Join-Methode verwendet, um Datenverkehr überall hin zu übertragen und dann zu bestimmen, wo sich die uninteressierten Empfänger befinden. DVMRP verwendet quellenbasierte Verteilungsbäume in der Form (S,G) und erstellt eigene Multicast-Routing-Tabellen für RPF-Prüfungen.

• Multicast OSPF (MOSPF): Erweitert OSPF für die Verwendung in Multicast, jedoch nur für den Dense Mode. MOSPF verfügt jedoch über eine explizite Join-Nachricht, sodass Routing-Geräte nicht ihre gesamte Domäne mit Multicast-Datenverkehr aus allen Quellen überfluten müssen. MOSPF verwendet quellenbasierte Verteilungsbäume in der Form (S,G).

• Bidirektionaler PIM-Modus: Eine Variante von PIM. Bidirektionales PIM erstellt bidirektionale freigegebene Strukturen, die an einer Rendezvouspunktadresse (RP) verwurzelt sind. Bidirektionaler Datenverkehr wechselt nicht wie in PIM-SM zu den kürzesten Pfadbäumen und ist daher für die Größe des Routing-Zustands statt für die Pfadlänge optimiert. Dies bedeutet, dass die End-to-End-Latenz im Vergleich zum PIM-Sparse-Modus länger sein kann. Bidirektionale PIM-Routen sind immer Platzhalter-Quellrouten (*,G). Das Protokoll macht (S,G)-Routen und datengesteuerte Ereignisse überflüssig. Die bidirektionalen (*,G) Gruppenbäume transportieren Datenverkehr sowohl stromaufwärts von den Sendern zum RP als auch stromabwärts vom RP zu den Empfängern. Folglich gelten die strikten RPF-basierten Regeln (Reverse Path Forwarding), die in anderen PIM-Modi zu finden sind, nicht für bidirektionales PIM. Stattdessen leitet bidirektionales PIM (*,G) den Datenverkehr von allen Quellen und der RP weiter. Bidirektionale PIM-Routing-Geräte müssen in der Lage sein, Datenverkehr auf vielen potenziell eingehenden Schnittstellen zu akzeptieren. Bidirektionales PIM lässt sich gut skalieren, da es keinen quellenspezifischen Zustand (S,G) benötigt. Bidirektionales PIM wird in Bereitstellungen mit vielen verteilten Quellen und vielen verteilten Empfängern empfohlen.

• PIM-Dense Mode: In diesem PIM-Modus wird davon ausgegangen, dass in fast allen möglichen Subnetzen mindestens ein Empfänger den Multicastdatenverkehr von einer Quelle empfangen möchte, sodass das Netzwerk auf allen möglichen Zweigen mit Datenverkehr überflutet und dann zurückgeschnitten wird, wenn Zweigstellen kein Interesse am Empfang der Pakete bekunden, explizit (per Nachricht) oder implizit (Timeoutstille). Dies ist der Dense Mode des Multicastbetriebs. LANs sind geeignete Netzwerke für den Betrieb im Dense-Mode-Modus. Einige Multicast-Routing-Protokolle, insbesondere ältere, unterstützen nur den Dense-Mode-Betrieb, weshalb sie für die Verwendung im Internet ungeeignet sind. Im Gegensatz zu DVMRP und MOSPF ermöglicht der PIM-Dense Mode einem Routing-Gerät, ein beliebiges Unicast-Routing-Protokoll zu verwenden, und führt RPF-Prüfungen mithilfe der Unicast-Routing-Tabelle durch. Der PIM-Dense Mode verfügt über eine implizite Join-Nachricht, sodass Routing-Geräte die Flood-and-Prune-Methode verwenden, um Datenverkehr überall zuzuleiten und dann zu bestimmen, wo sich die uninteressierten Empfänger befinden. PIM Dense Mode verwendet quellenbasierte Verteilungsbäume in der Form (S,G), wie alle Dense-Mode-Protokolle. PIM unterstützt auch den Sparse-Dense Mode mit gemischten Sparse- und Dense-Gruppen, aber es gibt keine spezielle Notation für diesen Betriebsmodus. Wenn der Sparse-Dense Mode unterstützt wird, lässt das Multicast-Routingprotokoll zu, dass einige Multicastgruppen sparsam und andere Gruppen dicht sind.

• PIM-Sparse-Modus: In diesem PIM-Modus wird davon ausgegangen, dass nur sehr wenige der möglichen Empfänger Pakete von jeder Quelle wünschen. Daher richtet das Netzwerk Pakete nur in Zweigstellen ein und sendet sie, die mindestens ein Leaf haben, das (per Nachricht) ein Interesse am Datenverkehr anzeigt. Dieses Multicastprotokoll ermöglicht es einem Routinggerät, ein beliebiges Unicast-Routingprotokoll zu verwenden und mithilfe der Unicast-Routing-Tabelle RPF-Überprüfungen (Reverse Path Forwarding) durchzuführen. Der PIM-Sparse-Modus verfügt über eine explizite Join-Nachricht, sodass Routing-Geräte ermitteln, wo sich die interessierten Empfänger befinden, und Join-Nachrichten stromaufwärts an ihre Nachbarn senden, wobei sie Strukturen von den Empfängern zum Rendezvous Point (RP) aufbauen. Der PIM-Sparse-Modus verwendet ein RP-Routinggerät als anfängliche Quelle für Multicast-Gruppendatenverkehr und erstellt daher Verteilungsbäume in der Form (*,G), wie dies bei allen Protokollen im Sparse-Mode der Fall ist. Der PIM-Sparse-Modus migriert zu einer (S,G) quellenbasierten Struktur, wenn dieser Pfad kürzer ist als der durch die RP für den Datenverkehr einer bestimmten Multicastgruppe. WANs sind geeignete Netzwerke für den Betrieb im Sparse-Mode-Modus, und in der Tat lautet eine gängige Multicast-Richtlinie, unter keinen Umständen den Dense Mode in einem WAN auszuführen.

• Core Based Trees (CBT): Teilt alle Merkmale des PIM-Sparse-Modus (Sparse-Modus, explizite Verknüpfung und Shared-Trees-Strukturen), soll aber bei der Suche nach Quellen effizienter sein als der PIM-Sparse-Modus. KVT ist außerhalb akademischer Diskussionen selten anzutreffen. Es gibt keine groß angelegten CBT-Einsätze, weder kommerziell noch anderweitig.

• PIM-Source-Specific Multicast (SSM): Verbesserung des PIM-Sparse-Modus, der es einem Client ermöglicht, Multicast-Datenverkehr direkt von der Quelle zu empfangen, ohne die Hilfe eines RP. Wird mit IGMPv3 verwendet, um einen Baum des kürzesten Pfads zwischen Empfänger und Quelle zu erstellen.

• IGMPv1: Das ursprüngliche Protokoll, das in RFC 1112, Hosterweiterungen für IP-Multicasting, definiert wurde. IGMPv1 sendet eine explizite Beitrittsnachricht an das Routing-Gerät, verwendet jedoch eine Zeitüberschreitung, um zu bestimmen, wann Hosts eine Gruppe verlassen. Zwischen Empfänger-Hosts und Routing-Geräten werden drei Versionen des Internet Group Management Protocol (IGMP) ausgeführt.

• IGMPv2: Definiert in RFC 2236, Internet Group Management Protocol, Version 2. IGMPv2 fügt der Beitrittsnachricht unter anderem eine explizite Abschiedsnachricht hinzu.

• IGMPv3: Definiert in RFC 3376, Internet Group Management Protocol, Version 3. IGMPv3 optimiert unter anderem die Unterstützung für eine einzelne Inhaltsquelle für eine Multicast-Gruppe oder Source-Specific Multicast (SSM). Wird mit PIM SSM verwendet, um einen Baum des kürzesten Pfads zwischen Empfänger und Quelle zu erstellen.

• Bootstrap-Router (BSR) und Auto-Rendezvous-Punkt (RP): Routing-Protokolle im Sparse-Mode ermöglichen das Auffinden von RPs innerhalb der Routing-Domäne (autonomes System oder AS). RP-Adressen können auch statisch konfiguriert werden.

• Multicast Source Discovery Protocol (MSDP): Ermöglicht Gruppen, die sich in einer Multicast-Routing-Domain befinden, RPs in anderen Routing-Domains zu finden. MSDP wird auf einer RP nicht verwendet, wenn sich alle Empfänger und Quellen in derselben Routingdomäne befinden. Läuft in der Regel auf demselben Routinggerät wie PIM-RP im Sparse-Modus. Nicht geeignet, wenn sich alle Empfänger und Quellen in derselben Routing-Domäne befinden.

• Session Announcement Protocol (SAP) und Session Description Protocol (SDP): Zeigen Sie Multicast-Sitzungsnamen an und korrelieren Sie die Namen mit Multicast-Datenverkehr. SDP ist ein Sitzungsverzeichnisprotokoll, das Multimedia-Konferenzsitzungen ankündigt und Setup-Informationen an Teilnehmer weitergibt, die an der Sitzung teilnehmen möchten. Ein Client verwendet SDP häufig, um eine Konferenzsitzung anzukündigen, indem er in regelmäßigen Abständen ein Ankündigungspaket mithilfe von SAP an eine bekannte Multicast-Adresse und einen bekannten Port transcastet.

• Pragmatisches allgemeines Multicast (PGM): Spezielle Protokollschicht für Multicast-Datenverkehr, die zwischen der IP-Schicht und der Multicast-Anwendung verwendet werden kann, um die Zuverlässigkeit des Multicast-Datenverkehrs zu erhöhen. PGM ermöglicht es einem Empfänger, in allen Fällen fehlende Informationen zu erkennen und Ersatzinformationen anzufordern, wenn die Empfängeranwendung dies erfordert.

Die Unterschiede zwischen den Multicast-Routing-Protokollen sind in Tabelle 1 zusammengefasst.

Es ist wichtig zu wissen, dass erneute Übertragungen aufgrund einer hohen Bitfehlerrate auf einer Verbindung oder einem überlasteten Routing-Gerät Multicast ebenso ineffizient machen können wie wiederholtes Unicast. Daher gibt es in vielen Multicast-Anwendungen einen Kompromiss hinsichtlich der Sitzungsunterstützung durch TCP (Transmission Control Protocol) (TCP sendet jedoch immer fehlende Segmente erneut) oder der einfachen Drop-and-Continue-Strategie des UDP-Datagrammdiensts (User Datagram Protocol) (die Neuordnung kann jedoch zu einem Problem werden). Modernes Multicast verwendet fast ausschließlich UDP.

Multicast-Leistung für Router der T-Serie

Die Core-Router der T-Serie von Juniper Networks bewältigen extreme Anforderungen an die Multicast-Paketreplikation bei minimaler Routerlast. Jede Speicherkomponente repliziert ein Multicast-Paket höchstens zweimal. Selbst im schlimmsten Szenario mit maximalem Fan-Out, wenn 1 Eingangsport und 63 Ausgangsports eine Kopie des Pakets benötigen, kopiert die Routing-Plattform der T-Serie ein Multicast-Paket nur sechsmal. Die meisten Multicast-Distributionsbäume sind viel spärlicher, sodass in vielen Fällen nur zwei oder drei Replikationen erforderlich sind. In keinem Fall hat die Architektur der T-Serie Auswirkungen auf die Multicastleistung, selbst bei den größten Multicast-Fanout-Anforderungen.