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.

Präsentation zum Thema: "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."—  Präsentation transkript:

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 von den Routern dupliziert.

4 IP Multicast Konzept Ein Sender schickt Pakete an eine multicast Adresse: – Eine multicast Adresse identifiziert eine multicast Gruppe (von Empfängern). Ein Empfänger teilt den lokalen Routern mit, dass 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. Dies führt dazu, dass 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, dass 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, dass 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 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 ( ), 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, dann wird das Weiterleiten eingestellt.

9 IGMPv2 W. Fenner. Internet Group Management Protocol Version 2. RFC 2236, 1997. Ein Problem mit IGMPv1 ist, dass es lange dauern kann, bis ein Router erkennt, dass kein Empfänger mehr für eine multicast Gruppe im LAN vorhanden ist. Dies liegt daran, dass ein Router mehrere erfolglose Queries abwartet bevor Daten für eine multicast Adresse nicht mehr weitergeleitet werden. Dies soll verhindern, dass 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, dass 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 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, dass 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 weitergeleitet auf denen es nicht angekommen ist. Dies geschieht für jedes Paket nur einmal um Schleifen zu vermeiden. D. h. kommt ein Paket zum zweiten mal an einem Router an, dann wird es verworfen. Problem: Man muss sich Pakete merken! Kein multicast routing sondern Fluten! Nur geeignet, wenn die überwältigende Mehrheit aller Stationen in einem Netz Interesse an den Daten haben.

13 Beispiel A B C D E 1 2 3 4 5 6 From A to Link Cost From C to Link Cost
From E to Link Cost A local C local E local 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 D local A 1 B 2 C A 1 1 A 3 1 D 1 2 B 3 2 3 4 5 C 2 1 E 6 1 E 4 1 C 6 2 D 6 E

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 A B C D E 1 2 3 4 5 6 From A to Link Cost From C to Link Cost
From E to Link Cost A local C local E local 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 D local A 1 B 2 C A 1 1 A 3 1 D 1 2 B 3 2 3 4 5 C 2 1 E 6 1 E 4 1 C 6 2 D 6 E

16 RPF RFP verbessert den Flooding Ansatz, es müssen keine zusätzlichen Informationen im Router gespeichert werden. 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, dass 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 indem die Anzahl der Nachrichten reduziert wird. Das Hauptproblem bleibt jedoch bestehen. Es ist immer noch ein Broadcast Protokoll.

18 Beispiel A B C D E 1 2 3 4 5 6 From A to Link Cost From C to Link Cost
From E to Link Cost A local C local E local 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 D local A 1 B 2 C A 1 1 A 3 1 D 1 2 B 3 2 3 4 5 C 2 1 E 6 1 E 4 1 C 6 2 D 6 E

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, dass 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 und selbst keine Endsysteme bedient, dann schickt er eine Pruning Nachricht an seinen eigenen Eltern-Router.

21 RPM – Pruning: Beispiel
A 1 B 2 C A 1 B 2 C 3 4 5 3 4 D E TRPB Baum 6 D E Wenn in den lokalen Netzen von C, E und B keine Empfänger sind: Prune A 1 B 2 C 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 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 Distanzvektoren versandt werden. Man verwendet eine eigene Routing Tabelle weil dies ermöglicht, dass 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:

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

29 Multicast OSPF (MOSPF)
J. Moy. Multicast Extensions to OSPF. RFC 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
1 B 2 C 3 4 5 D 6 E 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
1 B 5 C Achtung! Nun repräsentieren die Zahlen die „Distanz“ (= Verzögerung, Kosten, etc.) zwischen zwei Knoten. 2 2 1 D 2 E 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 dass 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 A B C D E D E Kürzeste Pfade aus OSPF:
1 B 5 C A 1 B C 2 2 2 2 1 1 D 2 E 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, 2002. PIM-SM geht davon aus, dass 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, dass jeder Eintrag in diese Routing Tabelle zu einem multicast-fähigem Router führt.

