Zusammenfassung

  • Die RREQ-Steuerwelle läuft vom OrigNode zum TargNode, doch ihre ermittelte Route trägt Daten in der Gegenrichtung; die RREP-Ermittlung baut den anderen Datenweg.
  • Endpunktadressen, lokale InstanceIDs und das sechs Bit breite Delta halten parallele Ermittlungen auseinander, attestieren aber keinen aktuellen Weiterleitungszustand.
  • Ein belastbarer Dienstnachweis braucht zeitlich zusammenpassende Belege für beide Routen, beide Paketrichtungen und den abgeschlossenen Request-Response-Austausch.

Die Antwort konnte nicht einfach den Hinweg übernehmen

In einem Low-Power and Lossy Network ist Hören nicht zwangsläufig gegenseitig. Sendeleistung, Störung und Zeitplanung können eine Richtung begünstigen, während die Gegenrichtung dieselbe Objective Function verfehlt. RFC 9854 erweitert RPL deshalb um eine reaktive AODV-Routenfindung, die Asymmetrie ausdrücklich darstellen kann.

Die erste temporäre RREQ-Instance ist am OrigNode verwurzelt; RREQ-DIOs bewegen sich zum TargNode. Der dabei ermittelte Aufwärtspfad dient jedoch Daten vom Ziel zurück zum Ursprung. Die RREP-Steuerung läuft vom Ziel zum Ursprung und kann eine zweite, am TargNode verwurzelte DODAG aufbauen. Deren Route trägt Daten vom Ursprung zum Ziel. Steuerungsrichtung und Nutzdatenrichtung zeigen bei beiden Instanzen entgegengesetzt.

Das S-Bit startet als 1 und bleibt nur gesetzt, wenn an jedem Hop auch die Gegenrichtung die Objective Function erfüllt. Erreicht S=1 das Ziel, darf dieses die Antwort per Unicast über den bekannten Zustand zurückgeben; eine zweite DODAG ist nicht erforderlich. Bei S=0 erzeugt das Ziel eine RREP-Instance und sendet RREP-DIOs per Multicast. Andere Router können andere bevorzugte Eltern wählen. „Bidirektional“ bezeichnet hier zwei ermittelbare Richtungen, nicht eine einzige symmetrische Kette.

Auch S=1 ist kein universeller Funkbeleg. Das RFC legt die Symmetrieprüfung nicht fest. ETX/RSSI wird nur als Beispiel genannt; Vorwissen, Testverkehr und OAM sind weitere Möglichkeiten. Das Bit ist eine Aussage beteiligter Router unter einer bestimmten Messmethode und zu einem bestimmten Zeitpunkt. Es ist keine Quittung für spätere Weiterleitung.

Delta ordnet Zustand zu, nicht Erfolg

RPLInstanceIDs werden lokal vergeben. Zwischen denselben Endpunkten können gleichzeitig Ermittlungen mit verschiedenen Objective Functions laufen, und verschiedene Ursprünge dürfen denselben Zahlenwert wählen. Die vollständige Identität einer RREQ-Instance verbindet deshalb die InstanceID mit der IP-Adresse des OrigNode; bei RREP gilt Entsprechendes für den TargNode.

Ist der naheliegende RREP-Wert bereits durch eine aktive Instanz mit derselben DODAGID belegt, wählt das Ziel einen anderen. Das sechs Bit breite Delta im RREP-Objekt hält fest, um wie viel der empfangene RREQ-Wert erhöht wurde; gerechnet wird modulo 256. Ein Empfänger subtrahiert Delta, um beim Installieren des Zielwegs die zugehörige Anfrage wiederzufinden. Die DODAGID liefert den Endpunktkontext, der dem einzelnen Oktett fehlt.

Das verhindert eine reale Verwechslung: Zustand einer Ermittlung oder Objective Function darf nicht an eine andere gehängt werden. Es zeigt, dass ein konformer Empfänger ein Paar erkennen kann. Es zeigt nicht, dass jeder notwendige Router den Zustand installierte, dass Einträge noch leben oder dass beide Seiten aus demselben Betriebszeitfenster stammen.

Rank, Sequenz und Lebensdauer beantworten verschiedene Fragen

Rank ist relative Position in einer DODAG-Version, nicht automatisch Entfernung oder Pfadkosten. Diese Warnung aus RFC 6550 wird in RFC 9854 ausdrücklich erneuert. Welche Metriken und Constraints einer Objective Function zur Verfügung stehen, katalogisiert RFC 6551. Ein niedriger Rank ist daher keine gemessene Dienstgüte.

Sequenznummern behandeln logische Frische. OrigNode erhöht seine Sequenznummer für eine neue Ermittlung. Einträge zum Ursprung führen Orig SeqNo, Einträge zum Ziel die ART Destination Sequence Number. Ein passender, aber veralteter Eintrag muss gelöscht werden. Das ordnet Generationen; es beweist weder die Installation in Hardware noch die heutige Erreichbarkeit eines Links.

