8.2.2. Nachbarn und Eltern über DODAG-Versionen hinweg

Die oben genannten Regeln regeln eine einzelne DODAG-Version. Die Regeln in diesem Abschnitt definieren, wie RPL funktioniert, wenn es mehrere DODAG-Versionen gibt.

8.2.2.1. DODAG-Version

1. Das Tupel (RPLInstanceID, DODAGID, DODAGVersionNumber) definiert eindeutig eine DODAG-Version. Jedes Element der DODAG-Elternmenge eines Knotens, wie durch die zuletzt gehörte DIO-Nachricht von jedem DODAG-Elternteil übermittelt, MUSS zur selben DODAG-Version gehören. Elemente der Kandidaten-Nachbarmenge eines Knotens KÖNNEN zu verschiedenen DODAG-Versionen gehören.

2. Ein Knoten ist Mitglied einer DODAG-Version, wenn jedes Element seiner DODAG-Elternmenge zu dieser DODAG-Version gehört oder wenn dieser Knoten die Wurzel des entsprechenden DODAG ist.

3. Ein Knoten DARF KEINE DIOs für DODAG-Versionen senden, von denen er kein Mitglied ist.

4. DODAG-Wurzeln KÖNNEN die von ihnen angekündigte DODAGVersionNumber erhöhen und somit zu einer neuen DODAG-Version wechseln. Wenn eine DODAG-Wurzel ihre DODAGVersionNumber erhöht, MUSS sie die Konventionen der Serial Number Arithmetic befolgen, wie in Abschnitt 7 beschrieben. Ereignisse, die die Erhöhung der DODAGVersionNumber auslösen, werden später in diesem Abschnitt und in Abschnitt 18 beschrieben.

5. Innerhalb eines gegebenen DODAG DARF ein Knoten, der keine Wurzel ist, KEINE höhere DODAGVersionNumber ankündigen als die höchste DODAGVersionNumber, die er gehört hat. Höher ist als der Größer-als-Operator in Abschnitt 7 definiert.

6. Sobald ein Knoten eine DODAG-Version durch Senden eines DIO angekündigt hat, DARF er NICHT Mitglied einer vorherigen DODAG-Version desselben DODAG sein (d.h. mit derselben RPLInstanceID, derselben DODAGID und einer niedrigeren DODAGVersionNumber). Niedriger ist als der Kleiner-als-Operator in Abschnitt 7 definiert.

Wenn die DODAG-Elternmenge auf einem Knoten, der keine Wurzel ist, leer wird (d.h. das letzte Elternteil wurde entfernt, wodurch der Knoten nicht mehr mit diesem DODAG assoziiert ist), sollten die DODAG-Informationen nicht unterdrückt werden, bis nach dem Ablauf eines implementierungsspezifischen lokalen Timers. Während des Intervalls vor der Unterdrückung des "alten" DODAG-Zustands kann der Knoten beobachten, ob die DODAGVersionNumber erhöht wurde, sollten neue Elternteile erscheinen. Dies hilft, die Möglichkeit von Schleifen zu schützen, die auftreten können, wenn dieser Knoten versehentlich der alten DODAG-Version in seinem eigenen früheren Unter-DODAG wieder beitreten würde.

Wenn die DODAGVersionNumber erhöht wird, breitet sich eine neue DODAG-Version von der DODAG-Wurzel nach außen aus. Ein Elternteil, das die neue DODAGVersionNumber ankündigt, kann nicht zum Unter-DODAG eines Knotens gehören, der eine ältere DODAGVersionNumber ankündigt. Daher kann ein Knoten sicher ein Elternteil beliebigen Ranks mit einer neueren DODAGVersionNumber hinzufügen, ohne eine Schleife zu bilden.

Angenommen zum Beispiel, ein Knoten hat ein DODAG mit DODAGVersionNumber N verlassen. Angenommen, ein Knoten hatte ein Unter-DODAG und versuchte, dieses Unter-DODAG zu vergiften, indem er einen Rank von INFINITE_RANK ankündigte, aber diese Ankündigungen könnten im LLN verloren gegangen sein. Wenn der Knoten dann einen Kandidaten-Nachbarn beobachtet, der eine Position in diesem ursprünglichen DODAG bei DODAGVersionNumber N ankündigt, könnte dieser Kandidaten-Nachbar möglicherweise im früheren Unter-DODAG des Knotens gewesen sein, und es gibt einen möglichen Fall, in dem das Hinzufügen dieses Kandidaten-Nachbarn als Elternteil eine Schleife verursachen könnte. Wenn in diesem Fall beobachtet wird, dass dieser Kandidaten-Nachbar eine DODAGVersionNumber N+1 ankündigt, dann ist dieser Kandidaten-Nachbar sicher sicher, da er sicher nicht im Unter-DODAG dieses ursprünglichen Knotens ist, da er in der Lage war, die DODAGVersionNumber zu erhöhen, indem er von der DODAG-Wurzel hörte, während dieser ursprüngliche Knoten getrennt war. Aus diesem Grund ist es für den getrennten Knoten nützlich, sich an die ursprünglichen DODAG-Informationen zu erinnern, einschließlich der DODAGVersionNumber N.

