Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol. Das MBone

Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Seminar: Internetprotokolle für die Multimediakommunikation 3 Michael Werner Matrikelnummer: 234700 Betreuung: Tim Seipold Lehrstuhl für Informatik IV, RWTH Aachen

Inhaltsverzeichnis 1. Idee des MBone 3 1.1. Abkürzungen und Begriffserläuterung 3 2. Funktionsweise von Multicast 4 2.1. Multicast im LAN - MAC- und IP-Multicast-Adressen 4 2.2. Multicast in Subnetzen 5 2.2.1. Internet Group Managment Protocol (IGMP) 5 Funktionsweise von IGMPv2 7 2.3. Multicast in einer Domäne 9 2.3.1. Multicastverteilbäume 9 Spanning Tree 9 Source-Based Trees 9 Shared Trees 11 2.3.2. Distance Vektor Multicast Routing Protocol (DVMRP) 11 2.3.3. Protocol Independent Multicast (PIM) 13 Protocol Independent Multicast Dense Mode (PIM-DM) 13 Protocol Independent Multicast Sparse Mode (PIM-SM) 13 2.4. Inter-Domain Multicast 16 2.4.1. Multicast Border Gateway Protocol (MBGP) und Multicast Source Discovery Protocol (MSDP) 16 2.4.2. Border Gateway Multicast Protocol (BGMP) 16 3. 16 3.1. Abrechnungsmodelle für IP-Multicast 18 3.2. Multicast-Anwendungen im MBone 18 4. Zusammenfassung 19 Michael Werner 2/20

1. Idee des MBone Der Begriff MBone steht für Multicast-Backbone und ist ein weltweites, virtuelles IP-Multicast Netzwerk. Virtuell bedeutet, dass das MBone kein eigenes physikalisches Netz ist. Es basiert auf der bereits vorhandenen Infrastruktur für IP-Kommunikation. IP-Multicast stellt im Gegensatz zu Unicast nicht eine Kommunikation zwischen einem Sender und genau einem Empfänger dar, sondern einem Sender ist es möglich gleichzeitig eine Gruppe von Empfängern zu adressieren. Ein Beispiel hierfür ist Internet-Radio. Wird dieses über Unicast implementiert, so muss der Radio-Server für jeden Empfänger einzeln jedes Datenpaket versenden. Das bedeutet bei vielen Empfängern extreme Serverlast und ineffizient belastete Leitungen, da der Inhalt der Pakete identisch ist. Ein effizientere Weg der Adressierung ist Multicast. Die Grundidee ist das Vervielfältigen der Pakete dezentral den Routern zu überlassen. Der Server schickt nur noch ein Paket ab, die Router leiten dieses an alle Netze mit Teilnehmern weiter. Im Gegensatz zu Broadcast, das das gesamte Netz mit Daten flutet und nicht nur bestimmten Hosts adressiert. Ein praktische vorhandene Umsetzung dieser Idee ist das MBone. 1.1. Abkürzungen und Begriffserläuterung IP Internet Protocol. Das Netzwerkprotokoll des Internet IPv4 IP Version 4 MAC Medium Access Control IANA Internet Assigned Numbers Authority. Ehemalige US-Organisation zur Vergabe von IP-Adressen IETF Internet Engineering Task Force, eine Internet Standardisierungsorganisation. TTL Time To Life. Anzahl der Router, die ein IP Paket passieren kann. BGP-4 Border Gateway Protocol Version 4, ein. Inter-Domain Unicast Routingprotokoll zum Austausch von Routinginformationen Link-Schicht IP-Schicht Multicastgruppe Querier Metrik Kernrouter 2. Schicht im OSI-Schichtmodell, in Ethernetnetzen auch MAC- Schicht genannt Entspricht der 3. Schicht im OSI-Schichtmodell Eine Gruppe von Empfängern einer Multicastadresse. Beispielsweise alle Empfänger eines Radiokanals Der Router, der als fragender IGMP-Router in einem Subnetz aktiv ist Güte einer Verbindung am Interface eines Routers Router in einem Shared Tree. Die Adresse ist allen anderen Routern bekannt Michael Werner 3/20

2. Funktionsweise von Multicast Das Ziel der Multicastadressierung ist es die Netzinfrastruktur effizienter zu nutzen und Server zu entlasten. Es gibt Dienste im Internet, die bei einer Implementierung mit einer normalen Unicast Punkt-zu- Punkt Verbindung ineffizient sind wie beispielsweise Internet-Radio. Viele Empfänger sollen zeitgleich die selben Daten erhalten. Das Verschicken der Daten per Unicast bei diesem Dienst würde den Server veranlassen, mehrfach die identischen Daten zu verschicken und die Leitungen stärker als nötig zu belasten. Das IP bietet drei Arten von Adressierungen: 1. Unicast stellt eine Punkt zu Punkt Verbindung dar 2. Broadcast ist an alle Hosts gerichtet 3. Multicast adressiert eine Gruppe von Rechnern und passt zur Struktur der problematischen Dienste wie Internet Radio. Hierzu ein Beispielnetz, an dem auch im folgenden weitere Sachverhalte aufgezeigt werden: Abb. 1: Funktionsweise von Multicast Ein Paket an drei Radioempfänger 2.1. Multicast im LAN - MAC- und IP-Multicast-Adressen Da ein Paket bevor es zur IP-Schicht weitergeleitet wird die Link-Schicht passieren muss, wird hier zunächst geklärt, wie die MAC-Multicast-Adressen zu einer IP-Multicast-Adresse aufgebaut sind. Eine MAC-Adresse setzt sich aus einem Multicast-Bit, einer 23 Bit breiten Herstellerkennung und einer 24 Bit breiten laufenden Nummer zusammen. Bei einer MAC-Multicast-Adresse wird das Multicast-Bit gesetzt und die Herstellerkennung entspricht der Bitfolge, die für IANA/IETF reserviert ist. 23 1 Bit stehen zur Identifikation der Multicastgruppe zur Verfügung. Die MAC-Multicast- Adresse ist direkt abhängig von der IP-Multicast-Adresse und es werden in die 23 Bit die untersten 23 Bit der zugehörigen IP-Multicast-Adresse eingetragen. Damit haben jeweils 2 5 =32 IP-Adressen die gleiche MAC-Adresse. 1 das oberste Bit der 24 Bit laufenden Nummer ist reserviert und immer 0 Michael Werner 4/20

