Kein Folientitel - pi4

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?
Martin Mauve
Universität Mannheim
1
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.
Martin Mauve
Universität Mannheim
2
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.
Martin Mauve
Universität Mannheim
3
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!
Martin Mauve
Universität Mannheim
4
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.
Martin Mauve
Universität Mannheim
5
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)
Martin Mauve
Universität Mannheim
6
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.
Martin Mauve
Universität Mannheim
7
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.
Martin Mauve
Universität Mannheim
8
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.
Martin Mauve
Universität Mannheim
9
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.
Martin Mauve
Universität Mannheim
10
„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:





Martin Mauve
DVMRP
MOSPF
PIM-SM
PIM-DM
CBT
Universität Mannheim
11
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.
Martin Mauve
Universität Mannheim
12
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
1
1
A
3
1
D
1
2
B
3
2
C
2
1
E
6
1
E
4
1
C
6
2
Martin Mauve
Universität Mannheim
A
1
3
D
6
B
2
4
5
C
E
13
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.
Martin Mauve
Universität Mannheim
14
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
1
1
A
3
1
D
1
2
B
3
2
C
2
1
E
6
1
E
4
1
C
6
2
Martin Mauve
Universität Mannheim
A
1
3
D
6
B
2
4
5
C
E
15
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.
Martin Mauve
Universität Mannheim
16
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 PoisonReverse: 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.
Martin Mauve
Universität Mannheim
17
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
1
1
A
3
1
D
1
2
B
3
2
C
2
1
E
6
1
E
4
1
C
6
2
Martin Mauve
Universität Mannheim
A
1
3
D
6
B
2
4
5
C
E
18
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.
Martin Mauve
Universität Mannheim
19
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.
Martin Mauve
Universität Mannheim
20
RPM – Pruning: Beispiel
A
1
3
D
6
B
2
4
5
C
A
1
B
3
4
D
E
2
C
TRPB Baum
E
Wenn in den lokalen Netzen von C, E und B keine Empfänger sind:
Prune
A
Martin Mauve
B
2
3
4
Prune
D
E
1
C
Universität Mannheim
21
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.
Martin Mauve
Universität Mannheim
22
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.
Martin Mauve
Universität Mannheim
23
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.
Martin Mauve
Universität Mannheim
24
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.
Martin Mauve
Universität Mannheim
25
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.
Martin Mauve
Universität Mannheim
26
DVMRP Beispiel

Als Java Applett:
http://www-mm.informatik.uni-mannheim.de/veranstaltungen/animation/routing/ripdvmrp/
Martin Mauve
Universität Mannheim
27
DVMRP - Bewertung

Martin Mauve
DVMRP hat im wesentlichen die glichen
Eigenschaften wie RPM.
Universität Mannheim
28
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.
Martin Mauve
Universität Mannheim
29
OSPF – Wiederholung: Datenbank
A
1
3
D
6
B
2
4
5
C
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
Martin Mauve
Universität Mannheim
30
OSPF – Wiederholung:
Lokale Berechnung der Routing Tabelle
A
1
2
D
2
B
5
2
1
C
E
Achtung! Nun repräsentieren die Zahlen
die „Distanz“ (= Verzögerung, Kosten, etc.)
zwischen zwei Knoten.
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}
E={A, B}
O={A-D-2, A-B-E-3, A-B-C-6}
Kürzeste Pfade: {A-B-1}
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, 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!
Martin Mauve
Universität Mannheim
31
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“).
Martin Mauve
Universität Mannheim
32
MOSPF – Pruning
A
1
2
D
2
B
5
2
1
C
E
A
1
B
2
2
D
E
C
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 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}
Martin Mauve
Universität Mannheim
33
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.
Martin Mauve
Universität Mannheim
34
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.
Martin Mauve
Universität Mannheim
35
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.
Martin Mauve
Universität Mannheim
36
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
Martin Mauve
Universität Mannheim
37
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 PIMSM) 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.
Martin Mauve
Universität Mannheim
38
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.

Martin Mauve
Daher gibt es analog zu BGP auch Exterior Gateway Protocols
für Multicast
Universität Mannheim
39
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.
Martin Mauve
Universität Mannheim
40
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.
Martin Mauve
Universität Mannheim
41
MSDP – Beispiel
Rendezvous Router
Empfänger
Empfänger
Rendezvous Router
Empfänger
PIM-SM Domäne
Martin Mauve
Sender
PIM-SM Domäne
Universität Mannheim
42
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.
Martin Mauve
Universität Mannheim
43
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.
Martin Mauve
Universität Mannheim
44
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.
Martin Mauve
Universität Mannheim
45
BGMP - Beispiel

Die Funktionsweise wird beschrieben in den Folien
von Mark Handley:

http://www.aciri.org/mjh/slides/mci/

Seiten 23-28
Martin Mauve
Universität Mannheim
46
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
Martin Mauve
Universität Mannheim
47
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
Martin Mauve
Universität Mannheim
48
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
Martin Mauve
Universität Mannheim
49
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.
Martin Mauve
Universität Mannheim
50
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.
Martin Mauve
Universität Mannheim
51
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.
Martin Mauve
Universität Mannheim
52
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.
Martin Mauve
Universität Mannheim
53
SDP und SAP

... werden wiederum sehr schön im Foliensatz von
Mark Handley beschrieben:

http://www.aciri.org/mjh/slides/mci/

Seiten 61-69
Martin Mauve
Universität Mannheim
54
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.
Martin Mauve
Universität Mannheim
55
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!)
Martin Mauve
Universität Mannheim
56
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.
Martin Mauve
Universität Mannheim
57
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).
Martin Mauve
Universität Mannheim
58
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!
Martin Mauve
Universität Mannheim
59
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
Martin Mauve
Client
Client
Universität Mannheim
Client
60
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.
Martin Mauve
Universität Mannheim
61
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.
Martin Mauve
Universität Mannheim
62
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.
Martin Mauve
Universität Mannheim
63
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.
Martin Mauve
Universität Mannheim
64
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.
Martin Mauve
Universität Mannheim
65
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.
Martin Mauve
Universität Mannheim
66
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.
Martin Mauve
Universität Mannheim
67
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.

Martin Mauve
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.
Universität Mannheim
68
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.
Martin Mauve
Universität Mannheim
69
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.
Martin Mauve
Universität Mannheim
70
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.

Martin Mauve
Reservierungen erlauben eine schnellere Antwort an Clients
und ermöglichen es kurzzeitige Netzpartitionierungen besser zu
überstehen.
Universität Mannheim
71
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.
Martin Mauve
Universität Mannheim
72
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.
Martin Mauve
Universität Mannheim
73
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.
Martin Mauve
Universität Mannheim
74
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.
Martin Mauve
Universität Mannheim
75
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.
Martin Mauve
Universität Mannheim
76
MASC – Topologie
N1a
C1
R1
R2
N1b
N2a
C2a
C2b
N2a
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.
Martin Mauve
Universität Mannheim
77
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).
Martin Mauve
Universität Mannheim
78
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).
Martin Mauve
Universität Mannheim
79
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.
Martin Mauve
Universität Mannheim
80
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.

Martin Mauve
Befindet sich im Experimentalstadium!
Universität Mannheim
81
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
Martin Mauve
Universität Mannheim
82