18. Überlegungen zur Verwaltbarkeit

Das Ziel dieses Abschnitts ist es, die Verwaltbarkeit von RPL und den Betrieb von RPL in einem LLN zu betrachten. Der Umfang dieses Abschnitts besteht darin, die folgenden Aspekte der Verwaltbarkeit zu berücksichtigen: Konfiguration, Überwachung, Fehlermanagement, Abrechnung und Leistung des Protokolls im Lichte der in [RFC5706] dargelegten Empfehlungen.

18.1. Einführung

Die meisten bestehenden IETF-Managementstandards sind MIB-Module (Datenmodelle basierend auf der Structure of Management Information (SMI)) zur Überwachung und Verwaltung von Netzwerkgeräten.

Für eine Reihe von Protokollen hat die IETF-Community das IETF Standard Management Framework verwendet, einschließlich des Simple Network Management Protocol [RFC3410], der Structure of Management Information [RFC2578] und MIB-Datenmodellen zur Verwaltung neuer Protokolle.

Wie in [RFC5706] dargelegt, wurde die gemeinsame Richtlinie in Bezug auf Betrieb und Management auf eine Richtlinie ausgeweitet, die offener für eine Reihe von Tools und Managementprotokollen ist, anstatt sich streng auf ein einzelnes Protokoll wie SNMP zu verlassen.

Im Jahr 2003 hielt das Internet Architecture Board (IAB) einen Workshop zum Thema Netzwerkmanagement [RFC3535] ab, in dem die Stärken und Schwächen einiger IETF-Netzwerkmanagementprotokolle diskutiert und mit den betrieblichen Anforderungen, insbesondere der Konfiguration, verglichen wurden.

Ein diskutiertes Problem war die Benutzerunfreundlichkeit des Binärformats von SNMP [RFC3410]. Im Falle von LLNs muss angemerkt werden, dass die CoRE-Arbeitsgruppe zum Zeitpunkt der Erstellung dieses Dokuments aktiv am Ressourcenmanagement von Geräten in LLNs arbeitet. Dennoch wird angenommen, dass dieser Abschnitt wichtige Hinweise dazu liefert, wie RPL bereitgestellt, betrieben und verwaltet werden sollte.

Wie in [RFC5706] angegeben:

Ein Managementinformationsmodell sollte eine Diskussion darüber enthalten, was verwaltbar ist, welche Aspekte des Protokolls konfiguriert werden müssen, welche Arten von Operationen zulässig sind, welche protokollspezifischen Ereignisse auftreten können, welche Ereignisse gezählt werden können und bei welchen Ereignissen ein Betreiber benachrichtigt werden sollte.

Diese Aspekte werden in den folgenden Abschnitten ausführlich erörtert.

RPL wird auf einer Vielzahl von Geräten verwendet, deren Ressourcen wie Speicher von wenigen Kilobyte bis zu mehreren hundert Kilobyte und sogar Megabyte variieren können. Wenn der Speicher stark eingeschränkt ist, ist es möglicherweise nicht möglich, alle in diesem Abschnitt aufgeführten Anforderungen zu erfüllen. Dennoch lohnt es sich, alle diese Anforderungen erschöpfend aufzulisten, und die Implementierer werden dann entscheiden, welche dieser Anforderungen entsprechend den verfügbaren Ressourcen auf dem Gerät erfüllt werden könnten.

18.2. Konfigurationsmanagement

Dieser Abschnitt behandelt das Konfigurationsmanagement und listet die Protokollparameter auf, für die das Konfigurationsmanagement relevant ist.

Einige der RPL-Parameter sind optional. Die Anforderungen an die Konfiguration gelten nur für die verwendeten Optionen.

18.2.1. Initialisierungsmodus

"Architectural Principles of the Internet" [RFC1958], Abschnitt 3.8, besagt: "Vermeiden Sie Optionen und Parameter, wann immer möglich. Alle Optionen und Parameter sollten dynamisch konfiguriert oder ausgehandelt werden, anstatt manuell". Dies gilt insbesondere in LLNs, wo die Anzahl der Geräte groß sein kann und eine manuelle Konfiguration nicht durchführbar ist. Dies wurde beim Design von RPL berücksichtigt, wobei die DODAG-Wurzel eine Reihe von Parametern für die Geräte bereitstellt, die dem DODAG beitreten, wodurch eine umständliche Konfiguration auf den Routern und potenzielle Quellen für Fehlkonfigurationen (z. B. Werte von Trickle-Timern usw.) vermieden werden. Dennoch gibt es zusätzliche RPL-Parameter, die eine RPL-Implementierung konfigurierbar machen sollte, die in diesem Abschnitt erläutert werden.

