IP-Multicast – Wikipedia

Posted on by
before-content-x4

IP-Netzwerktechnik zum Weiterleiten von Übertragungen von einem Sender an mehrere Empfänger

IP-Multicast ist eine Methode zum Senden von IP-Datagrammen (Internet Protocol) an eine Gruppe interessierter Empfänger in einer einzigen Übertragung. Es ist die IP-spezifische Form von Multicast und wird für Streaming-Medien und andere Netzwerkanwendungen verwendet. Es verwendet speziell reservierte Multicast-Adressblöcke in IPv4 und IPv6.

Zu den mit IP-Multicast verbundenen Protokollen gehören das Internet Group Management Protocol, das protokollunabhängige Multicast und die Multicast-VLAN-Registrierung. IGMP-Snooping wird zum Verwalten des IP-Multicast-Verkehrs in Layer-2-Netzwerken verwendet.

IP-Multicast wird in RFC beschrieben 1112. IP-Multicast wurde erstmals 1986 standardisiert.[1] Die Spezifikationen wurden erweitert RFC 4604 Gruppenmanagement einbeziehen und in RFC 5771 Adressen mit administrativem Gültigkeitsbereich einzuschließen.

Technische Beschreibung[edit]

Überblick[edit]

IP-Multicast ist eine Technik für die Eins-zu-Viele- und Viele-zu-Viele-Echtzeitkommunikation über eine IP-Infrastruktur in einem Netzwerk. Es lässt sich auf eine größere Empfängerpopulation skalieren, indem weder Vorkenntnisse über die Identität eines Empfängers noch Vorkenntnisse über die Anzahl der Empfänger erforderlich sind. Multicast nutzt die Netzwerkinfrastruktur effizient, indem die Quelle ein Paket nur einmal senden muss, selbst wenn es an eine große Anzahl von Empfängern gesendet werden muss. Die Knoten im Netzwerk (normalerweise Netzwerk-Switches und -Router) kümmern sich um die Replikation des Pakets, um mehrere Empfänger zu erreichen, sodass Nachrichten nur einmal über jede Verbindung des Netzwerks gesendet werden.

Das am häufigsten verwendete Transportschichtprotokoll für die Verwendung der Multicast-Adressierung ist das User Datagram Protocol (UDP). UDP ist von Natur aus nicht zuverlässig – Nachrichten können verloren gehen oder nicht in der richtigen Reihenfolge zugestellt werden. Zuverlässige Multicast-Protokolle wie Pragmatic General Multicast (PGM) wurden entwickelt, um die Erkennung von Verlusten und die erneute Übertragung zusätzlich zu IP-Multicast hinzuzufügen.

Zu den Schlüsselkonzepten in IP-Multicast gehört eine IP-Multicast-Gruppenadresse.[2] Ein Multicast-Verteilungsbaum und eine empfängergesteuerte Baumerstellung.[3]

Eine IP-Multicast-Gruppenadresse wird von Quellen und Empfängern zum Senden und Empfangen von Multicast-Nachrichten verwendet. Quellen verwenden die Gruppenadresse als IP-Zieladresse in ihren Datenpaketen. Empfänger verwenden diese Gruppenadresse, um das Netzwerk darüber zu informieren, dass sie an den Empfang von an diese Gruppe gesendeten Paketen interessiert sind. Zum Beispiel, wenn ein Inhalt der Gruppe zugeordnet ist 239.1.1.1Die Quelle sendet Datenpakete an 239.1.1.1. Empfänger für diesen Inhalt informieren das Netzwerk, dass sie daran interessiert sind, an die Gruppe gesendete Datenpakete zu empfangen 239.1.1.1. Der Empfänger schließt sich an 239.1.1.1. Das Protokoll, das normalerweise von Empfängern verwendet wird, um einer Gruppe beizutreten, wird als Internet Group Management Protocol (IGMP) bezeichnet.[4]

