8. Aufwärtsrouten

Dieser Abschnitt beschreibt, wie RPL Aufwärtsrouten entdeckt und wartet. Er beschreibt die Verwendung von DODAG-Informationsobjekten (DIOs), den Nachrichten, die verwendet werden, um diese Routen zu entdecken und zu warten. Er spezifiziert, wie RPL DIOs generiert und darauf reagiert. Er beschreibt auch DODAG-Informationsanforderungsnachrichten (DIS), die verwendet werden, um DIO-Übertragungen auszulösen.

Wie in Abschnitt 3.2.8 erwähnt, MÜSSEN Knoten, die beschließen, einem DODAG beizutreten, mindestens einen DODAG-Elternteil als Standardroute für die zugehörige Instanz bereitstellen. Diese Standardroute ermöglicht es, ein Paket aufwärts weiterzuleiten, bis es schließlich auf einen gemeinsamen Vorfahren trifft, von dem es abwärts zum Ziel geroutet wird. Wenn sich das Ziel nicht im DODAG befindet, kann die DODAG-Wurzel das Paket möglicherweise unter Verwendung einer Konnektivität zur Außenseite des DODAG weiterleiten; wenn sie das Paket nicht nach außen weiterleiten kann, muss die DODAG-Wurzel es verwerfen.

Eine DIO-Nachricht kann auch explizite Routing-Informationen transportieren:

• DODAGID: Die DODAGID ist eine globale oder eindeutige lokale IPv6-Adresse der Wurzel. Ein Knoten, der einem DODAG beitritt, SOLLTE eine Host-Route über einen DODAG-Elternteil zu der Adresse bereitstellen, die von der Wurzel als DODAGID verwendet wird.

• RIO-Präfix: Die Wurzel KANN eine oder mehrere Routeninformationsoptionen (RIO) in eine DIO-Nachricht einfügen. Das RIO wird verwendet, um eine externe Route anzukündigen, die über die Wurzel erreichbar ist, verbunden mit einer Präferenz, wie in Abschnitt 6.7.5 dargestellt, der das RIO aus [RFC4191] enthält. Es wird als eine Fähigkeit der Wurzel im Gegensatz zu einer Routing-Ankündigung interpretiert und DARF NICHT in einem anderen Routing-Protokoll neu verteilt werden, obwohl es von einem Eingangs-RPL-Router verwendet werden SOLLTE, um einen DODAG auszuwählen, wenn ein Paket von einem an diesen RPL-Router angeschlossenen Knoten in eine RPL-Domäne injiziert wird. Eine Zielfunktion KANN die im RIO angekündigten Routen oder die Präferenz für diese Routen verwenden, um einen DODAG gegenüber einem anderen für dieselbe Instanz zu bevorzugen.

8.1. DIO-Basisregeln

1. Für die folgenden DIO-Basisfelder MUSS ein Knoten, der keine DODAG-Wurzel ist, dieselben Werte ankündigen wie sein bevorzugter DODAG-Elternteil (definiert in Abschnitt 8.2.1). Auf diese Weise werden diese Werte unverändert den DODAG hinunter propagiert und von jedem Knoten angekündigt, der eine Route zu dieser DODAG-Wurzel hat. Diese Felder sind wie folgt:

   1. Geerdet (G)
   2. Betriebsmodus (MOP)
   3. DAG-Präferenz (Prf)
   4. Version
   5. RPLInstanceID
   6. DODAGID

2. Ein Knoten KANN die folgenden Felder bei jedem Hop aktualisieren:

   1. Rang (Rank)
   2. DTSN

3. Das von jeder Wurzel gesetzte DODAGID-Feld MUSS innerhalb der RPL-Instanz eindeutig sein und MUSS eine routingfähige IPv6-Adresse sein, die der Wurzel gehört.

8.2. Entdeckung und Wartung von Aufwärtsrouten

Die Entdeckung von Aufwärtsrouten ermöglicht es einem Knoten, einem DODAG beizutreten, indem er Nachbarn entdeckt, die Mitglieder des interessierenden DODAG sind, und eine Reihe von Eltern identifiziert. Die genauen Richtlinien für die Auswahl von Nachbarn und Eltern sind implementierungsabhängig und werden von der OF gesteuert. Dieser Abschnitt spezifiziert den Satz von Regeln, denen diese Richtlinien für die Interoperabilität folgen müssen.

