1. Einführung

Low-Power und Lossy Networks (LLNs) bestehen größtenteils aus eingeschränkten Knoten (mit begrenzter Rechenleistung, Speicher und manchmal Energie, wenn sie batteriebetrieben sind oder Energy Harvesting nutzen). Diese Router sind durch verlustbehaftete Verbindungen miteinander verbunden, die typischerweise nur niedrige Datenraten unterstützen und meist instabil sind mit relativ niedrigen Paketzustellraten. Ein weiteres Merkmal solcher Netzwerke ist, dass die Verkehrsmuster nicht einfach Punkt-zu-Punkt sind, sondern in vielen Fällen Punkt-zu-Mehrpunkt oder Mehrpunkt-zu-Punkt. Darüber hinaus können solche Netzwerke potenziell bis zu Tausende von Knoten umfassen. Diese Eigenschaften stellen einzigartige Herausforderungen an eine Routing-Lösung: Die IETF ROLL-Arbeitsgruppe hat anwendungsspezifische Routing-Anforderungen für ein Routing-Protokoll für Low-Power und Lossy Networks (LLN) definiert, die in [RFC5867], [RFC5826], [RFC5673] und [RFC5548] spezifiziert sind.

Dieses Dokument spezifiziert das IPv6-Routing-Protokoll für LLNs (RPL). Beachten Sie, dass RPL zwar gemäß den in den oben genannten Anforderungsdokumenten festgelegten Anforderungen spezifiziert wurde, seine Verwendung jedoch keineswegs auf diese Anwendungen beschränkt ist.

1.1. Designprinzipien

RPL wurde mit dem Ziel entwickelt, die in [RFC5867], [RFC5826], [RFC5673] und [RFC5548] dargelegten Anforderungen zu erfüllen.

Ein Netzwerk kann mehrere Instanzen von RPL gleichzeitig ausführen. Jede solche Instanz kann unterschiedliche und potenziell antagonistische Einschränkungen oder Leistungskriterien bedienen. Dieses Dokument definiert, wie eine einzelne Instanz arbeitet.

Um in einem breiten Spektrum von LLN-Anwendungsdomänen nützlich zu sein, trennt RPL die Paketverarbeitung und -weiterleitung vom Ziel der Routing-Optimierung. Beispiele für solche Ziele sind die Minimierung des Energieverbrauchs, die Minimierung der Latenz oder die Erfüllung von Einschränkungen. Dieses Dokument beschreibt die Betriebsart von RPL. Andere Begleitdokumente spezifizieren Routing-Zielfunktionen. Eine RPL-Implementierung zur Unterstützung einer bestimmten LLN-Anwendung wird die erforderliche(n) Zielfunktion(en) enthalten, wie von der Anwendung gefordert.

RPL-Operationen erfordern bidirektionale Verbindungen. In einigen LLN-Szenarien können diese Verbindungen asymmetrische Eigenschaften aufweisen. Es ist erforderlich, dass die Erreichbarkeit eines Routers überprüft wird, bevor der Router als Elternteil verwendet werden kann. RPL erwartet, dass während der Elternauswahlphase ein externer Mechanismus ausgelöst wird, um Verbindungseigenschaften und Nachbarschaftserreichbarkeit zu überprüfen. Neighbor Unreachability Detection (NUD) ist ein solcher Mechanismus, aber Alternativen sind möglich, einschließlich Bidirectional Forwarding Detection (BFD) [RFC5881] und Hinweise von unteren Schichten über Layer-2 (L2)-Trigger wie [RFC5184]. Generell wird ein Erkennungsmechanismus bevorzugt, der auf Verkehr reagiert, um die Kosten für die Überwachung nicht genutzter Verbindungen zu minimieren.

