Multicast
Kommunikationsformen / Routing-Schemata |
---|
Unicast
|
Broadcast
|
Anycast
|
Multicast
|
Geocast
|
Multicast (englisch) bezeichnet in der Telekommunikation eine Nachrichtenübertragung von einem Punkt zu einer Gruppe und ist daher eine Form der Mehrpunktverbindung. Die Technik kommt gemäß OSI-Modell in der Vermittlungsschicht (Layer 3) zum Einsatz. Ihr Vorteil besteht darin, dass zeitgleich Nachrichten an mehrere Teilnehmer oder an eine geschlossene Teilnehmergruppe übertragen werden können, ohne dass sich die hierfür verwendete Datenübertragungsrate beim Sender mit der Zahl der Empfänger multipliziert. Der Sender benötigt beim Multicasting nur dieselbe Datenübertragungsrate wie für einen einzelnen Empfänger. Handelt es sich um paketorientierte Datenübertragung, findet die Vervielfältigung der Datenpakete an jedem einzelnen Verteiler (Router, Switch oder Hub) auf der Route statt.
Der Unterschied zu Broadcast besteht darin, dass beim Broadcast Inhalte verbreitet werden (hier: ganz überwiegend sog. Content), die – mit geeigneter Empfangsausrüstung – jeder ansehen kann, wohingegen beim Multicast vorher eine Anmeldung beim Sender erforderlich ist.
Eine spezielle Ausprägung von Multicast ist Geocast, bei der nur in einen räumlich abgegrenzten Bereich gesendet wird.
IP-Multicast
Multicast ist die übliche Bezeichnung für IP-Multicast, welches es ermöglicht, in IP-Netzen effizient Pakete an viele Empfänger zur gleichen Zeit zu senden. Das passiert mit einer speziellen Multicast-Adresse. In IPv4 ist hierfür der Adress-Bereich 224.0.0.0 bis 239.255.255.255, in IPv6 jede mit FF00::/8 beginnende Adresse reserviert. Zusätzlich wird zur Koordination bei IPv4 das Protokoll IGMP oder CGMP (nur Cisco-Komponenten) benutzt. In IPv6 übernimmt ICMPv6 die Steuerungsfunktion.
Bei der Übertragung über Ethernet werden die IPv4- oder IPv6-Multicast-Adressen auf bestimmte Pseudo-MAC-Adressen abgebildet, um bereits durch die Netzwerkkarte eine Filterung nach relevantem Datenverkehr zu ermöglichen. Die Abbildung erfolgt dabei nach folgenden Regeln:
- Bei IPv4 werden die untersten 23 Bit der IP-Adresse in die MAC-Adresse 01-00-5e-00-00-00 eingesetzt, wodurch sich Adressen aus dem Bereich von 01-00-5e-00-00-00 bis 01-00-5e-7f-ff-ff ergeben können. Hierbei wird bewusst in Kauf genommen, dass mehrere IPv4-Adressen auf dieselbe MAC-Adresse abgebildet werden (zum Beispiel 224.0.0.1 und 233.128.0.1).
- IPv6-Multicast-Adressen werden auf MAC-Adressen abgebildet, indem die letzten vier Bytes der Adresse in die MAC 33-33-XX-XX-XX-XX eingesetzt werden. Auch hierbei werden verschiedene Multicast-Adressen auf identische MAC-Adressen abgebildet.
Eine gesteigerte Bedeutung erfahren die Multicast-Adressen in IPv6. Eine IPv6-Multicast-Adresse hat ein Präfix von FF00::/8 (1111 1111). Das zweite Byte der Adresse FF00::/16 definiert die Lebenszeit und den Geltungsbereich (scope). Dabei besitzt eine permanente Adresse einen Wert von "0", eine temporäre Adresse einen von "1" (flag). Der Gültigkeitsbereich einer Multicast-Adresse variiert von node, link, site, organization bis zu global und wird mit dem Parametern 1, 2, 5, 8 bzw. E angezeigt.
Beispiel: Präfix FF02::/16 ist eine permanente Multicast-Adresse für einen link
Multicasting macht die Broadcast-Adressen überflüssig. Soll z.B. ein Paket an alle Netzwerkgeräte eines Segmentes gesendet werden, wird eine spezielle Multicast-Adresse mit der Bedeutung „ALL Nodes“ verwendet.
Multicast wird auch im Zusammenhang mit Audio- und Videoübertragungen verwendet. Protokolle wie das RTP nutzen diesen Mechanismus. Weiterhin unterstützen auch Routing-Protokolle wie das Routing Information Protocol (RIP) in der Version 2 oder Open Shortest Path First (OSPF) Multicasting. OSPF nutzt die Adressen 224.0.0.5 oder 224.0.0.6, um Informationen zu verteilen.
Daneben ist Multicast für ein funktionierendes AppleTalk-Netzwerk notwendig. Auch wird es eingesetzt bei Service Location Protocol und Multicast DNS als Teilimplementierung von Zeroconf Multicast. Neben diesen zurzeit in der Apple-Welt bevorzugt eingesetzten Protokollen wird Multicast in Windows-Systemen für SSDP benutzt.
Da Multicast-Pakete von den meisten Routern im Internet nicht verarbeitet werden, werden multicastfähige Teilnetze über Tunnel zum Multicast Backbone (MBone) verbunden.
Im Kontext von Mobile-IP benötigt Multicast spezifische Unterstützung, siehe RFC 5757. Insbesondere im Kontext von Proxy-Mobile-IP hat die IETF einfach einsetzbare und zuverlässige Lösungen für mobilen Multicast entwickelt, siehe RFC 6224.
Sicherheit
IPsec realisiert sichere Kommunikation für Punkt-zu-Punkt-Kommunikation über das Internet Protocol. Für verschlüsseltes Multicast gibt es jedoch ein Problem mit dem Schlüsseltausch, da hier der Empfänger den Authentisierungs- und Verschlüsselungsalgorithmus festlegt. Bei Multicast muss das vom Sender erledigt werden, da er IP-Pakete mit demselben Algorithmus an mehrere Empfänger verschickt. Für die Lösung dieses Problems gibt es mehrere Verfahren.
Zentralisierte Verfahren
- Logical Key Hierarchy
- Oneway-Function Tree
Verteilte Verfahren
- Ingemarsson-Tang-Wong
- Burmester-Desmedt
- Tree-Based Group Diffie-Hellman
Weitere Multicast-Protokolle
Ein kritischer Gesichtspunkt bei der Abwicklung von Multicast-Datenverkehr ist die effiziente Zustellung der Pakete an die einzelnen Stationen auf der Grundlage von Routing-Protokollen. IP Multicast überträgt Daten von der Quelle zu einer Empfängergruppe über eine Baumstruktur. Unterschiedliche IP-Multicast-Routing-Protokolle nutzen dabei verschiedene Verfahren, um diesen Baum zu konstruieren. Ist dieser Verteilungsbaum einmal aufgebaut, fließt der gesamte Datenverkehr über ihn. Vier Multicast-Routing-Protokolle haben sich etabliert:
- Distance Vector Multicast Routing Protocol (DVMRP) gemäß RFC 1075
- Multicast Open Shortest Path First Multicast OSPF (MOSPF) als Erweiterung des Routing-Protokolls nach RFC 1584
- Protocol Independent Multicast (PIM)
- Shortest Path Bridging (SPB)
IP-Multicast-Routing-Protokolle lassen sich in zwei generelle Ansätze teilen:
- den Dense Mode („dicht“), der unterstellt, dass die Empfängerstationen im Netz sehr dicht beieinander liegen und ausreichend Durchsatz ermöglichen, und
- den Sparse Mode („spärlich“), der davon ausgeht, dass die Empfänger sehr weiträumig über das Netzwerk verteilt sind und wie in einer WAN-Umgebung nur über geringe Bandbreite verfügen.
Während DVMRP und MOSPF der ersten Klasse zuzurechnen sind, existieren für PIM Ausprägungen für beide Arten.
Internet Relay Chat bildet Netze, welche einen einfachen TCP-basierten Multicast-Baum realisieren. Das Messaging-Protokoll PSYC verwendet ein ähnliches Prinzip, wobei für jeden Chatraum oder Kommunikationskanal ein eigener optimierter Multicast-Baum erzeugt wird. Für XMPP wird überlegt, wie Multicast nachgerüstet werden kann, was aber durch die bisherige Struktur sehr schwierig ist. Für verteilte Chat-Netze wurde mittlerweile allgemein eingesehen, dass sie nicht mittels IP-Multicast realisiert werden können. Der Einsatz weiterer Multicast-Protokolle ist daher unumgänglich.
Mit Multimedia Broadcast Multicast Service steht seit 2005 für das Mobilfunksystem UMTS ein Verfahren zur Verfügung, das zur Ausstrahlung von Multimediainhalten über Multicast-Kanäle dient.
Spezifikationen[Bearbeiten | Quelltext bearbeiten]
- RFC 1112: Host Extensions for IP Multicasting, incl. Mapping von IPv4-Multicast-Adressen auf MAC-Adressen (englisch)
- RFC 2464: Transmission of IPv6 Packets over Ethernet Networks (englisch)
- RFC 3180: GLOP Addressing in 233/8 (englisch)
- RFC 4291: IP Version 6 Addressing Architecture (englisch)
- RFC 4608: Source-Specific Protocol Independent Multicast in 232/8 (englisch)
- RFC 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey (englisch)
- RFC 6224: Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains
- RFC 7046: A Common API for Transparent Hybrid Multicast
- RFC 7287: Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains.
- RFC 7411: Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers.
© biancahoegel.de
Datum der letzten Änderung: Jena, den: 09.08. 2022