1 / 82

8. IP Multicast

8. IP Multicast. Problem: ein Sender möchte die gleichen Daten an eine Menge von Empfänger schicken. Die Menge von Empfängern bezeichnet man als multicast Gruppe. Unterschied zum Broadcast: beim Broadcast werden die gleichen Daten an alle Stationen im Netz geschickt. Anwendungsbeispiele

gordy
Download Presentation

8. IP Multicast

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 8. IP Multicast • Problem: ein Sender möchte die gleichen Daten an eine Menge von Empfänger schicken. Die Menge von Empfängern bezeichnet man als multicast Gruppe. • Unterschied zum Broadcast: beim Broadcast werden die gleichen Daten an alle Stationen im Netz geschickt. • Anwendungsbeispiele • Videokonferenzen • Radio/Fernsehen über das Internet • Web-Caching • Netzwerkbasierte Computerspiele • Börsenticker • Wie realisiert man so etwas effizient?

  2. IP Unicast für Gruppen-Kommunikation? • Probleme: • Ineffizient. • Hohe Verzögerungszeiten, da der Sender ein Paket für jeden Empfänger auf die Leitung geben muss.

  3. IP Multicast - Idee • Multicast ist eine Technologie, bei der Datenpakete an mehrere Empfänger gesendet werden. • Bei Multicast soll über jede Schicht 2 Verbindung nur eine Kopie des Paketes verschickt werden. • Bei Bedarf wird das Paket vom den Routern dupliziert.

  4. IP Multicast Konzept • Ein Sender schickt Pakete an eine multicast Adresse: 224.0.0.0 – 239.255.255.255. • Eine multicast Adresse identifiziert eine multicast Gruppe von Empfängern. • Ein Empfänger teilt den lokalen Routern mit, daß er die Pakete einer multicast Adresse empfangen möchte. • Multicast fähige Router arbeiten mit Hilfen von multicast Routing Protokollen zusammen, um die Pakete effizient vom Sender zu allen Empfängern zu befördern. • IP Multicast ist anonym, d.h. ein Sender kennt die Empfänger nicht. • Multicast Adressen bezeichnen eine (dynamische) Gruppe von Empfängern und sagen nichts darüber aus, wo diese Empfänger zu finden sind!

  5. Multicast Unterstützung im Endsystem • Problem: welche Schicht 2 Adresse bekommen multicast Daten? Problematisch, da eine multicast Adresse ja kein Endsystem adressiert. • Vorgehen zur Adressabbildung von einer multicast Adresse auf eine Schicht 2 Adresse: • Die Schicht 2 Adresse wird algorithmisch aus der multicast Adresse abgeleitet. Dabei ist ein gewisser Adressraum von Schicht 2 Adressen für multicast reserviert. • Bei Ethernet werden die unteren 24 Bit der multicast Adresse mit einem festen 24 Bit Präfix versehen. • Wenn eine Anwendung einer multicast (Empfänger) Gruppe beitreten möchte, dann instruiert sie die Netzwerkkarte, Pakete mit der entsprechenden Schicht 2 Adresse zu empfangen. • Die führt dazu, daß ein lokaler Router die Pakete für eine multicast Gruppe nur einmal in das lokale Netz weiterleiten muss, selbst wenn es dort mehrere Empfänger gibt.

  6. Multicast Unterstützung im Endsystem • Problem: wie erfährt ein lokaler Router, daß sich ein Empfänger für eine gewisse multicast Gruppe in einem Angeschlossenen Sub-Netz befindet? • Nur wenn er diese Information besitzt, kann der Router mit anderen Routern zusammenarbeiten um den Empfänger mit den gewünschten Daten zu versorgen. • Lösung: es gibt ein spezielles Protokoll, mit dem Empfänger signalisieren, daß sie den Empfang der Daten wünschen, die an eine gewissen multicast Adresse gesendet werden: Internet Group Management Protocol (IGMP)

  7. IGMPv1 • S. Deering. Host Extensions for IP Multicasting. RFC 1112. 1989. • IGMP wird ausschließlich zwischen Endsystemen und deren lokalen Router verwendet, nicht zum Routing im Inneren des Netzes. • IGMP Membership Queries: • Werden von Routern an die all Hosts multicast Gruppe geschickt (224.0.0.1), dies ist eine Gruppe die niemals das lokale Netz verlässt. • Sind eine Aufforderung an alle Endsysteme: es sollen die multicast Adressen gemeldet werden, für die Empfänger im lokalen Netz vorhanden sind.

  8. IGMPv1 • IGMP Membership Reports: • Als Antwort auf einen IGMP Membership Query generiert ein Endsystemen für jede multicast Adresse, an der sie interessiert ist, einen IGMP Membership Report. Diese wird ebenfalls an die all Hosts multicast Gruppe geschickt. • Um eine Explosion von Membership Reports zu vermeiden werden diese nicht sofort gesandt, sondern um eine zufällige Zeitspanne verzögert. Wenn ein anderes Endsystem die gleiche Adresse früher nachfragt, dann sendet man nichts. • Erhält ein Router für eine multicast Adresse wenigstens einen Report, dann leitet er Daten für diese multicast Adresse in das lokale Netz weiter. • Erhält ein Router für eine multicast Adresse eine bestimmte Anzahl von Queries lang keinen Report für die multicast Adresse, dann wird das weiterleiten eingestellt.

  9. IGMPv2 • W. Fenner. Internet Group Management Protocol Version 2. RFC 2236, 1997. • Ein Problem mit IGMPv1 ist, daß es lange dauern kann, bis ein Router erkennt, daß kein Empfänger mehr für eine multicast Gruppe im LAN vorhanden ist. • Dies liegt daran, daß ein Router mehrere erfolglose Queries abwartet bevor Daten für eine multicast Adresse nicht mehr weitergeleitet werden. Dies soll verhindern, daß ein einzelner Paketverlust die Weiterleitung beendet. • IGMPv2 beinhaltet eine Mechanismus, mit dem sich Empfänger explizit abmelden können. Dieser Mechanismus ist recht komplex, da verhindert werden muss, daß ein Empfänger, der sich abmeldet, andere Empfänger im selben LAN stört.

  10. IGMPv3 • B. Cain, S. Deering, I. Kouvelas, and A. Thyagarajan. Internet Group Management Protocol Version 3. Internet Draft. 2000. Work in Progress. • In IGMPv1 und IGMPv2 leitet ein Router alle Daten weiter, die von beliebigen Sendern an eine gegebenen multicast Adresse gesendet werden. • Dies kann unter Umständen nicht wünschenswert sein. • IGMPv3 erweitert IGMPv2 um die Funktionalität, daß Endsysteme die Sender einschränken können, von denen Sie Daten auf einer multicast Adresse empfangen wollen.

  11. „Interior Gateway“ Multicast Routing • Problem: wie arbeiten die Router im Inneren des Netzes zusammen um die Pakete von dem/den Sender(n) an die Empfänger weiterzuleiten? • Prinzipiell geht es beim Multicast Routing darum einen Baum aufzubauen, auf dessen Kanten die Pakete weitergeleitet werden und an dessen Knoten die Pakete kopiert werden. • Multicast Routing: • DVMRP • MOSPF • PIM-SM • PIM-DM • CBT

  12. Multicast Routing: Flooding • Prinzipielle Idee beim Flooding (Fluten) ist das folgende: • Jedes Paket wird von jedem Router auf alle Links geforwarded auf denen es nicht angekommen ist. • Dies geschieht für jedes Paket nur einmal um Schleifen zu vermeiden. D. h. kommt das selbe Paket wieder an einem Router an, dann wird es verworfen. • Problem: • Kein multicast routing sondern Broadcast! • Nur geeignet, wenn die überwältigende Mehrheit aller Stationen in einem Netz Interesse an den Daten haben.

  13. Beispiel From A to Link Cost From C to Link Cost From E to Link Cost A local 0 C local 0 E local 0 B 1 1 B 2 1 B 4 1 D 3 1 A 2 2 A 4 2 C 1 2 E 5 1 D 6 1 E 1 2 D 5 2 C 5 1 From B to Link Cost From D to Link Cost B local 0 D local 0 A B C 1 2 A 1 1 A 3 1 D 1 2 B 3 2 3 4 5 C 2 1 E 6 1 D E 6 E 4 1 C 6 2

  14. Multicast Routing: Reverse-Path-Forwarding (RPF) • Idee: wenn ein Distanz-Vektor Protokoll (z.B. RIP) für unicast verwendet wird, dann haben wir schon wichtige Informationen über die Topologie des Netzes. Diese sollten wir nutzen! • Bei RPF wird ein eingehendes multicast Paket nur dann weitergeleitet, wenn es auf dem Link empfangen wurde, der den kürzesten Weg zum Sender darstellt. • Ansonsten funktioniert RPF wie Flooding.

  15. Beispiel From A to Link Cost From C to Link Cost From E to Link Cost A local 0 C local 0 E local 0 B 1 1 B 2 1 B 4 1 D 3 1 A 2 2 A 4 2 C 1 2 E 5 1 D 6 1 E 1 2 D 5 2 C 5 1 From B to Link Cost From D to Link Cost B local 0 D local 0 A B C 1 2 A 1 1 A 3 1 D 1 2 B 3 2 3 4 5 C 2 1 E 6 1 D E 6 E 4 1 C 6 2

  16. RPF • RFP verbessert den Flooding Ansatz, es werden weniger Nachrichten im Netz verbreitet. • Aber: RPF ist immer noch ein Ansatz für Broadcast und nicht für Multicast. Die Hauptnachteile bleiben also bestehen.

  17. Multicast Routing:Reverse Path Broadcast (RPB) • Beim reverse Path Broadcast wird wir RPF verbessert, indem Pakete nur auf diejenigen Links weitergeleitet, die für den empfangenden Router auf den kürzesten Weg zum Sender liegen. • Dies erfordert, daß ein Router Informationen von seinen Nachbarn bekommt, ob er für ein bestimmtes Ziel für diesen Nachbarn auf dem kürzesten Weg liegt. • Diese Information erhält man beispielsweise über Poison-Reverse: Wenn man von einem Nachbarn einen poison reverse Eintrag bekommt, dann ist klar, dass man für diesen Nachbarn auf dem kürzesten Weg zum betreffenden Eintrag liegt. • Wir betrachten die vorhergehende Situation für RPB. • RPB verbessert Flooding weiter, das Hauptproblem bleibt jedoch bestehen. Es ist immer noch ein Broadcast Protokoll.

  18. Beispiel From A to Link Cost From C to Link Cost From E to Link Cost A local 0 C local 0 E local 0 B 1 1 B 2 1 B 4 1 D 3 1 A 2 2 A 4 2 C 1 2 E 5 1 D 6 1 E 1 2 D 5 2 C 5 1 From B to Link Cost From D to Link Cost B local 0 D local 0 A B C 1 2 A 1 1 A 3 1 D 1 2 B 3 2 3 4 5 C 2 1 E 6 1 D E 6 E 4 1 C 6 2

  19. Multicast Routing:Truncated Reverse Path Broadcast (TRPB) • Truncated Reverse Path Broadcast erweitert RPB um die Eigenschaft, daß Router die Daten nur in Subnetze weiterleiten, die wenigstens einen Empfänger haben. • Dies wird mit Hilfe von IGMP festgestellt. • Ansonsten funktioniert TRPB wie RPB, ist also immer noch ein Broadcast Protokoll.

  20. Multicast Routing: Reverse Path Multicasting (RPM) • Die Hauptidee bei RPM ist, daß Teilbäume, die keine Empfänger beinhalten abgeschnitten werden: • Wenn ein Router ein Blatt Router ist – er also keine Kinder im multicast Baum hat: • Wenn kein Teilnehmer im LAN an der Übertragung an die multicast Gruppe interessiert ist, dann sendet der Router eine Pruning Nachricht an seinen Eltern-Router. Der Eltern-Router wird daraufhin aufhören, Daten für diese multicast Gruppe an diesen Router weiterleiten. • Wenn ein Router ein Eltern-Router ist – er also Kinder im multicast Baum hat: • Wenn er von allen Kindern eine Pruning Nachricht bekommen hat, dann schickt er selbst eine Pruning Nachricht an seinen eigenen Eltern-Router.

  21. RPM – Pruning: Beispiel A B C 1 2 A B C 1 2 3 4 5 3 4 TRPB Baum D E 6 D E Wenn in den lokalen Netzen von C, E und B keine Empfänger sind: Prune A B C 1 2 3 4 Prune D E

  22. RPM • Router speichern die Informationen über die abgeschnittenen Teilbäume. Dabei ist ein Eintrag pro multicast Gruppe und Kind Router erforderlich. • Was passiert wenn ein neuer Empfänger in einem Teilbaum hinzukommt, der abgeschnitten ist? • Die Einträge in den Routern haben nur eine gewisse Lebenszeit. Danach wird der Eintrag gelöscht und der abgeschnittene Teilbau wieder mit Paketen für die multicast Gruppe geflutet. • Die Länge der Lebenszeit ist ein trade-off zwischen der Verzögerung bis ein Empfänger die multicast Daten erhält wenn er in einem abgeschnittenen Teilbaum ist und der Häufigkeit mit der Pakete geflutet werden.

  23. RPM Bewertung • Bei RPM wird die Struktur der Empfängergruppe explizit verwendet. RPM ist ein multicast Routing Verfahren. • RPM ist nicht gut geeignet für multicast Gruppen, bei denen nur ein kleiner Teil der Netze einen Empfänger für eine gegebene multicast-Gruppe enthält (sparse multicast Tree), da von Zeit zu Zeit geflutet wird. • RPM skaliert nicht gut, da in den Routern für jeden Nachbar Informationen gehalten werden muss, falls dieser KEINE Daten einer bestimmten Sitzung erhalten möchte.

  24. Distance Vector Multicast Routing Protocol (DVMRP) • T. Pusateri. Distance Vector Multicast Routing Protocol. Internet Draft. 2000. Work in Progress.Es empfiehlt sich die Seiten 1-7 zu lesen! • DVMRP ist eines der multicast Protokolle, die über eine längere Zeit im Internet verwendet wurden und noch heute verwendet werden. • DVMRP benutzt Prizipien von RPM und entwickelt diese weiter. • DVMRP benutzt eine eigenen Routing Tabelle, die unabhängig von der unicast Routing Tabelle ist. • DVMRP benutzt zur Bestimmung der Routing Tabelle ein Verfahren, welches an RIP angelehnt ist.

  25. DVMRP – Aufbau der Routing Tabelle • Die Routing Tabelle wird analog zu RIP konstruiert, indem distance Vectors versandt werden. • Man verwendet eine eigene Routing Tabelle weil dies ermöglicht, daß unicast und multicast Verkehr unterschiedlich geroutet wird. Dies ist sinnvoll, da zur Zeit noch viele (multicast) Tunnel vorhanden sind. • Poison Reverse spielt eine besondere Rolle: es wird verwendet um festzustellen ob man für einen Nachbar Router auf dem Kürzesten Weg zu einem Ziel liegt. Um diese Information von einer unendlichen Strecke zu unterscheiden wird bei Poison Reverse unendlich + Distanz verschickt (anstelle von unendlich). • Diese Informationen werden unabhängig von den multicast Gruppen gespeichert und aktualisiert.

  26. DVMRP – Pruning und Grafting • DVMRP verwendet Pruning mit periodischem Broadcast wie bei RPM. • Um einen Sender jederzeit eingliedern zu können besteht die Möglichkeit Grafting durchzuführen. • Dabei schickt ein Router der die Daten für eine bestimmte multicast Gruppe bekommen möchte eine explizite Grafting Nachricht an seinen Eltern-Router. Dieser forwarded dann die Daten wieder zu diesem Kind. • Grafting erfolgt rekursiv, wenn der Eltern-Knoten ebenfalls die Daten für eine multicast Gruppe nicht mehr erhält, da er sie mittels Pruning abbestellt hat.

  27. DVMRP Beispiel • Als Java Applett: http://www-mm.informatik.uni-mannheim.de/veranstaltungen/animation/routing/ripdvmrp/

  28. DVMRP - Bewertung • DVMRP hat im wesentlichen die glichen Eigenschaften wie RPM.

  29. Multicast OSPF (MOSPF) • J. Moy. Multicast Extensions to OSPF. RFC 1584. 1994. • MOSPF ist eine Erweiterung von OSPF, die multicast ermöglicht. D.h. um MOSPF einsetzten zu können muss OSPF im unicast routing verwendet werden.

  30. OSPF – Wiederholung: Datenbank A B C 1 2 3 4 5 D E 6 Karte/Datenbank: From From Link Cost Number From From Link Cost Number A B 1 1 1 C E 5 1 1 A D 3 1 1 D A 3 1 1 B A 1 1 1 D E 6 1 1 B C 2 1 1 E B 4 1 1 B E 4 1 1 E C 5 1 1 C B 2 1 1 E D 6 1 1

  31. OSPF – Wiederholung: Lokale Berechnung der Routing Tabelle Achtung! Nun repräsentieren die Zahlen die „Distanz“ (= Verzögerung, Kosten, etc.) zwischen zwei Knoten. A B C 1 5 2 2 1 D E 2 E={A, B, D, E} O={A-D-E-4, A-B-E-C-4, A-B-C-6} Kürzeste Pfade: {A-B-1, A-D-2, A-B-E-3} E={A} O={A-B-1, A-D-2} Achtung 2 Schritte!!! E={A, B, C, D, E} O={A-B-C-6} Kürzeste Pfade: {A-B-1, A-D-2, A-B-E-3, A-B-E-C-4} E={A, B} O={A-D-2, A-B-E-3, A-B-C-6} Kürzeste Pfade: {A-B-1} E={A, B, D} O={A-B-E-3, A-D-E-4, A-B-C-6} Kürzeste Pfade: {A-B-1, A-D-2} Dann noch 1 weiterer Schritt bis zum Ende!

  32. MOSPF • In OSPF werden link-state Advertisements verschickt (im Netz geflutet), so daß jeder Router die vollständige Topologie des Netzes kennt. • Bei MOSPF wird zusätzlich die Information über die Gruppenmitgliedschaften im Netz geflutet, so daß jedem Router für jede Multicast Gruppe bekannt ist, welche anderen Router im Netz lokale Teilnehmer als Empfänger für diese Multicast Gruppe haben. • Dann wird der Dijkstra Algorithmus verwendet um für einen Sender den Multicast Baum zu bestimmen. Dies geschieht in jedem Router und führ in allen Routern zum selben Baum. • Der Baum wird dann mit Hilfe der zusätzlichen Informationen über die Gruppenmitgliedschaft zurechtgestutzt (ge-“pruned“).

  33. MOSPF – Pruning A B C 1 5 A B C 1 2 2 2 2 1 1 D E 2 D E Kürzeste Pfade aus OSPF: {A-B-1, A-D-2, A-B-E-3, A-B-E-C-4} Dann wird gepruned: d.h. die Knoten, die keine Lokalen Teilnehmer haben und die nicht zum Weiterleiten im Baum benötigt werden, werden entfernt: {A-B-1, A-D-2, A-B-E-3, A-B-E-C-4}

  34. MOSPF - Bewertung • MOSPF verhindert das regelmäßige Fluten und Zurechtstutzen des multicast Baumes. • Aber MOSPF skaliert (wie DVMRP) schlecht: • Wie DVMRP wird ein Multicast Baum pro Sender und Gruppe gebildet. • Für jede Gruppe) muss jeder Router für jeden anderen Router im Netzt speichern, ob dieser an der Gruppe interessiert ist. • Gruppenmitgliedschaft wird im ganzen Netz geflutet.

  35. Protocol Independent Multicast – Sparse Mode (PIM-SM) • B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. „Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised)“, Internet Draft, 2000. • PIM-SM geht davon aus, daß Routing Tabellen existieren. • Für diese Routing Tabellen können z.B. die durch unicast Routing gewonnenen Informationen verwendet werden. Oder es kann ein dediziertes Protokoll (wie in DVMRP) benutzt werden. • PIM-SM geht davon aus, daß jeder Eintrag in diese Routing Tabelle zu einem multicast-fähigem Router führt.

  36. PIM-SM Prinzipielle Idee • Im PIM-SM wird für jede Multicast-Gruppe ein gemeinsamer Multicast-Baum für alle Sender aufgebaut. • Die Wurzel dieses Baumes heißt Rendezvous Point (RP) oder Rendezvous Router. • In einer Domäne gibt es gewöhnlich mehrere Kandidaten für RPs. • Für eine gegebene Multicast-Adresse wird ein RP durch eine Abbildung der Adresse mittels einer Hash-Funktion bestimmt. D.h. für eine Multicast Adresse gibt es in einer Domäne genau einen RP. • Sender schicken ihre Daten an den RP, dieser leitet sie auf den Gruppen spezifischen Multicast Baum (*,G) zu den Empfängern. • Empfänger können die Bildung eines Sender-Spezifischen Baumes (S,G) einleiten, um die Effizienz zu erhöhen.

  37. PIM-SM Funktionsweise • Die Funktionsweise wird beschrieben in den Folien von Mark Handley: • http://www.aciri.org/mjh/slides/mci/ • Seiten 14-22 • Dieser Foliensatz ist sehr interessant und empfehlenswert, 180 Seiten Multimedia Kommunikation! • Den ganzen Foliensatz gibt es auch als Postscript:http://www.aciri.org/mjh/mci.ps.gz

  38. Weitere Ansätze zum „Interior Gateway“ Multicast Routing • PIM-Dense Mode (PIM-DM): ähnlich zu DVMRP, für dicht besetzte Multicast Bäume. • Core Based Trees (CBT): hier wird (ähnlich zu PIM-SM) ein gemeinsamer Multicast Baum für alle Sender verwendet. Dieser Baum ist bidirektional, d.h. er wird auch benutzt um Daten von Sendern zu Rendezvous-Stelle weiterzuleiten.

  39. Exterior Gateway Multicast Routing • Die bisher vorgestellten Multicast Routing Verfahren werden innerhalb einer Domäne verwendet. • Diese kann zum Beispiel einen Teil eines Landes umfassen (z.B. alle Unis in Baden-Württemberg). • Die Verfahren sind ungeeignet für einen Welt-weiten oder Kontinent-weiten Einsatz: • DVMRP: Fluten im gesamten Internet ist ausgeschlossen. • MOSPF: Link-State Infos über das gesamte Internet sind nicht handhabbar. • PIM-SM: Die Verwaltung der Rendezvous Stellen ist auf globaler Ebene nicht möglich. • Daher gibt es analog zu BGP auch Exterior Gateway Protocols für Multicast

  40. Multicast Source Discovery Protocol (MSDP) • D. Farinacci, et. Al. Multicast Source Discovery Protocol (MSDP), Internet Draft, 2000. • MSDP ist ein Exterior Gateway Protocol für PIM-SM. • MSDP verwendet für die Signalisierung eine Erweiterung von BGP (MBGP):T. Bates, et. Al. Multiprotocol Extensions for BGP-4, RFC 2858. 2000. • MBGP verallgemeinert BGP, so daß mehrere Schicht 3 Protokolle parallel BGP benutzen können (z.B. auch IPv6) • MSDP ist eines dieser Schicht 3 Protokolle.

  41. MSDP – Problem • In PIM-SM schickt ein Sender seine Daten zunächst an einen Rendezvous Router, der sie dann im Multicast Baum verteilt. • Verschiedenen administrative Domänen haben jeweils einen eigenen Satz von Rendezvous Routern. • Jeder Sender sendet an den Rendezvous Router in seiner Domäne. • Grundlegendes Problem: wie erfährt man von Sendern in anderen administrativen Domänen? • Ist dieses Problem gelöst, dann kann ein Rendezvous Router in einer Domäne den Rendezvous Router eines Senders in einer anderen Domäne kontaktieren und sich in den Multicast Baum einklinken um dann selbst die Daten weiterzuleiten. • Danach funktioniert alles wie gehabt, d.h. es kann ein Sender spezifischer Baum aufgebaut werden.

  42. MSDP – Beispiel Rendezvous Router Rendezvous Router Empfänger Empfänger Empfänger Sender PIM-SM Domäne PIM-SM Domäne

  43. MSDP – Wie erfährt man die Präsenz von Sendern in anderen Domänen? • Die Rendezvous Router aller Domänen unterhalten sich untereinander mit Hilfe von MSDP. • Wann immer ein Rendezvous Router einen Sender in der eigenen Domäne entdeckt wird dies per Reverse Path Broadcast mitgeteilt. • Diese Ankündigung wird periodisch wiederholt, solange der Sender vorhanden ist. • MSDP benutzt hierzu TCP Verbindungen zwischen den Rendezvous Routern verschiedener Domänen.

  44. Border Gateway Multicast Protocol (BGMP) • D. Thaler, D. Estrin, D. Meyer. Border Gateway Multicast Protocol (BGMP). Internet Draft. Work-in-Progress. 2000. • BGMP ist ein Multicast Exterior Gateway Protocol welches mit beliebige Multicast Interior Gateway Protocols (M-IGP) zusammenarbeiten kann. • Wie in MSDP wird davon ausgegangen, daß ein geeignetes (unicast) Exterior Gateway Protocol (z.B. MBGP) vorhanden ist, welches die Routingtabellen für jeden BGMP Router bestimmt. • BGMP ist dann verantwortlich für die Baumbildung und das geeignete Weiterleiten der Pakete auf der Basis der Informationen die das (unicast) Exterior Gateway Protocol zur Verfügung stellt.

  45. BGMP – Prinzipielle Idee • BGMP ist ein Protokoll, welches normalerweise einen einzigen Multicast Baum (*,G) für eine Multicast-Gruppe aufbaut. • Dieser ähnelt dem von PIM-SM. • Bei BGMP wird der Multicast-Adressraum in disjunkte Teile zerlegt und jeder Teil einer Domäne zugeordnet. • Eine Domäne ist Rendezvous Stelle für die Multicast-Gruppen, die die ihr zugeordneten Multicast-Adressen verwenden. Dies ist analog zum Rendezvous Router in PIM-SM. • BGMP kann Sender Spezifische (S,G) Bäume aufbauen, dies wird aber nur dann verwendet, wenn • ein M-IGP (S,G) Bäume verwendet (machen z. Zeit alle gängigen M-IGPs) und • der (*,G) Baum einen anderen BGMP Router verwendet als der (S,G) Baum verwenden würde.

  46. BGMP - Beispiel • Die Funktionsweise wird beschrieben in den Folien von Mark Handley: • http://www.aciri.org/mjh/slides/mci/ • Seiten 23-28

  47. IP Multicast Scoping • Es ist im allgemeinen nicht erwünscht, daß die Daten eines Senders weltweit verbreitet werden: • Unnötiger Datenverkehr für flood & prune Ansätze. • Multicast Adressen werden weltweit für eine Sitzung blockiert. • Daher verwendet man multicast scoping, dabei legt der Sender fest, in welcher Region seine Empfänger sind. D.h. er macht eine Aussage darüber wie weit seine Daten sich im Netz ausbreiten dürfen. • Es gibt 2 Ansätze für multicast scoping: • TTL Scoping • Administrative Scoping

  48. TTL Scoping • Bei TTL scoping wird das TTL Feld benutz um Regionen voneinander abzugrenzen. • Wie bei unicast wird in IP multicast die TTL eines Paketes um 1 in jeden Router dekrementiert. • Für spezielle links kann in den Routern ein minimaler TTL Wert eingestellt werden, den ein multicast Paket haben muss, damit es über diesen Link weitergeleitet wird. Hat ein multicast Pakete eine kleinere TTL so wird es nicht über diesen Link weitergeleitet. • Typische Werte: • Tunnel zwischen EU Ländern: 48 • Tunnel zu anderen Kontinenten: 64

  49. TTL Scoping Problem • Mit TTL-Scoping können nur ineinander liegende Regionen abgegrenzt werden. Die folgende Abgrenzung ist nicht möglich: Scope B Scope A Scope A&B

  50. Administrative Scoping • Bei administrative scoping werden die Multicast Adressen die vom scoping betroffen sein sollen von den Routern die auf der Grenze einer Region liegen nicht weitergeleitet. • So kann man beliebige Bereiche aufbauen. • Die Multicast Adressen, die dem administrative scoping unterliegen werden entsprechen administratively scoped multicast addresses genannt. Diese sind zur Zeit 239.0.0.0 bis 239.255.255.255. • TTL Scoping wird für alle übrigen multicast Adressen verwendet.

More Related