8.2.1. Nachbarn und Eltern innerhalb einer DODAG-Version

RPLs Algorithmen und Verarbeitung zur Entdeckung von Aufwärtsrouten beziehen sich auf drei logische Sätze von Link-Local-Knoten. Erstens ist der Kandidatennachbarsatz eine Teilmenge der Knoten, die über Link-Local-Multicast erreicht werden können. Die Auswahl dieses Satzes ist implementierungs- und OF-abhängig. Zweitens ist der Elternsatz eine eingeschränkte Teilmenge des Kandidatennachbarsatzes. Schließlich ist der bevorzugte Elternteil ein Mitglied des Elternsatzes, das der bevorzugte nächste Hop in Aufwärtsrouten ist. Konzeptionell ist der bevorzugte Elternteil ein einzelner Elternteil; obwohl es sich um einen Satz mehrerer Eltern handeln kann, wenn diese Eltern gleichermaßen bevorzugt werden und denselben Rang haben.

Genauer gesagt:

1. Der DODAG-Elternsatz MUSS eine Teilmenge des Kandidatennachbarsatzes sein.

2. Eine DODAG-Wurzel MUSS einen DODAG-Elternsatz der Größe Null haben.

3. Ein Knoten, der keine DODAG-Wurzel ist, KANN einen DODAG-Elternsatz mit einer Größe von größer oder gleich eins beibehalten.

4. Der bevorzugte DODAG-Elternteil eines Knotens MUSS Mitglied seines DODAG-Elternsatzes sein.

5. Der Rang eines Knotens MUSS größer sein als alle Elemente seines DODAG-Elternsatzes.

6. Wenn die Neighbor Unreachability Detection (NUD) [RFC4861] oder ein gleichwertiger Mechanismus feststellt, dass ein Nachbar nicht mehr erreichbar ist, DARF ein RPL-Knoten diesen Knoten NICHT im Kandidatennachbarsatz berücksichtigen, wenn er Routen berechnet und ankündigt, bis er feststellt, dass er wieder erreichbar ist. Routen durch einen nicht erreichbaren Nachbarn MÜSSEN aus der Routing-Tabelle entfernt werden.

Diese Regeln stellen sicher, dass es eine konsistente Teilordnung auf Knoten innerhalb des DODAG gibt. Solange sich die Knotenränge nicht ändern, stellt die Einhaltung der obigen Regeln sicher, dass die Route jedes Knotens zu einer DODAG-Wurzel schleifenfrei ist, da der Rang bei jedem Hop zur Wurzel abnimmt.

Die OF kann die Auswahl des Kandidatennachbarsatzes und des Elternsatzes leiten, wie in [RFC6552] diskutiert.

8.2.2. Nachbarn und Eltern über DODAG-Versionen hinweg

Die obigen Regeln regeln eine einzelne DODAG-Version. Die Regeln in diesem Abschnitt definieren, wie RPL arbeitet, wenn mehrere DODAG-Versionen vorhanden sind.

8.2.2.1. DODAG-Version

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

2. Ein Knoten ist Mitglied einer DODAG-Version, wenn jedes Element seines DODAG-Elternsatzes 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, deren Mitglied er nicht ist.

4. DODAG-Wurzeln KÖNNEN die DODAGVersionNumber, die sie ankündigen, erhöhen und somit zu einer neuen DODAG-Version wechseln. Wenn eine DODAG-Wurzel ihre DODAGVersionNumber erhöht, MUSS sie den Konventionen der Seriennummernarithmetik folgen, wie in Abschnitt 7 beschrieben. Ereignisse, die das Erhöhen 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 DODAGVersionNumber ankündigen, die höher ist als die höchste DODAGVersionNumber, die er gehört hat. Höher ist definiert als der Größer-als-Operator in Abschnitt 7.

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

