Zusammenfassung

  • Ein positives PDR-ACK bedeutet: Die Root erklärt den angeforderten Track für aufgebaut und verpflichtet sich auf seine ausgehandelte Lebensdauer. Eine tatsächliche Paketnutzung bestätigt es nicht.
  • Belastbare Betriebsbelege verbinden Anforderung und Sequenz, modusspezifische Installation, Segment- und Track-Lebensdauer, Identität im Paket, Pfadbeobachtung und Ergebnis beim Empfänger.

Der früheste Erfolgsbeleg kam, bevor der Datenverkehr begann. Die Root hatte die richtige Sequenz beantwortet und den Track akzeptiert. Im Lagebild wurde daraus „deterministischer Dienst aktiv“. Dabei fehlten noch ein Paket mit TrackID, ein Ausgangszähler und die Annahme durch die Anwendung. Aus einem Steuerungsversprechen war unbemerkt ein Betriebsergebnis geworden.

RFC 9914 erschien im April 2026 als Proposed Standard und definiert Root-Initiated Routing State für RPL. Der RFC-Editor-Eintrag nennt die Aktualisierungen von RFC 6550, RFC 6553 und RFC 8138. Die Norm beschreibt die Projektion eines Tracks in ein Low-Power-and-Lossy Network, keine konkrete Einführung oder gemessene Leistung.

Der Ingress kann per P-DAO-REQ TrackID, Endpunkte, gewünschte Lebensdauer und PDRSequence an die Root senden. Diese Sequenz korreliert das PDR-ACK. Positiv heißt: aufgebaut und für die vereinbarte Zeit zugesagt. Negativ heißt: abgelehnt. Keines der beiden Signale stammt aus einer Paketbeobachtung.

Der Aufbau besitzt je nach Modus eine andere Gestalt. Im Non-Storing Mode hält die Root Zustand für Source Routing oder Tunnel. Im Storing Mode sendet sie ein Projected DAO, kurz P-DAO, an den Egress. Die Information läuft rückwärts zum Ingress, jeder Router installiert seinen Abschnitt, und vom Ingress kommt ein positives P-DAO-ACK. Bleibt es aus, kann die Root dieselbe TrackID erneut verwenden oder den Track abbauen. Ein gemeinsames Feld „installiert“ verschweigt, wer den Zustand tatsächlich verwahrt.

Auch Ablehnungen sind differenziert. Die Vector Information Option kann Fehler wie Out of Resources, Predecessor Unreachable oder Unreachable Target melden. Damit ist belegt, warum ein Knoten ein Segment nicht annahm. Die physische Funkursache oder eine Anwendungsstörung ist damit nicht automatisch bewiesen.

Die Zeit läuft auf mehreren Ebenen. Segment Sequence ordnet Aktualisierungen, Segment Lifetime begrenzt den Abschnitt. Eine ältere Sequenz wird ignoriert; die Wiederholung desselben Tupels darf Zustand nicht verändern; Lebensdauer null löscht das Segment. Abschnitte können asynchron erneuert werden, unabhängig von der äußeren Track-Zusage. Ein noch gültiger Track-Timer ist daher keine Momentaufnahme unveränderter Innensegmente.

Tiefere Änderungen können für den Ingress transparent bleiben. Kann die Root den Dienst nicht mehr halten, reißt sie den ganzen Track ab und darf ein asynchrones negatives PDR-ACK mit Lebensdauer null senden. Dass diese Meldung noch nicht kam, beweist nicht, dass jeder Hop unverändert blieb.

Im Datenpfad hat der Track höhere Priorität als die Haupt-DODAG-Route. Ein Paket auf dem Track darf nicht in den normalen DODAG zurückkehren. Ist der nächste Track-Nachbar unerreichbar, wird es verworfen. Allgemeine RPL-Erreichbarkeit ersetzt folglich keinen Track-Zustellnachweis.

TrackID und DODAGID können über RPL Packet Information, Source Routing oder Kapselung sichtbar werden. RFC 9008 und RFC 6553 liefern die geerbten Regeln. Ein Mitschnitt verbindet ein Paket an einem Ort mit dem Track, nicht aber unbeobachtete Hops oder den Anwendungserfolg. Bei einer Neuprojektion können bereits fliegende und spätere Pakete unterschiedliche Wege nehmen; Jitter und Umordnung bleiben möglich.

RFC 8655 beschreibt den DetNet-Rahmen für begrenzte Dienstziele. RFC 9912 ordnet RAW-Schutzpfade, Replikation, Eliminierung und schnelle Anpassung ein. Diese Architekturen erklären den Zweck eines Tracks, messen aber keine einzelne Instanz.

Der verteilte Zustand schafft eine Angriffsfläche. Ein bösartiger Knoten kann mit gefälschten P-DAOs Zustandsflattern erzeugen oder Routerspeicher erschöpfen. RFC 9914 verlangt Link-Layer-Sicherheit und verweist auf die RPL-Bedrohungsanalyse in RFC 7416. Das IANA-RPL-Register koordiniert Codes und Statuswerte; es bescheinigt keine sichere Bereitstellung.

Ein prüfbarer Nachweis bewahrt P-DAO-REQ und PDRSequence, Root-Entscheidung und Track-Lebensdauer, Modus, gegebenenfalls P-DAO/P-DAO-ACK, Ablehnung je Knoten, Segment Sequence und Lebensdauer, beobachtete TrackID/DODAGID, Telemetrie an Ingress, Egress und Hops, Verluste oder Umordnung sowie das Anwendungsergebnis. Das ist eine redaktionelle Evidenzkette, kein vorgeschriebenes RFC-Datenschema.

Heng Lus Minimum Initial Specification hält die gemeinsame Basis eng und spätere Entscheidungen lokal verantwortlich. Running-Code Primacy gewichtet ausgeführten und beobachteten Zustand höher als Symbole. Reality Layers trennt Antrag, ACK, Route, Paket und Dienst. Das sind offengelegte redaktionelle Grundsätze, keine zusätzlichen IETF-Regeln.

Ein PDR-ACK ist nicht zu schwach. Es wird nur schwach, wenn ein System ihm fremde Aussagen anhängt. Mit Paket- und Empfängerbeleg dahinter entsteht eine lückenlose, ehrliche Automatisierung.

Sources