16. Zusammenfassung der Anforderungen für interoperable Implementierungen

Dieser Abschnitt fasst die grundlegende Interoperabilität zusammen und verweist auf normativen Text für RPL-Implementierungen, die in einem von drei Hauptmodi arbeiten. Von Implementierungen wird erwartet, dass sie entweder keine Abwärtsrouten, nur den Non-Storing-Modus oder nur den Storing-Modus unterstützen. Ein vierter Modus, der Betrieb als Blatt, ist ebenfalls möglich.

Implementierungen, die dieser Spezifikation entsprechen, können unterschiedliche Teilmengen von Fähigkeiten enthalten, wie es für das Anwendungsszenario angemessen ist. Es ist wichtig für den Implementierer, ein Interoperabilitätsniveau zu unterstützen, das mit dem übereinstimmt, was vom Anwendungsszenario gefordert wird. Zu diesem Zweck können über diese Spezifikation hinaus weitere Anleitungen bereitgestellt werden (z.B. als Anwendbarkeitserklärungen), und es wird verstanden, dass solche weiteren Anleitungen in einigen Fällen Teile dieser Spezifikation außer Kraft setzen können.

16.1. Gemeinsame Anforderungen

In einem allgemeinen Fall kann das höchste Maß an Interoperabilität erreicht werden, wenn alle Knoten in einem RPL-LLN kooperieren, um denselben MOP, dieselbe OF, dieselben Metriken und Einschränkungen zu verwenden, und somit in der Lage sind, als RPL-Router zu agieren. Wenn ein Knoten nicht in der Lage ist, ein RPL-Router zu sein, kann es möglich sein, in einer eingeschränkteren Weise als RPL-Blatt zu interagieren.

Alle RPL-Implementierungen müssen die Verwendung von RPL-Paketinformationen unterstützen, die innerhalb von Datenpaketen transportiert werden (Abschnitt 11.2). Ein solcher Mechanismus ist in [RFC6553] beschrieben.

RPL-Implementierungen müssen die Verwendung von Neighbor Unreachability Detection (NUD) oder einem gleichwertigen Mechanismus unterstützen, um die Erreichbarkeit benachbarter RPL-Knoten aufrechtzuerhalten (Abschnitt 8.2.1). Alternative Mechanismen können auf die eingeschränkten Fähigkeiten der Implementierung optimiert sein, wie z.B. Hinweise von der Verbindungsschicht.

Diese Spezifikation bietet Mittel, um eine PIO zu erhalten und somit eine IPv6-Adresse zu bilden. Wenn dieser Mechanismus verwendet wird, kann es notwendig sein, Adressauflösung und Erkennung doppelter Adressen durch einen externen Prozess durchzuführen, wie z.B. IPv6 ND [RFC4861] oder 6LoWPAN ND [6LOWPAN-ND].

16.2. Betrieb als RPL-Blattknoten (Nur)

• Eine Implementierung eines Blattknotens (nur) nimmt niemals als RPL-Router teil. Interoperable Implementierungen von Blattknoten verhalten sich wie in Abschnitt 8.5 zusammengefasst.

• Die Unterstützung einer bestimmten MOP-Kodierung ist nicht erforderlich, obwohl, wenn der Blattknoten DAO-Nachrichten sendet, um Abwärtsrouten einzurichten, der Blattknoten dies in einer Weise tun sollte, die mit dem durch den MOP angezeigten Betriebsmodus konsistent ist.

• Die Unterstützung einer bestimmten OF ist nicht erforderlich.

• Zusammenfassend lässt sich sagen, dass ein Blattknoten im Allgemeinen keine DIO-Nachrichten ausgibt, er kann DAO- und DIS-Nachrichten ausgeben. Ein Blattknoten akzeptiert DIO-Nachrichten, obwohl er DAO- und DIS-Nachrichten im Allgemeinen ignoriert.

16.3. Betrieb als RPL-Router

Wenn keine weiteren Anleitungen verfügbar sind, MUSS eine RPL-Router-Implementierung zumindest die metriklose OF0 [RFC6552] unterstützen.