Dazu ein Beispiel: IP -M ulticast-a dresse: 224.1.139.18 11100000 00000001 10001011 00010010 unbenutzt H ertstellerkennung der IETF/IANA 23 Bit 00000001 00000000 01011110 00000001 10001011 00010010 M u lticast-bit R e serv ie rte s Bit E th ern et-m ulticast-adresse Abb. 2: MAC- und IP-Multicast-Adressen - Umsetzung einer IP-Multicast-Adresse auf die entsprechende MAC-Multicast-Adresse Nur wenn ein Paket an eine dem Host zugehörige MAC-Adresse gerichtet ist wird es ausgepackt und an die IP-Schicht weitergeleitet. IP-Multicast-Adressen bestehen im Gegensatz dazu nur aus 32 Bit. Die ersten vier Bits der IP- Multicast-Adressen von IPv4 sind immer 1110. Die nächsten 28 Bit sind die Multicastgruppen-ID. In dezimaler Notation liegen IP-Multicast-Adressen zwischen 224.0.0.0 und 239.255.255.255. 1110 Multicastgruppen-ID(28 Bit) Abb. 3: IP- und MAC-Multicast-Adressen - Aufbau einer IP-Multicast-Adresse 2.2. Multicast in Subnetzen Wie in der Einleitung bereits erwähnt, wird bei der Multicast-Kommunikation nicht für jeden Empfänger ein eigenes Paket vom Server abgeschickt, sondern nur eines, das von den Routern vervielfältigt und auf die Interfaces weitergeleitet wird, an denen sich 2 Teilnehmer befinden. Um festzustellen, ob an den Interfaces eines Routers direkt Multicastempfänger angeschlossen sind, existiert das Internet Group Management Protocol. 2.2.1. Internet Group Managment Protocol (IGMP) IGMP ermöglicht es einem Router Informationen über Multicastempfänger an seinen LANs zu erhalten. Die meisten Betriebssysteme unterstützten derzeit IGMP in der Version 1, viele werden allerdings auf IGMP in der Version 2 (IGMPv2) vorbereitet (siehe [Ct00]), daher die Erläuterungen hier anhand von IGMPv2 (spezifiziert in [R2236]). IGMP Pakete sind ein Bestandteil des IPv4 und direkt oberhalb der IP Schicht angesiedelt. 2 direkt oder hinter weiteren Routern Michael Werner 5/20

Eine IGMPv2 Nachricht besteht generell aus 8 Bytes und ist wie folgt aufgebaut: Type(4 Bit) Max Resp Time (4 Bit) Group Address(32 Bit) Checksum(16 Bit) Abb. 4: IGMP - Aufbau eines IGMPv2 Pakets Es gibt folgende Nachrichtentypen (Type): IGMPv2 Membership-Query Mit dieser Nachricht fragt der Router ab, ob Gruppenmitglieder an einem bestimmten Interface angeschlossen sind. Bleibt in der Nachricht das Group Adress Feld leer, wird jeder Host aufgefordert sämtliche seiner Gruppenzugehörigkeiten zu melden. Ist eine bestimmte Gruppe eingetragen, so melden die Hosts lediglich ihre Mitgliedschaft in dieser Gruppe beim Router. Max Resp Time in Millisekunden ist die Zeit, die maximal bis zu einer Antwort der einzelnen Hosts vergehen darf. IGMPv2 Membership-Report Dies ist die Antwort auf ein vom Router abgeschicktes Query. Damit wird bestätigt, dass ein Host in diesem Subnetz in einer bestimmten Multicastgruppe ist. Außerdem sollte (Wortlaut [R2236]) ein Rechner, der neu in eine Gruppe eintritt, sofort ein Report an alle Router schicken. Jeder Host setzt für jede Gruppe, in der er Mitglied ist, einen zufällig großen Timer zwischen 1 und Max Resp Time Millisekunden. Ist der Timer abgelaufen, ohne dass zuvor einen Report für diese Gruppe von einem anderen Host empfangen wurde, wird der Report verschickt, ansonsten verworfen. So wird gewährleistet, dass jeweils nur ein Report pro Gruppe beim Router ankommt. IGMPv2 Leave-Group Diese Meldung wird von einem Host an alle Router geschickt und beinhaltet die Information, dass gerade dieser Host die Gruppe verlassen hat. Der Router - sofern er Querier ist - überprüft daraufhin mit einem Group-Specific-Query, ob noch weitere Teilnehmer dieser Gruppe vorhanden sind. Die Leave-Group Nachricht sollte (Wortlaut [R2236]) geschickt werden, wenn dieser Host zuletzt den Report an den Router gesendet hat, d.h. während seines Timerlaufs keinen Report für diese Gruppe empfangen hat. IGMPv1 Membership-Report Wird zu Kompatibilitätszwecken mitgeführt. Die Checksum wird aus dem gesamten Paket ermittelt und dient zur Kontrolle, ob ein Paket unbeschadet den Empfänger erreicht hat. Dazu wird der Inhalt des IGMP-Paketes im Einer-Komplement aufaddiert und das Einer-Komplement des Ergebnisses in Checksum eingetragen. ZumVerifizieren wird überprüft, ob XOR über dem Paketinhalt inklusive Checksum 1 ergibt. Die Checksum muss in jedes Paket eingetragen und beim Empfänger überprüft werden, bevor ein Paket verarbeitet wird (Wortlaut [R2236]). Michael Werner 6/20