Bei Routing-Protokollen, die auf gemeinsam genutzten Bäumen basieren, wird ein Multicast-Verteilungsbaum für diese Gruppe erstellt, sobald die Empfänger einer bestimmten IP-Multicast-Gruppe beitreten. Das dafür am häufigsten verwendete Protokoll ist Protocol Independent Multicast (PIM). Es werden Multicast-Verteilungsbäume so eingerichtet, dass Datenpakete von Absendern zu einer Multicast-Gruppe alle Empfänger erreichen, die der Gruppe beigetreten sind. Es gibt verschiedene PIM-Implementierungen: Sparse Mode (SM), Dense Mode (DM), quellenspezifisches Multicast (SSM) und Bidirectional Mode (Bidir oder Sparse-Dense Mode, SDM). Von diesen ist PIM-SM ab 2006 am weitesten verbreitet;;[citation needed] SSM und Bidir sind einfachere und skalierbarere Varianten, die in jüngerer Zeit entwickelt wurden und immer beliebter werden.[citation needed]

Für den IP-Multicast-Betrieb ist keine aktive Quelle erforderlich, um die Empfänger der Gruppe zu kennen. Die Multicast-Baumkonstruktion ist empfängergesteuert und wird von Netzwerkknoten initiiert, die sich in der Nähe der Empfänger befinden. IP-Multicast skaliert auf eine große Empfängerpopulation. Das IP-Multicast-Modell wurde vom Internetarchitekten Dave Clark wie folgt beschrieben: “Sie legen Pakete an einem Ende ab, und das Netzwerk verschwört sich, um sie an jeden zu liefern, der danach fragt.”[5]

IP-Multicast erstellt Statusinformationen pro Multicast-Verteilungsbaum im Netzwerk. Wenn ein Router Teil von 1000 Multicast-Bäumen ist, verfügt er über 1000 Multicast-Routing- und Weiterleitungseinträge. Andererseits muss ein Multicast-Router nicht wissen, wie er alle anderen Multicast-Bäume im Internet erreicht. Es muss nur über Multicast-Bäume Bescheid wissen, für die es nachgeschaltete Empfänger hat. Dies ist der Schlüssel zur Skalierung von Multicast-adressierten Diensten. Im Gegensatz dazu muss ein Unicast-Router wissen, wie er alle anderen Unicast-Adressen im Internet erreicht, auch wenn dies nur über eine Standardroute erfolgt. Aus diesem Grund ist die Aggregation der Schlüssel zur Skalierung des Unicast-Routings. Es gibt auch Core-Router, die Routen zu Hunderttausenden übertragen, da sie die Internet-Routing-Tabelle enthalten.

Routing[edit]

Jeder Host, der ein empfangendes Mitglied einer Multicast-Gruppe sein möchte (dh Daten empfangen möchte, die einer bestimmten Multicast-Adresse entsprechen), muss IGMP zum Beitritt verwenden. Benachbarte Router verwenden dieses Protokoll ebenfalls zur Kommunikation.

Beim Unicast-Routing überprüft jeder Router die Zieladresse eines eingehenden Pakets und sucht das Ziel in einer Tabelle, um zu bestimmen, welche Schnittstelle verwendet werden soll, damit dieses Paket seinem Ziel näher kommt. Die Quelladresse ist für den Router irrelevant. Beim Multicast-Routing wird jedoch die Quelladresse (bei der es sich um eine einfache Unicast-Adresse handelt) verwendet, um die Richtung des Datenstroms zu bestimmen. Die Quelle des Multicast-Verkehrs wird als Upstream betrachtet. Der Router bestimmt, welche Downstream-Schnittstellen Ziele für diese Multicast-Gruppe sind (die Zieladresse), und sendet das Paket über die entsprechenden Schnittstellen aus. Der Begriff Weiterleitung in umgekehrter Richtung wird verwendet, um dieses Konzept des Weiterleitens von Paketen von der Quelle weg zum Ziel zu beschreiben.

Eine Reihe von Fehlern kann auftreten, wenn Pakete, die für Unicast bestimmt sind, versehentlich an eine Multicast-Adresse gesendet werden. Insbesondere das Senden von ICMP-Paketen an eine Multicast-Adresse wurde im Zusammenhang mit DoS-Angriffen verwendet, um eine Paketverstärkung zu erreichen.

Im lokalen Netzwerk wird die Multicast-Übermittlung von IGMP (im IPv4-Netzwerk) und MLD (im IPv6-Netzwerk) gesteuert. Innerhalb einer Routing-Domäne werden PIM oder MOSPF verwendet. Zwischen Routing-Domänen werden domänenübergreifende Multicast-Routing-Protokolle wie MBGP verwendet.