Wenn der DODAG-Elternsatz auf einem Knoten, der keine Wurzel ist, leer wird (d. h. der letzte Elternteil wurde entfernt, wodurch der Knoten nicht mehr mit diesem DODAG verbunden ist), sollten die DODAG-Informationen erst nach Ablauf eines implementierungsspezifischen lokalen Timers unterdrückt werden. Während des Intervalls vor der Unterdrückung des "alten" DODAG-Zustands kann der Knoten beobachten, ob die DODAGVersionNumber erhöht wurde, sollten neue Eltern erscheinen. Dies hilft, vor der Möglichkeit von Schleifen zu schützen, die auftreten könnten, wenn dieser Knoten versehentlich der alten DODAG-Version in seinem eigenen früheren Sub-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, der die neue DODAGVersionNumber ankündigt, kann nicht zum Sub-DODAG eines Knotens gehören, der eine ältere DODAGVersionNumber ankündigt. Daher kann ein Knoten sicher einen Elternteil beliebigen Rangs mit einer neueren DODAGVersionNumber hinzufügen, ohne eine Schleife zu bilden.

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

Wann genau eine DODAG-Wurzel die DODAGVersionNumber erhöht, ist implementierungsabhängig und liegt außerhalb des Geltungsbereichs dieser Spezifikation. Beispiele sind das periodische Erhöhen der DODAGVersionNumber, bei administrativen Eingriffen oder bei Erkennung von verlorener Konnektivität oder DODAG-Ineffizienz auf Anwendungsebene.

