9. Abwärts-Routen

Dieser Abschnitt beschreibt, wie RPL Abwärts-Routen (Downward Routes) entdeckt und wartet. RPL konstruiert und wartet Abwärts-Routen mit Destination Advertisement Object (DAO)-Nachrichten. Abwärts-Routen unterstützen P2MP-Flüsse, von den DODAG-Wurzeln zu den Blättern. Abwärts-Routen unterstützen auch P2P-Flüsse: P2P-Nachrichten können über eine Aufwärts-Route zu einer DODAG-Wurzel (oder einem gemeinsamen Vorfahren) fließen und dann von der DODAG-Wurzel über eine Abwärts-Route zu einem Ziel.

Diese Spezifikation beschreibt die zwei Modi, aus denen eine RPL-Instanz für die Wartung von Abwärts-Routen wählen kann. Im ersten Modus, genannt "Storing" (Speichernd), speichern Knoten Abwärts-Routing-Tabellen für ihren Sub-DODAG. Jeder Hop auf einer Abwärts-Route in einem speichernden Netzwerk prüft seine Routing-Tabelle, um über den nächsten Hop zu entscheiden. Im zweiten Modus, genannt "Non-Storing" (Nicht-Speichernd), speichern Knoten keine Abwärts-Routing-Tabellen. Abwärts-Pakete werden mit Quell-Routen geroutet, die von einer DODAG-Wurzel befüllt werden [RFC6554].

RPL ermöglicht eine einfache Ein-Hop-P2P-Optimierung sowohl für speichernde als auch für nicht-speichernde Netzwerke. Ein Knoten kann ein P2P-Paket, das für einen Ein-Hop-Nachbarn bestimmt ist, direkt an diesen Knoten senden.

9.1. Destination Advertisement Parents

Um Abwärts-Routen zu etablieren, senden RPL-Knoten DAO-Nachrichten aufwärts. Die Next-Hop-Ziele dieser DAO-Nachrichten werden "DAO Parents" genannt. Die Sammlung der DAO-Parents eines Knotens wird als "DAO Parent Set" bezeichnet.

1. Ein Knoten KANN DAO-Nachrichten unter Verwendung der All-RPL-Nodes-Multicast-Adresse senden, was eine Optimierung zur Bereitstellung von Ein-Hop-Routing ist. Das 'K'-Bit MUSS bei der Übertragung des Multicast-DAO gelöscht sein.

2. Das DAO-Parent-Set eines Knotens MUSS eine Teilmenge seines DODAG-Parent-Sets sein.

3. Im Storing-Modus-Betrieb DARF ein Knoten Unicast-DAO-Nachrichten NICHT an Knoten adressieren, die keine DAO-Parents sind.

4. Im Storing-Modus-Betrieb MÜSSEN die IPv6-Quell- und Zieladressen einer DAO-Nachricht Link-Local-Adressen sein.

5. Im Non-Storing-Modus-Betrieb DARF ein Knoten Unicast-DAO-Nachrichten NICHT an Knoten adressieren, die keine DODAG-Wurzeln sind.

6. Im Non-Storing-Modus-Betrieb MÜSSEN die IPv6-Quell- und Zieladressen einer DAO-Nachricht eine Unique-Local- oder eine globale Adresse sein.

Die Auswahl von DAO-Parents ist implementierungs- und Zielfunktions-spezifisch.

9.2. Entdeckung und Wartung von Abwärts-Routen

Destination Advertisement kann so konfiguriert werden, dass es vollständig deaktiviert ist oder entweder in einem Storing- oder Non-Storing-Modus arbeitet, wie im MOP in der DIO-Nachricht gemeldet.

1. Alle Knoten, die einem DODAG beitreten, MÜSSEN sich an die MOP-Einstellung der Wurzel halten. Knoten, die nicht die Fähigkeit haben, vollständig als Router teilzunehmen, z.B. die nicht dem angekündigten MOP entsprechen, KÖNNEN dem DODAG als Blatt beitreten.

2. Wenn der MOP 0 ist, was kein Abwärts-Routing anzeigt, DÜRFEN Knoten KEINE DAO-Nachrichten senden und KÖNNEN DAO-Nachrichten ignorieren.

3. Im Non-Storing-Modus SOLLTE die DODAG-Wurzel Quell-Routing-Tabelleneinträge für Ziele speichern, die von DAOs gelernt wurden. Die DODAG-Wurzel MUSS in der Lage sein, Quell-Routen für jene Ziele zu generieren, die von DAOs gelernt wurden, die gespeichert wurden.

4. Im Storing-Modus MÜSSEN alle Nicht-Wurzel-, Nicht-Blatt-Knoten Routing-Tabelleneinträge für Ziele speichern, die von DAOs gelernt wurden.

Ein DODAG kann einen von mehreren möglichen Betriebsmodi haben, wie durch das MOP-Feld definiert. Entweder unterstützt er keine Abwärts-Routen, er unterstützt Abwärts-Routen durch Quell-Routing von DODAG-Wurzeln, oder er unterstützt Abwärts-Routen durch netzwerkinterne Routing-Tabellen.