Auch die Zeitbegriffe sind getrennt. Das L-Feld begrenzt die Teilnahme an der temporären Instanz und ist ausdrücklich unabhängig von der Route Lifetime. Die Lebensdauer eines Routeneintrags stammt aus der DODAG-Konfiguration und kann durch Nutzung verlängert werden. „Instanz aktiv“, „Route nicht abgelaufen“ und „Paket kürzlich gesehen“ sind drei Uhren, die nicht zu einem Ampelwert verschmolzen werden dürfen.

Hop-by-Hop und Source Routing hinterlassen andere Belege

Bei H=1 legen Zwischenrouter Einträge mit Quelle, Instanz, Ziel, Next Hop, Lebensdauer und Sequenzzustand an. Für den zielgerichteten Weg kann im symmetrischen Fall der RREP-Sender der Next Hop sein; im asymmetrischen Fall folgt der Eintrag dem bevorzugten Elternknoten der RREP-DODAG. Ein Installationsbeleg muss daher Richtung, Router, Next Hop, Generation und Ablaufzeit nennen.

Bei H=0 trägt ein Address Vector den Weg. Ein asymmetrischer RREP-Vektor enthält die Knoten seiner tatsächlichen zweiten Steuerwelle; im symmetrischen Fall sendet das Ziel den ersten Vektor unverändert zurück. Prüfungen auf doppelte Adressen mindern Schleifenrisiken. Trotzdem bleibt der Vektor ein Steuerobjekt und belegt nicht, dass jede Schnittstelle beim späteren Paketversand erreichbar war.

Nach dem Empfang von RREP kann OrigNode laut RFC mit Anwendungsdaten beginnen. Dieses „kann beginnen“ ist die Grenze der Discovery. Das erste Paket kann auf abgelaufenen Zustand, neue Asymmetrie, Stau oder eine Anwendung treffen, die nie antwortet.

Fünf Quittungen für einen Rundweg

Erstens braucht die Ermittlung einen Identitätsbeleg: beide Adressen und DODAGIDs, beide numerischen InstanceIDs, Delta, Objective Function, H- und S-Bit, Sequenzen, Instanzuhren und Beobachter. Zweitens braucht der vom RREQ ermittelte Datenweg TargNode→OrigNode einen Installationsbeleg pro relevantem Router oder einen genauen Source Vector. Drittens braucht OrigNode→TargNode denselben Nachweis unabhängig; die Knoten können andere sein.

Viertens müssen Pakete richtungsbezogen beobachtet werden. Zähler und Probes brauchen Zeitraum, Nenner, Reset-Historie sowie Quell-, Ziel- und Instanzkontext. Erfolg in einer Richtung sagt nur etwas über diese Richtung; zwei Probes aus verschiedenen Zeiten belegen keinen gleichzeitig nutzbaren Zustand.

Fünftens verbindet nur der Anwendungsbeleg eine eindeutige Anfrage am Ursprung mit Annahme am Ziel, Antworterzeugung und rechtzeitigem Antwortempfang. Erst diese Kette ist der Dienstfakt. Die gepaarte Steuerung kann ihn nicht erzeugen.

Sicherheit begrenzt Sprecher, nicht Ergebnisse

RFC 9854 übernimmt das optionale RPL-Sicherheitsmodell und verweist auf die Bedrohungsanalyse in RFC 7416. Ein Teilnehmer braucht den Schlüssel einer geschützten Ermittlung; ein bösartiger Router mit diesem Schlüssel kann dennoch falsche Angaben machen, Ermittlungen einschleusen oder Antworten verändern. Ein manipulierter Source Vector kann Schleifen erzeugen, ein gefälschter gratuitous RREP Denial of Service unterstützen.

Authentifizierung erhöht das Vertrauen in den Ursprung einer Steuerbotschaft innerhalb der konfigurierten Domäne. Sie macht den Router nicht zum unabhängigen Zeugen nachgelagerter Dienstleistung. Das IANA-RPL-Register führt MOP 4 und die RREQ-, RREP- und ART-Optionen. Registrierung belegt gemeinsame Codierung, nicht die Verbreitung einer Implementierung.

Die RFC-Editor-Informationsseite, der Datatracker-Eintrag und die Errata-Suche belegen Status, Publikationsgeschichte und den zum Prüfzeitpunkt leeren Errata-Bestand. Keiner davon ist ein Feldtest.

Heng Lus Running-Code Primacy trennt Spezifikation von laufender Wirklichkeit. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption hält gemeinsame Regeln klein und lokale Verifikation explizit. Sein Text über Realitätsebenen liefert die letzte Grenze: Ein symbolisch sauberes Paar ersetzt keine ausführbaren Belege aus Routen, Paketen und Anwendung.

Quellen