11. Paketweiterleitung und Schleifenvermeidung/-erkennung

11.1. Vorschläge für die Paketweiterleitung

Dieses Dokument spezifiziert ein Routing-Protokoll. Diese nicht-normativen Vorschläge werden bereitgestellt, um beim Design einer Weiterleitungsimplementierung zu helfen, indem illustriert wird, wie eine solche Implementierung mit RPL funktionieren könnte.

Bei der Weiterleitung eines Pakets an ein Ziel wird der Auswahl eines Next-Hop-Nachfolgers wie folgt Vorrang gegeben:

1. Diese Spezifikation deckt nur ab, wie ein Nachfolger aus der DODAG-Version ausgewählt wird, die mit der im IPv6-Header des weitergeleiteten Pakets markierten RPLInstanceID übereinstimmt. Routing außerhalb der Instanz kann durchgeführt werden, solange zusätzliche Regeln eingeführt werden, wie z.B. strikte Ordnung von Instanzen und Routing-Protokollen zum Schutz vor Schleifen. Solche Regeln können in einem separaten Dokument definiert werden.

2. Wenn eine lokale administrative Präferenz eine Route bevorzugt, die von einem anderen Routing-Protokoll als RPL gelernt wurde, dann verwenden Sie diesen Nachfolger.

3. Wenn der Paket-Header eine Quellroute spezifiziert, indem er einen RH4-Header wie in [RFC6554] spezifiziert enthält, dann verwenden Sie diese Route. Wenn der Knoten das Paket mit dieser spezifizierten Quellroute nicht weiterleiten kann, dann sollte dieses Paket verworfen werden. Der Knoten KANN einen Fehler protokollieren. Der Knoten kann eine ICMPv6-Fehlermeldung im Source Routing Header an die Quelle des Pakets senden (siehe Abschnitt 20.18).

4. Wenn es einen Eintrag in der Routing-Tabelle gibt, der mit dem Ziel übereinstimmt, das aus einer Multicast-Zielankündigung gelernt wurde (z.B. das Ziel ist ein One-Hop-Nachbar), dann verwenden Sie diesen Nachfolger.

5. Wenn es einen Eintrag in der Routing-Tabelle gibt, der mit dem Ziel übereinstimmt, das aus einer Unicast-Zielankündigung gelernt wurde (z.B. das Ziel befindet sich unten im Sub-DODAG), dann verwenden Sie diesen Nachfolger. Wenn es DAO Path Control-Bits gibt, die mit mehreren Nachfolgern assoziiert sind, dann konsultieren Sie die Path Control-Bits, um die Nachfolger bei der Auswahl nach Präferenz zu ordnen. Wenn für ein gegebenes DAO Path Control-Bit mehrere Nachfolger aufgezeichnet sind, die dieses Bit behauptet haben, sollte dem Nachfolger Vorrang gegeben werden, der dieses Bit zuletzt behauptet hat.

6. Wenn es eine DODAG-Version gibt, die eine Route zu einem Präfix anbietet, das mit dem Ziel übereinstimmt, dann wählen Sie einen dieser DODAG-Eltern als Nachfolger gemäß der OF und den Routing-Metriken aus.

7. Jeder andere noch nicht versuchte DODAG-Elternteil kann für den nächsten Versuch gewählt werden, ein Unicast-Paket weiterzuleiten, wenn keine bessere Übereinstimmung existiert.

8. Schließlich wird das Paket verworfen. ICMP Destination Unreachable KANN aufgerufen werden (eine Inkonsistenz wird erkannt).

Das Hop Limit MUSS bei der Weiterleitung gemäß [RFC2460] dekrementiert werden.

Beachten Sie, dass der gewählte Nachfolger NICHT der Nachbar sein DARF, der der Vorgänger des Pakets war (Split Horizon), außer in dem Fall, wo beabsichtigt ist, dass das Paket von einer Aufwärts- in eine Abwärtsrichtung wechselt, wie durch die Routing-Tabelle des Knotens bestimmt, der die Änderung vornimmt, wie z.B. das Umschalten von DIO-Routen zu DAO-Routen, wenn das Ziel näher kommt, um die Reise zum Ziel fortzusetzen.

11.2. Schleifenvermeidung und -erkennung

RPL-Schleifenvermeidungsmechanismen werden einfach gehalten und sind so konzipiert, dass sie Churn und Zustände minimieren. Schleifen können aus einer Reihe von Gründen entstehen, z.B. Verlust von Kontrollpaketen. RPL enthält eine reaktive Schleifenerkennungstechnik, die vor einem Zusammenbruch schützt und die Reparatur defekter Pfade auslöst.