18.2.1.1. DIS-Betriebsmodus beim Hochfahren

Wenn ein Knoten zum ersten Mal eingeschaltet wird:

1. Der Knoten kann sich entscheiden, still zu bleiben und auf den Empfang von DIO-Nachrichten von interessierenden DODAGs zu warten (die eine unterstützte OF und Metriken/Einschränkungen ankündigen) und keine Multicast-DIO-Nachrichten zu senden, bis er einem DODAG beigetreten ist.

2. Der Knoten kann sich entscheiden, eine oder mehrere DIS-Nachrichten (optional mit Anforderung von DIO für ein bestimmtes DODAG) als anfängliche Sonde für nahegelegene DODAGs zu senden, und wenn nach einer konfigurierbaren Zeitspanne keine DIO-Nachrichten als Antwort eingehen, kann der Knoten entscheiden, ein Floating-DODAG zu rooten und mit dem Senden von Multicast-DIO-Nachrichten zu beginnen.

Eine RPL-Implementierung SOLLTE die Konfiguration des oben aufgeführten bevorzugten Betriebsmodus zusammen mit den erforderlichen Parametern (im zweiten Modus: Anzahl der DIS-Nachrichten und zugehöriger Timer) ermöglichen.

18.2.2. Konfiguration von DIO- und DAO-Basisnachrichten und -Optionen

RPL spezifiziert eine Reihe von Protokollparametern unter Berücksichtigung des breiten Spektrums von Anwendungen, in denen es verwendet wird. Allerdings wurde besonderes Augenmerk darauf gelegt, die Anzahl dieser Parameter zu begrenzen, die auf jedem RPL-Router konfiguriert werden müssen. Stattdessen können eine Reihe von Standardwerten verwendet werden, und bei Bedarf können diese Parameter von der DODAG-Wurzel bereitgestellt werden, wodurch eine dynamische Parametereinstellung ermöglicht wird.

Eine RPL-Implementierung SOLLTE die Konfiguration der folgenden Routing-Protokollparameter ermöglichen. Beachten Sie, wie oben erwähnt, dass ein großer Satz von Parametern auf der DODAG-Wurzel konfiguriert ist.

18.2.3. Protokollparameter, die auf jedem Router im LLN konfiguriert werden müssen

Eine RPL-Implementierung MUSS die Konfiguration der folgenden RPL-Parameter ermöglichen:

• RPLInstanceID [DIO-Nachricht, in DIO-Basisnachricht]. Obwohl die RPLInstanceID auf der DODAG-Wurzel konfiguriert werden muss, muss sie auch als Richtlinie auf jedem Knoten konfiguriert werden, um festzustellen, ob der Knoten einem bestimmten DODAG beitreten soll oder nicht. Beachten Sie, dass eine zweite RPLInstanceID auf dem Knoten konfiguriert werden kann, falls dieser zur Wurzel eines Floating-DODAG wird.

• Liste der unterstützten Objective Code Points (OCPs)

• Liste der unterstützten Metriken: [RFC6551] spezifiziert eine Reihe von Metriken und Einschränkungen, die für die DODAG-Bildung verwendet werden. Daher sollte eine RPL-Implementierung die Konfiguration der Liste von Metriken ermöglichen, die ein Knoten akzeptieren und verstehen kann. Wenn eine DIO mit einer Metrik und/oder Einschränkung empfangen wird, die nicht verstanden oder unterstützt wird, tritt der Knoten, wie in Abschnitt 8.5 angegeben, als Blattknoten bei.