Funktionsweise von IGMPv2 Das Bild des Internet-Radios ist auch hier sehr hilfreich. Der Router erfragt periodisch mittels eines Membership-General-Query, für welche Multicastgruppe Empfänger an seinen Interfaces vorhanden sind. Er erhält Antwort über Empfänger der einzelnen Sender pro Interface und speichert diese. Erhält er nach einer bestimmten Zeit 3 keine Bestätigung dieses Eintrags, wird er automatisch gelöscht. Die Hosts erwidern auf ein General oder Group-Specific-Query einen Report. Dieser wird nach einem zufälligen Timerlauf zwischen 1 und Max Resp Time Millisekunden verschickt, sofern während dessen kein Report für diese Gruppe empfangen wurde. Hat ein Host zuletzt während seines Timerlaufs keinen Report empfangen und seinerseits einen Report an die Router gesendet, so sollte (Wortlaut [R2236]) er eine Leave-Group Nachricht beim Abschalten des Radiosenders an den Router schicken. Dieser stellt sofort mit einem Group- Specific-Query fest, ob noch weitere Empfänger vorhanden sind und nicht unnötigerweise Datenpakete eines Senders in dieses Subnetz geleitet werden. Hat ein Host einen Report versendet, ist ihm nichts über weitere Empfänger bekannt. Wurde er unterbrochen, so ist mindestens noch ein weiterer Empfänger anwesend und es ist unnötig eine Leave-Group Nachricht zu verschicken. Tritt ein Host neu in eine Gruppe von Empfängern ein, so sollte (Wortlaut [R2236]) er direkt einen Report an alle Router schicken, damit auch sofort Radiodaten in dieses Teilnetz weitergeleitet werden. Würde dieser Report nicht sofort gesendet und dieser Empfänger wäre der erste Empfänger im Subnetz, so stände ein Wartezeit bis zum nächsten General-Query an. Zur Adressierung der IGMP-Pakete gibt es einige festgelegte Multicast-Adressen: 224.0.0.1 alle Systeme wird verwendet für Querys 224.0.0.2 alle Router wird verwendet für Leave-Group Darüber hinaus gibt es noch weitere, die hier keine Verwendung finden. Die Reports werden an die eigene Multicast-Adresse geschickt. Somit ist zusätzlich zu den Routern auch den Hosts im Subnetz möglich den Report zu verarbeiten und ihren Reporttimer zu verwerfen. Hier zwei Beispiele: Abb. 5: IGMP Der Router sendet einen General Query und die Hosts antworten darauf mit einem an ihre Multicastgruppe adressierten Report. Host 1 schickt zuerst einen Report, da sein Timer abgelaufen ist, danach Host 2(Reihenfolge beliebig ausgewählt). Host 4 antwortet nicht, da er die beiden vorherigen Reports erhalten hat. 3 muss nicht nach dem nächsten Query sein, ist separat einstellbar siehe [R2236] Michael Werner 7/20

Abb. 6: IGMP Host 1 verlässt 224.2.18.9 und sendet eine Leave-Group Nachricht an alle Router im LAN. Der Querier antwortet mit einem Group-Specific-Query für diese Gruppe. Darauf sendet Host 4 einen Report. Es gibt keine explizite Adresse für den Query-Router, sondern nur für alle Router. Bei mehreren Routern in einem Subnetz ist generell jeder Router ein Querier. Empfängt ein Router eine Query- Nachricht von einem Router mit einer niedrigeren IP-Adresse, so stellt er das Versenden von Query-Nachrichten für dieses Subnetz ein und nimmt es erst wieder auf, falls er eine bestimmte Zeit kein weiteres Query von einem Router mit niedriger IP-Adresse empfängt. Dieser eben skizzierte Ablauf findet in reinen IGMPv2 Netzen statt. Treten Komponenten gemischt auf, sind folgende Sonderfallbehandlungen zu beachten: Ein IGMPv2 Host ist an ein IGMPv1 Querier angeschlossen. Dabei müssen die General- Queries des Routers deren Max Resp Time 0 ist als 100 interpretiert werden. Es müssen IGMPv1 Reports gesendet werden. Ist ein IGMPv2 Router zusammen mit mindestens einem IGMPv1 Router aktiv, so muss der Querier IGMPv1 Queries verschicken und Leave-Group Nachrichten ignorieren. Andernfalls könnte der IGMPv1 Router kein der Antworten verwerten und würde für dieses Interface alle Multicastdaten verwerfen. Ein IGMPv1 Host ist an einen IGMPv2 Router angeschlossen. Der Router muss IGMPv1 Reports verwerten und alle Leave-Group Nachrichten ignorieren, damit kein Group-Specific- Query verschickt wird, auf den ein IGMPv1 Host nicht reagieren könnte. Wäre dieser Host dann der letzte einer Gruppe, so würde der Router dennoch annehmen, es wäre kein Gruppenmitglied mehr vorhanden. Ein IGMPv2 Host ist in einem Netz mit IGMPv1 Hosts präsent. Hier muss der IGMPv2 Host Report-Timer auch verwerfen, wenn er IGMPv1 Reports empfängt. Zu beachten ist, dass alle IGMP Nachrichten einen IP TTL Wert von 1 haben. Das bedeutet, dass die Pakete am nächsten Router direkt nach der Auswertung verworfen und nicht in andere Netze weitergeleitet werden. Michael Werner 8/20