RPL erwartet auch einen externen Mechanismus, um auf einige Kontrollinformationen, die als "RPL Packet Information" bezeichnet werden, in Datenpaketen zuzugreifen und diese zu transportieren. Die RPL Packet Information ist in Abschnitt 11.2 definiert und ermöglicht die Zuordnung eines Datenpakets zu einer RPL-Instanz und die Validierung von RPL-Routing-Zuständen. Die RPL-Option [RFC6553] ist ein Beispiel für einen solchen Mechanismus. Der Mechanismus ist für alle Pakete erforderlich, außer wenn striktes Source Routing verwendet wird (d. h. für Pakete, die im Non-Storing-Modus nach unten gehen, wie in Abschnitt 9 weiter ausgeführt), was von Natur aus Endlosschleifen verhindert und die Notwendigkeit für die RPL Packet Information verringert. Zukünftige Begleitspezifikationen können alternative Wege vorschlagen, um die RPL Packet Information in den IPv6-Paketen zu transportieren, und können die RPL Packet Information erweitern, um zusätzliche Funktionen zu unterstützen.

RPL bietet einen Mechanismus zur Verbreitung von Informationen über die dynamisch gebildete Netzwerktopologie. Diese Verbreitung ermöglicht eine minimale Konfiguration in den Knoten, sodass die Knoten größtenteils autonom arbeiten können. Dieser Mechanismus verwendet Trickle [RFC6206], um die Verbreitung wie in Abschnitt 8.3 beschrieben zu optimieren.

In einigen Anwendungen stellt RPL Topologien von Routern zusammen, die unabhängige Präfixe besitzen. Diese Präfixe können je nach Herkunft der Router aggregierbar sein oder nicht. Ein Präfix, das einem Router gehört, wird als On-Link angekündigt.

RPL führt auch die Fähigkeit ein, ein Subnetz mit einem gemeinsamen Präfix zu binden und innerhalb dieses Subnetzes zu routen. Eine Quelle kann Informationen über das Subnetz injizieren, die von RPL verbreitet werden sollen, und diese Quelle ist für dieses Subnetz autoritativ. Da viele LLN-Verbindungen nicht-transitive Eigenschaften haben, darf ein gemeinsames Präfix, das RPL über das Subnetz verbreitet, nicht als On-Link angekündigt werden.

Insbesondere kann RPL IPv6 Neighbor Discovery (ND)-Informationen wie die [RFC4861] Prefix Information Option (PIO) und die [RFC4191] Route Information Option (RIO) verbreiten. ND-Informationen, die von RPL verbreitet werden, behalten ihre gesamte ursprüngliche Router-zu-Host-Semantik bei, mit begrenzten Erweiterungen für Router-zu-Router, obwohl sie nicht mit Routing-Ankündigungen verwechselt werden dürfen und niemals direkt in einem anderen Routing-Protokoll neu verteilt werden dürfen. Ein RPL-Knoten kombiniert oft Host- und Router-Verhalten. Als Host verarbeitet er die Optionen wie in [RFC4191], [RFC4861], [RFC4862] und [RFC6275] spezifiziert. Als Router kann der RPL-Knoten die Informationen aus den Optionen wie für die spezifische Verbindung erforderlich ankündigen, beispielsweise in einer ND Router Advertisement (RA)-Nachricht, obwohl der genaue Vorgang außerhalb des Geltungsbereichs liegt.

Eine Reihe von Begleitdokumenten zu dieser Spezifikation wird weitere Anleitungen in Form von Anwendbarkeitserklärungen geben, die eine Reihe von Betriebspunkten spezifizieren, die für die Anwendungsszenarien Gebäudeautomation, Hausautomation, Industrie und Stadt geeignet sind.

1.2. Erwartungen an den Verbindungsschicht-Typ

In Übereinstimmung mit der Schichtenarchitektur von IP verlässt sich RPL nicht auf bestimmte Merkmale einer spezifischen Verbindungsschicht-Technologie. RPL ist so konzipiert, dass es über eine Vielzahl verschiedener Verbindungsschichten arbeiten kann, einschließlich solcher, die eingeschränkt, potenziell verlustbehaftet oder typischerweise in Verbindung mit stark eingeschränkten Host- oder Routergeräten verwendet werden, wie z. B., aber nicht beschränkt auf, Low-Power-Wireless- oder PLC (Power Line Communication)-Technologien.

Implementierer können [RFC3819] als nützliche Referenz bei der Gestaltung einer Verbindungsschicht-Schnittstelle zwischen RPL und einer bestimmten Verbindungsschicht-Technologie finden.