36 PIM-SM Prinzipielle Idee
In 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: Seiten 14-22 Dieser Foliensatz ist sehr interessant und empfehlenswert, 180 Seiten Multimedia Kommunikation! Den ganzen Foliensatz gibt es auch als Postscript:

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 MBGP verallgemeinert BGP, so dass 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 Empfänger Empfänger Empfänger Sender PIM-SM Domäne
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 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: Seiten 23-28

47 IP Multicast Scoping Es ist im allgemeinen nicht erwünscht, dass 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 bis TTL Scoping wird für alle übrigen multicast Adressen verwendet.

51 Administrative Scoping Probleme
Man sieht einem Paket nicht an, wie weit es weitergeleitet wird. Das wissen nur die Router an der Grenze einer Zone. Auch der Sender benötigt explizites Wissen über die Zuordnung von Zonen und Adressen. Zonen, die sich überschneiden müssen disjunkte Adressen besitzen. Dies ist ein nicht einfach zu lösendes administratives Problem. Es ist nicht ungewöhnlich, dass ein Router falsch konfiguriert wird. Bei TTL scoping wird das Paket i. d.R. spätestens an der nächst höheren Grenze verworfen (Ländergrenze falsch konfiguriert -> an der Grenze Europas wird das Paket verworfen). Bei administrative scoping ist es möglich, dass ein Paket durch eine falsch konfigurierten Router weltweit verbreitet wird.

52 Wie finden sich Sender und Empfänger?
Für diese Aufgabe wird das Session Announcement Protocol (SAP) verwendet. M. Handley, C. Perkins, E. Whelan. Session Announcement Protocol. RFC Die Idee von SAP ist, daß die Beschreibung von Sitzungen (verwendete Adressen, TTL, Medienkodierung, etc.) in Regelmäßigen Abständen auf einer speziellen Multicast Gruppe angekündigt werden. In IPv4 ist dies: Diese Ankündigung wird von einer Anwendung generiert (z.B. von dem Session DiRectory tool SDR) und mit dem TTL scope der angekündigten Sitzung verschickt. Um die Belastung des Netzes gering zu halten ist die Frequenz der Ankündigungen invers proportional zu der Anzahl aller Ankündigungen auf der speziellen Multicast Gruppe.

53 Wie sehen Sitzungsankündigungen aus?
Das Format der Sitzungsankündigungen die mit SAP verschickt werden ist als Session Description Protocol (SDP) spezifiziert. M. Handley, V. Jacobson. SDP: Session Description Protocol. RFC SDP kann durch SAP transportiert werden. SDP kann auch für andere Zwecke eingesetzt werden, z.B. für das direkte (Punkt-zu-Punkt) Einladen von Sitzungsteilnehmern.

54 SDP und SAP ... werden wiederum sehr schön im Foliensatz von Mark Handley beschrieben: Seiten 61-69

55 Multicast Address Allocation
Auch mit SAP/SDP stellt sich noch die Frage, wie derjenige, der eine Sitzung ankündigt eine geeignete Multicast Adresse auswählt. Dies ist ein aktuelles Forschungsgebiet, es gibt noch keine allgemein anerkannte Vorgehensweise. Diese Fragestellung wird in der MALLOC WG (Multicast Address Allocation) der IETF bearbeitet. Es gibt eine Reihe von RFCs/Internet Drafts über dieses Themengebiet, die wir im Folgenden behandeln werden.

56 Internet Multicast Address Allocation Architecture
D. Thaler, M. Handley, D. Estrin. The Internet Multicast Address Allocation Architecture. Internet Draft. Work-In-Progress Die Allokation von multicast Adressen erfolgt mit Hilfe einer 3-stufigen Architektur: Host-Server: für die Nachfrage von Adressen Intradomain Server-Server: für die Koordination von Servern innerhalb einer Domäne Interdomain Server-Server: für die Koordinierung von Servern verschiedener Domänen Die Benutzung einer multicast Adresse kann in zwei Dimensionen begrenzt sein: Zeitlich: Startzeitpunkt/Endzeitpunkt (möglicherweise unendlich) der Benutzung Räumlich: durch multicast scoping (bei der Internet Multicast Address Allocation Architecture werden nur administratively scoped multicast addresses vergeben!)