Im Folgenden sind einige gängige Übermittlungs- und Routingprotokolle aufgeführt, die für die Multicast-Verteilung verwendet werden:

Schicht 2 Lieferung[edit]

Unicast-Pakete werden an einen bestimmten Empfänger in einem Ethernet- oder IEEE 802.3-Subnetz gesendet, indem eine bestimmte Schicht-2-MAC-Adresse in der Ethernet-Paketadresse festgelegt wird. Broadcast-Pakete verwenden eine Broadcast-MAC-Adresse (FF: FF: FF: FF: FF: FF: FF).

IPv4-Multicast-Pakete werden über den Ethernet-MAC-Adressbereich 01: 00: 5e: 00: 00: 00–01: 00: 5e: 7f: ff: ff (mit einer OUI der IANA) zugestellt. Dieser Bereich verfügt über 23 Bit verfügbaren Adressraum. Das erste Oktett (01) enthält das Broadcast / Multicast-Bit. Die unteren 23 Bits der 28-Bit-Multicast-IP-Adresse werden auf die 23 Bits des verfügbaren Ethernet-Adressraums abgebildet. Dies bedeutet, dass die Zustellung von Paketen nicht eindeutig ist. Wenn zwei Hosts im selben Subnetz jeweils eine andere Multicast-Gruppe abonnieren, deren Adresse sich nur in den ersten 5 Bits unterscheidet, werden Ethernet-Pakete für beide Multicast-Gruppen an beide Hosts gesendet, sodass die Netzwerksoftware auf den Hosts die nicht erforderlichen Pakete verwerfen muss.[6]

Bei IPv6-Multicast-Adressen wird der Ethernet-MAC von den vier Oktetten niedriger Ordnung abgeleitet, die mit dem MAC 33: 33: 00: 00: 00: 00 ODER verknüpft sind, z. B. die IPv6-Adresse FF02: DEAD: BEEF :: 1: 3 würde der Ethernet-MAC-Adresse 33: 33: 00: 01: 00: 03 zugeordnet.[7]

Wenn ein Switch Multicast-Adressen nicht versteht, wird dieser Datenverkehr an alle Mitglieder eines LAN übertragen. In diesem Fall muss die Netzwerkkarte (oder das Betriebssystem) des Systems die an Multicast-Gruppen gesendeten Pakete filtern, die sie nicht abonniert haben.

Es gibt Switches, die den IGMP-Verkehr abhören und eine Statustabelle verwalten, deren Netzwerksysteme einer bestimmten Multicast-Gruppe zugeordnet sind. Diese Tabelle wird dann verwendet, um Datenverkehr, der für eine bestimmte Gruppe bestimmt ist, nur an eine begrenzte Anzahl von Hosts (Ports) weiterzuleiten. Dieser Vorgang des Abhörens des IGMP-Verkehrs wird als IGMP-Snooping bezeichnet.

Darüber hinaus können einige Switches mit Layer 3-Funktionen als IGMP-Abfrager fungieren. In Netzwerken, in denen kein Router als Multicast-Router vorhanden ist, kann ein Switch mit aktiviertem IGMP-Snooping-Abfrager verwendet werden, um die erforderlichen IGMP-Nachrichten zu generieren, damit Benutzer den Multicast-Verkehr abonnieren können.

Überlegungen zu Wireless[edit]

Das drahtlose 802.11-Netzwerk verwendet denselben MAC-Adressbereich wie das kabelgebundene Ethernet, um IP-Multicast-Adressen zuzuordnen. Ein drahtloses 802.11-Netzwerk verarbeitet Multicast-Verkehr jedoch unterschiedlich, abhängig von der Konfiguration der DTIM (Delivery Traffic Indication Message) und den Einstellungen für das Beacon-Intervall. Befinden sich keine Stationen innerhalb des Basisdienstes im Energiesparmodus, werden Multicast-Pakete sofort nach ihrem Eintreffen gesendet. Wenn sich eine oder mehrere Stationen im Energiesparmodus befinden, liefern Access Points nur nach jedem DTIM-Intervall Multicast-Verkehr und senden mit einer der unterstützten Raten im festgelegten Grundpreis. In den meisten drahtlosen Zugangspunkten beträgt die Standardkonfiguration für dieses Intervall entweder 102,4 ms[citation needed] (Beacon-Intervall = 100 ms, DTIM = 1) oder 204,8 ms[citation needed] (Beacon-Intervall = 100 ms, DTIM = 2) und die Übertragungsrate beträgt entweder 1 Mbit / s oder 6 Mbit / s[citation needed], abhängig vom Betriebsband und Schutzmodus. Die Einstellungen für DTIM und Beacon-Intervall können angepasst werden, um die Multicast-Leistung in drahtlosen Netzwerken zu verbessern.[8]

