8. ip multicast

Martin Mauve Universität Mannheim 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?


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.


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.


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!


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.


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)


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.


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.


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.


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.


„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


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.


Beispiel

From B to Link Cost

B local 0

A 1 1

D 1 2

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 3 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 2

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 1

D 3 1

From E to Link Cost

E local 0

B 4 1

A 4 2

D 6 1

C 5 1

C 1 2

E 1 2

C 6 2

A

D E

CB

3

6

1

4

2

5


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.


Beispiel

From B to Link Cost

B local 0

A 1 1

D 1 2

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 3 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 2

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 1

D 3 1

From E to Link Cost

E local 0

B 4 1

A 4 2

D 6 1

C 5 1

C 1 2

E 1 2

C 6 2

A

D E

CB

3

6

1

4

2

5


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.


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.


Beispiel

From B to Link Cost

B local 0

A 1 1

D 1 2

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 3 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 2

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 1

D 3 1

From E to Link Cost

E local 0

B 4 1

A 4 2

D 6 1

C 5 1

C 1 2

E 1 2

C 6 2

A

D E

CB

3

6

1

4

2

5


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.


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.


RPM – Pruning: Beispiel

A

D E

CB

3

6

1

4

2

5

A

D E

CB

3

1

4

2

TRPB Baum

Wenn in den lokalen Netzen von C, E und B keine Empfänger sind:

A

D E

CB

3

1

4

2

Prune

Prune


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.


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.


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.


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.


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.


DVMRP Beispiel

Als Java Applett:

http://www-mm.informatik.uni-mannheim.de/veranstaltungen/animation/routing/ripdvmrp/


DVMRP - Bewertung

DVMRP hat im wesentlichen die glichen Eigenschaften wie RPM.


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.


OSPF – Wiederholung: Datenbank

A

D E

CB

3

6

1

4

2

5

From Link Cost

A 1 1

A 3 1

B 1 1

B 2 1

B 4 1

From

B

D

A

C

E

C 2 1B

From Link Cost

C 5 1

D 3 1

D 6 1

E 4 1

E 5 1

From

E

A

E

B

C

E 6 1D

Karte/Datenbank:

Number

1

1

1

1

1

1

Number

1

1

1

1

1

1


OSPF – Wiederholung: Lokale Berechnung der Routing Tabelle

A

D E

CB

2

2

1

2

5

1

Achtung! Nun repräsentieren die Zahlendie „Distanz“ (= Verzögerung, Kosten, etc.)zwischen zwei Knoten.

E={A}O={A-B-1, A-D-2}

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}

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}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}

Dann noch 1 weiterer Schritt bis zum Ende!


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“).


MOSPF – Pruning

A

D E

CB

2

2

1

2

5

1

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 habenund 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}

A

D E

CB

2

1

2 1


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.


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.


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.


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


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.


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


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.


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.


MSDP – Beispiel

PIM-SM DomänePIM-SM Domäne

SenderEmpfänger Empfänger Empfänger

Rendezvous RouterRendezvous Router


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.


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.


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.


BGMP - Beispiel

Die Funktionsweise wird beschrieben in den Folien von Mark Handley:


Seiten 23-28


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


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


TTL Scoping Problem

Mit TTL-Scoping können nur ineinander liegende Regionen abgegrenzt werden. Die folgende Abgrenzung ist nicht möglich:

Scope AScope B

Scope A&B


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.


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, daß 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, daß ein Paket durch eine falsch konfigurierten Router weltweit verbreitet wird.


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 2974. 2000.

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: 224.2.127.254.

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.


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 2327. 1998.

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.


SDP und SAP

... werden wiederum sehr schön im Foliensatz von Mark Handley beschrieben:


Seiten 61-69


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.


Internet Multicast Address Allocation Architecture D. Thaler, M. Handley, D. Estrin. The Internet Multicast Address

Allocation Architecture. Internet Draft. Work-In-Progress. 2000. 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!)


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, daß 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.


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, daß ein Konflikt vorliegt (unter Umständen nicht so einfach, z.B. 2 Videokonferenzen mit denselben Tools).


Arten der Multicast Address Allocation

Static: statisch allokierte Adressen werden für bestimmte Zwecke vergeben. Beispiele sind 224.0.1.1 für NTP oder 224.2.127.254 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!


Internet Multicast AddressAllocation Architecture

Domäne A

Prefix Coordinator

Domäne B

Prefix Coordinator

Prefix Coordinator

Domäne CPrefix Coordinator

Prefix Coordinator

Layer 3

Layer 2

MAAS MAASMAAS

Client Client Client Client

Layer 1


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 daß 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.


Schicht 1: Multicast Address Dynamic Client Allocation Protocol (MADCAP) S. Hanna, B. Patel, M. Shah. Multicast Address Dynamic Client

Allocation Protocol (MADCAP). RFC 2730. 1999.

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.


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 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.


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.


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, daß der Client anderweitig bedient wird.

Sonst wird die REQUEST Nachricht per unicast direkt an den MAAS geschickt.


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.


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.


Layer 2: Multicast Address Allocation Protocol (AAP) M. Handley, S. Hanna. Multicast Address Allocation Protocol

(AAP). Internet Draft. Work-In-Progress. 2000.

Das AAP ist für die Koordination von MAAS und Prefix Coordinators zuständig:

MAAS – MAAS: um innerhalb einer Domäne sicherzustellen, daß 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.


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.


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 versuche 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.


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.


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.



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.



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.


Schicht 3: Multicast Address-Set Claim (MASC) P. Radoslavov, et. Al. The Multicast Address-Set Claim

(MASC) Protocol. RFC 2909. 2000. 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.


MASC – Anforderungen/ Designentscheidungen Effiziente Ausnutzung des Adressraumes. Dies

bedeutet, daß 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.


MASC – Topologie

R1 R2

N1bN1a N2aN2a

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.


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).


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 keine 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).


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.


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!


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

8. ip multicast

Documents