57 Anforderungen an Multicast Address Allocation
Robustheit / Verfügbarkeit: man sollte immer in der Lage sein, eine multicast Adresse zu erhalten. Minimale Verzögerung: die Verzögerungszeit, bis man eine multicast Adresse erhält sollte gering sein (wenige Sekunden). Geringe Wahrscheinlichkeit für Mehrfachvergabe: die Wahrscheinlichkeit, dass es einen Adresskonflikt wegen Mehrfachvergabe der gleichen Adresse gibt sollte gering sein. Gute Ausnutzung des Adressraumes: multicast Adresse sind eine begrenzte Resource (insbesondere in IPv4). Sie sollte effizient genutzt werden.

58 Anforderungen an Multicast Address Allocation
Insbesondere die letzten beiden Kriterien sind konfliktionär: wenn man die Ausnutzung des Adressraumes optimiert, dann erhöht man die Wahrscheinlichkeit für Adresskonflikte. Man hat sich entschieden die gute Ausnutzung des Adressraumes zu bevorzugen. D.h. es kann in Ausnahmefällen zu Adresskonflikten kommen. Bei Adresskonflikt: Ignorieren der Sender die nicht relevant sind (wird von IGMPv3 und geeigneten multicast routing Verfahren unterstützt). Dazu muss die Anwendung feststellen können, dass ein Konflikt vorliegt (unter Umständen nicht so einfach, z.B. 2 Videokonferenzen mit denselben Tools).

59 Arten der Multicast Address Allocation
Static: statisch allokierte Adressen werden für bestimmte Zwecke vergeben. Beispiele sind für NTP oder für SAP. Diese Zuordnung wird von der IANA durchgeführt. Scope Relative: In jedem scope (administratively scoped multicast addresses) sind die oberen 256 Adressen für diese Allokationsart reserviert. Sie wird verwendet wenn Dienste auf einer wohlbekannten Adresse für jeden Scope angeboten werden. Die Zuordnung Offset – Dienst wird ebenfalls von der IANA verwaltet. Dynamisch: alles andere – also der Regelfall!

60 Internet Multicast Address Allocation Architecture
Domäne A Domäne B Prefix Coordinator Prefix Coordinator Prefix Coordinator Layer 3 Prefix Coordinator Prefix Coordinator Domäne C Layer 2 MAAS MAAS MAAS Layer 1 Client Client Client Client

61 Layer 1-3 Haben nichts mit den Schichten im ISO/OSI Modell zu tun!
Layer 1: Protokoll/Mechanismus um von einem multicast address allocation server (MAAS) eine multicast Adresse zugewiesen zu bekommen. Der Server ist dafür verantwortlich zu verhindern dass es zu Adresskonflikten kommt (soweit das möglich ist). Layer 2: Ein Protokoll/Mechanismus, mit dem die MAAS einer Domäne sich untereinander koordinieren und den Adressraum von Layer 3 Prefix Coordinators in Erfahrung bringen. Layer 3: Ein Protokoll/Mechanismus, mit dem multicast Adressbereiche (in Form von Präfixen) auf die verschiedenen Domänen aufgeteilt werden.

62 Schicht 1: Multicast Address Dynamic Client Allocation Protocol (MADCAP)
S. Hanna, B. Patel, M. Shah. Multicast Address Dynamic Client Allocation Protocol (MADCAP). RFC MADCAP dient der Kommunikation zwischen Client und MAAS. MADCAP basiert auf UDP, Zuverlässigkeit wird durch Übertragungswiederholung durch den Client erreicht. Dabei wird eine Nachricht vom Client dann wiederholt, wenn nach Ablauf eines gewissen Time-outs keine Antwort vom Server vorliegt. Damit ein Server MADCAP Operationen bei einer Übertragungswiederholung nicht mehrfach ausführt erhält jede Nachricht vom Client eine (für gewisse Zeit) eindeutige ID, ähnlich einer Sequenznummer. Diese ID wird bei Übertragungswiederholungen erneut verwendet.