Im Gegensatz zu Ethernet wird der meiste Datenverkehr in 802.11 zuverlässig über ACKs und NACKs gesendet, sodass Funkstörungen keinen unerträglich hohen Paketverlust verursachen. Multicast-Pakete werden jedoch einmal gesendet und nicht bestätigt, sodass sie viel höheren Verlustraten unterliegen. Es gibt verschiedene Methoden, um damit umzugehen, z. B. das wiederholte Unicasting von Multicast-Daten an jeden Client oder das Anfordern von ACKs von jedem Client.[9] Einige Methoden erfordern nur Änderungen am Zugriffspunkt und werden von einigen Geräten der Enterprise-Klasse unterstützt, während andere Verbesserungen Änderungen an Clients erfordern würden und daher keine breite Akzeptanz gefunden haben.

Sicheres Multicasting[edit]

IP-Multicast ist eine Internetkommunikationsmethode, bei der ein einzelnes Datenpaket von einem Absender übertragen und auf eine Reihe von Empfängern repliziert werden kann. Die Replikationstechniken hängen etwas von den Medien ab, die zur Übertragung der Daten verwendet werden. Durch die Übertragung von Multicast auf einem inhärenten Broadcast-Medium wie Ethernet oder einer Satellitenverbindung kann das Datenpaket automatisch von allen Empfängern empfangen werden, die direkt an das Medium angeschlossen sind. Im Gegensatz dazu erfordert die Übertragung von Multicast auf Medien, die Punkt-zu-Punkt oder Punkt-zu-Mehrpunkt sind,, dass das Paket für jede Verbindung repliziert wird. Der Replikationsprozess sollte optimal ablaufen, wenn ein Verteilungsbaum innerhalb des Netzwerks erstellt wird. Das Paket kann an jedem der Zweige im Baum repliziert werden. Dies verringert die Anforderung, dass der Absender das Paket für jeden Empfänger einmal replizieren muss.

Die Verwendung von IPSec als Kommunikationsverbindung erfordert einen Punkt-zu-Punkt-Verbindungsaufbau. Normalerweise ist die Sicherheit von Absender zu Empfänger erforderlich, was bedeutet, dass der Absender das Paket auf jeder der sicheren Verbindungen replizieren muss – eine für jeden Empfänger. Wenn die Anzahl der Empfänger zunimmt, muss der Sender skalieren, indem er das Paket auf jeden der Empfänger repliziert. Die Verarbeitungslast des Absenders kann hoch sein, was die Skalierbarkeit des Absenders einschränkt. Für die sichere Übertragung von Multicast war eine neue Methode erforderlich, die als Secure Multicast oder Multicast Security bezeichnet wurde.