2.3. Multicast in einer Domäne Mittels IGMP erhält ein Router Informationen darüber, ob direkt an einem seiner Interfaces Teilnehmer bestimmter Multicastgruppen angeschlossen sind. Damit nach diesen Informationen Multicastdaten zum Empfänger gesendet werden können, müssen die Pakete vom Sender zu den Routern mit direkten Teilnehmern gelangen. Eine Möglichkeit ist das gesamte Netz mit Multicastverkehr zu fluten, was jegliche Leitungsentlastung ad absurdum führen würde. Eine Baumstruktur wäre offensichtlich sinnvoller. Mit den Theorien zur Entwicklung solcher Bäume und den in der Praxis eingesetzten Protokollen beschäftigt sich dieser Abschnitt. 2.3.1. Multicastverteilbäume Spanning Tree Die einfachste Möglichkeit eines Verteilbaumes ist der Spanning Tree. Dabei wird ein minimal aufspannender Baum über alle existierenden Router gebildet. Der Kosten einer Kante ist die Metrik der Verbindung, je niedriger desto besser. Zur Weiterleitung des Multicastverkehrs werden Pakete auf alle Interfaces mit Ausnahme des Quellinterfaces gesendet, die zum Spanning Tree gehören. Diese Methode birgt Nachteile, die an dem bereits aus der Einleitung bekanntem modifizierten Beispielnetz ersichtlich sind. Abb. 7: Spanning Tree Die Route zwischen Radiosender und Empfänger an R6 ist nicht optimal. Der direkte Weg vom Radiosender zu R6 wäre günstiger, aber die Leitung gehört nicht zum Spanning Tree. Generell ist beim Spanning Tree das Problem, dass die Pakete alle Router und Subnetze durchlaufen, egal wie viele Empfänger vorhanden sind. Weiterhin konzentriert sich der gesamte Multicastverkehr auf die Leitungen des Baumes. Source-Based Trees Eine weitere Möglichkeit sind senderspezifische Bäume; die sogenannten Source-Based Trees. Pro Sender einer Multicastgruppe wird ein Verteilbaum konstruiert. Um diesen Baum aufzubauen gibt es drei Ansätze: Michael Werner 9/20

1. Reverse Path Forwarding (RPF) Bei diesem Algorithmus speichert der Router beim Empfang eines Pakets dessen Sender und das Interface, auf dem es empfangen wurde. Wenn das Interface zum kürzesten Pfad zum Sender gehört, wird das Paket auf allen Interfaces mit Ausnahme des Quellinterface weitergeleitet, ansonsten verworfen. Um die kürzesten Pfade zu ermitteln, wird auf Unicast-Routingverfahren zurückgegriffen (nähere Informationen zu Unicast-Routing siehe [Hui95]). 2. Truncated Reverse Path Broadcasting (TRPB) Im Unterschied zu RPF werden bei TRPB die Pakete nicht auf alle Interfaces weitergeleitet. Ein Problem bei RPF sind Pakete, die aufgrund des Algorithmus in Subnetze gelangen, in denen nach den IGMP-Informationen der Router keine Teilnehmer existieren. Dort wo dies bekannt ist, wird das Paket verworfen. Trotzdem erhalten alle Router ein Paket, egal ob es dort benötigt wird oder nicht. 3. Reverse Path Multicasting (RPM) Dieses Verfahren ist eine Weiterentwicklung des TRPB. Router, die keine Daten benötigen, können sich explizit vom Verteilungsbaum abmelden. Dieses Abmelden nennt man Pruning. Wenn ein Router ein empfangenes Datenpaket eines Senders nicht benötigt, schickt er eine Prune-Nachricht über das Interface, an dem er das Paket empfangen hat. Ein Router benötigt ein Paket nicht, wenn er für alle Interfaces keine direkten Empfänger besitzt und/oder dort Prune-Nachrichten für diesen Sender erhalten hat. Im Beispielnetz werden folgende Prune-Nachrichten geschickt: Abb. 8: Source-Based Tree mit RPM Da in den LANs an R4 und R7 keine Empfänger für diesen Radiosender präsent sind melden sie sich vom Verteilbaum ab. R3 besitzt ebenfalls keine Empfänger, erhält aber nur von R4 und nicht von R6 eine Prune-Nachricht und meldet sich nicht ab. Periodisch wird auch bei RPM der gesamte Verteilbaum mit Multicastdaten geflutet. Ein Router, der sich mit einer Prune-Nachricht abgemeldet hat, kann sich mittels einer sogenannten Graft-Nachricht unverzüglich wieder anmelden. Dies geschieht, falls sich ein neuer Teilnehmer für diesen Sender per IGMP beim Router meldet oder der Router eine Graft-Nachricht erhält. Michael Werner 10/20