• Präfixinformationen sowie gültige und bevorzugte Lebensdauer und die Flags 'L' und 'A'. [DIO-Nachricht, Präfixinformationsoption]. Eine RPL-Implementierung SOLLTE konfigurierbar machen, ob die Präfixinformationsoption mit der DIO-Nachricht übertragen werden muss, um die Präfixinformationen für die Autokonfiguration zu verteilen. In diesem Fall MUSS die RPL-Implementierung zulassen, dass die Liste der Präfixe in der PIO zusammen mit den entsprechenden Flags angekündigt wird.

• Angeforderte Informationen [DIS-Nachricht, in Option für angeforderte Informationen]. Beachten Sie, dass eine RPL-Implementierung konfigurierbar machen SOLLTE, wann solche Nachrichten gesendet werden sollen und unter welchen Umständen, zusammen mit dem Wert der RPLInstance ID, 'V'/'I'/'D'-Flags.

• 'K'-Flag: wann ein Knoten das 'K'-Flag in einer DAO-Nachricht setzen sollte [DAO-Nachricht, in DAO-Basisnachricht].

• MOP (Betriebsmodus) [DIO-Nachricht, in DIO-Basisnachricht].

• Routeninformationen (und Präferenz) [DIO-Nachricht, in Routeninformationsoption]

18.2.4. Protokollparameter, die auf jedem Nicht-DODAG-Root-Router im LLN konfiguriert werden müssen

Eine RPL-Implementierung MUSS die Konfiguration des Zielpräfixes ermöglichen [DAO-Nachricht, in RPL-Zieloption].

Darüber hinaus gibt es Umstände, unter denen ein Knoten ein Ziel festlegen möchte, um eine spezifische Verarbeitung des Ziels zu ermöglichen (Priorisierung usw.). Solche Verarbeitungsregeln liegen außerhalb des Geltungsbereichs dieser Spezifikation. Bei Verwendung SOLLTE eine RPL-Implementierung die Konfiguration des Zieldeskriptors auf Zielbasis ermöglichen (z. B. unter Verwendung von Zugriffslisten).

Ein Knoten, dessen DODAG-Elternmenge leer ist, kann zur DODAG-Wurzel eines Floating-DODAG werden. Er kann auch seine DAGPreference so einstellen, dass er weniger bevorzugt wird. Daher MUSS eine RPL-Implementierung die Konfiguration des Satzes von Aktionen ermöglichen, die der Knoten in diesem Fall initiieren sollte:

• Starten eines eigenen (Floating-) DODAG: Die neue DODAGID muss zusätzlich zu seiner DAGPreference konfiguriert werden.

• Vergiften des defekten Pfads (siehe Verfahren in Abschnitt 8.2.2.5).

• Auslösen einer lokalen Reparatur.

18.2.5. Parameter, die auf der DODAG-Wurzel konfiguriert werden müssen

Darüber hinaus werden mehrere andere Parameter nur auf der DODAG-Wurzel konfiguriert und in Optionen angekündigt, die in DIO-Nachrichten übertragen werden.

Wie in Abschnitt 8.3 angegeben, verwendet eine RPL-Implementierung Trickle-Timer, um das Senden von DIO-Nachrichten zu steuern. Der Betrieb des Trickle-Algorithmus wird durch einen Satz konfigurierbarer Parameter bestimmt, die konfigurierbar sein MÜSSEN und die dann von der DODAG-Wurzel entlang des DODAG in DIO-Nachrichten angekündigt werden.

• DIOIntervalDoublings [DIO-Nachricht, in DODAG-Konfigurationsoption]

• DIOIntervalMin [DIO-Nachricht, in DODAG-Konfigurationsoption]

• DIORedundancyConstant [DIO-Nachricht, in DODAG-Konfigurationsoption]

Darüber hinaus SOLLTE eine RPL-Implementierung die Konfiguration des folgenden Satzes von RPL-Parametern ermöglichen:

• Pfadkontrollgröße [DIO-Nachricht, in DODAG-Konfigurationsoption]

• MinHopRankIncrease [DIO-Nachricht, in DODAG-Konfigurationsoption]

• Das DODAGPreference-Feld [DIO-Nachricht, DIO-Basisobjekt]

• DODAGID [DIO-Nachricht, in DIO-Basisoption] und [DAO-Nachricht, wenn das 'D'-Flag der DAO-Nachricht gesetzt ist]

