12. Multicast-Betrieb

Dieser Abschnitt beschreibt einen Multicast-Routing-Betrieb über ein IPv6-RPL-Netzwerk und insbesondere, wie Unicast-DAOs verwendet werden können, um Gruppenregistrierungen weiterzuleiten. Dasselbe DODAG-Konstrukt kann verwendet werden, um Unicast- und Multicast-Verkehr weiterzuleiten. Dieser Abschnitt beschränkt sich auf eine Beschreibung, wie Gruppenregistrierungen ausgetauscht werden können und wie die Weiterleitungsinfrastruktur funktioniert. Er bietet keine vollständige Beschreibung von Multicast innerhalb eines LLN und beschreibt insbesondere nicht die Generierung von DODAGs, die speziell auf Multicast ausgerichtet sind, oder die Details des Betriebs von RPL für Multicast -- das wird Gegenstand weiterer Spezifikationen sein.

Die Multicast-Gruppenregistrierung verwendet DAO-Nachrichten, die identisch mit Unicast sind, außer für den Typ der Adresse, die transportiert wird. Der Hauptunterschied besteht darin, dass der nach unten gehende Multicast-Verkehr an alle Kinder kopiert wird, die sich bei der Multicast-Gruppe registriert haben, während Unicast-Verkehr nur an ein Kind weitergegeben wird.

Knoten, die den RPL-Storing-Betriebsmodus unterstützen, SOLLTEN auch Multicast-DAO-Operationen unterstützen, wie unten beschrieben. Von Knoten, die nur den Non-Storing-Betriebsmodus unterstützen, wird nicht erwartet, dass sie diesen Abschnitt unterstützen.

Der Multicast-Betrieb wird durch das MOP-Feld im DIO gesteuert.

Wenn das MOP-Feld Multicast-Unterstützung erfordert, dann muss ein Knoten, der dem RPL-Netzwerk als Router beitritt, wie in diesem Abschnitt beschrieben für Multicast-Signalisierung und -Weiterleitung innerhalb des RPL-Netzwerks arbeiten. Ein Knoten, der den durch das MOP-Feld geforderten Multicast-Betrieb nicht unterstützt, kann nur als Blatt beitreten.
Wenn das MOP-Feld keine Multicast-Unterstützung erfordert, dann wird Multicast auf eine andere Weise behandelt, die außerhalb des Geltungsbereichs dieser Spezifikation liegt. (Beispiele können eine Reihe von Unicast-Kopien oder Flooding mit begrenztem Umfang sein).

Ein Router könnte wählen, eine Listener-Registrierungs-DAO-Nachricht nur an seinen bevorzugten Elternteil weiterzugeben; in diesem Fall könnten zurückkommende Multicast-Pakete für alle seine Sub-DODAGs verloren gehen, wenn die Übertragung über diesen Link fehlschlägt. Alternativ könnte der Router wählen, zusätzliche Eltern zu kopieren, wie er es für DAO-Nachrichten tun würde, die Unicast-Ziele ankündigen; in diesem Fall könnte es Duplikate geben, die der Router bereinigen muss.

Als Ergebnis werden Multicast-Routing-Zustände in jedem Router auf dem Weg von den Listenern zur DODAG-Wurzel installiert, was es der Wurzel ermöglicht, ein Multicast-Paket an alle ihre Kinder-Router zu kopieren, die eine DAO-Nachricht einschließlich einer Target-Option für diese Multicast-Gruppe ausgegeben hatten.

Für ein Multicast-Paket, das von innerhalb des DODAG stammt, wird das Paket an die bevorzugten Eltern weitergegeben, und wenn das fehlschlägt, dann an die Alternativen im DODAG. Das Paket wird auch an alle registrierten Kinder kopiert, außer an dasjenige, das das Paket übergeben hat. Schließlich, wenn es einen Listener in der externen Infrastruktur gibt, dann muss die DODAG-Wurzel das Paket weiter in die externe Infrastruktur propagieren.

Als Ergebnis agiert die DODAG-Wurzel als automatischer Proxy-Rendezvous-Point für das RPL-Netzwerk und als Quelle zum Nicht-RPL-Bereich für alle im RPL-Bereich gestarteten Multicast-Flüsse. Also, unabhängig davon, ob die Wurzel tatsächlich an einen Nicht-RPL-Bereich angeschlossen ist, und unabhängig davon, ob der DODAG geerdet oder schwebend ist, kann die Wurzel jederzeit innere Multicast-Streams bedienen.