Bei RPF und TRPB verläuft der Baum über alle Router und kann Netzbelastung in Teilen ohne Empfänger erzeugen. RPM schränkt dieses Problem mittels Pruning und Grafting ein. Generell müssen bei Source-Based Trees Informationen pro (Sender, Gruppe)-Paar im Router gespeichert werden und nicht, wie beim Spanning Tree, nur einmal pro Domäne. Shared Trees Shared Trees bilden einen Verteilbaum pro Multicastgruppe. Dieser wird als Spanning Tree über alle Router mit direkten Empfängern erstellt. Ein neuer Teilnehmer hinter einem nicht im Baum integriertem Router meldet sich bei einem Router des bisherigen Verteilbaums an. Diese werden auch Kernrouter genannt. Auf diesem Weg wird der Verteilbaum erweitert. Die Adressen der Kernrouter werden zuvor im gesamten Netz verteilt. Wie diese Verteilung und Anmeldung genau implementiert ist wird direkt bei den Protokollen erklärt, die Shared Trees verwenden. Ein Shared Tree muss nicht alle Router enthalten, sondern nur die benötigten. Es werden nur Informationen pro Gruppe im Router gespeichert, nicht wie bei Source-Based Trees pro (Sender, Gruppe)-Paar. Der Verkehr konzentriert sich allerdings wie beim Spanning Tree auf bestimmte Leitungen und Router. 2.3.2. Distance Vektor Multicast Routing Protocol (DVMRP) Das DVMRP war das erste verfügbare Multicast Routing Protokoll und wird auch heute noch oft im MBone verwendet (siehe [Ct00]). Mittels des für Unix frei verfügbaren Programms mrouted, welches DVMRP verwendet, konnte unkompliziert ein Unix-Rechner als Multicastrouter genutzt werden (siehe [Mbo01] Kapitel 5 - DVMRP). Spezifiziert ist DVMRP in [R1075]. DVMRP verwendet Source-Based Trees mit dem RPM Algorithmus. Die Pakete, die dazu von DVMRP-Routern verschickt werden, sind IGMP-Pakete. An den IGMP-Header werden bis zu 512 Byte Daten für DVMRP angehängt, um beispielsweise eine Prune- oder Graft-Nachricht zu verschicken. Wie andere Unicast-Routingprotokolle versendet DVMRP Pakete, die benachbarte Router über bekannte Routen informieren oder nach Routen fragen (Nähere Informationen zu Unicast- Routing siehe [Hui95]). Der IGMP-Header wird wie folgt gefüllt: Version (4 Bit) Type (4 Bit) Subtype(8 Bit) Checksum(16 Bit) Abb. 9: DVMRP - Aufbau des IGMP-Headers bei einer DVMRP-Nachricht Version ist immer 1, Type ist für DVMRP immer 3. Subtype kann folgende Werte annehmen: 1 (Antwort auf Fragen nach Routinginformationen) 2 (Fragen nach Routinginformationen) 3 (Prune) 4 (Graft) Checksum verhält sich wie unter IGMPv2 beschrieben. Michael Werner 11/20

Um beispielsweise ein Pruning zu senden wird eine Bitfolge bestehend aus dem IGMP-Header und einer Bitfolge für die Prune-Nachricht 4 an den Router geschickt, von dem unnötiger Multicastverkehr empfangen wurde. Bitfolge für Prune-Nachricht: 00001001 count(8 Bit) Abb. 10: DVMRP - Aufbau einer DVMRP Prune-Nachricht 00001001 ist eine für die Prune-Nachricht festgelegt Bitfolge. count ist die Anzahl der Multicastgruppen, für die der Router keine Daten mehr benötigt. Daran angehängt wird eine Liste von Adressen, die aus so vielen Elementen besteht, wie in count aufgeführt ist. Ein Listenelement besteht aus einer 32 Bit Multicast-Address und einer 32 Bit Hold Down Time, die angibt, wie lange der Prune-Nachricht gültig ist. Multicast Address(32 Bit) Hold Down time(32 Bit) Abb. 11: DVMRP - Aufbau eines Listenelements aus der Adressliste einer DVMRP Prune-Nachricht Trotz gleicher Mechanismen zum Ermitteln einer kürzesten Route besteht ein Unterschied in der Verwendung zwischen Unicast RIP und DVMRP. Bei beiden Protokollen werden die Informationen in den Routingtabellen gespeichert und mit den benachbarten Routern ausgetauscht. RIP verwendet jedoch diese Tabelleneinträge zum tatsächlichen Routen von Paketen. DVMRP nutzt sie lediglich zum Überprüfen, ob Pakete auf dem Interface empfangen wurden, das zur kürzesten Route zum Sender gehört. Ist das der Fall, wird es dem RPM Algorithmus entsprechend weitergeleitet. DVMRP bietet die Möglichkeit mittels Tunnel nicht multicastfähige Bereiche zu überbrücken. Einem Interface, hinter dem sich ein Tunnel befindet kann genauso eine Metrik zugeordnet werden, wie einem Interface, das die direkte Verbindung zu einem multicastfähigen Router herstellt. Anhand dieser Metrik wird entschieden welche Route die günstigste ist. Zu Beginn des MBone war diese Eigenschaft besonders wichtig, da es noch kein netzabdeckendes Multicastnetz gab. Der große Vorteil auch der Grund für seine enorme Verbreitung und Kompatibilität war die freie und frühe Verfügbarkeit von mrouted. Allerdings ist DVMRP abhängig von RIP als Unicast- Routingprotokoll zum bestimmen des kürzesten Pfads zum Sender und pflegt eigene Routingtabellen. Es skaliert aufgrund des periodischen Flutens des RPM Algorithmus sehr schlecht. Folglich ist es ungeeignet für größere Netze in denen nur wenige Teilnehmer vorhanden sind. Für diese spärlichen besetzten Regionen bedarf es einer effizienteren Lösung. 4 in [R1075] auch Non-Membership-Report genannt Michael Werner 12/20