Wenn Abwärts-Routen durch Quell-Routing von DODAG-Wurzeln unterstützt werden, wird allgemein erwartet, dass die DODAG-Wurzel die Quell-Routing-Informationen, die von DAOs gelernt wurden, gespeichert hat, um die Quell-Routen zu konstruieren. Wenn die DODAG-Wurzel es versäumt, einige Informationen zu speichern, können einige Ziele unerreichbar sein.

Wenn Abwärts-Routen durch netzwerkinterne Routing-Tabellen unterstützt werden, kann der in dieser Spezifikation definierte Multicast-Betrieb unterstützt werden oder nicht, ebenfalls wie durch das MOP-Feld angezeigt.

Wenn Abwärts-Routen durch netzwerkinterne Routing-Tabellen unterstützt werden, wie in dieser Spezifikation beschrieben, wird erwartet, dass Knoten, die als Router agieren, ausreichend provisioniert wurden, um den erforderlichen Routing-Tabellen-Status zu halten. Wenn ein Knoten, der als Router agiert, nicht in der Lage ist, den vollen Routing-Tabellen-Status zu halten, dann ist der Routing-Status nicht vollständig, Nachrichten können als Folge verworfen werden, und ein Fehler kann protokolliert werden (Abschnitt 18.5). Zukünftige Erweiterungen zu RPL können verfeinerte Aktionen/Verhalten ausarbeiten, um diesen Fall zu verwalten.

Zum Zeitpunkt des Schreibens dieser Spezifikation unterstützt RPL keinen gemischten Betriebsmodus, bei dem einige Knoten Quell-Routen verwenden und andere Routing-Tabellen speichern: zukünftige Erweiterungen zu RPL können diesen Betriebsmodus unterstützen.

9.2.1. Wartung der Pfad-Sequenz

Für jedes Ziel (Target), das mit einem Knoten assoziiert ist (diesem gehört), ist dieser Knoten verantwortlich, DAO-Nachrichten zu emittieren, um die Abwärts-Routen bereitzustellen. Die Target+Transit-Informationen, die in diesen DAO-Nachrichten enthalten sind, propagieren anschließend den DODAG hinauf. Der Pfad-Sequenz-Zähler (Path Sequence counter) in der Transit-Information-Option wird verwendet, um Frische anzuzeigen und veraltete Abwärts-Routing-Informationen zu aktualisieren, wie in Abschnitt 7 beschrieben.

Für ein Ziel, das mit einem Knoten assoziiert ist (diesem gehört), MUSS dieser Knoten den Pfad-Sequenz-Zähler erhöhen und eine neue DAO-Nachricht generieren, wenn:

1. die Pfad-Lebensdauer aktualisiert werden soll (z.B. eine Auffrischung oder ein No-Path).

2. die DODAG-Parent-Address-Subfeld-Liste geändert werden soll.

Für ein Ziel, das mit einem Knoten assoziiert ist (diesem gehört), KANN dieser Knoten den Pfad-Sequenz-Zähler gelegentlich erhöhen und eine neue DAO-Nachricht generieren, um die Abwärts-Routing-Informationen aufzufrischen. Im Storing-Modus generiert der Knoten ein solches DAO an jeden seiner DAO-Parents, um Multipath zu ermöglichen. Alle DAOs, die zur gleichen Zeit für dasselbe Ziel generiert werden, MÜSSEN mit derselben Pfad-Sequenz in der Transit-Information gesendet werden.

9.2.2. Generierung von DAO-Nachrichten

Ein Knoten könnte DAO-Nachrichten senden, wenn er DAO-Nachrichten empfängt, als Ergebnis von Änderungen in seinem DAO-Parent-Set, oder als Reaktion auf ein anderes Ereignis wie den Ablauf einer zugehörigen Präfix-Lebensdauer. Im Falle des Empfangs von DAOs spielt es eine Rolle, ob die DAO-Nachricht "neu" ist oder neue Informationen enthält. Im Non-Storing-Modus ist jede DAO-Nachricht, die ein Knoten empfängt, "neu". Im Storing-Modus ist eine DAO-Nachricht "neu", wenn sie eines dieser Kriterien für ein enthaltenes Ziel erfüllt:

1. sie hat eine neuere Pfad-Sequenznummer,

2. sie hat zusätzliche Pfad-Kontroll-Bits, oder

3. es ist eine No-Path-DAO-Nachricht, die die letzte Abwärts-Route zu einem Präfix entfernt.

Ein Knoten, der eine DAO-Nachricht von seinem Sub-DODAG empfängt, KANN die Planung einer DAO-Nachrichtenübertragung unterdrücken, wenn diese DAO-Nachricht nicht neu ist.

9.3. DAO-Basisregeln

1. Wenn ein Knoten eine DAO-Nachricht mit neueren oder anderen Informationen als die vorherige DAO-Nachrichtenübertragung sendet, MUSS er das DAOSequence-Feld um mindestens eins erhöhen. Eine DAO-Nachrichtenübertragung, die identisch mit der vorherigen DAO-Nachrichtenübertragung ist, KANN das DAOSequence-Feld erhöhen.

