Nachdem in Teil 1 Multicast innerhalb eines Segments betrachtet wurde, schauen wir jetzt auf Multicast Routing.
Zuerst, welche Multicast Routingprotokolle gibt es? Es gibt veraltete und obsolote, aber auch vier aktuell benutzte. Veraltet und obsolet sind: Distance Vector Multicast Routing Protocol (DVMRP), Multicast OSPF (MOSPF) und Core-Based Trees (CBT).
Aktuelle Multicast Routingprotkolle:
– Protocol Independent Multicast, Dense Mode (PIM-DM)
– Protocol Independent Multicast, Sparse Mode (PIM-SM)
– Protocol Independent Multicast, Source-Specific Multicast (PIM-SSM)
– Bidirectional Protocol Independent Multicast (Bidir-PIM)
PIM-SSM und BiDir-PIM stammen von PIM-SM ab, aber werden oft als eigene Protokolle angesehen.
Wie funktioniert Multicast Forwarding? Unicast Forwarding kennen wir schon, der Router checkt seine Routingtabelle für den besten Weg: Zieladresse aus dem Paket ermitteln, Longest-Match-Route suchen und Paket am richtigen Interface senden. Die Quelle spielt dabei für den Router keine Rolle, er leitet das Paket an das für ihn richtige Interface weiter.
Multicast Forwarding ist allerdings etwas anders, zu erst muss der Router das Paket nicht nur einmal weiterleiten sondern vielleicht mehrmals, da an mehreren Interfaces Empfänger dieser Gruppe vorhanden sind. Außerdem achtet der Router darauf, wo sich die Source befindet, denn zur Source darf er nicht weiterleiten.
Was würde passieren wenn ein Router ein Multicast Paket auch an das Source Interface weiterleiten würde (oder anderweitig ein Routing Loop ist)? Mit hoher Wahrscheinlichkeit ein Multicast Storm. Ein Multicast Storm unterscheided sich von einem „normalen“ Loop im Netzwerk dahingehend, dass die Pakete vervielfältigt werden. Denn bei jedem Router können sie ja wieder mehrfach repliziert werden und werden erneut auf den Weg gebracht. Das belastet die Endsysteme und besonders die Router. Die Pakete Loopen bis ihre TTL erschöpft ist. Damit diese Loops nicht passieren können, müssen alle Multicast Router immer die Source kennen.
Dabei gibt es die Terminologie von Upstream und Downstream. Dabei sollten Multicast Pakete immer Downstream fließen, von der Quelle weg. Aber woher weiß der Router jetzt wo die Quelle ist und wie weiß er welche Interface Upstream und Downstream sind? Dafür sorgt das Multicast Routingprotokoll.
Multicast Routing
Zuerst eine Wiederholung von Unicast Routing. Bei Unicast Routing sorgen die Routingprotkolle dafür, den besten Weg zum Ziel zu finden. Damit kennt der Router sein Ausgangsinterface und kann Pakete zum Ziel effektiv weiterleiten.
Multicast Routingprotokolle berechnen, im Gegensatz zu Unicast Routingprotokollen, den Weg zur Source und bestimmen damit das Upstream Interface, also den kürzestes Weg zur Source. Das heißt, der Router kennt den Weg zur Quelle, statt dem kürzesten Weg zum Ziel. Daher heißt das auch Reverse Path Forwarding (RPF).
Wie berechnet der Router nun den Weg zur Source? Der einfachste Weg wäre, die Unicast Routingtabelle zu checken, darin sind alle Wege zu allen erreichbaren Zielen des Routers zu finden. Aber Multicast Routen nutzen ihre eigene Routingabelle, denn sie müssen ja nicht nur wissen welches das Upstream Interface ist, sondern auch welche Source (S) zu welcher Gruppe (G) gehört um die (S,G) Routingeinträge erzeugen zu können.
Wir müssen also, um die Multicast Routingtabelle füllen zu können, erst wissen wo die Ziele der Multicast Gruppe sind. Wer nimmt an der Gruppe Teil? Die Receiver/Empfänger haben sich per IGMP am Router gemeldet (mit der Report Message) und der Router verteilt die Info per PIM weiter. So kann nun jeder Router sein Upstream Interface (Richtung Quelle) und seine Downstream Interfaces (Richtung Empfänger) definieren. Mit diesen Infos kann der Router nun seine Multicast Routingtabelle füllen.
Nachdem alle Router ihre Multicast Routingtabellen gefüllt haben, entsteht der so genannte Multicast Tree. Ausgehend von der Source zu allen Receivern sind jetzt alle Multicast Wege bekannt. Ähnlich wie bei einem Baum der sich beginnend von der Wurzel und dem Stamm in viele Äste verteilt.
Der Multicast Tree ist allerdings dynamisch, er verändert sich laufend weil immer neue Empfänger dazu kommen können oder andere den Multicast Stream verlassen. Wenn ein Empfänger den Stream verlässt, wird durch das Multicast Routingprotokoll diese Info weitergeleitet und, falls sonst keiner mehr teilnimmt, dieser „Ast“ des Multicast Trees beendet (Pruned) und keine Pakete mehr dorthin weitergeleitet. Genauso wenn ein Teilnehmer beginnt dem Stream zu folgen (Join), wird Multicast auf dieser Verbindung weitergeleitet. Außerdem hat der Baum nur bestand solange die Multicast Session läuft. Für jede Session wird ein neuer Baum erzeugt.
Implicit Joins vs. Explicit Joins
Damit Router über vorhandene bzw. neue Multicast Teilnehmer informiert werden können, muss es eine Möglichkeit geben den Join mitzuteilen. Hierbei gibt es zwei Ansätze.
PIM-Dense Mode (PIM-DM) nutzt hierbei den Implicit Join. Das funktioniert so, dass es ein Flooding bzw. Broadcasting an alle Multicast Router gibt und diese den Stream dann annehmen oder wieder Prunen, wenn sie nicht teilnehmen müssen (da kein Teilnehmer da ist). Jeder Upstream Nachbarrouter hält den Status für seine Interfaces, entweder Forwarding oder Pruned. Die Pruned-Interfaces haben einen Timer, wenn dieser Timer abläuft, wird wieder Traffic weitergeleitet und, erneut, wird geprüft ob der Nachbar diesen Multicast Stream benötigt oder er wird wieder gepruned. Durch diesen Ansatz, und des recht vielen unnötigen Traffics, ist PIM-DM besser in Dense (dicht, kompakt, eng gepackt) Netzwerken geeignet. Also mit vielen Multicast Teilnehmern.
PIM-Sparse Mode (PIM-SM) nutzt den Explicit Join. Hierbei nimmt ein Router selbstständig am Multicast Tree teil indem er, nachdem er per IGMP einen Join erhalten hat, sich beim Upstream Router via PIM meldet und er dem Stream hinzugefügt wird. Wenn alle Teilnehmer hinter diesem neuen Router den Stream verlassen, pruned er sich selbst vom Stream und verlässt ihn so wieder. Explicit Joins benötigen deutlich weniger Overhead und Traffic als Implicit Joins und sind so besser geeignet für Umgebungen mit weniger Multicast Teilnehmern. PIM-SM ist heute als der Standard anzusehen. Hierbei sind „wenig Teilnehmer“ als Beispiel 2000 von 100000 Devices (2%). Es heißt also nicht, dass Sparse-Mode nur in kleinen Netzen oder mit sehr wenig Teilnehmern eingesetzt wird. Es kommt immer auf das Verhältnis der Teilnehmer und Nicht-Teilnehmer an. Aber wahrscheinlich ist in 99% der Firmen/Infrastrukturen wenig Teilnehmer im Multicast und somit ist PIM-SM das Protokoll der Wahl.