Die Internet Engineering Task Force (IETF) hat ein neues Internet Protocol (IP) erstellt, um Multicast-Verkehr sicher über ein Paketnetzwerk zu übertragen. Die Protokolldefinition wurde in der Multicast Security Workgroup entwickelt und führte zu mehreren Request for Comments (RFC), die jetzt als Standards für die Sicherung des IP-Multicast-Verkehrs verwendet werden. Das Protokoll ermöglichte es einem Absender, das Multicast-Paket zu verschlüsseln und im optimalen Verteilungsbaum an das Paketnetzwerk weiterzuleiten. Das Paket kann an den optimalen Stellen im Netzwerk repliziert und an alle Empfänger übermittelt werden. Die Empfänger können das Paket entschlüsseln und in der sicheren Netzwerkumgebung weiterleiten. Der Absender eines Multicast-Pakets kennt die potenziellen Empfänger nicht. Daher ist die Erstellung paarweiser Verschlüsselungsschlüssel (einer für jeden Empfänger) nicht möglich. Der Absender muss Pakete mit einem gemeinsam genutzten Schlüssel verschlüsseln, den alle legitimen Empfänger zum Entschlüsseln der Pakete verwenden. Die Sicherheit des Systems basiert auf der Fähigkeit, die Verteilung der Schlüssel nur an diese legitimen Empfänger zu steuern. Zu diesem Zweck hat die IETF das in RFC-6407 definierte GDOI-Protokoll (Group Domain of Interpretation) erstellt. Das Protokoll ermöglicht es dem Absender und dem Empfänger, einem Schlüsselserver beizutreten, auf dem Richtlinien und Schlüssel verschlüsselt und an die Mitglieder der sicheren Multicast-Gruppe verteilt werden. Der Schlüsselserver kann Absender und Empfänger in einer bestimmten Gruppe authentifizieren und autorisieren, in der der gemeinsam genutzte Schlüssel zum Ver- und Entschlüsseln des Datenverkehrs zwischen Mitgliedern der Gruppe verwendet wird.

Zuverlässiger Multicast[edit]

Multicast ist naturgemäß kein verbindungsorientierter Mechanismus, daher sind Protokolle wie TCP, die die erneute Übertragung fehlender Pakete ermöglichen, nicht geeignet. Für Anwendungen wie das Streamen von Audio und Video ist das gelegentliche Verwerfen von Paketen kein Problem. Für die Verteilung kritischer Daten ist jedoch ein Mechanismus erforderlich, um eine erneute Übertragung anzufordern.

Ein solches von Cisco vorgeschlagenes Schema ist PGM (ursprünglich Pretty Good Multicasting, aber aus markenrechtlichen Gründen in Pragmatic General Multicast geändert).[citation needed] dokumentiert in RFC 3208. In diesem Schema haben Multicast-Pakete Sequenznummern, und wenn ein Paket übersehen wird, kann ein Empfänger anfordern, dass das Paket erneut mit anderen Mitgliedern der Multicast-Gruppe multicastet, wobei die Ersatzdaten ignoriert werden, wenn sie nicht benötigt werden. Eine erweiterte Version, PGM-CC, hat versucht, IP-Multicasting “TCP-freundlicher” zu machen, indem die gesamte Gruppe auf die vom schlechtesten Empfänger verfügbare Bandbreite reduziert wurde.

Zwei weitere von der Internet Engineering Task Force (IETF) dokumentierte Schemata sind: das Standard-Track-Protokoll NACK-Oriented Reliable Multicast (NORM), dokumentiert in RFC 5740 und RFC 5401und das Protokoll File Delivery over Unidirectional Transport (FLUTE), dokumentiert in RFC 6726. Für diese gibt es neben proprietären Open-Source-Implementierungen auch Open-Source-Implementierungen. Andere solche Protokolle existieren, wie z. B. Scalable Reliable Multicast, und werden von einer Vielzahl von Quellen definiert. Solche Protokolle unterscheiden sich in den Mitteln zur Fehlererkennung, den bei der Fehlerbehebung verwendeten Mechanismen, der Skalierbarkeit einer solchen Wiederherstellung und den zugrunde liegenden Vorstellungen, was es bedeutet, zuverlässig zu sein. Eine Liste zuverlässiger Multicast-Protokolle aus dem ACM SIGCOMM Multicast Workshop vom 27. August 1996 dokumentiert eine Reihe von Ansätzen für das Problem.

Unabhängige Gruppen wie die Internet Protocol Multicast Standards Initiative (IPMSI) haben behauptet, dass das Fehlen eines wirklich skalierbaren Secure Reliable IP Multicast-Protokolls wie des vorgeschlagenen Secure Multicast für die erweiterte Wiederholung des Fernsehens (SMART) die Einführung von IP Multicast in Domänenübergreifenden behindert hat Routing. Das Fehlen eines weit verbreiteten Systems mit AES-Sicherheit und skalierbarer Zuverlässigkeit hat verhindert, dass Massenmedienübertragungen von Sportereignissen (wie dem Super Bowl) und / oder aktuellen Nachrichtenereignissen im öffentlichen Internet übertragen werden.[citation needed]