Verhalten der DAG-Wurzel: In einigen Fällen möchte ein Knoten möglicherweise nicht dauerhaft als Floating-DODAG-Wurzel fungieren, wenn er keinem geerdeten DODAG beitreten kann. Beispielsweise möchte ein batteriebetriebener Knoten möglicherweise nicht über einen längeren Zeitraum als Floating-DODAG-Wurzel fungieren. Daher KANN eine RPL-Implementierung die Fähigkeit unterstützen, zu konfigurieren, ob ein Knoten für einen konfigurierten Zeitraum als Floating-DODAG-Wurzel fungieren kann oder nicht.

Inkrement der DAG-Versionsnummer: Eine RPL-Implementierung kann durch Konfiguration an der DODAG-Wurzel das Aktualisieren der DODAG-Zustände durch Aktualisieren der DODAGVersionNumber ermöglichen. Eine RPL-Implementierung SOLLTE konfigurierbar machen, ob periodische oder ereignisgesteuerte Mechanismen von der DODAG-Wurzel verwendet werden, um die Änderung der DODAGVersionNumber zu steuern (was eine globale Reparatur auslöst, wie in Abschnitt 3.2.2 angegeben).

18.2.6. Konfiguration von RPL-Parametern im Zusammenhang mit DAO-basierten Mechanismen

DAO-Nachrichten sind optional und werden in DODAGs verwendet, die einen Abwärts-Routing-Betrieb erfordern. Dieser Abschnitt behandelt den Satz von Parametern im Zusammenhang mit DAO-Nachrichten und gibt Empfehlungen zu deren Konfiguration.

Wie in Abschnitt 9.5 angegeben, wird empfohlen, das Senden von DAO-Nachrichten an DAO-Eltern zu verzögern, um die Chancen zur Durchführung einer Routenaggregation zu maximieren. Nach Empfang einer DAO-Nachricht sollte der Knoten daher einen DelayDAO-Timer starten. Der Standardwert ist DEFAULT_DAO_DELAY. Eine RPL-Implementierung KANN die Konfiguration des DelayDAO-Timers ermöglichen.

In einem speichernden Betriebsmodus kann ein speichernder Knoten DTSN inkrementieren, um als Teil routinemäßiger Routingtabellenaktualisierungen und -wartungen zuverlässig einen Satz von DAO-Aktualisierungen von seinen unmittelbaren Kindern auszulösen. Eine RPL-Implementierung KANN die Konfiguration eines Satzes von Regeln ermöglichen, die die Auslöser für das DTSN-Inkrement (manuell oder ereignisbasiert) angeben.

Wenn ein DAO-Eintrag abläuft oder ungültig wird, SOLLTE ein Knoten einen angemessenen Versuch unternehmen, jedem der DAO-Eltern einen No-Path zu melden. Diese Anzahl von Versuchen KANN konfigurierbar sein.

Eine Implementierung sollte die Ratenbegrenzung des Sendens von DAO-Nachrichten unterstützen. Die zugehörigen Parameter KÖNNEN konfigurierbar sein.

18.2.7. Konfiguration von RPL-Parametern im Zusammenhang mit Sicherheitsmechanismen

Wie in Abschnitt 10 beschrieben, sind die in diesem Dokument beschriebenen Sicherheitsfunktionen optional zu implementieren, und eine bestimmte Implementierung kann eine Teilmenge (einschließlich der leeren Menge) der beschriebenen Sicherheitsfunktionen unterstützen.

Zu diesem Zweck kann eine Implementierung, die beschriebene Sicherheitsfunktionen unterstützt, konzeptionell eine Sicherheitsrichtliniendatenbank implementieren. Zur Unterstützung der Sicherheitsmechanismen SOLLTE eine RPL-Implementierung die Konfiguration einer Teilmenge der folgenden Parameter ermöglichen:

• Akzeptierte Sicherheitsmodi [Ungesicherter Modus, Vorinstallierter Modus, Authentifizierter Modus]

• Akzeptierte KIM-Werte [Sichere RPL-Kontrollnachrichten, im Sicherheitsabschnitt]

• Akzeptierte Level-Werte [Sichere RPL-Kontrollnachrichten, im Sicherheitsabschnitt]

• Akzeptierte Algorithmuswerte [Sichere RPL-Kontrollnachrichten, im Sicherheitsabschnitt]