2.3.3. Protocol Independent Multicast (PIM) PIM arbeitet unabhängig von einem Unicastprotokolls und einer seiner Modi bietet eine effiziente Unterstützung von spärlich besetzten Regionen. Es gibt zwei Modi von PIM: 1. PIM Dense Mode (PIM-DM) und 2. PIM Sparse Mode (PIM-SM). Spezifiziert ist PIM-DM in [RPIM] und PIM-SM in [R2363]. Protocol Independent Multicast Dense Mode (PIM-DM) PIM-DM arbeitet mit Source-Based Trees, die mittels RPM aufgebaut werden. Der Unterschied zwischen PIM-DM und DVMRP liegt in der Ermittlung des kürzesten Pfades zum Sender eines Source-Based Trees. DVMRP ermittelt mit Unicast-Routingverfahren die Route zum Sender und speichert sie in einer eigenen Routingtabelle. PIM-DM greift auf die bereits vorhandenen Unicast- Routingtabellen zurück und ermittelt daraus, ob ein Paket auf dem Interface ankam, das zur kürzesten Route zum Sender gehört. Es müssen also keine eigenen Routingeinträge gespeichert werden. Lediglich die Prune-Zustände müssen pro (Sender, Gruppe)-Paar gesichert werden. Protocol Independent Multicast Sparse Mode (PIM-SM) Der Grundgedanke bei diesem Modus ist das Fehlen jeglicher Teilnehmer und damit das Ausbleiben des periodischen Fluten des gesamten Netzes. Teilnehmer, die Multicastdaten benötigen oder senden, müssen sich explizit anmelden. Dazu stehen sogenannte Rendezvous Points (RP) in einem PIM-SM Netz zur Verfügung. An diesen allen weiteren Routern im Netz bekannten RPs melden sich Sender wie Empfänger an und bilden einen gruppenspezifischen Shared Tree mit einem zentralen Router dem RP. Erneut ist das Radiobeispiel hilfreich. Ein Radiosender registriert sich mit einer Register-Nachricht per Unicast beim RP als Quelle für einen bestimmten Kanal. Abb. 12: PIM-SM Ein Radiosender registriert sich beim RP Michael Werner 13/20

Empfänger melden per Join-Nachricht ebenfalls an den RP, dass sie den Kanal empfangen möchten. Die Router auf dem Weg zwischen Empfänger und RP bilden aufgrund der Join-Nachricht ihre Routinginformationen für die Weiterleitung der Radiopakete - auf welchem Interface darf Multicastverkehr empfangen werden und auf welche Interfaces wird er weitergeleitet. Abb. 13: PIM-SM Eine Empfänger registriert sich beim RP und ein Shared Tree wird zwischen RP und Empfänger aufgebaut. Bei der Anmeldung des ersten Empfängers sendet der RP eine Join-Nachricht an den Radiosender und erhält die Multicastdaten per Unicast. Der RP leitet die Daten als Multicastpakete über den Shared Tree an die Empfänger weiter und diese können Radio hören. Abb. 14: PIM-SM Sobald der erste Empfänger beim RP angemeldet ist, wird eine Join- Nachricht an den Radiosender gesendet, damit der RP Multciastdaten erhält und über den Shared Tree verteilen kann. Da es pro Gruppe in einer Domäne nur einen RP gibt ist es wahrscheinlich, dass die Route über den RP nicht wirklich optimal ist. Es ist möglich einen Source-Based Tree direkt zwischen Empfänger und Radiosender aufzubauen, sobald der Datenverkehr ein gewisses, selbst konfigurierbares Maß überschreitet. Um einen Source-Based Tree aufzubauen wird eine Join-Nachricht vom Empfänger zum Radiosender und eine Prune-Nachricht vom Empfänger an den RP geschickt - beides per Uni- Michael Werner 14/20

cast. Die Router direkt zwischen Empfänger und Radiosender bauen aufgrund der Join-Nachricht ihre Routinginformationen auf und bilden einen Source-Based Tree vom Sender über die Zwischen- Router zum Empfänger. Die Prune-Nachricht unterdrückt die Weiterleitung der Pakete über den Shared Tree zum Empfänger. Abb. 15: PIM-SM Der Empfänger an R5 baut einen Source-Based Tree mit dem Radiosender auf. Dazu wird eine Join-Nachricht an den Sender und eine Prune-Nachricht an den RP gesendet. Der Shared Tree wird nur aufrecht erhalten, falls weitere Teilnehmer ihn benötigen. Sonst sendet der RP einen Prune-Nachricht an den Radiosender und erhält keine Daten mehr. PIM-SM benutzt sogenannte Softstates. Das bedeutet jeder Eintrag muss in einer bestimmten Zeit wieder aufgefrischt werden, sonst geht er verloren. In diesem Beispiel würde ein Ausbleiben der Prune-Nachrichten des Empfängers an den RP bedeuten, dass dieser wieder einen Shared Tree zum Empfänger etabliert. Der Aufbau der Nachrichtentypen ist im Vergleich zu DVMRP sehr umfangreich und komplex. Beispielsweise verwenden Join- oder Prune-Nachrichten zum codieren von Gruppenadressen spezielle Hash-Algorithmen. Detaillierte Informationen dazu sind in [R2362] zu finden. Ein Problem bei diesem Konzept ist die Fokussierung auf einen RP pro Gruppe. Um die Ausfallsicherheit zu erhöhen, gibt es eine Gruppe von RPs, sogenannte Candidate-Rendevouz Points (C-RP). Diese C-RPs senden Meldungen darüber, dass sie RPs für eine bestimmte Gruppe sind. Darauf hören sogenannte Bootstrap Router (BSR), die diese Meldungen aufnehmen und eine Liste der RPs anlegen. Einer der Bootstrap Router 5 ist dann dafür zuständig die Liste an alle PIM Router im Netz zu verteilen. Fällt der BSR aus, springt ein Vertreter ein, fällt ein RP aus, wird die Liste von den BSRs angepasst. Ein Vorteil von PIM ist die Unterstützung von spärlich besetzten Regionen. Die Ausfallgefahr aufgrund der Fokussierung auf einen RP kann durch die BSR verringert werden. Sinnvoll ist die Möglichkeit PIM-SM auch domänenübergreifend zu nutzen. Mit diesem Thema befasst sich unter anderem der folgende Abschnitt. 5 in [R2362] steht lediglich durch einen einfaches Auswahlverfahren Michael Werner 15/20

