1.1. Design Principles (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 möglicherweise gegensätzliche Einschränkungen oder Leistungskriterien bedienen. Dieses Dokument definiert, wie eine einzelne Instanz arbeitet.

Um in einem breiten Spektrum von LLN-Anwendungsbereichen 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 Einhaltung von Einschränkungen. Dieses Dokument beschreibt die Betriebsart von RPL. Andere Begleitdokumente spezifizieren Routing-Zielfunktionen (Objective Functions). Eine RPL-Implementierung zur Unterstützung einer bestimmten LLN-Anwendung enthält die erforderlichen Zielfunktion(en), 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 Elternknoten verwendet werden kann. RPL erwartet, dass während der Elternauswahlphase ein externer Mechanismus ausgelöst wird, um Verbindungseigenschaften und Nachbar-Erreichbarkeit 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]. Im Allgemeinen 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 Steuerinformationen, die als "RPL-Paketinformationen" bezeichnet werden, in Datenpaketen zuzugreifen und diese zu transportieren. Die RPL-Paketinformationen sind in Abschnitt 11.2 definiert und ermöglichen 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-Paketinformationen verringert. Zukünftige Begleitspezifikationen könnten alternative Wege vorschlagen, um die RPL-Paketinformationen in den IPv6-Paketen zu transportieren, und könnten die RPL-Paketinformationen 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 weitgehend autonom arbeiten können. Dieser Mechanismus verwendet Trickle [RFC6206], um die Verbreitung zu optimieren, wie in Abschnitt 8.3 beschrieben.

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 einspeisen, 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 verbreiten, wie z. B. die [RFC4861] Prefix Information Option (PIO) und die [RFC4191] Route Information Option (RIO). ND-Informationen, die von RPL verbreitet werden, behalten ihre ursprüngliche Semantik für Router-zu-Host bei, mit begrenzten Erweiterungen für Router-zu-Router, obwohl sie nicht mit Routing-Ankündigungen verwechselt werden dürfen und niemals direkt in ein anderes Routing-Protokoll umverteilt 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] angegeben. Als Router kann der RPL-Knoten die Informationen aus den Optionen wie für die spezifische Verbindung erforderlich ankündigen, zum Beispiel 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 Gebäudeautomatisierungs-, Heimautomatisierungs-, Industrie- und städtische Anwendungsszenarien geeignet sind.