Genau wann eine DODAG-Wurzel die DODAGVersionNumber erhöht, ist implementierungsabhängig und außerhalb des Geltungsbereichs dieser Spezifikation. Beispiele umfassen das periodische Erhöhen der DODAGVersionNumber, bei administrativer Intervention oder bei der Erkennung von verlorenem Verbindung oder DODAG-Ineffizienz auf Anwendungsebene.

Nachdem ein Knoten zu einer neuen DODAG-Version gewechselt und diese angekündigt hat, machen ihn die obigen Regeln unfähig, die vorherige DODAG-Version (frühere DODAGVersionNumber) anzukündigen, sobald er sich verpflichtet hat, die neue DODAG-Version anzukündigen.

8.2.2.2. DODAG-Wurzeln

1. Eine DODAG-Wurzel ohne Möglichkeit, das anwendungsdefinierte Ziel zu erfüllen, DARF NICHT das Grounded-Bit setzen.

2. Eine DODAG-Wurzel MUSS einen Rank von ROOT_RANK ankündigen.

3. Ein Knoten, dessen DODAG-Elternmenge leer ist, KANN zur DODAG-Wurzel eines schwebenden DODAG werden. Er KANN auch seine DAGPreference so setzen, dass er weniger bevorzugt ist.

In einer Bereitstellung, die Nicht-LLN-Links verwendet, um eine Anzahl von LLN-Wurzeln zu föderieren, ist es möglich, RPL über diese Nicht-RPL-Links auszuführen und einen Router als "Backbone-Wurzel" zu verwenden. Die Backbone-Wurzel ist die virtuelle Wurzel des DODAG und zeigt einen Rank von BASE_RANK über das Backbone. Alle LLN-Wurzeln, die dieser Backbone-Wurzel übergeordnet sind, einschließlich der Backbone-Wurzel selbst, wenn sie auch als LLN-Wurzel dient, zeigen einen Rank von ROOT_RANK zum LLN. Diese virtuellen Wurzeln sind Teil desselben DODAG und kündigen dieselbe DODAGID an. Sie koordinieren DODAGVersionNumbers und andere DODAG-Parameter mit der virtuellen Wurzel über das Backbone. Die Koordinationsmethode liegt außerhalb des Geltungsbereichs dieser Spezifikation (wird in zukünftigen Begleitspezifikationen definiert).

8.2.2.3. DODAG-Auswahl

Die Objective Function und die Menge der angekündigten Routing-Metriken und -Einschränkungen eines DAG bestimmen, wie ein Knoten seine Nachbarmenge, Elternmenge und bevorzugten Elternteile auswählt. Diese Auswahl bestimmt implizit auch das DODAG innerhalb eines DAG. Eine solche Auswahl kann administrative Präferenz (Prf) sowie Metriken oder andere Überlegungen umfassen.

Wenn ein Knoten die Möglichkeit hat, einem bevorzugteren DODAG beizutreten und dabei andere Optimierungsziele zu erfüllen, wird der Knoten im Allgemeinen versuchen, dem bevorzugteren DODAG beizutreten, wie durch die OF bestimmt. Unter sonst gleichen Bedingungen bleibt es der Implementierung überlassen zu bestimmen, welches DODAG am bevorzugtesten ist (da, zur Erinnerung, ein Knoten pro RPL-Instanz nur einem DODAG beitreten darf).

8.2.2.4. Rank und Bewegung innerhalb einer DODAG-Version

1. Ein Knoten DARF KEINEN Rank ankündigen, der kleiner oder gleich einem Mitglied seiner Elternmenge innerhalb der DODAG-Version ist.

2. Ein Knoten KANN einen niedrigeren Rank als seine vorherige Ankündigung innerhalb der DODAG-Version ankündigen.

3. Sei L der niedrigste Rank innerhalb einer DODAG-Version, den ein gegebener Knoten angekündigt hat. Innerhalb derselben DODAG-Version DARF dieser Knoten KEINEN effektiven Rank höher als L + DAGMaxRankIncrease ankündigen. INFINITE_RANK ist eine Ausnahme von dieser Regel: Ein Knoten KANN einen INFINITE_RANK innerhalb einer DODAG-Version ohne Einschränkung ankündigen. Wenn der Rank eines Knotens höher wäre als durch L + DAGMaxRankIncrease erlaubt, MUSS er beim Ankündigen des Ranks seinen Rank als INFINITE_RANK ankündigen.

4. Ein Knoten KANN jederzeit wählen, einem anderen DODAG innerhalb einer RPL-Instanz beizutreten. Ein solcher Beitritt hat keine Rank-Einschränkungen, es sei denn, dieses andere DODAG ist eine DODAG-Version, von der dieser Knoten zuvor Mitglied war; in diesem Fall muss die Regel des vorherigen Punktes (3) beachtet werden. Bis ein Knoten ein DIO sendet, das seine neue DODAG-Mitgliedschaft anzeigt, MUSS er Pakete entlang des vorherigen DODAG weiterleiten.