2. Die RPLInstanceID- und DODAGID-Felder einer DAO-Nachricht MÜSSEN denselben Wert haben wie die Mitglieder des Parent-Sets des Knotens und die DIOs, die er überträgt.

3. Ein Knoten KANN das 'K'-Flag in einer Unicast-DAO-Nachricht setzen, um ein Unicast-DAO-ACK als Antwort anzufordern, um den Versuch zu bestätigen.

4. Ein Knoten, der eine Unicast-DAO-Nachricht mit gesetztem 'K'-Flag empfängt, SOLLTE mit einem DAO-ACK antworten. Ein Knoten, der eine DAO-Nachricht ohne gesetztes 'K'-Flag empfängt, KANN mit einem DAO-ACK antworten, insbesondere um einen Fehlerzustand zu melden.

5. Ein Knoten, der das 'K'-Flag in einer Unicast-DAO-Nachricht setzt, aber kein DAO-ACK als Antwort erhält, KANN die DAO-Nachrichtenübertragung für einen weiteren Versuch neu planen, bis zu einer implementierungsspezifischen Anzahl von Wiederholungen.

6. Knoten SOLLTEN DAOs ohne neuere Sequenznummern ignorieren und DÜRFEN sie NICHT weiterverarbeiten.

Im Gegensatz zum Versionsfeld eines DIO, das nur von einer DODAG-Wurzel erhöht und von anderen Knoten unverändert wiederholt wird, sind DAOSequence-Werte für jeden Knoten eindeutig. Der Sequenznummernraum für Unicast- und Multicast-DAO-Nachrichten kann entweder derselbe oder unterschiedlich sein. Es wird EMPFOHLEN, denselben Sequenznummernraum zu verwenden.

9.4. Struktur von DAO-Nachrichten

DAOs folgen einer gemeinsamen Struktur sowohl in speichernden als auch in nicht-speichernden Netzwerken. In der allgemeinsten Form kann eine DAO-Nachricht mehrere Gruppen von Optionen enthalten, wobei jede Gruppe aus einer oder mehreren Target-Optionen besteht, gefolgt von einer oder mehreren Transit-Information-Optionen.

Die gesamte Gruppe von Transit-Information-Optionen gilt für die gesamte Gruppe von Target-Optionen. Spätere Abschnitte beschreiben weitere Details für jeden Betriebsmodus.

1. RPL-Knoten MÜSSEN eine oder mehrere RPL-Target-Optionen in jede DAO-Nachricht aufnehmen, die sie übertragen. Eine RPL-Target-Option MUSS ein Präfix haben, das die IPv6-Adresse des Knotens einschließt, wenn dieser Knoten benötigt, dass der DODAG Abwärts-Routen zu diesem Knoten bereitstellt. Der RPL-Target-Option KANN unmittelbar eine opake RPL-Target-Descriptor-Option folgen, die sie qualifiziert.

2. Wenn ein Knoten die Informationen in einer Transit-Information-Option für eine Target-Option aktualisiert, die eine seiner Adressen abdeckt, MUSS er die Pfad-Sequenznummer in dieser Transit-Information-Option erhöhen. Die Pfad-Sequenznummer KANN gelegentlich erhöht werden, um eine Auffrischung der Abwärts-Routen zu bewirken.

3. Einer oder mehreren RPL-Target-Optionen in einer Unicast-DAO-Nachricht MÜSSEN eine oder mehrere Transit-Information-Optionen folgen. Alle Transit-Optionen gelten für alle Target-Optionen, die ihnen unmittelbar vorausgehen.

4. Multicast-DAOs DÜRFEN NICHT das DODAG-Parent-Address-Subfeld in Transit-Information-Optionen enthalten.

5. Ein Knoten, der eine DAO-Nachricht empfängt und verarbeitet, die Informationen für ein bestimmtes Ziel enthält, und der vorherige Informationen für dieses Ziel hat, MUSS die Pfad-Sequenznummer in der Transit-Information-Option, die mit diesem Ziel assoziiert ist, verwenden, um zu bestimmen, ob die DAO-Nachricht aktualisierte Informationen enthält oder nicht, gemäß Abschnitt 7.

6. Wenn ein Knoten eine DAO-Nachricht empfängt, die den obigen Regeln nicht folgt, MUSS er die DAO-Nachricht ohne weitere Verarbeitung verwerfen.

Im Non-Storing-Modus baut die Wurzel einen strikten Quell-Routing-Header auf, Hop-by-Hop, indem sie rekursiv Ein-Hop-Informationen nachschlägt, die ein Ziel (Adresse oder Präfix) und eine Transit-Adresse verbinden. In einigen Fällen, wenn eine Kind-Adresse von einem Präfix abgeleitet ist, das einem Elternteil gehört und von diesem angekündigt wird, kann diese Eltern-Kind-Beziehung von der Wurzel zum Zweck der Konstruktion des Quell-Routing-Headers abgeleitet werden. In allen anderen Fällen ist es notwendig, die Wurzel über die Transit-Ziel-Beziehung von einem erreichbaren Ziel zu informieren, um später die rekursive Konstruktion des Routing-Headers zu ermöglichen. Eine Adresse, die als Ziel in einer DAO-Nachricht angekündigt wird, MUSS im selben Router kollokiert sein oder On-Link durch den Router erreichbar sein, dem die Adresse gehört, die in der zugehörigen Transit-Information angegeben ist. Die folgenden zusätzlichen Regeln gelten, um die Kontinuität des Ende-zu-Ende-Quell-Routing-Pfads sicherzustellen:

1. Die Adresse eines Elternteils, die in der Transit-Option verwendet wird, MUSS aus einem PIO von diesem Elternteil mit gesetztem 'R'-Flag entnommen werden. Das 'R'-Flag in einem PIO zeigt an, dass das Präfix-Feld tatsächlich die volle Eltern-Adresse enthält, aber das Kind SOLLTE NICHT annehmen, dass die Eltern-Adresse On-Link ist.

2. Ein PIO mit einem gesetzten 'A'-Flag zeigt an, dass der RPL-Kind-Knoten das Präfix verwenden kann, um eine Adresse automatisch zu konfigurieren. Ein Elternteil, der ein Präfix in einem PIO mit gesetztem 'A'-Flag ankündigt, MUSS sicherstellen, dass die Adresse oder das gesamte Präfix im PIO von der Wurzel erreichbar ist, indem er es als DAO-Ziel ankündigt. Wenn der Elternteil auch das 'L'-Flag setzt, was anzeigt, dass das Präfix On-Link ist, dann MUSS er das gesamte Präfix als Ziel in einer DAO-Nachricht ankündigen. Wenn das 'L'-Flag gelöscht ist und das 'R'-Flag gesetzt ist, was anzeigt, dass der Elternteil seine eigene Adresse im PIO bereitstellt, dann MUSS der Elternteil diese Adresse als DAO-Ziel ankündigen.

3. Eine Adresse, die als Ziel in einer DAO-Nachricht angekündigt wird, MUSS im selben Router kollokiert sein oder On-Link durch den Router erreichbar sein, dem die Adresse gehört, die in der zugehörigen Transit-Information angegeben ist.

4. Um eine optimale Komprimierung des Routing-Headers zu ermöglichen, SOLLTE der Elternteil das 'R'-Flag in allen PIOs mit gesetztem 'A'-Flag und gelöschtem 'L'-Flag setzen, und das Kind SOLLTE bevorzugen, als Transit die Adresse des Elternteils zu verwenden, die im PIO gefunden wird, der verwendet wird, um die Adresse automatisch zu konfigurieren, die als Ziel in der DAO-Nachricht angekündigt wird.

5. Ein Router könnte Ziele haben, von denen nicht bekannt ist, dass sie für einen Elternteil On-Link sind, entweder weil sie Adressen sind, die sich auf einer alternativen Schnittstelle befinden, oder weil sie zu Knoten gehören, die extern zu RPL sind, zum Beispiel verbundene Hosts. Um ein solches Ziel in das RPL-Netzwerk zu injizieren, MUSS der Router sich selbst als das DODAG-Parent-Address-Subfeld in der Transit-Information-Option für dieses Ziel ankündigen, unter Verwendung einer Adresse, die für den DAO-Parent dieses Knotens On-Link ist. Wenn das Ziel zu einem externen Knoten gehört, dann MUSS der Router das External 'E'-Flag in der Transit-Information setzen.

Ein Kind-Knoten, der eine Adresse aus einem Eltern-PIO mit gesetztem 'L'-Flag automatisch konfiguriert hat, muss diese Adresse nicht als DAO-Ziel ankündigen, da der Elternteil sicherstellt, dass das gesamte Präfix bereits von der Wurzel erreichbar ist. Wenn jedoch das 'L'-Flag nicht gesetzt ist, ist es im Non-Storing-Modus für den Kind-Knoten notwendig, die Wurzel über die Eltern-Kind-Beziehung zu informieren, unter Verwendung einer erreichbaren Adresse des Elternteils, um die rekursive Konstruktion des Routing-Headers zu ermöglichen. Dies geschieht durch Assoziierung einer Adresse des Elternteils als Transit mit der Adresse des Kindes als Ziel in einer DAO-Nachricht.

9.5. DAO-Übertragungsplanung

Da DAOs aufwärts fließen, kann der Empfang eines Unicast-DAO das Senden eines Unicast-DAO an einen DAO-Parent auslösen.

1. Beim Empfang einer Unicast-DAO-Nachricht mit aktualisierten Informationen, wie z.B. enthaltend eine Transit-Information-Option mit einer neuen Pfad-Sequenz, SOLLTE ein Knoten ein DAO senden. Er SOLLTE diese DAO-Nachricht NICHT sofort senden. Er SOLLTE das Senden der DAO-Nachricht verzögern, um DAO-Informationen von anderen Knoten zu aggregieren, für die er ein DAO-Parent ist.

2. Ein Knoten SOLLTE das Senden einer DAO-Nachricht mit einem Timer (DelayDAO) verzögern. Der Empfang einer DAO-Nachricht startet den DelayDAO-Timer. DAO-Nachrichten, die empfangen werden, während der DelayDAO-Timer aktiv ist, setzen den Timer nicht zurück. Wenn der DelayDAO-Timer abläuft, sendet der Knoten ein DAO.