• Schlüsselmaterial zur Unterstützung von authentifizierten oder vorinstallierten Schlüsselmodi.

Darüber hinaus SOLLTE eine RPL-Implementierung die Konfiguration einer DODAG-Wurzel mit einer Teilmenge der folgenden Parameter ermöglichen:

• Angekündigte Level-Werte [Sichere DIO-Nachricht, im Sicherheitsabschnitt]

• Angekündigter KIM-Wert [Sichere DIO-Nachricht, im Sicherheitsabschnitt]

• Angekündigter Algorithmuswert [Sichere DIO-Nachricht, im Sicherheitsabschnitt]

18.2.8. Standardwerte

Dieses Dokument spezifiziert Standardwerte für den folgenden Satz von RPL-Variablen:

• DEFAULT_PATH_CONTROL_SIZE
• DEFAULT_DIO_INTERVAL_MIN
• DEFAULT_DIO_INTERVAL_DOUBLINGS
• DEFAULT_DIO_REDUNDANCY_CONSTANT
• DEFAULT_MIN_HOP_RANK_INCREASE
• DEFAULT_DAO_DELAY

Es wird empfohlen, Standardwerte in Protokollen anzugeben; allerdings machen Standardwerte, wie in [RFC5706] diskutiert, möglicherweise immer weniger Sinn. RPL ist ein Routing-Protokoll, das in einer Reihe von Kontexten verwendet werden soll, in denen Netzwerkeigenschaften wie die Anzahl der Knoten sowie Link- und Knotentypen voraussichtlich erheblich variieren werden. Daher werden sich diese Standardwerte wahrscheinlich mit dem Kontext und der technologischen Entwicklung ändern. Tatsächlich haben sich die mit LLNs verbundenen Technologien (z. B. Hardware, Verbindungsschichten) in den letzten Jahren dramatisch weiterentwickelt, und es wird erwartet, dass sich solche Technologien in den kommenden Jahren erheblich ändern und weiterentwickeln werden.

Die vorgeschlagenen Werte basieren nicht auf umfangreichen aktuellen Best Practices und werden als konservativ angesehen.

18.3. Überwachung des RPL-Betriebs

Mehrere RPL-Parameter sollten überwacht werden, um den korrekten Betrieb des Routing-Protokolls und des Netzwerks selbst zu überprüfen. Dieser Abschnitt listet den Satz von Überwachungsparametern von Interesse auf.

18.3.1. Überwachung von DODAG-Parametern

Eine RPL-Implementierung SOLLTE Informationen über die folgenden Parameter bereitstellen:

• DODAG-Versionsnummer [DIO-Nachricht, in DIO-Basisnachricht]

• Status des 'G'-Flags [DIO-Nachricht, in DIO-Basisnachricht]

• Status des MOP-Feldes [DIO-Nachricht, in DIO-Basisnachricht]

• Wert des DTSN [DIO-Nachricht, in DIO-Basisnachricht]

• Wert des Rangs [DIO-Nachricht, in DIO-Basisnachricht]

• DAOSequence: Inkrementiert bei jeder eindeutigen DAO-Nachricht, in der DAO-ACK-Nachricht zurückgemeldet [DAO- und DAO-ACK-Nachrichten]

• Routeninformationen [DIO-Nachricht, Routeninformationsoption] (Liste der IPv6-Präfixe pro Elternteil zusammen mit Lebensdauer und Präferenz]

• Trickle-Parameter:

  • DIOIntervalDoublings [DIO-Nachricht, in DODAG-Konfigurationsoption]
  • DIOIntervalMin [DIO-Nachricht, in DODAG-Konfigurationsoption]
  • DIORedundancyConstant [DIO-Nachricht, in DODAG-Konfigurationsoption]

• Pfadkontrollgröße [DIO-Nachricht, in DODAG-Konfigurationsoption]

• MinHopRankIncrease [DIO-Nachricht, in DODAG-Konfigurationsoption]

Werte, die nur auf der DODAG-Wurzel überwacht werden können:

• Transitinformationen [DAO, Transitinformationsoption]: Eine RPL-Implementierung SOLLTE die Konfiguration ermöglichen, ob der Satz empfangener Transitinformationsoptionen auf der DODAG-Wurzel angezeigt werden soll. In diesem Fall sollte die RPL-Datenbank der empfangenen Transitinformationen auch die Pfadsequenz, Pfadkontrolle, Pfadlebensdauer und Elternadresse enthalten.

18.3.2. Überwachung von DODAG-Inkonsistenzen und Schleifenerkennung

Die Erkennung von DODAG-Inkonsistenzen ist in RPL-Netzwerken besonders kritisch. Daher wird für eine RPL-Implementierung empfohlen, geeignete Überwachungstools bereitzustellen. Eine RPL-Implementierung SOLLTE einen Zähler bereitstellen, der die Anzahl der Male meldet, in denen der Knoten eine Inkonsistenz in Bezug auf einen DODAG-Elternteil erkannt hat, z. B. wenn sich die DODAGID geändert hat.

Wenn möglich, sollten detailliertere Informationen zur Inkonsistenzerkennung bereitgestellt werden. Eine RPL-Implementierung KANN Zähler bereitstellen, die die Anzahl der folgenden Inkonsistenzen melden:

• Pakete empfangen mit gesetztem 'O'-Bit (nach unten) von einem Knoten mit höherem Rang

• Pakete empfangen mit gelöschtem 'O'-Bit (nach oben) von einem Knoten mit niedrigerem Rang

• Anzahl der Pakete mit gesetztem 'F'-Bit

• Anzahl der Pakete mit gesetztem 'R'-Bit

18.4. Überwachung der RPL-Datenstrukturen

18.4.1. Kandidaten-Nachbar-Datenstruktur

Ein Knoten in der Kandidaten-Nachbarliste ist ein Knoten, der auf die gleiche Weise entdeckt wurde und qualifiziert ist, potenziell ein Elternteil zu werden (mit ausreichend hoher lokaler Zuversicht). Eine RPL-Implementierung SOLLTE eine Möglichkeit bieten, die Kandidaten-Nachbarliste mit einer Metrik zu überwachen, die die lokale Zuversicht (den Grad der Stabilität der Nachbarn) widerspiegelt, wie sie durch einige Metriken gemessen wird.

Eine RPL-Implementierung KANN einen Zähler bereitstellen, der die Anzahl der Male meldet, in denen ein Kandidaten-Nachbar ignoriert wurde, sollte die Anzahl der Kandidaten-Nachbarn den maximal zulässigen Wert überschreiten.

18.4.2. Destination-Oriented Directed Acyclic Graph (DODAG) Tabelle

Für jeden DODAG wird erwartet, dass eine RPL-Implementierung die folgenden DODAG-Tabellenwerte verfolgt:

• RPLInstanceID

• DODAGID

• DODAGVersionNumber

• Rang

• Objective Code Point

• Ein Satz von DODAG-Eltern

• Ein Satz von Präfixen, die entlang des DODAG nach oben angeboten werden

• Trickle-Timer, die verwendet werden, um das Senden von DIO-Nachrichten für den DODAG zu steuern

• Liste der DAO-Eltern

• DTSN

• Knotenstatus (Router versus Blatt)

Eine RPL-Implementierung SOLLTE die Überwachung des oben aufgeführten Satzes von Parametern ermöglichen.

18.4.3. Routingtabelle und DAO-Routingeinträge

Eine RPL-Implementierung verwaltet mehrere Informationselemente im Zusammenhang mit dem DODAG und den DAO-Einträgen (für speichernde Knoten). Im Falle eines nicht speichernden Knotens wird eine begrenzte Menge an Informationen verwaltet (die Routingtabelle ist meist auf einen Satz von DODAG-Eltern zusammen mit Merkmalen des DODAG wie oben erwähnt reduziert); wohingegen im Falle von speichernden Knoten diese Informationen um Routingeinträge erweitert werden.

Eine RPL-Implementierung SOLLTE die Überwachung der folgenden Parameter ermöglichen:

• Nächster Hop (DODAG-Elternteil)

• Schnittstelle des nächsten Hops

• Pfadmetrikwert für jeden DODAG-Elternteil

Ein DAO-Routingtabelleneintrag enthält konzeptionell die folgenden Elemente (nur für speichernde Knoten):

• Werbender Nachbar-Informationen

• IPv6-Adresse