5. Ein Knoten KANN jederzeit, nachdem er die nächste DODAGVersionNumber von geeigneten DODAG-Elternteilen gehört hat, wählen, zur nächsten DODAG-Version innerhalb des DODAG zu migrieren.

Konzeptionell pflegt eine Implementierung eine DODAG-Elternmenge innerhalb der DODAG-Version. Bewegung beinhaltet Änderungen an der DODAG-Elternmenge. Nach oben bewegen birgt nicht das Risiko, eine Schleife zu erzeugen, aber nach unten bewegen könnte, so dass diese Operation zusätzlichen Einschränkungen unterliegt.

Wenn ein Knoten zur nächsten DODAG-Version migriert, muss die DODAG-Elternmenge für die neue Version neu aufgebaut werden. Eine Implementierung könnte die Migration für eine angemessene Zeitspanne verschieben, um zu sehen, ob einige andere Nachbarn mit potenziell besseren Metriken, aber höherem Rank, sich ankündigen. Ebenso muss ein Knoten, wenn er zu einem neuen DODAG springt, eine neue DODAG-Elternmenge für dieses neue DODAG konstruieren.

Wenn ein Knoten sich in einem DODAG, an das er angehängt ist, nach unten bewegen muss, indem er seinen Rank erhöht, KANN er seine Routen vergiften und die Bewegung verzögern, wie in Abschnitt 8.2.2.5 beschrieben.

Ein Knoten darf jeder DODAG-Version beitreten, von der er noch nie ein früheres Mitglied war, ohne jegliche Einschränkungen, aber wenn der Knoten ein früheres Mitglied der DODAG-Version war, muss er weiterhin die Regel beachten, dass er zu keinem Zeitpunkt im Leben der DODAG-Version einen Rank höher als L+DAGMaxRankIncrease ankündigen darf. Diese Regel muss beachtet werden, um keine Lücke zu schaffen, die es dem Knoten ermöglichen würde, seinen Rank effektiv bis auf INFINITE_RANK zu erhöhen, was Auswirkungen auf andere Knoten haben und ein ressourcenverschwendendes Count-to-Infinity-Szenario schaffen kann.

8.2.2.5. Vergiftung

1. Ein Knoten vergiftet Routen, indem er einen Rank von INFINITE_RANK ankündigt.

2. Ein Knoten DARF KEINE Knoten mit einem Rank von INFINITE_RANK in seiner Elternmenge haben.

Obwohl eine Implementierung INFINITE_RANK zum Zwecke der Vergiftung ankündigen kann, ist dies nicht dasselbe wie das Setzen des Ranks auf INFINITE_RANK. Zum Beispiel kann ein Knoten weiterhin Datenpakete senden, deren RPL-Paketinformationen einen Rank enthalten, der nicht INFINITE_RANK ist, aber dennoch INFINITE_RANK in seinen DIOs ankündigen.

Wenn beobachtet wird, dass ein (ehemaliges) Elternteil einen Rank von INFINITE_RANK ankündigt, hat sich dieses (ehemalige) Elternteil vom DODAG getrennt und kann nicht mehr als Elternteil agieren, noch kann ein anderer Knoten als größer als INFINITE_RANK betrachtet werden. Daher kann dieses (ehemalige) Elternteil nicht mehr als Elternteil agieren und wird aus der Elternmenge entfernt.

8.2.2.6. Trennung

1. Ein Knoten, der nicht in der Lage ist, mit einem DODAG innerhalb einer gegebenen DODAG-Version verbunden zu bleiben, d.h. der keine nicht-leere Elternmenge beibehalten kann, ohne die Regeln dieser Spezifikation zu verletzen, KANN sich von dieser DODAG-Version trennen. Ein Knoten, der sich trennt, wird zur Wurzel seines eigenen schwebenden DODAG und SOLLTE diese neue Situation sofort in einem DIO ankündigen als Alternative zur Vergiftung.

8.2.2.7. Einem Elternteil folgen

1. Wenn ein Knoten ein DIO von einem seiner DODAG-Elternteile erhält, das anzeigt, dass das Elternteil das DODAG verlassen hat, SOLLTE dieser Knoten über ein alternatives DODAG-Elternteil in seinem aktuellen DODAG bleiben, wenn möglich. Er KANN dem verlassenden Elternteil folgen.

Ein DODAG-Elternteil kann sich bewegt haben, zur nächsten DODAG-Version migriert sein oder zu einem anderen DODAG gesprungen sein. Ein Knoten sollte eine gewisse Präferenz dafür geben, im aktuellen DODAG zu bleiben, wenn möglich über ein alternatives Elternteil, sollte aber dem Elternteil folgen, wenn es keine anderen Optionen gibt.