2.4. Inter-Domain Multicast Weitläufige, spärlich besetzte Region können domänenübergreifend sein. Da bei PIM-SM ein RP pro Domäne nötig ist, werden Verfahren benötigt, die eine Kommunikation zwischen den einzelnen RPs ermöglichen. 2.4.1. Multicast Border Gateway Protocol (MBGP) und Multicast Source Discovery Protocol (MSDP) Das MBGP ist kein eigenes Protokoll sondern es werden die Multiprotokoll-Erweiterung des BGP- 4 (siehe [R2283]) verwendet, das für den Austausch von Unicast-Routinginformationen zwischen Domänen zuständig ist. Mit diesen Erweiterungen ist es möglich Multicast-Routinginformationen auszutauschen. MBGP Router werden dazu an allen Übergängen zu anderen Domänen installiert und tauschen mit den MBGP-Routern der angrenzenden Domänen Routinginformationen aus. Das MSDP ist für einen neuen Empfänger aus Domäne A zuständig, der sich für einen Radiosender aus Domäne B anmelden will. Dieses Problem ergibt sich zwar nur falls PIM-SM verwendet wird, aber genau das wird bei Inter-Domain Multicasting ausdrücklich empfohlen (siehe [Mbo01] Kapitel 7 Inter-Domain Multicast). Das periodische Fluten von DVMRP oder PIM-DM belastet Netze stärker als nötig wäre. Um MSDP zu nutzen wird in jeder Domäne eine MSDP-Instanz installiert 6. Meldet sich ein neuer Radiosender bei seinem RP an, so sendet die MSDP-Instanz ein Source-Active-Nachricht an alle benachbarten MSDP-Instanzen. Diese Nachricht wird an deren Nachbarn weitergeschickt usw. Die MSDP-Instanzen informieren die RPs und diese überprüfen, ob sie Empfänger für diesen Radiosender haben. Wenn ja wird eine Join-Nachricht an die Quelle gesendet und der RP erhält die Daten der neuen Radiostation aus einer anderen Domäne. Detailliertere Informationen siehe [Far00]. 2.4.2. Border Gateway Multicast Protocol (BGMP) Die Kombination aus MBGP und MSDP stellen nur eine Übergangslösung dar. Die IETF arbeitet derzeit an einem Konzept, welches dieses Problem ganzheitlich lösen soll. Das BGMP soll gewährleisten, dass zwischen den einzelnen Domänen mit Teilnehmern ein bidirektionaler Shared Tree aufgebaut wird. Über diesen werden nicht nur die Multicastdaten sondern auch Join- und Prune- Nachrichten zum An bzw. Abmelden verschickt. Dieses Protokoll ist allerdings noch in der Konzeptionsphase (siehe [Tha00]). 3. Die Darstellung des MBone erfolgt exemplarisch am deutschen Teil. Dieser ist in das Deutsche Forschungsnetz integriert und besteht aus den auf der unteren Landkarte zu sehenden multicastfähigen Routern, die über Stuttgart an die USA und das europäische Forschungsnetz angeschlossen sind. Diese bilden einen Ring mit einer Querverbindung über Frankfurt. Somit kann jeder Router auch im Fall einer ausgefallenen Leitung erreicht werden. 6 für gewöhnlich der gleiche physikalische Router wie der RP in einer Domäne Michael Werner 16/20

Abb. 16: - MBone-Topologie in Deutschland basierend auf dem deutschen Forschungsnetz Damit keine gleichwertigen Routen entstehen können, ist die Metrik der Strecke Köln-Stuttgart mit Zwei um Eins niedriger als die anderen Strecken des Rings. Das Netz wird mit PIM-SM betrieben. Die Außenverbindung wird über MBGP hergestellt. Das bedeutet, dass von außerhalb kein Teilnehmer an einer deutschen Gruppe teilnehmen kann, da sich RPs nicht per MSDP austauschen. Auch deutsche Multicast-Radiosender sind für internationale Empfänger nicht erreichbar. Kommerzielle Internet Service Provider gehen zögerlich an das Thema MBone heran, da einige Probleme gerade für die kommerzielle Nutzung noch nicht gelöst sind wie beispielsweise die Abrechnung von Multicastdiensten. Michael Werner 17/20