• Schnittstellen-ID, an die dieser Eintrag den DAO-Eltern gemeldet wurde

• Wiederholungszähler

• Logisches Äquivalent des DAO-Inhalts:

  • DAO-Sequence
  • Pfadsequenz
  • DAO-Lebensdauer
  • DAO-Pfadkontrolle

• Zielpräfix (oder Adresse oder Multicast-Gruppe)

Eine RPL-Implementierung SOLLTE Informationen über den Status jedes DAO-Routingtabelleneintragsstatus bereitstellen.

18.5. Fehlermanagement

Das Fehlermanagement ist eine kritische Komponente, die zur Fehlerbehebung, Überprüfung der korrekten Betriebsweise des Protokolls und zum Netzwerkdesign verwendet wird; außerdem ist es eine Schlüsselkomponente der Netzwerk-Leistungsüberwachung. Eine RPL-Implementierung SOLLTE die Bereitstellung der folgenden Informationen im Zusammenhang mit dem Fehlermanagement ermöglichen:

• Speicherüberlauf zusammen mit der Ursache (z. B. Überlauf der Routingtabellen usw.)

• Anzahl der Male, in denen ein Paket nicht an einen als gültig gekennzeichneten DODAG-Elternteil gesendet werden konnte

• Anzahl der Male, in denen ein Paket empfangen wurde, für das der Router keine entsprechende RPLInstanceID hatte

• Anzahl der Male, in denen ein lokales Reparaturverfahren ausgelöst wurde

• Anzahl der Male, in denen eine globale Reparatur von der DODAG-Wurzel ausgelöst wurde

• Anzahl der empfangenen fehlerhaften Nachrichten

• Anzahl der Sekunden mit weiterzuleitenden Paketen und keinem nächsten Hop (DODAG-Elternteil)

• Anzahl der Sekunden ohne nächsten Hop (DODAG-Elternteil)

• Anzahl der Male, in denen ein Knoten einem DODAG als Blatt beigetreten ist, weil er eine DIO mit einer Metrik/Einschränkung empfangen hat, die nicht verstanden wurde, und er in diesem Fall so konfiguriert war, dass er als Blattknoten beitritt (siehe Abschnitt 18.6)

Es wird EMPFOHLEN, Fehler zumindest über Fehlerprotokollnachrichten zu melden. Andere Protokolle können verwendet werden, um solche Fehler zu melden.

18.6. Richtlinie

Richtlinienregeln können von einer RPL-Implementierung verwendet werden, um zu bestimmen, ob der Knoten einem bestimmten DODAG beitreten darf oder nicht, der von einem Nachbarn mittels DIO-Nachrichten angekündigt wird.

Dieses Dokument spezifiziert den Betrieb innerhalb eines einzelnen DODAG. Ein DODAG wird durch das folgende Tupel (RPLInstanceID, DODAGID) charakterisiert. Darüber hinaus werden, wie oben erwähnt, DIO-Nachrichten verwendet, um andere DODAG-Merkmale wie die Routingmetriken und Einschränkungen, die zum Aufbau des DODAG verwendet werden, und die verwendete Zielfunktion (spezifiziert durch OCP) anzukündigen.

Die ersten Richtlinienregeln bestehen darin, die folgenden Bedingungen anzugeben, die ein RPL-Knoten erfüllen muss, um einem DODAG beizutreten:

• RPLInstanceID

• Liste der unterstützten Routingmetriken und Einschränkungen

• Zielfunktion (OCP-Werte)

Eine RPL-Implementierung MUSS die Konfiguration dieser Parameter ermöglichen und SOLLTE angeben, ob der Knoten die DIO einfach ignorieren muss, wenn das angekündigte DODAG nicht mit der lokalen Richtlinie kompatibel ist, oder ob der Knoten als Blattknoten beitreten sollte, wenn nur die Liste der unterstützten Routingmetriken und Einschränkungen und die OF nicht unterstützt wird. Darüber hinaus SOLLTE eine RPL-Implementierung das Hinzufügen der DODAGID als Teil der Richtlinie ermöglichen.