Für einen konsistenten Betrieb muss eine RPL-Router-Implementierung den vom DODAG verwendeten MOP unterstützen.

Alle RPL-Router müssen Trickle [RFC6206] implementieren.

16.3.1. Unterstützung für Aufwärtsrouten (Nur)

Eine Implementierung eines RPL-Routers, der nur Aufwärtsrouten unterstützt, unterstützt Folgendes:

• Aufwärtsrouten (Abschnitt 8)

• MOP-Kodierung 0 (Abschnitt 20.3)

• Zusammenfassend werden DIO- und DIS-Nachrichten ausgegeben, und DAO-Nachrichten werden nicht ausgegeben. DIO- und DIS-Nachrichten werden akzeptiert, und DAO-Nachrichten werden ignoriert.

16.3.2. Unterstützung für Aufwärtsrouten und Abwärtsrouten im Non-Storing-Modus

Eine Implementierung eines RPL-Routers, der Aufwärtsrouten und Abwärtsrouten im Non-Storing-Modus unterstützt, unterstützt Folgendes:

• Aufwärtsrouten (Abschnitt 8)

• Abwärtsrouten (Non-Storing) (Abschnitt 9)

• MOP-Kodierung 1 (Abschnitt 20.3)

• Quellgerouteter Abwärtsverkehr ([RFC6554])

• Zusammenfassend werden DIO- und DIS-Nachrichten ausgegeben, und DAO-Nachrichten werden an die DODAG-Wurzel ausgegeben. DIO- und DIS-Nachrichten werden akzeptiert, und DAO-Nachrichten werden von anderen Knoten als DODAG-Wurzeln ignoriert. Multicast wird nicht durch die in dieser Spezifikation beschriebenen Mittel unterstützt, obwohl es durch einige alternative Mittel unterstützt werden kann.

16.3.3. Unterstützung für Aufwärtsrouten und Abwärtsrouten im Storing-Modus

Eine Implementierung eines RPL-Routers, der Aufwärtsrouten und Abwärtsrouten im Storing-Modus unterstützt, unterstützt Folgendes:

• Aufwärtsrouten (Abschnitt 8)

• Abwärtsrouten (Storing) (Abschnitt 9)

• MOP-Kodierung 2 (Abschnitt 20.3)

• Zusammenfassend werden DIO-, DIS- und DAO-Nachrichten ausgegeben. DIO-, DIS- und DAO-Nachrichten werden akzeptiert. Multicast wird nicht durch die in dieser Spezifikation beschriebenen Mittel unterstützt, obwohl es durch einige alternative Mittel unterstützt werden kann.

16.3.3.1. Optionale Unterstützung für grundlegendes Multicast-Schema

Eine Storing-Modus-Implementierung kann durch die folgenden Ergänzungen mit grundlegender Multicast-Unterstützung erweitert werden:

• Grundlegende Multicast-Unterstützung (Abschnitt 12)

• MOP-Kodierung 3 (Abschnitt 20.3)

16.4. Punkte für zukünftige Spezifikationen

Eine Reihe von Punkten bleibt zukünftigen Spezifikationen vorbehalten, einschließlich, aber nicht beschränkt auf Folgendes:

• Wie ein Nicht-RPL-Knoten wie ein IPv6-Host angeschlossen wird, z.B. um zumindest PIO-Material konsistent an den angeschlossenen Knoten zu verteilen.

• Wie Authentifizierungsmaterial zur Unterstützung erhalten wird, wenn der authentifizierte Modus verwendet wird (Abschnitt 10.3).

• Details des Betriebs über mehrere gleichzeitige Instanzen.

• Erweiterte Konfigurationsmechanismen, wie die Bereitstellung von RPLInstanceIDs, Parametrisierung von Zielfunktionen und Parameter zur Steuerung der Sicherheit. (Es wird erwartet, dass solche Mechanismen das DIO als Mittel zur Verbreitung von Informationen über den DODAG erweitern könnten).