Die RPL-Schleifenerkennung verwendet RPL Packet Information, die innerhalb der Datenpakete transportiert wird, und verlässt sich auf einen externen Mechanismus wie [RFC6553], der die RPL Packet Information in einen IPv6 Hop-by-Hop Option Header platziert.

Der Inhalt der RPL Packet Information ist wie folgt definiert:

• Down 'O': 1-Bit-Flag, das anzeigt, ob das Paket erwartet wird, nach oben oder unten fortzuschreiten. Ein Router setzt das 'O'-Flag, wenn das Paket erwartet wird, nach unten fortzuschreiten (unter Verwendung von DAO-Routen), und löscht es, wenn er in Richtung der DODAG-Wurzel weiterleitet (zu einem Knoten mit einem niedrigeren Rang). Ein Host oder RPL-Blattknoten MUSS das 'O'-Flag auf 0 setzen.

• Rank-Error 'R': 1-Bit-Flag, das anzeigt, ob ein Rangfehler erkannt wurde. Ein Rangfehler wird erkannt, wenn es eine Diskrepanz in den relativen Rängen und der Richtung gibt, wie im 'O'-Bit angezeigt. Ein Host oder RPL-Blattknoten MUSS das 'R'-Bit auf 0 setzen.

• Forwarding-Error 'F': 1-Bit-Flag, das anzeigt, dass dieser Knoten das Paket nicht weiter zum Ziel weiterleiten kann. Das 'F'-Bit könnte von einem Kindknoten gesetzt werden, der keine Route zum Ziel für ein Paket mit gesetztem Down 'O'-Bit hat. Ein Host oder RPL-Blattknoten MUSS das 'F'-Bit auf 0 setzen.

• RPLInstanceID: 8-Bit-Feld, das die DODAG-Instanz anzeigt, entlang der das Paket gesendet wird.

• SenderRank: 16-Bit-Feld, das von der Quelle auf Null gesetzt wird und von einem Router, der innerhalb des RPL-Netzwerks weiterleitet, auf DAGRank(rank) gesetzt wird.

11.2.1. Quellknoten-Betrieb

Wenn die Quelle die RPLInstanceID kennt, die für das Paket bevorzugt wird, dann MUSS sie das mit dem Paket assoziierte RPLInstanceID-Feld entsprechend setzen; andernfalls MUSS sie es auf die RPL_DEFAULT_INSTANCE setzen.

11.2.2. Router-Betrieb

11.2.2.1. Instanz-Weiterleitung

Die RPLInstanceID wird von der Quelle mit dem Paket assoziiert. Diese RPLInstanceID MUSS mit der RPL-Instanz übereinstimmen, auf die das Paket von jedem Knoten platziert wird, sei es ein Host oder Router. Die RPLInstanceID ist Teil der RPL Packet Information.

Ein RPL-Router, der ein Paket im RPL-Netzwerk weiterleitet, MUSS prüfen, ob das Paket die RPL Packet Information enthält. Wenn nicht, dann MUSS der RPL-Router die RPL Packet Information einfügen. Wenn der Router ein Ingress-Router ist, der das Paket in das RPL-Netzwerk injiziert, MUSS der Router das RPLInstanceID-Feld in der RPL Packet Information setzen. Die Details, wie dieser Router die Abbildung auf eine RPLInstanceID bestimmt, liegen außerhalb des Geltungsbereichs dieser Spezifikation und bleiben zukünftigen Spezifikationen überlassen.

Ein Router, der ein Paket außerhalb des RPL-Netzwerks weiterleitet, MUSS die RPL Packet Information entfernen.

Wenn ein Router ein Paket empfängt, das eine gegebene RPLInstanceID spezifiziert, und der Knoten das Paket entlang des mit dieser Instanz assoziierten DODAG weiterleiten kann, dann MUSS der Router dies tun und den RPLInstanceID-Wert unverändert lassen.

Wenn ein Knoten ein Paket nicht entlang des mit der RPLInstanceID assoziierten DODAG weiterleiten kann, dann SOLLTE der Knoten das Paket verwerfen und eine ICMP-Fehlermeldung senden.

11.2.2.2. DAG-Inkonsistenz-Schleifenerkennung

Der DODAG ist inkonsistent, wenn die Richtung eines Pakets nicht mit der Rangbeziehung übereinstimmt. Ein Empfänger erkennt eine Inkonsistenz, wenn er ein Paket empfängt mit entweder:

• dem 'O'-Bit gesetzt (auf Down) von einem Knoten eines höheren Rangs.

• dem 'O'-Bit gelöscht (für Up) von einem Knoten eines niedrigeren Rangs.