Zuverlässige IP-Multicasting-Protokolle wie PGM und SMART sind experimentell. Das einzige Standard-Track-Protokoll ist NORM (die Standard-Track-Revision von RFC 3941 ist angegeben in RFC 5401, die Überarbeitung der Standards von RFC 3940 ist angegeben in RFC 5740).

Multicast-basierte Protokolle[edit]

Da Multicast ein anderer Übertragungsmodus als Unicast ist, können nur Protokolle, die für Multicast entwickelt wurden, sinnvoll mit Multicast verwendet werden. Die meisten vorhandenen Anwendungsprotokolle, die Multicast verwenden, werden über dem User Datagram Protocol (UDP) ausgeführt.

In vielen Anwendungen wird das Echtzeit-Transportprotokoll (RTP) zum Framing von Multimedia-Inhalten über Multicast verwendet. Das Resource Reservation Protocol (RSVP) kann für die Bandbreitenreservierung in einem Netzwerk verwendet werden, das die Multicast-Verteilung unterstützt. Multicast-DNS (mDNS) kann verwendet werden, um Domänen- oder Hostnamen ohne dedizierten DNS-Server mithilfe von Multicast aufzulösen.

Einsatz[edit]

IP-Multicast wird häufig in Unternehmen, an kommerziellen Börsen und in Netzwerken zur Bereitstellung von Multimedia-Inhalten eingesetzt. IP-Multicast wird häufig in Unternehmen für IPTV-Anwendungen wie Live-TV-Vertrieb und im Fernsehen übertragene Unternehmensbesprechungen verwendet.[citation needed]

In der Hotellerie ist IP-Multicast für den IPTV-Vertrieb in Hotels üblich geworden, und im Einzelhandel wird IP-Multicast mittlerweile häufig für den TV-Vertrieb und für Video-Werbeanwendungen verwendet.

Pay-TV-Betreiber und einige Bildungseinrichtungen mit bedeutenden Studentenwohnheimen auf dem Campus haben IP-Multicast eingesetzt, um große Gruppen von Empfängern Einweg-Streaming-Medien wie Hochgeschwindigkeitsvideos bereitzustellen. Darüber hinaus wurden Audio- und Videokonferenzen mit Multicast-Technologien in einigen Fällen eingesetzt. Diese sind weitaus weniger verbreitet und werden am häufigsten an Forschungs- und Bildungseinrichtungen verwiesen, die häufig über eine größere Netzwerkkapazität verfügen, um die Anforderungen zu erfüllen.[citation needed] Einige technische Konferenzen und Besprechungen werden über IP-Multicast übertragen. Bis vor kurzem[when?] Viele der Sitzungen der IETF-Sitzungen wurden mit Multicast durchgeführt.[citation needed]

Eine andere Verwendung von Multicast innerhalb von Campus- und kommerziellen Netzwerken ist die Dateiverteilung, insbesondere um Betriebssystem-Images und -Updates an Remote-Hosts zu liefern. Der Hauptvorteil von Multicast-Boot-Images gegenüber Unicasting-Boot-Images ist die deutlich geringere Nutzung der Netzwerkbandbreite.

IP-Multicast wurde auch im Finanzsektor für Anwendungen wie Börsenticker und Hoot-n-Holler-Systeme eingesetzt.[10]

Während IP-Multicast in jedem dieser Bereiche einige Erfolge erzielt hat, stehen Multicast-Dienste dem durchschnittlichen Endbenutzer im Allgemeinen nicht zur Verfügung.[citation needed] Es gibt zwei wichtige, verwandte Faktoren für diesen Mangel an weit verbreiteter Bereitstellung. Erstens führt die Weiterleitung von Multicast-Verkehr zu einer hohen Protokollkomplexität für Netzwerkdienstanbieter.[citation needed] Zweitens bietet die Kernnetzwerkinfrastruktur eine weitaus größere Angriffsfläche mit besonderer Anfälligkeit für Denial-of-Service-Angriffe.[citation needed]