63 MADCAP Ablauf - DISCOVER
Zunächst sendet der Client eine DISCOVER Nachricht. Diese Nachricht beschreibt die vom Client gewünschten Eigenschaften des angeforderten Adressbereiches: Start/Endzeitpunkt der Gültigkeit Anzahl der Adressen Scope und weitere .... Die DISCOVER Nachricht kann an eine spezielle multicast Adresse (scope domäne) geschickt werden, auf der alle MAAS lauschen. So kann ein Client einen initialen Server finden. Oder, wenn bereits ein Server bekannt ist, kann dieser direkt per unicast mit einer DISCOVER Nachricht kontaktiert werden.

64 MADCAP Ablauf - OFFER Wenn ein MAAS eine DISCOVER Nachricht empfängt und die Anfrage annehmen möchte (Politiken sind konfigurierbar), dann antwortet er mit einer OFFER. In der OFFER können die Eigenschaften der Adressen leicht verändert zu der Anfrage sein. Dies ist ein Aushandlungsprozess. Die OFFER wird per unicast an den Absender der DISCOVER Nachricht geschickt. Dazu sollte der MAAS die Adressen mit den entsprechenden Eigenschaften zur Verfügung haben und reservieren. Diese Reservierung sollte bestehen bleiben, bis der Client antwortet oder eine maximale Antwortzeit überschritten ist. Wenn der Server die Anfrage nicht annehmen möchte, so sendet er dem Client ein NAK.

65 MADCAP Ablauf: REQUEST
Hat ein Client eine oder mehrere OFFER Nachrichten erhalten, so wählt er einen der Server aus und schickt eine REQUEST Nachricht. Wurde die ursprüngliche DISCOVER Nachricht per multicast verschickt, so muss auch der REQUEST per multicast verschickt werden. So merken auch die Server, die eine OFFER geschickt haben, aber nicht ausgewählt wurden, dass der Client anderweitig bedient wird. Sonst wird die REQUEST Nachricht per unicast direkt an den MAAS geschickt.

66 MADCAP Ablauf: ACK/NAK
Empfängt ein MAAS einen REQUEST und kann die Reservierung durchführen, so tut er dies und antwortet mit einem ACK. Kann er die Reservierung nicht durchführen, so antwortet er mit einem NAK.

67 MADCAP – Ablauf: RENEW/RELEASE
Mit RENEW kann ein Client eine Adresse verlängern oder den Server um die Veränderung anderer Eigenschaften der Adresse bitten. Der Server antwortet mit ACK/NAK, je nachdem ob dies legitim ist oder nicht. Mit RELEASE kann ein Client Adressen explizit zurück geben. Adressen werden vom MAAS auch dann als zurückgegeben betrachtet, wenn ihre Gültigkeitsdauer abgelaufen ist, ohne dass sich der Client hierfür melden muss.

68 Layer 2: Multicast Address Allocation Protocol (AAP)
M. Handley, S. Hanna. Multicast Address Allocation Protocol (AAP). Internet Draft. Work-In-Progress Das AAP ist für die Koordination von MAAS und Prefix Coordinators zuständig: MAAS – MAAS: um innerhalb einer Domäne sicherzustellen, dass die Vergebenen multicast Adressen nicht kollidieren. MAAS – Prefix Coordinator: ist relevant für multicast Adressen, die einen Scope haben, welcher die Domäne verlässt. Für diese Art der Adressen teilen die Prefix Coordinators den MAAS mit, welche Adressen in dieser Domäne allokiert werden dürfen. AAP Nachrichten werden auf einer speziellen multicast Adresse verschickt, deren scope die Domäne ist. Alle MAAS und alle Prefix Coordinators empfangen die Daten, die an diese Adresse gesendet werden.

69 AAP: MAAS – MAAS Adresse anfordern mit Address Claim (ACLM):
Ein MAAS kann Adressen anfordern, indem er einen ACLM an die AAP multicast Adresse schickt. Dazu wählt er Adressen, von denen er annimmt, dass diese noch nicht belegt sind. Der MAAS wiederholt diese Anforderung 2 mal, wenn dann kein Wiederspruch von anderen MAAS erfolgt gilt die Adresse als allokiert.