3. Wenn ein Knoten einen Knoten zu seinem DAO-Parent-Set hinzufügt, SOLLTE er eine DAO-Nachrichtenübertragung planen.

Der Wert und die Berechnung von DelayDAO sind implementierungsabhängig. Ein Standardwert von DEFAULT_DAO_DELAY ist in dieser Spezifikation definiert.

9.6. Auslösen von DAO-Nachrichten

Knoten können ihren Sub-DODAG auslösen, DAO-Nachrichten zu senden. Jeder Knoten wartet eine DAO Trigger Sequence Number (DTSN), die er durch DIO-Nachrichten kommuniziert.

1. Wenn ein Knoten hört, dass einer seiner DAO-Parents seine DTSN erhöht, MUSS der Knoten eine DAO-Nachrichtenübertragung planen, unter Verwendung der Regeln in den Abschnitten 9.3 und 9.5.

2. Im Non-Storing-Modus, wenn ein Knoten hört, dass einer seiner DAO-Parents seine DTSN erhöht, MUSS der Knoten seine eigene DTSN erhöhen.

In einem Storing-Modus-Betrieb, als Teil routinemäßiger Routing-Tabellen-Updates und -Wartung, KANN ein speichernder Knoten die DTSN erhöhen, um zuverlässig einen Satz von DAO-Updates von seinen unmittelbaren Kindern auszulösen.

In einem Storing-Modus-Betrieb ist es nicht notwendig, DAO-Updates vom gesamten Sub-DODAG auszulösen, da diese Zustandsinformation Hop-by-Hop den DODAG hinauf propagieren wird.

In einem Non-Storing-Modus-Betrieb wird eine DTSN-Erhöhung auch bewirken, dass die unmittelbaren Kinder eines Knotens ihre DTSN wiederum erhöhen, was einen Satz von DAO-Updates vom gesamten Sub-DODAG auslöst. Typischerweise würde in einem Non-Storing-Modus-Betrieb nur die Wurzel die DTSN unabhängig erhöhen, wenn eine DAO-Auffrischung benötigt wird, aber eine globale Reparatur (wie durch Erhöhung der DODAGVersionNumber) nicht gewünscht ist. Typischerweise würden in einem Non-Storing-Modus-Betrieb alle Nicht-Wurzel-Knoten ihre DTSN nur erhöhen, wenn beobachtet wird, dass ihr(e) Elternteil(e) dies tun.

Im Allgemeinen kann ein Knoten DAO-Updates gemäß implementierungsspezifischer Logik auslösen, wie z.B. basierend auf der Erkennung einer Abwärts-Routen-Inkonsistenz oder gelegentlich basierend auf einem internen Timer.

In einem speichernden Netzwerk kann die Auswahl eines geeigneten DelayDAO für ausgelöste DAOs die Anzahl der übertragenen DAOs stark reduzieren. Der Trigger fließt den DODAG hinunter; im besten Fall fließen die DAOs den DODAG hinauf, so dass Blätter DAOs zuerst senden, wobei jeder Knoten eine DAO-Nachricht nur einmal sendet. Eine solche Planung könnte angenähert werden, indem DelayDAO umgekehrt proportional zum Rang gesetzt wird. Beachten Sie, dass dieser Vorschlag als Optimierung gedacht ist, um eine effiziente Aggregation zu ermöglichen (er ist nicht für den korrekten Betrieb im allgemeinen Fall erforderlich).

9.7. Non-Storing-Modus

Im Non-Storing-Modus routet RPL Nachrichten abwärts unter Verwendung von IP-Quell-Routing. Die folgende Regel gilt für Knoten, die im Non-Storing-Modus sind. Der Storing-Modus hat einen separaten Satz von Regeln, beschrieben in Abschnitt 9.8.

1. Das DODAG-Parent-Address-Subfeld einer Transit-Information-Option MUSS eine oder mehrere Adressen enthalten. Alle diese Adressen MÜSSEN Adressen von DAO-Parents des Senders sein.

2. DAOs werden direkt an die Wurzel entlang einer Standard-Route gesendet, die als Teil der Eltern-Auswahl installiert wurde.

3. Wenn ein Knoten einen Knoten aus seinem DAO-Parent-Set entfernt, KANN er eine neue DAO-Nachricht mit einer aktualisierten Transit-Information-Option generieren.

Im Non-Storing-Modus verwendet ein Knoten DAOs, um seine DAO-Parents an die DODAG-Wurzel zu melden. Die DODAG-Wurzel kann eine Abwärts-Route zu einem Knoten zusammensetzen, indem sie DAO-Parent-Sets von jedem Knoten in der Route verwendet. Die Pfad-Sequenz-Information kann verwendet werden, um veraltete DAO-Informationen zu erkennen. Der Zweck dieser Per-Hop-Routenberechnung ist es, den Verkehr zu minimieren, wenn sich DAO-Parents ändern. Wenn Knoten vollständige Quell-Routen melden würden, müsste bei einer DAO-Parent-Änderung der gesamte Sub-DODAG neue DAOs an die DODAG-Wurzel senden. Daher kann im Non-Storing-Modus ein Knoten ein einzelnes DAO senden, obwohl er sich entscheiden könnte, mehr als eine DAO-Nachricht an jeden von mehreren DAO-Parents zu senden.