Aufgrund der hohen Statusanforderungen in Routern können Anwendungen mit einer großen Anzahl von Bäumen bei Verwendung von IP-Multicast nicht arbeiten. Nehmen Sie als Beispiel Anwesenheitsinformationen, bei denen jede Person mindestens einen Baum ihrer Abonnenten behalten muss, wenn nicht mehrere. Es wurde noch kein Mechanismus demonstriert, der es ermöglichen würde, das IP-Multicast-Modell auf Millionen von Absendern und Millionen von Multicast-Gruppen zu skalieren, und daher ist es noch nicht möglich, vollständig allgemeine Multicast-Anwendungen praktisch zu machen.[citation needed] Aus diesen Gründen und auch aus wirtschaftlichen Gründen[citation needed]IP-Multicast wird im Allgemeinen nicht in kommerziellen Internet-Backbones verwendet.

RFC 3170 ((IP-Multicast-Anwendungen: Herausforderungen und Lösungen) bietet einen Überblick über Bereitstellungsprobleme.

Geschichte[edit]

Entwicklung[edit]

IP-Multicasting wurde zuerst von Steve Deering an der Stanford University entwickelt, für die er den IEEE Internet Award erhielt.[11]

Der MBONE war ein langjähriger experimenteller Ansatz, um Multicast zwischen Standorten mithilfe von Tunneln zu ermöglichen. Während der MBONE nicht mehr betriebsbereit ist, besteht erneut Interesse daran, Multicast-Verkehr erneut zu tunneln, um den Dienst einer Vielzahl von Endbenutzern zur Verfügung zu stellen.

CastGate[edit]

CastGate war ein Versuch der ETRO-TELE-Forschungsgruppe an der Vrije Universiteit Brussel, IP-Multicast im Internet einzuführen.[12]

Obwohl Multicast es einem Internetbenutzer ermöglicht hätte, Rich Media und andere Inhalte zu empfangen, ohne das Netz stark zu belasten, war es für die meisten Internetbenutzer immer noch nicht verfügbar. Das CastGate-Projekt hat versucht, dieses Problem zu beheben, indem Endbenutzern ermöglicht wurde, über einen automatisch konfigurierten IP-Tunnel eine Verbindung über Netzwerke herzustellen, die IP-Multicast nicht nativ unterstützen. Die Idee war, dass mehr Inhaltsanbieter den Vorteil des Streaming von Inhalten gegenüber Multicast sehen würden, wenn mehr Benutzer über Multicast-Funktionen verfügen. Die Hoffnung war, wenn mehr Inhaltsanbieter und Benutzer diesen Dienst nutzen würden, würden mehr Internetdienstanbieter ihren Kunden IP-Multicast nativ ermöglichen.[12]

CastGate lieferte einen Software-Client für Microsoft Windows und Linux, um eine Verbindung zum CastGate-Tunnelnetzwerk herzustellen. Außerdem wurden Tools zum Hinzufügen von Tunnelservern und Tools zum Empfangen von Ankündigungen des Session Announcement Protocol vom Multicast-Netzwerk mit Video- und Audiostreams bereitgestellt.[13]

Das Projekt unterhielt bis 2007 eine Website.[13]

Kommerzielle Bereitstellung[edit]

Ab 2005[14] Die BBC begann, in Großbritannien ansässige Internetdienstanbieter zu ermutigen, Multicast-adressierbare Dienste in ihre Netze aufzunehmen, indem sie BBC Radio in höherer Qualität bereitstellten[15] als über ihre Unicast-adressierten Dienste verfügbar ist. Dies wurde auch von einer Vielzahl kommerzieller Radiosender unterstützt, darunter BBC, GCap Media, EMAP und Virgin Radio.[16]

Die deutschen öffentlich-rechtlichen Rundfunkanstalten ARD[17] Das ZDF und das deutsch-französische Netzwerk Arte bieten ihre TV-Sendungen in mehreren Sendern an. Der österreichische Internetdienstanbieter Telekom Austria bietet seinen Kunden von Digital Subscriber Line (DSL) eine TV-Set-Top-Box an, die beim Empfang von TV- und Radiosendungen Multicast-Adressierung verwendet. In Deutschland bietet T-Home, eine Marke der Deutschen Telekom, einen ähnlichen Service an.

IP-Multicast-Software[edit]

  • Media Tools Repository, UK: UCL, archiviert von das Original am 08.01.2007 – eine Sammlung von Tools für das MBone.
  • VideoLAN – eine kostenlose Software-Multicast-Video-Streaming-Anwendung.
  • Xorp – ein freier Software-Router mit Multicast-Unterstützung (IGMP, PIM).
  • Smcroute – Ein einfaches Tool zum Bearbeiten von Multicast-Routen auf dem Linux-Kernel.
  • SSM-Ping, NEIN: Venås, archiviert von das Original am 26.11.2007 – Tool zum Testen der Multicast-Konnektivität.
  • Wilbert, IGMP v3, Kloosterhof, archiviert von das Original am 26.08.2007 – Host-Implementierung von IGMPv3 unter FreeBSD.
  • IP Multi (Software), Palo Alto: Xerox[permanent dead link]
  • Java Zuverlässiger Multicast-Dienst, archiviert von das Original am 30.01.2013abgerufen 08.09.2012 – Bibliotheken und Dienste zum Erstellen von Multicast-fähigen Anwendungen
  • PIM-Implementierung, USC, archiviert von das Original am 24.12.2007 – eine Implementierung des PIM-Protokolls, die inzwischen veraltet ist
  • qpimd – PIM Daemon für Quagga, GNU – PIM-Modul für die Quagga Routing Suite.
  • GateD, Nächster Hop, archiviert von das Original am 09.09.2007 – Unix-Implementierung von Routing-Protokollen, einschließlich Multicast.
  • PIM-DM-Code für GateD, University of Oregon, archiviert von das Original am 15.10.2007.
  • NORM, NRL – Nack-Oriented Reliable Multicast vom US Naval Research Laboratory mit einer Open Source C ++ – Implementierung.
  • ecmh (Easy Cast du Multi Hub), Unfix – IPv6 Multicast Daemon ermöglicht die Verwendung von IPv6 Multicast ohne PIM.
  • MRD6 – IPv6-Multicast-Routing-Daemon
  • UFTP – verschlüsseltes UDP-basiertes FTP mit Multicast
  • GStreamer – ein kostenloses Software-Multimedia-Framework, das Multicast-Video-Streaming unterstützt
  • Mcproxy (Multicast-Proxy) – ein IGMP / MLD-Proxy, der PMIPv6-Multicast-Erweiterungen unterstützt

Siehe auch[edit]

Verweise[edit]

  1. ^ RFC 988
  2. ^ RFC 5771
  3. ^ RFC 1112
  4. ^ “Was ist meine IP, Ihre Adresse IPv4 IPv6 Dezimal auf myip”. Mein Ip ist.
  5. ^ 1968-, Taylor, Ian J. (2009). Von P2P und Grids bis hin zu Diensten im Web: Entwicklung verteilter Communities. Harrison, Andrew B., Taylor, Ian J., 1968- (2. Aufl.). London: Springer. ISBN 9781848001220. OCLC 314174970.CS1-Wartung: numerische Namen: Autorenliste (Link)
  6. ^ RFC 1112 Abschnitt 6.4
  7. ^ RFC 2464
  8. ^ “802.11 Multicasting”. Drahtlose Netze. Abgerufen 2008-10-08.
  9. ^ “EURASIP Journal für drahtlose Kommunikation und Vernetzung”. EURASIP Journal für drahtlose Kommunikation und Vernetzung.
  10. ^ Speakerbus, ein IP-Hoot-n-Holler-Anbieter.
  11. ^ Internet-Preisträger (PDF), IEEE, archiviert von das Original (PDF) am 16.09.2012abgerufen 2010-08-26.
  12. ^ ein b Marnix Goossen; . Pieter Liefooghe; Arnout Swinnen (30. September 2006). “The CastGateproject:” Aktivieren von Internet-Multicast für die Verteilung von Inhalten“”“” (PDF). Archiviert von das Original (PDF) am 26. Mai 2011. Abgerufen 25. Mai 2013. Präsentation auf der NORDUNET Konferenz
  13. ^ ein b “CastGate: Aktivieren von Internet-Multicast”. Archiviert von das Original am 28. September 2007. Abgerufen 25. Mai 2013.
  14. ^ “Rugby Union”, Nachrichten, Großbritannien: Die BBC.
  15. ^ Multicast-Dienste, Großbritannien: Die BBC.
  16. ^ “Radio”, Multicast, Großbritannien: Die BBC Research & Developmentabgerufen 19. April 2012
  17. ^ IPTV, DE: ARDabgerufen 2015-05-17.

Externe Links[edit]

after-content-x4