Nachdem ein Knoten zu einer neuen DODAG-Version gewechselt ist und diese ankündigt, machen ihn die obigen Regeln unfähig, die vorherige DODAG-Version (vorherige 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 das Grounded-Bit NICHT setzen.

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

3. Ein Knoten, dessen DODAG-Elternsatz leer ist, KANN die DODAG-Wurzel eines schwebenden DODAG werden. Er KANN auch seine DAGPreference so einstellen, dass er weniger bevorzugt wird.

In einer Bereitstellung, die Nicht-LLN-Verbindungen verwendet, um eine Anzahl von LLN-Wurzeln zu föderieren, ist es möglich, RPL über diese Nicht-RPL-Verbindungen auszuführen und einen Router als "Backbone-Wurzel" zu verwenden. Die Backbone-Wurzel ist die virtuelle Wurzel des DODAG und exponiert einen Rang von BASE_RANK über das Backbone. Alle LLN-Wurzeln, die dieser Backbone-Wurzel untergeordnet sind, einschließlich der Backbone-Wurzel, wenn sie auch selbst als LLN-Wurzel dient, exponieren einen Rang von ROOT_RANK gegenüber dem 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 Zielfunktion und der Satz der angekündigten Routing-Metriken und Einschränkungen eines DAG bestimmen, wie ein Knoten seinen Nachbarsatz, Elternsatz und bevorzugte Eltern auswählt. Diese Auswahl bestimmt implizit auch den DODAG innerhalb eines DAG. Eine solche Auswahl kann administrative Präferenzen (Prf) sowie Metriken oder andere Überlegungen umfassen.

Wenn ein Knoten die Möglichkeit hat, einem bevorzugteren DODAG beizutreten und gleichzeitig andere Optimierungsziele zu erfüllen, wird der Knoten im Allgemeinen versuchen, dem bevorzugteren DODAG beizutreten, wie von der OF bestimmt. Wenn alles andere gleich ist, bleibt es der Implementierung überlassen, zu bestimmen, welcher DODAG am meisten bevorzugt wird (da, zur Erinnerung, ein Knoten nur einem DODAG pro RPL-Instanz beitreten darf).

8.2.2.4. Rang und Bewegung innerhalb einer DODAG-Version

1. Ein Knoten DARF KEINEN Rang ankündigen, der kleiner oder gleich irgendeinem Mitglied seines Elternsatzes innerhalb der DODAG-Version ist.

2. Ein Knoten KANN einen Rang ankündigen, der niedriger ist als seine vorherige Ankündigung innerhalb der DODAG-Version.

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

4. Ein Knoten KANN jederzeit wählen, einem anderen DODAG innerhalb einer RPL-Instanz beizutreten. Ein solcher Beitritt hat keine Rangeinschränkungen, es sei denn, dieser andere DODAG ist eine DODAG-Version, deren Mitglied dieser Knoten zuvor war; in diesem Fall muss die Regel des vorherigen Aufzählungspunktes (3) beachtet werden. Bis ein Knoten ein DIO überträgt, 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 gehört hat, die von geeigneten DODAG-Eltern angekündigt wurde, wählen, zur nächsten DODAG-Version innerhalb des DODAG zu migrieren.

Konzeptionell unterhält eine Implementierung einen DODAG-Elternsatz innerhalb der DODAG-Version. Bewegung beinhaltet Änderungen am DODAG-Elternsatz. Aufwärtsbewegung birgt nicht das Risiko, eine Schleife zu erzeugen, aber Abwärtsbewegung könnte dies tun, daher unterliegt dieser Vorgang zusätzlichen Einschränkungen.

Wenn ein Knoten zur nächsten DODAG-Version migriert, muss der DODAG-Elternsatz für die neue Version neu aufgebaut werden. Eine Implementierung könnte die Migration für eine angemessene Zeitspanne verschieben, um zu sehen, ob sich andere Nachbarn mit potenziell besseren Metriken, aber höherem Rang ankündigen. Ähnlich muss ein Knoten, wenn er in einen neuen DODAG springt, einen neuen DODAG-Elternsatz für diesen neuen DODAG konstruieren.

Wenn ein Knoten einen DODAG, an den er angeschlossen ist, nach unten bewegen muss, wodurch sein Rang erhöht wird, dann KANN er seine Routen vergiften und vor der Bewegung verzögern, wie in Abschnitt 8.2.2.5 beschrieben.

Ein Knoten darf jeder DODAG-Version beitreten, deren Mitglied er noch nie zuvor war, ohne 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 Rang höher als L+DAGMaxRankIncrease ankündigen darf. Diese Regel muss beachtet werden, um kein Schlupfloch zu schaffen, das es dem Knoten ermöglichen würde, seinen Rang effektiv bis zu INFINITE_RANK zu erhöhen, was Auswirkungen auf andere Knoten haben und ein ressourcenverschwendendes Count-to-Infinity-Szenario schaffen könnte.

8.2.2.5. Vergiftung (Poisoning)

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

2. Ein Knoten DARF KEINE Knoten mit einem Rang von INFINITE_RANK in seinem Elternsatz haben.

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

Wenn beobachtet wird, dass ein (ehemaliger) Elternteil einen Rang von INFINITE_RANK ankündigt, hat sich dieser (ehemalige) Elternteil vom DODAG getrennt und ist nicht mehr in der Lage, als Elternteil zu fungieren, noch gibt es eine Möglichkeit, dass ein anderer Knoten als einen Rang größer als INFINITE_RANK habend betrachtet werden kann. Daher kann dieser (ehemalige) Elternteil nicht mehr als Elternteil fungieren und wird aus dem Elternsatz entfernt.

8.2.2.6. Trennung (Detaching)

1. Ein Knoten, der nicht in der Lage ist, mit einem DODAG innerhalb einer gegebenen DODAG-Version verbunden zu bleiben, d. h. der keinen nicht-leeren Elternsatz 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 als Alternative zur Vergiftung ankündigen.

8.2.2.7. Einem Elternteil folgen

1. Wenn ein Knoten ein DIO von einem seiner DODAG-Eltern erhält, das anzeigt, dass der Elternteil den DODAG verlassen hat, SOLLTE dieser Knoten in seinem aktuellen DODAG über einen alternativen DODAG-Elternteil 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 einen alternativen Elternteil, sollte aber dem Elternteil folgen, wenn es keine anderen Optionen gibt.

8.2.3. DIO-Nachrichtenkommunikation

Wenn eine DIO-Nachricht empfangen wird, muss der empfangende Knoten zunächst bestimmen, ob die DIO-Nachricht zur weiteren Verarbeitung angenommen werden soll oder nicht, und anschließend die DIO-Nachricht zur weiteren Verarbeitung vorlegen, wenn sie geeignet ist.

1. Wenn die DIO-Nachricht fehlerhaft ist, ist die DIO-Nachricht nicht für die weitere Verarbeitung geeignet und ein Knoten MUSS sie stillschweigend verwerfen. (Siehe Abschnitt 18 für Fehlerprotokollierung).

2. Wenn der Absender der DIO-Nachricht ein Mitglied des Kandidatennachbarsatzes ist und die DIO-Nachricht nicht fehlerhaft ist, MUSS der Knoten das DIO verarbeiten.

8.2.3.1. Verarbeitung von DIO-Nachrichten

Wenn DIO-Nachrichten von Kandidatennachbarn empfangen werden, können die Nachbarn zu DODAG-Eltern befördert werden, indem die Regeln der DODAG-Entdeckung wie in Abschnitt 8.2 beschrieben befolgt werden. Wenn ein Knoten einen Nachbarn in den DODAG-Elternsatz aufnimmt, wird der Knoten über den neuen DODAG-Elternknoten an den DODAG angeschlossen.

Der am meisten bevorzugte Elternteil sollte verwendet werden, um einzuschränken, welche anderen Knoten DODAG-Eltern werden können. Einige Knoten im DODAG-Elternsatz können einen Rang haben, der kleiner oder gleich dem am meisten bevorzugten DODAG-Elternteil ist. (Dieser Fall kann beispielsweise auftreten, wenn ein energiebeschränktes Gerät einen niedrigeren Rang hat, aber gemäß einem Optimierungsziel vermieden werden sollte, was zu einem bevorzugteren Elternteil mit einem höheren Rang führt.)

8.3. DIO-Übertragung

RPL-Knoten übertragen DIOs unter Verwendung eines Trickle-Timers [RFC6206]. Ein DIO von einem Absender mit einem niedrigeren DAGRank, das keine Änderungen am Elternsatz, bevorzugten Elternteil oder Rang des Empfängers verursacht, SOLLTE in Bezug auf den Trickle-Timer als konsistent betrachtet werden.

Die folgenden Pakete und Ereignisse MÜSSEN in Bezug auf den Trickle-Timer als Inkonsistenzen betrachtet werden und dazu führen, dass der Trickle-Timer zurückgesetzt wird:

• Wenn ein Knoten beim Weiterleiten eines Pakets eine Inkonsistenz feststellt, wie in Abschnitt 11.2 detailliert beschrieben.

• Wenn ein Knoten eine Multicast-DIS-Nachricht ohne Option für angeforderte Informationen empfängt, es sei denn, ein DIS-Flag schränkt dieses Verhalten ein.

• Wenn ein Knoten ein Multicast-DIS mit einer Option für angeforderte Informationen empfängt und der Knoten alle Prädikate in der Option für angeforderte Informationen erfüllt, es sei denn, ein DIS-Flag schränkt dieses Verhalten ein.

• Wenn ein Knoten einer neuen DODAG-Version beitritt (z. B. durch Aktualisieren seiner DODAGVersionNumber, Beitritt zu einer neuen RPL-Instanz usw.).

Beachten Sie, dass diese Liste nicht erschöpfend ist und eine Implementierung andere Nachrichten oder Ereignisse als Inkonsistenzen betrachten KANN.

Ein Knoten SOLLTE seinen DIO-Trickle-Timer NICHT als Reaktion auf Unicast-DIS-Nachrichten zurücksetzen. Wenn ein Knoten ein Unicast-DIS ohne Option für angeforderte Informationen empfängt, MUSS er als Antwort ein DIO an den Absender unicasten. Dieses DIO MUSS eine DODAG-Konfigurationsoption enthalten. Wenn ein Knoten eine Unicast-DIS-Nachricht mit einer Option für angeforderte Informationen empfängt und die Prädikate dieser Option für angeforderte Informationen erfüllt, MUSS er als Antwort ein DIO an den Absender unicasten. Dieses Unicast-DIO MUSS eine DODAG-Konfigurationsoption enthalten. Somit KANN ein Knoten eine Unicast-DIS-Nachricht an einen potenziellen DODAG-Elternteil senden, um die DODAG-Konfiguration und andere Parameter zu sondieren.

8.3.1. Trickle-Parameter

Die Konfigurationsparameter des Trickle-Timers sind wie folgt spezifiziert:

• Imin: aus der DIO-Nachricht als (2^DIOIntervalMin) ms gelernt. Der Standardwert von DIOIntervalMin ist DEFAULT_DIO_INTERVAL_MIN.

• Imax: aus der DIO-Nachricht als DIOIntervalDoublings gelernt. Der Standardwert von DIOIntervalDoublings ist DEFAULT_DIO_INTERVAL_DOUBLINGS.

• k: aus der DIO-Nachricht als DIORedundancyConstant gelernt. Der Standardwert von DIORedundancyConstant ist DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, wenn k den Wert 0x00 hat, ist dies als Redundanzkonstante von unendlich in RPL zu behandeln, d. h. Trickle unterdrückt niemals Nachrichten.

8.4. DODAG-Auswahl

Die DODAG-Auswahl ist implementierungs- und OF-abhängig. Um unregelmäßige Bewegungen zu begrenzen und bei gleichen Metriken SOLLTEN Knoten ihre vorherige Auswahl beibehalten. Außerdem SOLLTEN Knoten ein Mittel bereitstellen, um einen Elternteil herauszufiltern, dessen Verfügbarkeit als schwankend erkannt wird, zumindest wenn stabilere Optionen verfügbar sind.

Wenn eine Verbindung zu einem geerdeten DODAG aus Sicherheits- oder anderen Gründen nicht möglich oder bevorzugt ist, KÖNNEN verstreute DODAGs so weit wie möglich zu größeren DODAGs aggregieren, um Konnektivität innerhalb des LLN zu ermöglichen.

Ein Knoten SOLLTE überprüfen, ob bidirektionale Konnektivität und ausreichende Verbindungsqualität mit einem Kandidatennachbarn verfügbar sind, bevor er diesen Kandidaten als DODAG-Elternteil in Betracht zieht.

8.5. Betrieb als Blattknoten

In einigen Fällen kann sich ein RPL-Knoten nur als Blattknoten an einen DODAG anschließen. Ein Beispiel für einen solchen Fall ist, wenn ein Knoten die OF oder die angekündigte Metrik/Einschränkung der RPL-Instanz nicht versteht oder nicht unterstützt (Richtlinie). Wie in Abschnitt 18.6, bezogen auf die Richtlinienfunktion, spezifiziert, kann der Knoten dem DODAG entweder als Blattknoten beitreten oder dem DODAG nicht beitreten. Wie in Abschnitt 18.5 erwähnt, wird dann empfohlen, einen Fehler zu protokollieren.

Ein Blattknoten erweitert die DODAG-Konnektivität nicht; in einigen Fällen muss der Blattknoten jedoch möglicherweise immer noch gelegentlich DIOs übertragen, insbesondere wenn der Blattknoten möglicherweise nicht immer als Blattknoten agiert hat und eine Inkonsistenz festgestellt wird.

Ein Knoten, der als Blattknoten arbeitet, muss die folgenden Regeln befolgen:

1. Er DARF KEINE DIOs übertragen, die den DAG-Metrik-Container enthalten.

2. Seine DIOs MÜSSEN einen DAGRank von INFINITE_RANK ankündigen.

3. Er KANN die DIO-Übertragung unterdrücken, es sei denn, die DIO-Übertragung wurde aufgrund der Erkennung einer Inkonsistenz beim Weiterleiten eines Pakets oder als Reaktion auf eine Unicast-DIS-Nachricht ausgelöst; in diesem Fall DARF die DIO-Übertragung NICHT unterdrückt werden.

4. Er KANN Unicast-DAOs übertragen, wie in Abschnitt 9.2 beschrieben.

5. Er KANN Multicast-DAOs an die '1-Hop'-Nachbarschaft übertragen, wie in Abschnitt 9.10 beschrieben.

Ein besonderer Fall, der erfordert, dass ein Blattknoten ein DIO sendet, ist, wenn dieser Blattknoten ein früheres Mitglied eines anderen DODAG war und ein anderer Knoten eine Nachricht unter der Annahme der alten Topologie weiterleitet, was eine Inkonsistenz auslöst. Der Blattknoten muss ein DIO übertragen, um die Inkonsistenz zu reparieren. Beachten Sie, dass aufgrund der verlustbehafteten Natur von LLNs, selbst wenn der Blattknoten seine Routen optimistisch vergiftet hat, indem er einen Rang von INFINITE_RANK im alten DODAG angekündigt hat, bevor er ein Blattknoten wurde, diese Ankündigung verloren gegangen sein kann und ein Blattknoten in der Lage sein muss, später ein DIO zu senden, um die Inkonsistenz zu reparieren.

Im Allgemeinen DARF sich der Blattknoten NICHT als Router ankündigen (d. h. DIOs senden).

8.6. Administrativer Rang

In einigen Fällen kann es vorteilhaft sein, den von einem Knoten angekündigten Rang über den von der OF berechneten hinaus basierend auf einer implementierungsspezifischen Richtlinie und Eigenschaften des Knotens anzupassen. Zum Beispiel sollte ein Knoten mit begrenzter Batterie ein Blatt sein, es sei denn, es gibt keine andere Wahl, und kann dann die von der OF spezifizierte Rangberechnung erhöhen, um einen übertriebenen Rang zu exponieren.