70 AAP: MAAS – MAAS Belegte Adressen werden Angekündigt oder Verteidigt mit Address In Use (AIU): Ein MAAS kündigt mit AIU in regelmäßigen Abständen periodisch alle Adressen an, die über Ihn reserviert wurden. Alle MAAS merken sich die Ankündigungen aller anderen MAAS. Wenn ein MAAS versucht eine Adresse zu allokieren (z.B. mit ACLM), die belegt ist, dann antwort mindestens einer der MAAS die die bestehende Belegung kennen mit einem AIU: Alle MAAS, die antworten wollen, stellen einen zufälligen Timer. Der MAAS, bei dem der Timer zuerst abläuft, antwortet. Alle anderen MAAS, die auch antworten wollten, sehen dies und unterdrücken das Senden der AIU Nachricht.

71 AAP: MAAS - MAAS Ein MAAS kann Adressen im Voraus reservieren:
Dazu schickt ein MAAS ein Address Intention To Use (AITU) an die AAP multicast Adresse. Die anderen MAAS reagieren ähnlich wie auf ein ACLM. Bleibt die AITU Nachricht nach 2-facher Wiederholung unwidersprochen, so gelten die Adressen als reserviert. Der MAAS kündigt die reservierten Adressen regelmäßig an. Andere MAAS dürfen diese Adressen nur dann verwenden, wenn ihnen die Adressen ausgehen. In diesem Fall senden sie ein ACLM für die Adresse, der MAAS mit der Reservierung muss diese daraufhin zurückziehen. Wenn ein MAAS die reservierten Adressen tatsächlich an einen Client vergeben möchte, dann sendet er direkt einen AIU für diese Adressen. Reservierungen erlauben eine schnellere Antwort an Clients und ermöglichen es kurzzeitige Netzpartitionierungen besser zu überstehen.

72 AAP: MAAS – Prefix Coordinator
Ein Prefix Coordinator kommuniziert mit anderen Prefix Coordinators aus anderen Domänen und mit den MAAS der eigenen Domäne. Prefix Coordinatoren teilen den Adresseraum für Adressen auf, deren Scope die Domäne verlässt. Gegenüber den MAAS hat ein Prefix Coordinator zwei Aufgaben: Es muss die zur Verfügung stehenden Adressen bekannt geben. Es muss entsprechend der Auslastung des Adressraumes neue Adressen für die eigenen MAAS besorgen.

73 AAP: MAAS – Prefix Coordinator
Die Prefix Coordinators einer Domäne schicken regelmäßig sogenannte Address Space Announce (ASA) Nachrichten, die beschreiben, welche Domänen-übergreifenden Adressen in der Domäne zur Verfügung stehen. Ein MAAS reagiert darauf wie folgt: Wird der zur Verfügung stehende Adressraum vergrößert, dann gibt es neue Adressen, die vergeben werden können. Warten Clients gerade auf Adressen, so können diese nun bedient werden. Wird der Adressraum verkleinert, so muss geprüft werden ob bereits vergebene Adressen davon betroffen sind. Ist dies der Fall, so sollte der MAAS versuchen den Client zu benachrichtigen, damit dieser die Verwendung der Adresse einstellt. Dies sollte ein Ausnahmefall sein, da die Prefix Coordinatoren keine Adressen weggeben sollten, die gerade verwendet werden.

74 AAP: MAAS – Prefix Coordinator
MAAS senden Address Space Reports (ASRP) um den Prefix Coordinators einen Überblick über die Auslastung der Domänen-übergreifenden Adressen zu geben. Entsprechend dieser Reports können die Prefix Coordinators sich um weitere Adressen von anderen Domänen bemühen, oder Adressen an andere Domänen abgeben.

75 Schicht 3: Multicast Address-Set Claim (MASC)
P. Radoslavov, et. Al. The Multicast Address-Set Claim (MASC) Protocol. RFC MASC wird von MASC Nodes (Prefix Allocators, i.d.R. Router auf der Grenze von Domänen) verwendet um Adressbereiche anzufordern und zu allokieren. Ein Adressbereich wird durch einen Präfix gekennzeichnet. Wenn ein MASC Node einen Adressbereich erhalten hat, so wird dieser in dreifacher Weise verwendet: Adressen aus diesem Bereich werden von den MAAS in derselben Domäne an die Endsysteme verteilt. Adressen aus diesem Bereich können in unter-Bereiche zerlegt und an untergeordnete Domänen vergeben werden. Adressen in diesem Bereich haben diese Domäne als Wurzeldomäne für Exterior Gateway Multicast Routing nach BGMP.