Knoten packen DAOs, indem sie eine einzelne DAO-Nachricht mit mehreren RPL-Target-Optionen senden. Jede RPL-Target-Option hat ihre eigenen, unmittelbar folgenden, Transit-Information-Optionen.

9.8. Storing-Modus

Im Storing-Modus routet RPL Nachrichten abwärts anhand der IPv6-Zieladresse. Die folgenden Regeln gelten für Knoten, die im Storing-Modus sind:

1. Das DODAG-Parent-Address-Subfeld einer Transmit-Information-Option MUSS leer sein.

2. Beim Empfang eines Unicast-DAO MUSS ein Knoten berechnen, ob das DAO die Menge der Präfixe ändern würde, die der Knoten selbst ankündigt. Diese Berechnung SOLLTE die Konsultation der Pfad-Sequenz-Information in den Transit-Information-Optionen einschließen, die mit dem DAO assoziiert sind, um zu bestimmen, ob die DAO-Nachricht neuere Informationen enthält, die die bereits beim Knoten gespeicherten Informationen ersetzen. Wenn ja, MUSS der Knoten eine neue DAO-Nachricht generieren und übertragen, unter Befolgung der Regeln in Abschnitt 9.5. Eine solche Änderung schließt den Empfang eines No-Path-DAO ein.

3. Wenn ein Knoten ein neues DAO generiert, SOLLTE er es per Unicast an jeden seiner DAO-Parents senden. Er DARF die DAO-Nachricht NICHT per Unicast an Knoten senden, die keine DAO-Parents sind.

4. Wenn ein Knoten einen Knoten aus seinem DAO-Parent-Set entfernt, SOLLTE er eine No-Path-DAO-Nachricht (Abschnitt 6.4.3) an diesen entfernten DAO-Parent senden, um die existierende Route ungültig zu machen.

5. Wenn Nachrichten an eine angekündigte Abwärts-Adresse unter einem Weiterleitungsfehler, Neighbor Unreachable Detection (NUD) oder ähnlichem Fehler leiden, KANN ein Knoten die Adresse als unerreichbar markieren und ein entsprechendes No-Path-DAO generieren.

DAOs kündigen an, zu welchen Zieladressen und Präfixen ein Knoten Routen hat. Im Gegensatz zum Non-Storing-Modus kommunizieren diese DAOs keine Informationen über die Routen selbst: diese Information ist im Netzwerk gespeichert und ist implizit aus der IPv6-Quelladresse. Wenn ein speichernder Knoten ein DAO generiert, verwendet er den gespeicherten Zustand von DAOs, die er empfangen hat, um einen Satz von RPL-Target-Optionen und ihren zugehörigen Transmit-Information-Optionen zu produzieren.

Da diese Information in den Routing-Tabellen jedes Knotens gespeichert ist, werden DAOs im Storing-Modus direkt an DAO-Parents kommuniziert, die diese Information speichern.

9.9. Pfad-Kontrolle (Path Control)

Eine DAO-Nachricht von einem Knoten enthält eine oder mehrere Target-Optionen. Jede Target-Option spezifiziert entweder ein vom Knoten angekündigtes Präfix, ein Präfix von Adressen, die außerhalb des LLN erreichbar sind, die Adresse eines Ziels im Sub-DODAG des Knotens oder eine Multicast-Gruppe, auf die ein Knoten im Sub-DODAG hört. Das Path-Control-Feld der Transit-Information-Option erlaubt Knoten, mehrere Abwärts-Routen anzufordern oder zuzulassen. Ein Knoten konstruiert das Path-Control-Feld einer Transit-Information-Option wie folgt:

1. Die Bitbreite des Path-Control-Feldes MUSS gleich dem Wert (PCS + 1) sein, wobei PCS im Kontrollfeld der DODAG-Konfigurations-Option spezifiziert ist. Bits größer als oder gleich dem Wert (PCS + 1) MÜSSEN bei der Übertragung gelöscht werden und MÜSSEN beim Empfang ignoriert werden. Bits unterhalb dieses Wertes werden als "aktive" Bits betrachtet.

2. Der Knoten MUSS logisch Gruppierungen seiner DAO-Parents konstruieren, während er das Path-Control-Feld befüllt, wobei jede Gruppe aus DAO-Parents gleicher Präferenz besteht. Diese Gruppen MÜSSEN dann nach Präferenz geordnet werden, was eine logische Abbildung von DAO-Parents auf Path-Control-Subfelder ermöglicht (siehe Abbildung 27). Gruppen KÖNNEN wiederholt werden, um sich über die gesamte Bitbreite des Path-Control-Feldes zu erstrecken, aber die Reihenfolge, einschließlich wiederholter Gruppen, MUSS beibehalten werden, damit die Präferenz korrekt kommuniziert wird.

