docAusarbeitung - Friedrich-Schiller
download 
Plainte Transcription
Ausarbeitung - Friedrich-Schiller
Multicast-Routing Grundlagen und Anwendung Seminararbeit im Seminar Neue Technologien in Internet und WWW Wintersemester 2003/04 Friedrich-Schiller-Universität Jena Wolfgang Schnerring <[email protected]> Oktober 2003 Zusammenfassung Während die klassische Art der Kommunikation im Internet eine 1:1-Beziehung (Unicast: ein Sender, ein Empfänger) darstellt, kommt es für einige Anwendungen (z. B. Videostreaming) auf eine 1:n-Beziehung (Multicast: ein Sender, viele Empfänger) an. In dieser Arbeit werden zunächst die Grundlagen des Unicast-Routings und die dafür eingesetzen Algorithmen betrachtet. Darauf aufbauend wird die für Multicasting benötigte Infrastruktur untersucht: Protokolle zur Verwaltung von Empfängergruppen und vor allem mehrere Multicast-Routingverfahren werden genau vorgestellt. Abschließend kommen Anwendungen, die von Multicast profitieren, sowie konkrete Umsetzungsmöglichkeiten im Internet zur Sprache, eine nicht ganz einfach Aufgabe, da die Unterstützung für Multicast noch nicht so weit verbreitet ist. 2 Inhaltsverzeichnis 1 Einleitung 2 Unicast 2.1 Routingtabellen . . . . . 2.2 Routingalgorithmen . . 2.3 Distanz-Vektor-Routing 2.4 Link-State-Routing . . . 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Multicast 3.1 Gruppenmanagement . . . . . . . . . . . . . . . . . . . . 3.1.1 IGMP . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Multicast-Routing . . . . . . . . . . . . . . . . . . . . . 3.2.1 Routing mit einem gemeinsamen Gruppenbaum . 3.2.2 Routing mit quellenbasierten Bäumen . . . . . . 3.2.3 Multicast-Routing im Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 6 7 7 . . . . . . 8 8 9 11 11 13 15 4 Anwendungen 17 4.1 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Content Delivery Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3 Andere Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5 Zusammenfassung 19 A Glossar 20 B Abkürzungsverzeichnis 21 C Literaturverzeichnis 22 D Index 24 3 1 Einleitung Bei der Kommunikation in einem Netzwerk ist es die Aufgabe der Vermittlungsschicht (network layer, [ISO/OSI]), die Nachrichten zu ihrem Ziel zu leiten. Ein wesentlicher Teil davon ist, einen Weg (Route) vom Sender zum Empfänger zu bestimmen. Klassischerweise handelt es sich dabei um 1:1-Verbindungen (Unicast), beispielsweise um eine Datei von einem Rechner auf einen anderen zu übertragen. Es gibt aber Anwendungen, die eine 1:n-Verbindung benötigen, also die Übertragung von einem Sender an eine Gruppe von Empfängern. Zu diesen Anwendungen zählen das Streaming von Audiound Videodaten, massenhafte Datenübertragung, beispielsweise von Software-Updates vom Hersteller an alle Benutzer, oder auch Multiplayer-Spiele. Diese Anwendungen verwenden Multicasts: Das Versenden einer Nachricht an mehrere Empfänger in einer Operation. Ohne weitere Unterstützung durch die Vermittlungsschicht müsste der Sender seine Nachricht an jeden Empfänger einzeln und gesondert verschicken. Dies bedeutet ein enormes Verkehrsaufkommen und ist eigentlich eine Verschwendung von Bandbreite, weil identische Nachrichten zuhauf durch das Netz fließen. Um das zu vermeiden, wurden Protokolle entwickelt, die es dem Sender ermöglichen, seine Nachricht nur einmal zu versenden, und sie dann mit Hilfe der Vermittlungsschicht an alle Empfänger weiterleiten. In dieser Arbeit sollen die Möglichkeiten zur Unterstützung von Multicasts vorgestellt werden, damit verbundene Fragen und Aufgaben untersucht und die theoretischen Hintergründe geklärt werden. Kapitel 2 gibt dazu zunächst einen Überblick über Routing-Verfahren im Unicast-Betrieb, die grundlegend für alle weiteren Betrachtungen sind. In Kapitel 3.1 wird dargestellt, wie Gruppen von Empfängern organisiert werden können, in Kapitel 3.2 werden dann die Routing-Verfahren für Multicasts untersucht. Schließlich werden in Kapitel 4 Anwendungen vorgestellt, die Multicasts benötigen, wie z. B. Content Delivery Networks (CDN). 2 Unicast Die Adressierung im Internet erfolgt hierarchisch durch Zusammenfassung von Rechnern zu Subnetzen, d. h. die IP-Adresse 1.2.3.4 bezeichnet den Rechner Nummer 4 im Subnetz 1.2.3 (in einem Netzwerk der Klasse C, vgl. dazu [RFC 1166]). Die Aufgabe beim Routing ist, eine Route, also einen Weg zum Ziel einer Nachricht zu ermitteln. Dabei gilt das Prinzip der Quellenunabhängigkeit, das bedeutet, der Weg einer Nachricht hängt einzig und allein davon ab, an wen sie adressiert ist, nicht davon, wer sie geschickt hat oder welchen Weg sie bisher schon zurückgelegt hat [MS04]. Zwischen Sender und Empfänger liegen meist mehrere Vermittlungsstellen, die sogenannten Router. Vereinfacht könnte man sagen, dass jeder Router für ein Subnetz zuständig 4 ist; deshalb reicht es aus, eine Nachricht für 1.2.3.4 an den Router des Netzes 1.2.3 zu schicken, dieser wird dann wissen, wie er sie an ihr Ziel zustellt. Daher ist es zur Ermittlung von Routen nützlich, das Netzwerk als einen Graphen darzustellen, in dem jeder Knoten einen Router repräsentiert, und die Kanten die Verbindungen (Hops) zwischen den Routern darstellen. Ein solcher Graph ist in Abbildung 1 zu sehen. Abbildung 1: Ein Netzwerk (a) und seine Darstellung als Graph (b). 2.1 Routingtabellen Damit ein Router eingehende Nachrichten weiterleiten kann, besitzt er eine Tabelle (die sogenannte Routing-Tabelle) mit Informationen für die Weiterleitung. Die RoutingTabelle enthält für jedes Ziel eine Angabe, wohin die Nachricht weitergeschickt werden soll. Durch die hierarchische Adressierung bedeutet das je einen Eintrag pro Subnetz und je einen Eintrag für die Rechner im lokalen Subnetz des Routers. Da es sich nur um Angaben für die nächste Station der Nachricht handelt, wird die Routing-Tabelle auch als Next-Hop-Tabelle bezeichnet. Für diese Tabelle müssen zwei Eigenschaften gelten: Universalität: Für jedes mögliche Ziel muss ein Hop vorhanden sein. Optimalität: Der enthaltene Hop muss auf dem kürzesten Weg zum Ziel führen. Aus [RFC 1958] ergeben sich außerdem die folgenden Anforderungen an Routing-Algorithmen: Korrektheit: Der berechnete Weg muss zum Ziel führen. Einfachheit: Der Algorithmus soll so einfach wie möglich sein. 5 Robustheit: Routing soll auch auf Ausfälle von Rechnern oder Verbindungsstrecken reagieren können. Stabilität: Routen sollen sich nur ändern, wenn dies durch externe Einwirkungen (z. B. Ausfälle) erforderlich ist. Fairness: Alle Anfragen sollen als gleich wichtig behandelt werden. Die Routing-Tabellen für das Beispiel-Netzwerk finden sich in Tabelle 1. Ziel Knoten 1.2.3 Next Hop 1.2.3 2.134.50 3.15.4 4.1.5 – 3.15.4 3.15.4 3.15.4 Knoten 2.134.50 Ziel Next Hop Knoten 3.15.4 Ziel Next Hop Ziel 1.2.3 2.134.50 3.15.4 4.1.5 1.2.3 2.134.50 3.15.4 4.1.5 1.2.3 2.134.50 3.15.4 4.1.5 3.15.4 – 3.15.4 4.1.5 1.2.3 2.134.50 – 4.1.5 Knoten 4.1.5 Next Hop 3.15.4 3.15.4 – Tabelle 1: Routingtabelle für alle Router aus Abbildung 1. Um doppelte Einträge zu vermeiden, kann ein Eintrag, der besonders häufig vorkommt, zum Standard-Eintrag bestimmt werden (Default-Route). Dieser bekommt die niedrigste Priorität und wird verwendet, wenn kein anderer Eintrag der Tabelle zutrifft. 2.2 Routingalgorithmen Um Routing-Tabellen zu berechnen, gibt es verschiedene Algorithmen. Beim statischen Routing werden die Tabellen einmal berechnet, z. B. bei der Inbetriebnahme des Netzwerks, und danach nicht mehr verändert. Dabei können Veränderungen (beispielsweise der Ausfall eines Routers) natürlich nicht mehr in Betracht gezogen werden. Anders beim dynamischen oder adaptiven Routing, hier werden die Routing-Tabellen regelmäßig oder bei Bedarf aktualisiert. Dadurch können ausgefallene Router automatisch umgangen, und auch andere Probleme ohne Eingriff von außen gelöst werden. Die dynamischen Routingalgorithmen lassen sich in zentrale und dezentrale (verteilte) Algorithmen unterteilen. Bei den zentralen Algorithmen übernimmt eine zentrale Instanz die Berechnung der Routing-Tabellen. Dies ist vor allem dann von Vorteil, wenn an einer Stelle besondere Informationen über das Netzwerk gebündelt vorliegen. Andererseits wird hierbei die Zentrale zu einem kritischen Punkt im Netzwerk, deren Ausfall erhebliche Störungen bis hin zum Totalausfall nach sich ziehen kann. Im Gegensatz dazu ist bei dezentralen Verfahren jeder Router selbst dafür verantwortlich, die Routing-Tabellen zu berechnen, aufgrund seines Kenntnisstandes über das Netzwerk. Im Internet kommen hauptsächlich solche dezentralen Verfahren zum Einsatz, wie das im nächsten Abschnitt vorgestellte Distanz-Vektor-Verfahren und das Link-State-Routing. 6 Ganz unabhängig von diesen Algorithmen gibt es noch die isolierten Routingverfahren, die davon ausgehen, dass ein Knoten keine weiteren Informationen über das ihn umgebende Netzwerk besitzt. Zu diesen zählen das Flooding, bei dem die Nachrichten schlicht über alle Verbindungen des Routers weitergegeben werden, das selektive Flooding, bei dem nur die Verbindungen genutzt werden, die in Richtung Ziel zeigen (falls so eine Klassifikation möglich ist), und das Hot-Potato-Routing, bei dem der Router versucht, die Nachricht so schnell wie möglich wieder loszuwerden, und sie deshalb über die Verbindung mit der aktuell kürzesten Warteschlange weiterschickt – dabei kann es natürlich zu erheblichen Umwegen kommen. 2.3 Distanz-Vektor-Routing Das Distanz-Vektor-Routing, oft nach seinen Erfindern auch als Bellman-Ford- oder Ford-Fulkerson-Algorithmus bezeichnet, ist als Routing Information Protocol (RIP) in [RFC 1058] standardisiert. In diesem Verfahren besitzt jeder Router eine Tabelle ( Vektor“), in der jeder andere ” Router des Netzwerks verzeichnet ist. Jeder Eintrag enthält neben dem Zielrouter und dem nächsten Hop auch die Distanz zum betreffenden Router. Die Distanz kann dabei durch verschiedene Metriken ausgedrückt werden: Anzahl der Hops (bis zum nächsten Nachbarn ein Hop), Übertragungszeit (kann mit pings gemessen werden), aktuelle Warteschlangenlänge oder anderes. Das Prinzip dieses Verfahrens besteht darin, dass jeder Router die Informationen aus seiner Routing-Tabelle regelmäßig an seine direkten Nachbarn schickt. Erhält ein Router Informationen von seinem Nachbarn, überprüft er die Einträge seiner Routing-Tabelle und aktualisiert diese, falls sein Nachbar einen kürzeren Weg zu einem Zielknoten gefunden hat. Denkt man sich einen aus den Routing-Tabellen aller Router erstellten Graphen mit den Routern als Knoten und gewichtet die Kanten entsprechend der Distanz, so erfasst nach einer kurzen Anlaufzeit jeder Router die kürzesten Wege zu allen Zielen, ganz ähnlich wie beim Algorithmus von Dijkstra zur Auffindung des kürzesten Pfades in einem Graphen. 2.4 Link-State-Routing Das Link-State-Routing ist ebenso wie das Distanz-Vektor-Routing ein dezentrales Routing-Verfahren, das darauf basiert, dass die Router untereinander Informationen austauschen. Allerdings werden beim Link-State-Routing nur die Informationen über die direkten Nachbarn verschickt, dafür aber gleich an alle Router des Netzwerks. Mit diesen Informationen kann dann jeder Router (mit Hilfe des Dijkstra-Algorithmus) seine RoutingTabelle berechnen. 7 Das Link-State-Routingverfahren kann auf Änderungen am Netzwerk viel schneller reagieren als das Distanz-Vektor-Routing, da alle Knoten gleichzeitig über eventuelle Änderungen wie den Ausfall eines Routers informiert werden. Link-State-Routing wurde als OSPF-Protokoll (Open Shortest Path First Protocol) im [RFC 2328] standardisiert und findet im Bereich des Routings innerhalb einer Domäne (Intradomain-Routing) Verwendung. Die Bezeichnung Shortest Path First“ ist ” etwas irreführend, denn auch andere Routingverfahren wie das Distanz-Vektor-Routing ermitteln natürlich kürzeste Pfade. 3 Multicast Die Zielsetzung beim Multicast ist die effiziente Nutzung der Netzwerkbandbreite, indem eine Nachricht an mehrere Empfänger gleichzeitig verschickt wird. Dazu müssen auf der Vermittlungsschicht die folgenden Aufgaben gelöst werden: 1. Identifikation der Empfänger und geeignete Adressierung 2. Routing einer Nachricht an mehrere Empfänger Die Grundlagen für die Verwirklichung dieser Ansätze legte Steve Deering in seiner Ende der achtziger Jahre entstandenen Doktorarbeit [Deer91]. Aus dieser entstand der Multicast-Backbone, ein virtuelles Netz von multicastfähigen Routern (siehe Abschnitt 4.1). 3.1 Gruppenmanagement Im Gegensatz zum Unicast, wo die (einzige) Zieladresse in jedem IP-Paket mitgeführt wird, müssen beim Multicast mehrere Empfänger berücksichtigt werden. Es ist nicht sinnvoll, alle Adressen einzeln aufzulisten und mitzuführen, weil das für große Zahlen von Empfängern nicht praktikabel wäre. Zudem kann es für bestimmte Anwendungen wünschenswert sein, dass der Sender die Identität der Empfänger nicht im einzelnen kennt. Daher werden im Internet Multicasts mit Hilfe von Empfängergruppen adressiert, d. h. eine IP-Adresse steht für eine ganze Gruppe von Hosts, und Nachrichten an diese Adresse werden an alle Mitglieder der Gruppe zugestellt. Für Multicast-Gruppen legt [RFC 1166] einen reservierten Adressraum fest, die Adressen der Klasse D (bei diesen sind die ersten vier Bit auf 1110“ gesetzt, also umfasst sie die Adressen 224.0.0.0 bis ” 239.255.255.255). Für die Realisierung dieser Gruppen-Abstraktion müssen einige Fragen gelöst werden: Wie werden Hosts zu einer Gruppe hinzugefügt? Kann jeder einer Gruppe beitreten bzw. an sie senden oder ist dies eingeschränkt, und wenn ja, von wem? Kennen die Mitglieder untereinander ihre Identitäten? 8 3.1.1 IGMP Diese Aufgaben werden vom Internet Group Management Protocol (IGMP Version 2, [RFC 2236]) übernommen. Das IGMP arbeitet zwischen einem Host und einem direkt angeschlossenen Router, d. h. der Router ist der erste Hop außerhalb des lokalen Netzwerks. Das bedeutet, es gibt kein Protokoll, dass zwischen den Mitgliedern einer Gruppe operiert, also auch keine Möglichkeit für Gruppenmitglieder, die Identitäten der anderen Mitglieder in Erfahrung zu bringen. Das IGMP verwendet drei Nachrichtentypen, die in Tabelle 2 zusammengestellt sind. Die hauptsächliche Funktion besteht darin, dass der Router herausfinden kann, für welche Multicast-Gruppen sich in seinem Subnetz Mitglieder befinden. Nachrichtentyp Sender Bedeutung membership query (allgemein) Router membership query (spezifisch) Router membership report Host leave group Host Anfrage, in welchen Multicast-Gruppen angeschlossene Hosts Mitglieder sind. Anfrage, ob die spezifische Multicast-Gruppe angeschlossene Hosts als Mitglieder hat. Der Host möchte einer bestimmten Multicast-Gruppe beitreten oder antwortet auf eine membership query. Der Host möchte die betreffende MulticastGruppe verlassen. Tabelle 2: IGMP-Nachrichtentypen Dazu kann er die angeschlossenen Hosts mit einer membership query entweder nach Mitgliedern einer speziellen Multicast-Gruppe oder schlicht aller Multicast-Gruppen fragen. Die Hosts antworten auf eine membership query mit einem membership report, wobei jeder membership report die Multicast-Adresse einer Gruppe enthält, deren Mitglied der antwortende Host ist. membership report-Nachrichten können von einem Host auch unaufgefordert geschickt werden, um erstmals einer Multicast-Gruppe beizutreten. Sowohl die membership query- als auch die membership report-Nachrichten werden von allen angeschlossenen Hosts empfangen. Da es für den Router nur darum geht, ob überhaupt irgendjemand in seinem Subnetz zu einer Multicast-Gruppe gehört, verwendet IGMP eine Feedback-Unterdrückung, um doppelte membership report-Nachrichten zu verhindern. Dazu wartet jeder Host nach dem Empfang einer membership query eine zufällig festgelegte Zeit zwischen Null und der in der Anfrage gesetzten maximalen Antwortzeit. Wenn er während dieses Wartens eine membership report-Nachricht eines anderen Hosts für die betreffende Multicast-Gruppe beobachtet, verwirft er seine eigene schwebende membership report-Nachricht, weil ja schon alles gesagt ist“. ” 9 Der letzte Nachrichtentyp, leave group, ist optional, da IGMP ein Soft-State-Protokoll ist. Wenn eine membership query nach einer bestimmten Multicast-Gruppe unbeantwortet bleibt, geht der Router davon aus, dass kein angeschlossener Host dieser Gruppe angehört. Mit anderen Worten, der Zustand (State; in diesem Fall die Tatsache, dass Hosts Mitglieder einer bestimmten Multicast-Gruppe sind) wird über ein TimeoutEreignis (in diesem Fall eine periodische membership query des Routers) zurückgesetzt, wenn er nicht explizit erneuert wird (durch eine membership report-Nachricht eines Hosts). Im Gegensatz zu Hard-State-Protokollen erfordern Soft-State-Protokolle keine Mechanismen für die Rückkehr zum Normalbetrieb für den Fall, dass die für die Rücksetzung des Zustandes zuständige Einheit ausgefallen ist. leave group-Nachrichten sind vor allem für Multicast-Gruppen mit starkem Verkehr (um überflüssige Übertragungen so bald als möglich zu beenden) oder mit stark wechselnden Mitgliedern interessant. Das IGMP-Nachrichtenformat ist in Abbildung 2 dargestellt. Es ist dem Format des ICMP [RFC 792] recht ähnlich, und IGMP-Nachrichten erhalten ebenfalls die IPProtokollnummer 2. 1 8 Typ 16 Maximale Antwortzeit 32 Prüfsumme Multicast-Gruppenadresse Abbildung 2: Das IGMP-Nachrichtenformat Die Ende 2002 verabschiedete IGMP-Version 3 [RFC 3376] sieht die Möglichkeit vor, dass Hosts bestimmte Quellen gezielt benennen können, von denen sie Nachrichten empfangen oder nicht empfangen möchten ( source filtering“). Das bedingt ein komplizierteres ” Nachrichtenformat, auf das hier nicht weiter eingegangen wird. Zusammenfassend kann man festhalten: Die Gruppenverwaltung via IGMP ist empfängergesteuert. Damit sind einige Schwierigkeiten verbunden, so gibt es z. B. überhaupt keine Kontrolle darüber, wer einer Gruppe beitreten darf und wer nicht. Auch ist nicht steuerbar, wer etwas an eine Multicast-Gruppe sendet. Es bedarf nicht einmal eines böswilligen Senders, denn da nicht geregelt ist, wie die Adressen für Multicast-Gruppen vergeben werden, könnten versehentlich zwei Sender die gleiche Adresse für ihre Empfängergruppe wählen und sich dadurch gegenseitig stören. Dieses Modell trägt die gleichen minimalistischen Züge, die das Unicast-Modell des Internet so erfolgreich gemacht haben. Es bleibt abzuwarten, ob diese Philosophie sich auch für den Multicast-Betrieb bewährt. 10 3.2 Multicast-Routing Mit Hilfe des IGMP kann ein Router feststellen, welchen Multicast-Verkehr er zur Weiterleitung an seine angeschlossenen Hosts empfangen muss. Nun gilt es die Frage zu beantworten, wie die Router die Nachrichten untereinander weiterleiten sollen, damit jeder Router den benötigten Verkehr empfangen kann. Das Ziel von Multicast-Routing ist, einen Baum von Verbindungen zu ermitteln, der alle Router mit angeschlossenen Hosts enthält, die Mitglieder der Multicast-Gruppe sind. Ein Beispiel für einen solchen Baum findet sich in Abbildung 3 (Die teilnehmenden Hosts und Router sind dunkel markiert). Für diese Aufgabe gibt es die folgenden allgemeinen Ansätze: Gemeinsamer Gruppenbaum Für die gesamte Multicast-Gruppe wird nur ein RoutingBaum gebildet. Quellenbasierte Bäume Für jeden Sender wird ein getrennter Routing-Baum gebildet. Pakete werden also abhängig vom Sender an die Mitglieder der Gruppe weitergeleitet. Abbildung 3: Router mit angeschlossenen Multicast-Teilnehmern. 3.2.1 Routing mit einem gemeinsamen Gruppenbaum Für den Fall, dass alle Nachrichten ungeachtet des Senders über den gleichen Baum weitergeleitet werden, benötigt man schlicht einen Baum, der alle Router enthält, an die 11 Abbildung 4: Ein gemeinsamer Gruppenbaum. Mitglieder der Multicast-Gruppe angeschlossen sind. Ein solcher Baum ist in Abbildung 4 zu sehen. Berücksichtigt man die Verbindungskosten, indem man wie auch beim Unicast-Routing die Kanten des Baumes entsprechend gewichtet, dann sollte der ermittelte Routing-Baum möglichst minimale Gesamtkosten aufweisen. Die Ermittlung eines Baums mit minimalen Kosten wird als Steiner-Baum-Problem bezeichnet und ist bewiesenermaßen NP-vollständig, jedoch gibt es Approximationsalgorithmen, die im Allgemeinen zu guten Ergebnissen führen [KR01]. Allerdings setzt eine solche Ermittlung Kenntnisse über alle Verbindungen des Netzwerks voraus, was im Internet nicht gegeben ist. Außerdem spielen in der Praxis noch andere Kriterien eine Rolle, z. B. die mögliche Wiederverwendung der bereits vorhandenen Unicast-Routingtabellen. Eine alternative Möglichkeit zur Ermittlung eines gemeinsamen Gruppenbaumes geht daher von einem Zentrumsknoten aus, an den sich Router, die an dem Multicast teilnehmen möchten, mittels so genannter Join-Nachrichten anschließen. Diese JoinNachrichten werden durch Unicast-Routing in Richtung Zentrum geleitet, bis sie auf einen Router treffen, der schon zum Baum gehört, oder beim Zentrum ankommen. Die entscheidende Frage dabei ist, wie der Zentrumsknoten ausgewählt wird. Man kann jedoch beweisen, dass Zentren so gewählt werden können, dass der resultierende Baum innerhalb eines konstanten Optimumfaktors liegt [KR01]. Abbildung 5 zeigt die Konstruktion eines solchen zentrumsbasierten Baums. Im Beispiel ist Knoten E als Zentrum gewählt worden. Die Nummerierung der Pfeile gibt die Reihenfolge an, in der die Join-Nachrichten verschickt werden. Knoten F tritt zuerst bei, dadurch wird die einzige EF -Verbindung zum anfänglichen Routing-Baum. Als nächstes tritt Knoten B bei – wir nehmen an, dass der kürzeste Unicast-Pfad von B zu E über D führt. Dadurch ergibt sich aus der Join-Nachricht der Pfad BDE, der auf den bestehenden Routing-Baum aufgepfropft“ wird. Der letzte beitretende Knoten ist A. Unter ” der Annahme, dass der Pfad von A nach E über B führt, resultiert schon die Ankunft 12 der Join-Nachricht bei B in der AB-Verbindung, die auf den Baum aufgepfropft wird, da B dem Baum ja bereits angehört. Abbildung 5: Konstruktion eines zentrumsbasierten Baums. 3.2.2 Routing mit quellenbasierten Bäumen Bei quellenbasierten Routingverfahren wird für jede Quelle in der Multicast-Gruppe ein Routing-Baum konstruiert. Algorithmen, die die kürzesten Unicast-Pfade von einer Quelle zu allen Zielen berechnen, sind bekannt (vgl. Unicast-Routing“, Abschnitt 2). ” Die Vereinigung aller dieser Pfade bildet dann jeweils für eine Quelle den gewünschten Routing-Baum. Diese Bäume sind nicht identisch mit dem gemeinsamen Routing-Baum, weil bei quellenbasierten Bäumen die Kosten von der Quelle zu jedem einzelnen Ziel minimiert werden, während der gemeinsame Baum die Summe aller Verbindungskosten minimiert. Abbildung 6 zeigt zwei quellenbasierte Bäume, der eine geht von A, der andere von B aus. Auch diese Vorgehensweise setzt allerdings voraus, das jeder Knoten Kenntnisse über die Zustände aller Verbindungen im Netzwerk besitzt, ist also ein Link-State-Algorithmus. Ein Algorithmus, der weniger Zustandsinformationen erfordert, ist der RPF-Algorithmus (Reverse-Path-Forwarding). Beim RPF überträgt ein Router eine Multicast-Nachricht von einer bestimmten Quelle über alle seine Ausgangsleitungen (außer der, über die er sie empfangen hat), aber nur dann, wenn die Nachricht auf der Leitung angekommen ist, die auf dem kürzesten Pfad zur Quelle liegt. Ansonsten verwirft er die Nachricht, weil er davon ausgehen kann, dass die Nachricht auf der Leitung ankommen wird oder bereits angekommen ist, die auf dem kürzesten Pfad zur Quelle liegt. Für Reverse-Path-Forwarding muss der Router nur den nächsten Hop auf dem kürzesten Pfad zur Quelle kennen, es ist nicht erforderlich, dass er den gesamten kürzesten Pfad kennt. Ein Beispiel für RPF ist in Abbildung 7 dargestellt. Wir nehmen dabei an, dass die fettgedruckten Linien die kürzesten Pfade zur Quelle (A) darstellen. Anfangs sendet 13 Abbildung 6: Zwei quellenbasierte Routing-Bäume. Abbildung 7: Reverse-Path-Forwarding. A die Multicast-Nachricht des Quell-Hosts an C und B. B leitet die Nachricht weiter an C und D, weil A auf seinem kürzesten Pfad zu A liegt. B verwirft alle Nachrichten des Quell-Hosts, die er von einem anderen Router (z. B. C oder D) empfängt. C empfängt eine Nachricht vom Quell-Host sowohl direkt von A als auch von B. Da B nicht auf dem kürzesten Pfad von C nach A liegt, verwirft C diese Nachricht. Anders die Nachricht, die C von A erhalten hat: diese leitet er an B, E und F weiter. In dem Beispiel wird allerdings auch ein Problem des reinen Reverse-Path-Forwarding deutlich: D leitet Multicast-Nachrichten an G weiter, obwohl keiner der an G angeschlossenen Hosts Mitglied der Multicast-Gruppe ist. Dies ist um so schlimmer, je mehr Router in dieser Richtung an D angeschlossen sind. Die Lösung für das Problem des Empfangs unerwünschter Pakete wird als Pruning (Beschneidung von Ästen) bezeichnet. Ein Router, der Multicast-Nachrichten empfängt, 14 obwohl kein angeschlossener Host zu der betreffenden Multicast-Gruppe gehört, sendet eine Prune-Nachricht an den Upstream-Router. Wenn ein Router von jedem seiner Downstream-Router Prune-Nachrichten empfängt, kann er eine Prune-Nachricht upstream weiterleiten (vgl. Abbildung 8). Abbildung 8: Pruning. Pruning ist vom Konzept her einfach, wirft aber zwei Fragen auf: Zum einen muss ein Router wissen, welches die Downstream- bzw. Upstream-Richtung in Bezug auf den Multicast-Empfang ist. Dies kann durch die Bereitstellung zusätzlicher Informationen gelöst werden. Das zweite Problem ist: Was passiert, wenn ein Router, der sich per Pruning abgekapselt hat, später der Multicast-Gruppe beitreten will? Einerseits könnte man das Pruning mit einem Timeout versehen, so dass es nach einer gewissen Zeit unwirksam wird, oder man führt Grafting (Aufpropfen) ein, so dass der Router das Pruning mittels einer Graft-Nachricht explizit rückgängig machen kann. 3.2.3 Multicast-Routing im Internet Nach der allgemeinen Betrachtung der verschiedenen Multicast-Routingalgorithmen werden im Folgenden konkrete, für das Internet standardisierte Multicast-Routing-Protokolle vorgestellt. DVMRP: Distance Vector Multicast Routing Protocol Das erste im Internet benutzte und vorrangig unterstützte Multicast-Routing-Protokoll ist DVMRP [RFC 1075]. Es implementiert quellenbasierte Bäume mittels ReversePath-Forwarding, Pruning und Grafting. Dabei kommt ein Distanz-Vektor-Algorithmus (siehe Abschnitt 2.3) zum Einsatz, mit dem jeder Router die nächsten Hops auf den kürzesten Pfaden zu jeder Quelle berechnen kann. 15 Außerdem berechnet DVMRP eine Liste der Downstream-Router, um Pruning zu ermöglichen, das bei DVMRP mit einem Timeout von standardmäßig zwei Stunden versehen ist. Per Grafting kann ein Router seinen Ast auch explizit dem Routing-Baum wieder hinzufügen. MOSPF: Multicast Open Shortest Path First Im Rahmen eines Systems, das OSPF (siehe Abschnitt 2.4) zum Unicast-Routing einsetzt, wird MOSPF [RFC 1584] für das Multicast-Routing verwendet. Router können ihre Multicast-Gruppenmitgliedschaft in Link-State-Advertisements einfügen, die im Rahmen des OSPF-Protokolls rundgesendet werden. Somit verfügen alle Router neben den für Unicast benötigten Topologieinformationen über die Mitglieder der verschiedenen Multicast-Gruppen, und können dadurch quellenspezifische Bäume mit dem kürzesten Pfad für jede Multicast-Gruppe berechnen. CBT: Core-Based Trees CBT [RFC 2201, RFC 2189] konstruiert einen gemeinsamen Gruppenbaum mit einem einzigen Zentrum ( Kern“). Dazu sendet ein Router ein join request per Unicast in ” Richtung Kern. Der Kern oder der erste Router, der schon zum Baum gehört und diese Nachricht empfängt, antwortet mit join ack. Nach dem Aufbau des Baumes sendet jeder Router in Minutenintervallen echo request-Nachrichten upstream, die mit einem echo reply beantwortet werden. Erhält ein Router keine Antwort auf ein echo request, versucht er es noch einige Male. Kommt kein echo reply, sendet er eine flush treeNachricht downstream, um den Downstream-Baum aufzulösen. PIM: Protocol Independent Multicast Das PIM-Routing-Protokoll [RFC 2362] berücksichtigt ausdrücklich zwei unterschiedliche Szenarien. Im so genannten Dense-Mode liegen die Multicast-Gruppenmitglieder dicht beieinander, d. h. viele oder die meisten Router im Bereich werden in das MulticastRouting einbezogen. Im Sparse-Mode hingegen ist die Anzahl der am Multicast beteiligten Router im Vergleich zur Gesamtzahl gering, und die Gruppenmitglieder sind großflächig verteilt. Im Dense-Mode geht man von der Annahme aus, dass alle Router mit in den Multicast einbezogen werden und verwendet daher einen Ansatz wie RPF, der MulticastNachrichten an alle Router flutet. Im Sparse-Mode ist die Zahl der teilnehmenden Router wesentlich geringer, daher ist ein Ansatz wie RPF ungünstig, weil er einen Router zwingt, konstant zu arbeiten (Pruning auszuführen), nur um ankommenden Multicast-Verkehr zu vermeiden. Daher gilt dort die umgekehrte Annahme, dass ein Router standardmäßig nicht einbezogen wird, und es wird ein zentrumsbasierter Ansatz gewählt, bei dem Router explizit durch Join-Nachrichten dem Multicast beitreten müssen. Inter-AS-Multicast-Routing Bisher wurde implizit davon ausgegangen, dass alle Router das gleiche Multicast-RoutingProtokoll verwenden. Innerhalb eines autonomen Systems (AS) ist dies normalerweise 16 auch der Fall, sobald aber unterschiedliche Systeme miteinander kommunizieren wollen, können unterschiedliche Protokolle ein Problem darstellen. Als De-facto-Protokoll für das Routing zwischen verschiedenen autonomen Systemen hat sich DVMRP durchgesetzt, obwohl es für die eher wenigen verstreuten Router, die heutzutage am Multicast-Verkehr teilnehmen, weniger gut geeignet ist, da es sich um ein Dense-Mode-Protokoll handelt. Die Entwicklung eines speziellen Inter-AS-MulticastProtokolls befindet sich noch in Arbeit bei der Arbeitsgruppe idmr der IETF [IDMR]. 4 Anwendungen Nach der Darstellung der Grundlagen und Verfahren für das Multicast-Routing wird im Folgenden auf deren praktische Umsetzung eingegangen sowie exemplarisch einige Anwendungsgebiete vorgestellt. 4.1 Umsetzung [RFC 1112] teilt Hosts und Router in drei Gruppen ein: Level 0 Keine Unterstützung für Multicast. Solche Hosts ignorieren Multicast-Nachrichten, die sie empfangen. Level 1 Unterstützung für das Senden von Multicast-Nachrichten. Solche Hosts können keiner Multicast-Gruppe beitreten, also auch keine Multicast-Nachrichten empfangen. Es bedarf nur wenig Programmieraufwand, um einen Level-0-Host zu einem Level-1-Host zu machen. Level 2 Volle Unterstützung für Multicast, also Senden und Empfangen. Dazu müssen solche Hosts wissen, wie man einer Multicast-Gruppe beitritt und sie wieder verlässt, d. h. sie müssen IGMP in ihrem TCP/IP-Stack unterstützen. Das Problem ist, dass der größte Teil der im Internet vorhandenen Router vom Typ Level 0“ ist, und Multicast nur von kleinen Inseln“ unterstützt wird. ” ” Wie kann also Multicast-Routing unter diesen Umständen umgesetzt werden? Um die Isolation eines Multicast-Routers unter lauter Unicast-Routern aufzuheben, bedient man sich des Tunneling, d. h. man bildet ein virtuelles Multicast-Netzwerk wie in Abbildung 9 dargestellt. Dazu wird die Multicast-Nachricht in einer Standard-Unicast-Nachricht verkapselt [RFC 2003] und dann ganz normal via Unicast an den entfernten Multicast-Router verschickt, der dann die Multicast-Nachricht wieder auspacken und entsprechend behandeln kann. Das bekannteste virtuelle Multicast-Netzwerk ist der MBone (Multicast-Backbone) [MBONE]. Der MBone wurde 1992 zum ersten Mal genutzt, um Audio-Streams einer 17 Abbildung 9: Multicast-Tunneling IETF-Konferenz in San Diego an Zuhörer weltweit zu übertragen. Seit April 2000 wurde vom Deutschen Forschungsnetz [DFN] die Multicast-Funktionalität sogar in alle Netzknoten des Wissenschaftsnetzes G-WiN integriert. 4.2 Content Delivery Networks Klassischerweise werden im Internet Inhalte von einem Server aus weltweit auf jede Anfrage hin an den Benutzer geschickt. Dieses Modell ist aber in manchen Situationen nicht mehr praktikabel. Wenn zu viele Benutzer gleichzeitig auf einen Server zugreifen wollen, kann man durch Lastverteilung auf mehrere Rechner Abhilfe schaffen. Wenn es sich allerdings um zeitkritische Anwendungen wie etwa Streaming von Multimediadaten (Video, Spiele, etc.) handelt, benötigt man unter Umständen eine verfeinerte Lösung. Ein CDN (Content Delivery Network) hat die Aufgabe, Inhalte schnell und zuverlässig an den Benutzer auszuliefern. Es besteht aus einer Anzahl von Servern, die sich an möglichst vielen verschiedenen Orten befinden. Die Funktion eines CDN vollzieht sich in zwei Schritten [BRS03]: Content Distribution Der auszuliefernde Inhalt wird vom Ursprungs-Server auf die verstreuten sogenannten Surrogat-Server verteilt. Da es sich hier zum einen um eine Vielzahl von Empfängern und zum anderen (beispielsweise beim Videostreaming) um große Mengen von Daten handelt, kommt hier Multicasting zum Einsatz. Request Routing Wenn ein Benutzer nun den Inhalt abrufen möchte, wird er nicht mehr vom Ursprungs-Server bedient, sondern auf einen geeigneten Surrogat-Server umgeleitet. Als Kriterium wird hier neben der Lastverteilung vor allem bei zeitkritischen Fällen auch die Nähe des Surrogat-Servers zum Benutzer herangezogen. Die 18 Umleitung kann entweder direkt auf DNS-Ebene erfolgen oder vom UrsprungsServer übernommen werden. 4.3 Andere Anwendungen Multicast eignet sich naturgemäß für alle Anwendungen, an denen mehrere Empfänger teilnehmen. Solche Anwendungen sind zum Beispiel: • Audio- und Videostreaming • Häufig aktualisierte Nachrichten-Schlagzeilen oder aktuelle Wettervorhersagen • Monitoring, z. B. Börsenticker, Messwerte, etc. • Massenhafter Datentransfer, z. B. File-sharing und Software-Updates All diesen Beispielen liegt ein gewisses Push-Paradigma zu Grunde: Daten werden von einer Quelle aus ausgestrahlt und können von vielen Empfängern genutzt werden – analog zu Rundfunk und Fernsehen. Es gibt aber auch im interaktiven Bereich Gebiete, die von Multicast profitieren können: • (Audio-/Video-) Konferenzen, gemeinsame Nutzung eines virtuellen Whiteboards“ ” • Kollaboration, gemeinsames Bearbeiten von Dokumenten • Chat-Gruppen • Multiplayer-Spiele 5 Zusammenfassung Multicast bietet eine effektive Übertragungsweise für die Kommunikation mit mehreren Empfängern (möglicherweise einer sehr großen Anzahl). Durch die Adressierung an eine ganze Empfängergruppe wird die Netzwerkbandbreite dabei effizient genutzt. Von den bisher entwickelten Protokollen ungelöste Fragen betreffen vor allem die Zugriffskontrolle, wer einer Gruppe beitreten darf und vor allem, wer an eine Gruppe senden darf. Leider ist die Nutzbarkeit von Multicast-Übertragungen derzeit noch recht eingeschränkt, da die allermeisten Router im Internet nicht multicastfähig sind. Tunnel wie der MBone schaffen zwar in gewissem Rahmen Abhilfe, aber damit Multicast wirkliche Verwendung finden kann, ist zunächst eine wesentliche Ausweitung der Infrastruktur nötig – Ansätze wie die Integration von Multicast-Routing in das Deutsche Forschungsnetz geben hier Anlass zur Hoffnung. 19 A Glossar Baum Ein kreisfreier, verbundener Graph. Downstream Die Richtung weg vom Sender hin zum Empfänger einer Nachricht. Hop Die Verbindung von einem Host zum nächsten. Host Ein Teilnehmer im Netzwerk. Multicast Das Versenden einer Nachricht an viele Empfänger (1:n-Kommunikation). Router Hardware, die Nachrichten innerhalb eines Subnetzes und zwischen Subnetzen weiterleitet. Routing Die Ermittlung des Weges, auf dem eine Nachricht weitergeleitet werden soll. Streaming Eine Übertragungsart von Multimediadaten, bei der der Empfänger die Daten schon während des Sendens betrachten kann und nicht warten muss, bis die Daten vollständig übertragen wurden. Unicast Das Versenden einer Nachricht an einen Empfänger (1:1-Kommunikation). Upstream Die Richtung weg vom Empfänger hin zum Sender einer Nachricht. 20 B Abkürzungsverzeichnis AS CBT CDN DVMRP ICMP IETF IGMP IP ISO MOSPF OSI OSPF PIM RFC RIP RPF TCP/IP Autonomous System Core-Based Trees Content Delivery Network Distance Vector Multicast Routing Protocol Internet Control Message Protocol Internet Engineering Task Force Internet Group Management Protocol Internet Protocol International Organisation for Standardization Multicast Open Shortest Path First Open Systems Interconnection Open Shortest Path First Protocol Independent Multicast Request For Comments Routing Information Protocol Reverse-Path-Forwarding Transport Control Protocol/Internet Protocol 21 Literatur [MS04] Ch. Meinel, H. Sack: WWW – Kommunikation, Internetworking, WebTechnologien, Springer, Berlin, 2004. [KR01] Kurore, Ross: Computernetze, Pearsons, 2004. [BRS03] Badach, Rieger, Schmauch: Web-Technologien – Architekturen, Konzepte, Trends, Hanser, 2003. [Deer91] S. Deering: Multicast routing in a datagram internetwork, PhD thesis, Stanford University, 1991. [ISO/OSI 8648] International Organisation for Standardization: Information processing systems – Open Systems Interconnection – Internal organization of the Network Layer, http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail? CSNUMBER=16011&ICS1=35&ICS2=100&ICS3=30, 1988. [IDMR] B. Fenner, A. Zinin: Inter-Domain Multicast Routing, http://ietf.org/html.charters/idmr-charter.html [MBONE] The RIPE MBone Working Group, http://www.ripe.net/ripe/wg/mbone/home.html. [DFN] Deutsches Forschungsnetz, http://www.dfn.de. [RFC 792] J. Postel: Internet Control Message Protocol, http://www.ietf.org/rfc/rfc792.txt, 1981. [RFC 1058] C. Hedrick: Routing Information Protocol, http://www.ietf.org/rfc/rfc1058.txt, 1988. [RFC 1075] Waitzman, Partridge, Deering: Distance Vector Multicast Routing Protocol, http://www.ietf.org/rfc/rfc1075.txt, 1988. [RFC 1112] S. Deering: Host Extensions for IP Multicasting, http://www.ietf.org/rfc/rfc1112.txt, 1989. [RFC 1166] Kirkpatrick, Stahl, Recker: Internet Numbers, http://www.ietf.org/rfc/rfc1166.txt, 1990. [RFC 1584] J. Moy: Multicast Extensions to OSPF, http://www.ietf.org/rfc/rfc1584.txt, 1994. 22 [RFC 1958] B. Carpenter: Architectural Principles of the Internet, http://www.ietf.org/rfc/rfc1958.txt, 1996. [RFC 2003] C. Perkins: IP Encapsulation within IP, http://www.ietf.org/rfc/rfc2003.txt, 1996. [RFC 2201] A. Ballardie: Core Based Trees (CBT) Multicast Routing Architecture, http://www.ietf.org/rfc/rfc2201.txt, 1997. [RFC 2189] A. Ballardie: Core Based Trees (CBT version 2) Multicast Routing, http://www.ietf.org/rfc/rfc2189.txt, 1997. [RFC 2236] W. Fenner: Internet Group Management Protocol, Version 2, http://www.ietf.org/rfc/rfc2236.txt, 1997. [RFC 3376] Cain, Deering, et al.: Internet Group Management Protocol, Version 3, http://www.ietf.org/rfc/rfc3376.txt, 2002. [RFC 2328] J. Moy: OSPF Version 2, http://www.ietf.org/rfc/rfc2328.txt, 1998. [RFC 2362] Estrin, et al.: Protocol Independent Multicast – Sparse Mode (PIM-SM), http://www.ietf.org/rfc/rfc2362.txt, 1998. 23 Index AS, siehe Autonomes System Autonomes System, 16 Multicast Open Shortest Path First, 16 Multicast-Gruppe, 8 Bellman, 7 network layer, 4 CBT, siehe Core-Based Trees CDN, siehe Content Delivery Network Content Delivery Network, 18 Core-Based Trees, 16 Open Shortest Path First Protocol, 8 OSPF, siehe Open Shortest Path First Protocol PIM, siehe Protocol Independent Multicast Protocol Independent Multicast, 16 Pruning, 14 Push-Paradigma, 19 Default-Route, 6 Dense-Mode, 16 Dijkstra-Algorithmus, 7 Distance Vector Multicast Routing Protocol, 15 Distanz-Vektor-Routing, 7 DVMRP, siehe Distance Vector Multicast Routing Protocol Quellenunabhängigkeit, 4 Reverse-Path-Forwarding, 13 RIP, siehe Routing Information Protocol Route, 4 Router, 4 Routing Information Protocol, 7 Routing-Tabelle, 5 Routingalgorithmen, 6 dezentrale, 6 dynamische, 6 für Multicast, 11 mit gemeinsamem Gruppenbaum, 11 mit quellenbasierten Bäumen, 13 isolierte, 7 statische, 6 zentrale, 6 RPF, siehe Reverse-Path- Forwarding Feedback-Unterdrückung, 9 Flooding, 7 selektives, 7 Ford, 7 Fulkerson, 7 Grafting, 15 Hard-State, 10 Hop, 5 Hot-Potato-Routing, 7 IGMP, siehe Internet Group Management Protocol Inter-AS-Multicast-Routing, 16 Internet Group Management Protocol, 9 Soft-State, 10 Sparse-Mode, 16 Steiner-Baum-Problem, 12 Surrogat-Server, 18 Kern, siehe Zentrumsknoten Link-State-Routing, 7 Tunneling, 17 MBone, 17 MOSPF, siehe Multicast Open Shortest Path First Multicast, 4 Unicast, 4 Zentrumsknoten, 12 24