Wenn die DODAG-Wurzel die DODAGVersionNumber erhöht, kann sich eine temporäre Rang-Diskontinuität zwischen der nächsten DODAG-Version und der vorherigen DODAG-Version bilden, insbesondere wenn Knoten ihren Rang in der nächsten DODAG-Version anpassen und ihre Migration in die nächste DODAG-Version aufschieben. Ein Router, der noch Mitglied der vorherigen DODAG-Version ist, kann wählen, ein Paket an einen (zukünftigen) Elternteil weiterzuleiten, der in der nächsten DODAG-Version ist. In einigen Fällen könnte dies dazu führen, dass der Elternteil eine Inkonsistenz erkennt, weil die Rangordnung in der vorherigen DODAG-Version nicht unbedingt dieselbe ist wie in der nächsten DODAG-Version, und das Paket als nicht vorwärtskommend beurteilt werden kann. Wenn der sendende Router weiß, dass der gewählte Nachfolger bereits der nächsten DODAG-Version beigetreten ist, dann MUSS der sendende Router den SenderRank auf INFINITE_RANK aktualisieren, während er die Pakete über die Diskontinuität in die nächste DODAG-Version weiterleitet, um eine falsche Erkennung von Ranginkonsistenz zu vermeiden.

Eine Inkonsistenz entlang des Pfades wird nicht als kritischer Fehler betrachtet und das Paket kann fortgesetzt werden. Jedoch sollte eine zweite Erkennung entlang des Pfades desselben Pakets nicht auftreten und das Paket MUSS verworfen werden.

Dieser Prozess wird durch das mit dem Paket assoziierte Rank-Error-Bit gesteuert. Wenn eine Inkonsistenz an einem Paket erkannt wird, wenn das Rank-Error-Bit nicht gesetzt war, dann wird das Rank-Error-Bit gesetzt. Wenn es gesetzt war, MUSS das Paket verworfen werden und der Trickle-Timer MUSS zurückgesetzt werden.

11.2.2.3. DAO-Inkonsistenz-Erkennung und -Wiederherstellung

DAO-Inkonsistenz-Schleifenwiederherstellung ist ein Mechanismus, der nur für den Storing-Betriebsmodus gilt.

Im Non-Storing-Modus werden die Pakete quellgeroutet zum Ziel, und DAO-Inkonsistenzen werden nicht lokal korrigiert. Stattdessen wird ein ICMP-Fehler mit einem neuen Code "Error in Source Routing Header" zurück an die Wurzel gesendet. Die Nachricht "Error in Source Routing Header" hat dasselbe Format wie die "Destination Unreachable Message", wie in [RFC4443] spezifiziert. Der Teil des aufrufenden Pakets, der in der ICMP-Nachricht zurückgesendet wird, sollte zumindest bis zum Routing-Header aufzeichnen, und der Routing-Header sollte von diesem Knoten konsumiert werden, so dass das Ziel im IPv6-Header der nächste Hop ist, den dieser Knoten nicht erreichen konnte.

Eine DAO-Inkonsistenz tritt auf, wenn ein Router eine Abwärts-Route hat, die zuvor von einer DAO-Nachricht über ein Kind gelernt wurde, aber diese Abwärts-Route im Kind nicht mehr gültig ist, z.B. weil dieser zugehörige Zustand im Kind bereinigt wurde. Mit DAO-Inkonsistenz-Schleifenwiederherstellung kann ein Paket verwendet werden, um die veralteten DAO-Zustände entlang eines Sub-DODAG rekursiv zu erkunden und zu bereinigen.

Im Allgemeinen sollte ein Paket, das nach unten geht, niemals wieder nach oben gehen. Wenn DAO-Inkonsistenz-Schleifenwiederherstellung angewendet wird, dann SOLLTE der Router das Paket an den Elternteil zurücksenden, der es übergeben hat, mit gesetztem Forwarding-Error 'F'-Bit und unberührtem 'O'-Bit. Andernfalls MUSS der Router das Paket stillschweigend verwerfen.

Bei Empfang eines Pakets mit gesetztem Forwarding-Error-Bit MUSS der Knoten die Routing-Zustände entfernen, die die Weiterleitung an diesen Nachbarn verursacht haben, das Forwarding-Error-Bit löschen und versuchen, das Paket erneut zu senden. Das Paket kann an einen alternativen Nachbarn gesendet werden, nach Ablauf eines benutzerkonfigurierbaren implementierungsspezifischen Timers. Wenn dieser alternative Nachbar immer noch einen inkonsistenten DAO-Zustand über diesen Knoten hat, wird der Prozess rekursiv, dieser Knoten wird das Forwarding-Error 'F'-Bit setzen, und der Routing-Zustand im alternativen Nachbarn wird ebenfalls bereinigt.