3. Für eine RPL-Target-Option, die die eigene Adresse eines Knotens oder ein Präfix außerhalb des LLN beschreibt, MUSS mindestens ein aktives Bit des Path-Control-Feldes gesetzt sein. Mehr aktive Bits des Path-Control-Feldes KÖNNEN gesetzt sein.

4. Wenn ein Knoten mehrere DAOs mit derselben RPL-Target-Option empfängt, MUSS er die Path-Control-Felder, die er empfängt, bitweise ODER-verknüpfen. Dieses aggregierte bitweise ODER repräsentiert die Anzahl der Abwärts-Routen, die das Präfix anfordert.

5. Wenn ein Knoten eine DAO-Nachricht an einen seiner DAO-Parents sendet, MUSS er eines oder mehrere der Bits auswählen, die im Subfeld als aktiv gesetzt sind, das auf die Gruppe abgebildet ist, die diesen DAO-Parent aus dem aggregierten Path-Control-Feld enthält. Ein gegebenes Bit kann nur einem Elternteil als aktiv präsentiert werden. Die DAO-Nachricht, die er an seinen Elternteil überträgt, MUSS diese aktiven Bits gesetzt und alle anderen aktiven Bits gelöscht haben.

6. Für die RPL-Target-Option und DAOSequence-Nummer MÜSSEN die DAOs, die ein Knoten an verschiedene DAO-Parents sendet, disjunkte Sätze von aktiven Path-Control-Bits haben. Ein Knoten DARF NICHT dasselbe aktive Bit in DAOs an zwei verschiedene DAO-Parents setzen.

7. Path-Control-Bits SOLLTEN gemäß der Präferenz-Abbildung von DAO-Parents auf Path-Control-Subfelder zugewiesen werden, so dass die aktiven Path-Control-Bits, oder Gruppierungen von Bits, die zu einem bestimmten Path-Control-Subfeld gehören, DAO-Parents innerhalb der Gruppe zugewiesen werden, die auf dieses Subfeld abgebildet wurde.

8. In einem Non-Storing-Modus-Betrieb KANN ein Knoten DAOs durchleiten, ohne eine weitere Verarbeitung am Path-Control-Feld durchzuführen.

9. Ein Knoten DARF KEINE DAO-Nachricht per Unicast senden, die keine aktiven Bits im Path-Control-Feld gesetzt hat. Es ist möglich, dass für eine gegebene Target-Option ein Knoten nicht genügend aggregierte Path-Control-Bits hat, um eine DAO-Nachricht mit diesem Target an jeden seiner DAO-Parents zu senden, in welchem Fall jene am wenigsten bevorzugten DAO-Parents möglicherweise keine DAO-Nachricht für dieses Target erhalten.

Das Path-Control-Feld erlaubt einem Knoten zu begrenzen, wie viele Abwärts-Routen zu ihm generiert werden. Es setzt eine Anzahl von Bits im Path-Control-Feld gleich der maximalen Anzahl von Abwärts-Routen, die er bevorzugt. Höchstens wird jedes Bit an einen DAO-Parent gesendet; Cluster von Bits können an einen einzelnen DAO-Parent gesendet werden, damit dieser sie unter seinen eigenen DAO-Parents aufteilt.

Ein Knoten, der eine DAO-Route für ein Target bereitstellt, das ein assoziiertes Path-Control-Feld hat, SOLLTE den Inhalt dieses Path-Control-Feldes verwenden, um eine Präferenzreihenfolge unter mehreren alternativen DAO-Routen für dieses Target zu bestimmen. Die Path-Control-Feld-Zuweisung wird von der Präferenz (der DAO-Parents) abgeleitet, wie bestimmt auf der Basis des besten Wissens dieses Knotens über die "Ende-zu-Ende" aggregierten Metriken in Abwärts-Richtung gemäß der Zielfunktion. Im Non-Storing-Modus kann die Wurzel die Abwärts-Route bestimmen, indem sie die Informationen von jedem empfangenen DAO aggregiert, was die Path-Control-Angaben bevorzugter DAO-Parents einschließt.

9.9.1. Beispiel für Pfad-Kontrolle

Angenommen, es gibt ein LLN, das im Storing-Modus arbeitet, das einen Knoten N mit vier Eltern, P1, P2, P3 und P4, enthält. Sei N drei Kinder, C1, C2 und C3, in seinem Sub-DODAG haben. Sei PCS 7, so dass es 8 aktive Bits im Path-Control-Feld geben wird: 11111111b. Betrachten Sie das folgende Beispiel:

Das Path-Control-Feld ist in vier Subfelder aufgeteilt, PC1 (11000000b), PC2 (00110000b), PC3 (00001100b) und PC4 (00000011b), so dass diese vier Subfelder vier verschiedene Präferenzebenen gemäß Abbildung 27 repräsentieren. Die Implementierung bei Knoten N, in diesem Beispiel, gruppiert {P1, P2} als von gleicher Präferenz zueinander und die am meisten bevorzugte Gruppe insgesamt. {P3} ist weniger bevorzugt als {P1, P2} und mehr bevorzugt als {P4}. Sei Knoten N dann seine Path-Control-Abbildung so durchführen, dass:

       {P1, P2} -> PC1 (11000000b) im Path-Control-Feld
       {P3}     -> PC2 (00110000b) im Path-Control-Feld
       {P4}     -> PC3 (00001100b) im Path-Control-Feld
       {P4}     -> PC4 (00000011b) im Path-Control-Feld