76 MASC – Anforderungen/ Designentscheidungen
Effiziente Ausnutzung des Adressraumes. Dies bedeutet, dass die Allokation von Adressbereichen dynamisch, auf Basis des aktuellen Bedarfes vorgenommen werden muss. Die Präfixe der zugeordneten Adressbereiche sollte aggregierbar sein um BGMP zu unterstützen. Die Adresszuordnung sollte möglichst stabil sein. Der verwendete Mechanismus sollte robust gegen den Ausfall einzelner Systeme sein. Geschwindigkeit der Adresszuteilung ist keine Anforderung, da dies auf unteren Ebenen (MADCAP/AAP) geregelt werden kann.

77 MASC – Topologie R1 R2 N1a N1b N2a N2a C1 C2a C2b C3
R1/R2 zwei root Domains (vergleichbar mit TLAs) N1/N2 zwei Serviceprovider, Kunden von R1/R2 (vergleichbar mit NLA) C1/C2/C3 Endverwender von Adressen (vergleichbar mit Sites) Die MASC Nodes sind i.d.R. identisch mit den entsprechenden Grenzroutern für interdomain unicast/multicast routing.

78 MASC – Funktionsweise MASC Knoten sind untereinander mit TCP entsprechend der Topologie miteinander verbunden. Ein MASC Knoten kann also Verbindungen zu Partnerknoten auf der gleichen Ebene, zu Knoten auf einer höheren Ebene und zu Knoten auf einer untergeordneten Ebene haben. Ein MASC Knoten flutet regelmäßig Informationen über die Adressbereiche, die er allokiert hat (PREFIX_IN_USE).

79 MASC – Funktionsweise Möchte ein MASC Knoten für seine Domäne (bzw. für eine untergeordnete Domäne) Adresse beschaffen, so flutet er den Wunsch nach einem Adressbereich/Lebenszeit (NEW_CLAIM) an seine Partnerknoten auf der gleichen Ebene und an seinen Elternknoten. Wenn es zu keinen Konflikten kommt (kein Wiederspruch innerhalb einer gewissen Zeit), dann gilt der Adressbereich als allokiert und kann verwendet/an untergeordnete Domänen weitergegeben werden. Im Konfliktfall wird dieses Vorgehen mit einem neuen Adressbereich wiederholt. Analog dazu kann auch der bestehende Adressbereich vergrößert werden (CLAIM_TO_EXPAND).

80 Wer gewinnt bei Kollisionen?
Jede Anforderung hat Attribute, die die Rangfolge von Anforderungen eindeutig bestimmen: Typ: PREFIX_IN_USE (Der Adressraum wird bereits verwendet) CLAIM_TO_EXPAND (Der Adressraum wird erweitert) NEW_CLAIM Dies ist das erste Entscheidungskriterium Timestamp: der Zeitpunkt zu dem die Adressanforderung getätigt wurde. Hier gewinnt wer den kleineren Zeitstempel hat. Eindeutiger Identifier (z.B. IP Adresse) des MASC Knotens. Hier gewinnt wer den größeren Identifier hat.

81 Zusammenfassung Multicast Adressallokation
3 Schichten: Schicht 1: Kommunikation Endsystem-MAAS, Vergabe von Adressen an die Endanwendungen. Schicht 2: Kommunikation MAAS-MAAS und MAAS-Prefix Coordinator, Verwaltung von Adressen in einer Domäne. Schicht 3: Kommunikation Prefix Coordinator-Prefix Coordinator, Verwaltung von Adressebereichen (durch Präfixe bestimmt) zwischen den Domänen. Befindet sich im Experimentalstadium!

82 Zusammenfassung Multicast
Mechanismen in den Endsystemen und im LAN (IGMP) Interior Multicast Routing: DVMRP MOSPF PIM-SM Exterior Gateway Routing: MSDP BGMP Adressverwaltung und Allokation: SAP/SDP MADCAP/AAP/MASC