Eine RPL-Implementierung SOLLTE die Konfiguration des Satzes akzeptabler oder bevorzugter Zielfunktionen (OFs), die durch ihre Objective Code Points (OCPs) referenziert werden, für einen Knoten zum Beitritt zu einem DODAG ermöglichen, und welche Aktion ergriffen werden sollte, wenn keiner der Kandidaten-Nachbarn eines Knotens eine der konfigurierten zulässigen Zielfunktionen ankündigt oder wenn die angekündigte Metrik/Einschränkung nicht verstanden/unterstützt wird. In diesem Fall können zwei Aktionen ergriffen werden:

• Der Knoten tritt dem DODAG als Blattknoten bei, wie in Abschnitt 8.5 angegeben.

• Der Knoten tritt dem DODAG nicht bei.

Ein Knoten in einem LLN kann Routinginformationen von verschiedenen Routingprotokollen, einschließlich RPL, lernen. In diesem Fall ist es wünschenswert, über administrative Präferenzen zu steuern, welche Route bevorzugt werden soll. Eine Implementierung SOLLTE die Angabe einer administrativen Präferenz für das Routingprotokoll ermöglichen, von dem die Route gelernt wurde.

Interne Datenstrukturen: Einige RPL-Implementierungen können die Größe der Kandidaten-Nachbarliste begrenzen, um die Speichernutzung zu begrenzen; in diesem Fall werden einige ansonsten brauchbare Kandidaten-Nachbarn möglicherweise nicht berücksichtigt und einfach aus der Kandidaten-Nachbarliste entfernt.

Eine RPL-Implementierung KANN einen Indikator für die Größe der Kandidaten-Nachbarliste bereitstellen.

18.7. Fehlerisolation

Es wird EMPFOHLEN, Nachbarn unter Quarantäne zu stellen, die beginnen, fehlerhafte Nachrichten mit inakzeptablen Raten auszugeben.

18.8. Auswirkungen auf andere Protokolle

RPL hat sehr begrenzte Auswirkungen auf andere Protokolle. Wenn auf einem Router mehr als ein Routingprotokoll erforderlich ist, wie z. B. einem LBR, wird erwartet, dass das Gerät Routing-Umverteilungsfunktionen zwischen den Routingprotokollen unterstützt, um die Erreichbarkeit zwischen den beiden Routing-Domänen zu ermöglichen. Eine solche Umverteilung SOLLTE durch die Verwendung von benutzerkonfigurierbaren Richtlinien geregelt werden.

In Bezug auf die Auswirkungen auf den Datenverkehr im Netzwerk wurde RPL so konzipiert, dass der Steuerverkehr dank Mechanismen wie Trickle-Timern (Abschnitt 8.3) begrenzt wird. Daher sollten die Auswirkungen von RPL auf andere Protokolle äußerst begrenzt sein.

18.9. Leistungsmanagement

Leistungsmanagement ist immer ein wichtiger Aspekt eines Protokolls, und RPL ist keine Ausnahme. Mehrere Metriken von Interesse wurden von der IP Performance Monitoring (IPPM) Arbeitsgruppe spezifiziert: Allerdings werden sie auf LLN unter Berücksichtigung der Kosten für die Überwachung dieser Metriken in Bezug auf Ressourcen auf den Geräten und erforderliche Bandbreite kaum anwendbar sein. Dennoch KÖNNEN RPL-Implementierungen einige davon unterstützen, und andere Parameter von Interesse sind unten aufgeführt:

• Anzahl der Reparaturen und Zeit bis zur Reparatur in Sekunden (Durchschnitt, Varianz)

• Anzahl der Male und Zeitraum, in dem ein Gerät ein Paket nicht weiterleiten konnte, weil kein erreichbarer Nachbar in seiner Routingtabelle vorhanden war

• Überwachung des Ressourcenverbrauchs durch RPL in Bezug auf Bandbreite und erforderlichen Speicher

• Anzahl der gesendeten und empfangenen RPL-Kontrollnachrichten

18.10. Diagnose

Es kann Situationen geben, in denen ein Knoten in den "ausführlichen" Modus versetzt werden sollte, um die Diagnose zu verbessern. Daher SOLLTE eine RPL-Implementierung die Möglichkeit bieten, einen Knoten in den ausführlichen Modus und aus diesem heraus zu versetzen, um zusätzliche Diagnoseinformationen zu erhalten.