Beachten Sie, dass die Implementierung {P4} wiederholt hat, um eine vollständige Abdeckung des Path-Control-Feldes zu erhalten.

1. Sei C1 ein DAO senden, das ein Target T mit einem Path-Control 10000000b enthält. Knoten N speichert einen Eintrag, der 10000000b mit dem Path-Control-Feld für C1 und Target T assoziiert.

2. Sei C2 ein DAO senden, das ein Target T mit einem Path-Control 00010000b enthält. Knoten N speichert einen Eintrag, der 00010000b mit dem Path-Control-Feld für C1 und Target T assoziiert.

3. Sei C3 ein DAO senden, das ein Target T mit einem Path-Control 00001100b enthält. Knoten N speichert einen Eintrag, der 00001100b mit dem Path-Control-Feld für C1 und Target T assoziiert.

4. Zu einem späteren Zeitpunkt generiert Knoten N ein DAO für Target T. Knoten N wird ein aggregiertes Path-Control-Feld konstruieren, indem er den Beitrag von jedem seiner Kinder, die ein DAO für Target T gegeben haben, ODER-verknüpft. Somit hat das aggregierte Path-Control-Feld die aktiven Bits gesetzt als: 10011100b.

5. Knoten N verteilt dann die aggregierten Path-Control-Bits unter seinen Eltern P1, P2, P3 und P4, um die DAO-Nachrichten vorzubereiten.

6. P1 und P2 sind berechtigt, aktive Bits vom am meisten bevorzugten Subfeld (11000000b) zu erhalten. Jene Bits sind 10000000b im aggregierten Path-Control-Feld. Knoten N muss das Bit nur einem der zwei Eltern zuweisen. In diesem Fall wird Knoten P1 das Bit zugewiesen und erhält das Path-Control-Feld 10000000b für sein DAO. Es sind keine Bits mehr übrig, um sie Knoten P2 zuzuweisen; somit hätte Knoten P2 ein Path-Control-Feld von 00000000b und ein DAO kann nicht an Knoten P2 generiert werden, da es keine aktiven Bits gibt.

7. Das zweitmeist bevorzugte Subfeld (00110000b) hat die aktiven Bits 00010000b. Knoten N hat P3 auf dieses Subfeld abgebildet. Knoten N kann das aktive Bit an P3 zuweisen, wobei ein DAO für P3 konstruiert wird, das Target T mit einem Path-Control von 00010000b enthält.

8. Das drittmeist bevorzugte Subfeld (00001100b) hat die aktiven Bits 00001100b. Knoten N hat P4 auf dieses Subfeld abgebildet. Knoten N kann beide Bits an P4 zuweisen, wobei ein DAO für P4 konstruiert wird, das Target T mit einem Path-Control von 00001100b enthält.

9. Das am wenigsten bevorzugte Subfeld (00000011b) hat keine aktiven Bits. Hätte es aktive Bits gegeben, wären jene Bits zum Path-Control-Feld des für P4 konstruierten DAO hinzugefügt worden.

10. Der Prozess der Befüllung der DAO-Nachrichten, die für P1, P2, P3, P4 bestimmt sind, mit anderen Targets (anderen als T) verläuft gemäß den aggregierten Path-Control-Feldern, die für jene Targets gesammelt wurden.

9.10. Multicast Destination Advertisement Nachrichten

Ein Spezialfall des DAO-Betriebs, verschieden vom Unicast-DAO-Betrieb, ist der Multicast-DAO-Betrieb, der verwendet werden kann, um '1-Hop'-Routing-Tabelleneinträge zu befüllen.

1. Ein Knoten KANN eine DAO-Nachricht an die Link-Local-Scope All-RPL-Nodes-Multicast-Adresse per Multicast senden.

2. Eine Multicast-DAO-Nachricht MUSS nur verwendet werden, um Informationen über den Knoten selbst anzukündigen, d.h. Präfixe, die direkt verbunden sind mit oder dem Knoten gehören, wie eine Multicast-Gruppe, die der Knoten abonniert hat, oder eine globale Adresse, die dem Knoten gehört.

3. Eine Multicast-DAO-Nachricht DARF NICHT verwendet werden, um Konnektivitätsinformationen weiterzuleiten, die (z.B. durch Unicast-DAO) von einem anderen Knoten gelernt wurden.

4. Ein Knoten DARF KEINE andere DAO-bezogene Verarbeitung an einer empfangenen Multicast-DAO-Nachricht durchführen; insbesondere DARF ein Knoten NICHT die Aktionen eines DAO-Parents bei Empfang eines Multicast-DAO durchführen.

• Das Multicast-DAO kann verwendet werden, um direkte P2P-Kommunikation zu ermöglichen, ohne dass der DODAG die Pakete weiterleiten muss.