8. IP Multicast

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 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, 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 1112. 1989.
• IGMP wird ausschließlich zwischen Endsystemen und
  deren lokalen Router verwendet, nicht zum Routing
  im Inneren des Netzes.
• IGMP Membership Queries
• Werden von Routern an die all Hosts multicast
  Gruppe geschickt (224.0.0.1), dies ist eine
  Gruppe die niemals das lokale Netz verlässt.
• Sind eine Aufforderung an alle Endsysteme es
  sollen die multicast Adressen gemeldet werden,
  für die Empfänger im lokalen Netz vorhanden sind.

8
IGMPv1

• IGMP Membership Reports
• Als Antwort auf einen IGMP Membership Query
  generiert ein Endsystemen für jede multicast
  Adresse, an der sie interessiert ist, einen IGMP
  Membership Report. Diese wird ebenfalls an die
  all Hosts multicast Gruppe geschickt.
• Um eine Explosion von Membership Reports zu
  vermeiden werden diese nicht sofort gesandt,
  sondern um eine zufällige Zeitspanne verzögert.
  Wenn ein anderes Endsystem die gleiche Adresse
  früher nachfragt, dann sendet man nichts.
• Erhält ein Router für eine multicast Adresse
  wenigstens einen Report, dann leitet er Daten für
  diese multicast Adresse in das lokale Netz
  weiter.
• Erhält ein Router für eine multicast Adresse eine
  bestimmte Anzahl von Queries lang keinen Report,
  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. 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,
  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
From C to
Link
Cost
From A to
Link
Cost
From E to
Link
Cost
C
local
0
A
local
0
E
local
0
B
2
1
B
1
1
B
4
1
A
2
2
D
3
1
A
4
2
E
5
1
D
6
1
C
1
2
D
5
2
C
5
1
E
1
2
From B to
Link
Cost
From D to
Link
Cost
B
local
0
D
local
0
A
C
B
1
2
A
1
1
A
3
1
D
1
2
B
3
2
3
4
5
C
2
1
E
6
1
D
E
6
E
4
1
C
6
2
14
Multicast Routing Reverse-Path-Forwarding (RPF)

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

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

• RFP verbessert den Flooding Ansatz, es 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 RoutingReverse 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
From C to
Link
Cost
From A to
Link
Cost
From E to
Link
Cost
C
local
0
A
local
0
E
local
0
B
2
1
B
1
1
B
4
1
A
2
2
D
3
1
A
4
2
E
5
1
D
6
1
C
1
2
D
5
2
C
5
1
E
1
2
From B to
Link
Cost
From D to
Link
Cost
B
local
0
D
local
0
A
C
B
1
2
A
1
1
A
3
1
D
1
2
B
3
2
3
4
5
C
2
1
E
6
1
D
E
6
E
4
1
C
6
2
19
Multicast RoutingTruncated 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
C
B
1
2
A
C
B
1
2
3
4
5
3
4
TRPB Baum
D
E
6
D
E
Wenn in den lokalen Netzen von C, E und B keine
Empfänger sind
Prune
A
C
B
1
2
3
4
Prune
D
E
22
RPM

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

23
RPM Bewertung

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

24
Distance Vector Multicast Routing Protocol (DVMRP)

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

25
DVMRP Aufbau der Routing Tabelle

• Die Routing Tabelle wird analog zu RIP
  konstruiert, indem 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
• http//www-mm.informatik.uni-mannheim.de/veranstal
  tungen/animation/routing/ripdvmrp/

28
DVMRP - Bewertung

• DVMRP hat im wesentlichen die gleichen
  Eigenschaften wie RPM.

29
Multicast OSPF (MOSPF)

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

30
OSPF Wiederholung Datenbank
A
C
B
1
2
3
4
5
D
E
6
Karte/Datenbank
From
Link
Cost
From
From
Link
Cost
From
Number
Number
A
1
1
B
C
5
1
E
1
1
A
3
1
D
D
3
1
A
1
1
B
1
1
A
D
6
1
E
1
1
B
2
1
C
E
4
1
B
1
1
B
4
1
E
E
5
1
C
1
1
C
2
1
B
E
6
1
D
1
1
31
OSPF Wiederholung Lokale Berechnung der
Routing Tabelle
Achtung! Nun repräsentieren die Zahlen die
Distanz ( Verzögerung, Kosten, etc.) zwischen
zwei Knoten.
A
C
B
1
5
2
2
1
D
E
2
EA, B, D, E OA-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
EA OA-B-1, A-D-2
Achtung 2 Schritte!!! EA, B, C, D,
E OA-B-C-6 Kürzeste Pfade A-B-1, A-D-2,
A-B-E-3, A-B-E-C-4
EA, B OA-D-2, A-B-E-3, A-B-C-6 Kürzeste
Pfade A-B-1
EA, B, D OA-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
C
B
1
5
A
C
B
1
2
2
2
2
1
1
D
E
2
D
E
Kürzeste Pfade aus OSPF A-B-1, A-D-2, A-B-E-3,
A-B-E-C-4
Dann wird gepruned d.h. die Knoten, die keine
Lokalen Teilnehmer haben und die nicht zum
Weiterleiten im Baum benötigt werden, werden
entfernt A-B-1, A-D-2, A-B-E-3, A-B-E-C-4
34
MOSPF - Bewertung

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

35
Protocol Independent Multicast Sparse Mode
(PIM-SM)

• B. Fenner, M. Handley, H. Holbrook, I. Kouvelas.
  Protocol Independent Multicast Sparse Mode
  (PIM-SM) Protocol Specification (Revised),
  Internet Draft, 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
• 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
  Postscripthttp//www.aciri.org/mjh/mci.ps.gz

38
Weitere Ansätze zum Interior Gateway Multicast
Routing

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

39
Exterior Gateway Multicast Routing

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

40
Multicast Source Discovery Protocol (MSDP)

• D. Farinacci, et. Al. Multicast Source Discovery
  Protocol (MSDP), Internet Draft, 2000.
• MSDP ist ein Exterior Gateway Protocol für
  PIM-SM.
• MSDP verwendet für die Signalisierung eine
  Erweiterung von BGP (MBGP)T. Bates, et. Al.
  Multiprotocol Extensions for BGP-4, RFC 2858.
  2000.
• MBGP verallgemeinert BGP, so 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
Rendezvous Router
Rendezvous Router
Sender
Empfänger
Empfänger
Empfänger
PIM-SM Domäne
PIM-SM Domäne
43
MSDP Wie erfährt man die Präsenz von Sendern in
anderen Domänen?

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

44
Border Gateway Multicast Protocol (BGMP)

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

45
BGMP Prinzipielle Idee

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

46
BGMP - Beispiel

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

47
IP Multicast Scoping

• Es ist im allgemeinen nicht erwünscht, 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 AB
50
Administrative Scoping

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

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

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

54
SDP und SAP

• ... werden wiederum sehr schön im Foliensatz von
  Mark Handley beschrieben
• http//www.aciri.org/mjh/slides/mci/
• 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. 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!)

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

60
Internet Multicast AddressAllocation Architecture
Domäne A
Domäne B
Prefix Coordinator
Prefix Coordinator
Prefix Coordinator
Layer 3
Domäne C
Prefix Coordinator
Prefix Coordinator
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
  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.

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

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
N1b
N1a
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