3.1. Abrechnungsmodelle für IP-Multicast Die Kosten einer Multicastübertragung verhalten sich bei eine großen Anzahl von Teilnehmern wesentlich günstiger als bei Unicastübertragung. Empfänger teilen sich Leitungen und die dadurch entstehende Kostenersparnis für beispielsweise Radiosender kann an die Kunden weitergegeben werden. Dazu gibt es die Modelle Equal Tree Split (ETS) und Equal Link Split among Downstream Members (ELSD). ETS teilt die Gesamtkosten für den Verteilungsbaum proportional auf die Anzahl der Empfänger auf. Bei sich ändernder Anzahl an Empfängern variieren die Kosten während einer Übertragung was nicht kundenfreundlich ist. Außerdem können die Kosten für bestehende Teilnehmer steigen, wenn ein weit entfernter Empfänger neu hinzukommt und die Leitungen des Verteilungsbaums insgesamt deutlich teuerer werden. ELSD verteilt die Kosten auf die einzelnen Teilstrecken. Das bedeutet, dass ein Teilnehmer in einem Ast mit bereits vielen Empfängern sehr wenig bezahlt, da sich die selben Leitungen viele teilen. Einen neuen entfernten Empfänger würden jedoch hohe Kosten treffen, da er seine Leitungen nicht teilt. Abb. 17: Abrechnungsmodelle für IP-Multicast Nach ELSD werden die Kosten auf die einzelnen Teilstrecken verteilt. Dieses Model ist zwar fairer bezüglich der Kostenverursachung ist aber wesentlich komplizierter. Hierzu müsste eine Bandbreitenreservierung stattfinden, die selbst im Unicastnetz noch Probleme bereitet. Weiter Informationen sind in [Her96] zu finden. 3.2. Multicast-Anwendungen im MBone Es sind zahlreiche Anwendungen im MBone verfügbar. Beispielsweise Whiteboard, Audio- und Videotools, Konferenzprogramme, Radiosender und andere Übertragungsdienste. Eine umfangreiche Liste mit Tipps und Tests sind in der Softwareliste der TU Dresden unter [TUDRE] zu finden. Um all diese Programme zu nutzen bedarf es eines Hilfsprogramms, welches Session Management Tool genannt wird, das es ermöglicht MBone-Sitzungen (Sessions) zu finden, zu eröffnen und daran teilzunehmen. Das bekannteste hierfür ist das Session Directory Tool (SDR). Es ermöglicht das Empfangen von Ankündigungen für geplante Sessions, das Ankündigen eigener Sessions und den Beitritt zu einer Session. Es wird zwischen Broadcast-Sessions mit nur geringer Interaktion und Michael Werner 18/20

interaktiven Meeting-Sessions unterschieden 7. Wird SDR gestartet, so tritt es direkt einer Gruppe bei, an die in der Praxis sämtliche Ankündigungen gesendet werden. Dies geschieht allerdings nur periodisch. Daher kann es bis zu 30 Minuten dauern bis alle Session-Informationen präsent sind. Anhand dieser empfangenen Ankündigungen ist es möglich genauere Informationen anzufordern oder der Session beizutreten. Beim Anlegen einer Session müssen diverse Einstellungen vorgenommen werden wie beispielsweise der Zeitraum der Session oder welche Medien genutzt werden. Nähere Informationen zu diesem Prozess sind in [Mbo01] zu finden. SDR bietet bereits fest integriert Lösungen um Audio- und Videodaten zu empfangen und zu senden sowie Whiteboard und Textverarbeitungsapplikationen. Es kann darüber hinaus auch erweitert werden. Vorraussetzung für die Nutzung von SDR ist ein Anschluss an ein multicastfähiges und in den MBone integriertes Netz. Genauere Informationen zu den Vorraussetzungen für die Teilnahme an MBone-Diensten sind unter [MBHBD] zu finden. 4. Zusammenfassung Das auf Forschungsnetzen aufbaubauende virtuelle IP-Multicast-Netzwerk MBone ist eine praktische Umsetzung der Ideen zu Multicast. Der Grundgedanke ist sinnvoll, da Dienste wie Internetradio mit vielen Teilnehmern eine starke Netzlast verursachen, die durch Multicast auf das nötig Mindestmaß verringert werden kann. Teile befinden sich allerdings noch in der Konzeptphase wie eine grundsätzliche Lösung für Interdomain-Multicast. Detailprobleme wie eine vorhersehbares, faires und zugleich praktikables Tarifmodell verhindern derzeit, dass sich Multicast auch kommerziell durchsetzt. 7 Darüber hinaus gibt es auch unbekannte und Test-Sessions. Michael Werner 19/20

Literaturverzeichnis Proseminar Internetprotokolle für die Multimediakommunikation [Ct00] Dr. A. Ebeling: Bilder für alle Multicast: Sedneverfahren für Audio und Video im Netz, c t 12/2000 Seite212 219 [Far00] D. Farinacci, Y. Rekhter, D. Meyer, P. Lothberg, H. Kilmer, J. Hall: Multicast Source Discovery Protocol, Internet Draft <draft-ietf-msdpspec-06.txt>, Work in Progress, Juli 2000 [Her96] Shai Herzog: Accounting and Access Control for Multicast Distribution: Models and Mechanisms, Ph.D. Dissertation, University of Southern California, USA, 1996 [Hui95] C. Huitema: Routing in the Internet, Prentice Hall PTR, 1995 [MBHBD] [Mbo01] [R1075] [R2236] [R2283] [R2362] [RPIM] [Tha00] [TUDRE] MBone-Handbuch der TU Dresden, http://bzvd.urz.tu-dresden.de/mbone/handbuch/ H. Fahner, P. Feil, T. Zsebsy: Mbone Aufbau und Einsatz von IP- Multicast-Netzen, ISBN 3-920993-99-3, 1. Auflage, dpunkt Verlag, 2001 D. Waitzman, C. Patridge, S. Deering: Distance Vector Multicast Routing Protocol, RFC 1075, November 1988 W.Fenner: Internet Group Management Protocol, Version 2 RFC 2236, November 1997 T. Bates, R. Chandra, D. Katz, Y. Rekhter: Multiprotocol Extensions for BGP-4, RFC 2283, Februar 1998 D. Estrin, D. Farinacci, A. Helmy, D.Thaler, S. Deering, M. Handley, V. Jacobsen, C. Liu, P. Sharma, L. Wie: Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification, RFC 2362, Juni 1998 Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy: Protocol Independent Multicast-dense Mode (pimdm): Protocol Specification, Work in Progress. D. Thaler, D. Estrin, D. Meyer: Border Gateway Multicast Protocol (BGMP): Protocol Specification, Internet Draft <draft-ietf-bgmp-spec- 01.txt>, Work in Progress, März 2000 TU Dresden MBone-Softwareliste, http://bzvd.urz.tu-dresden.de/mbone/software.html Michael Werner 20/20