Zusammenfassung

  • TREB Revision 01 lässt teilnehmende BPv7-Knoten ihren gewählten nächsten Knoten, lokale Zeiten und Linkmerkmale eintragen und über Bundle-Statusberichte zurückmelden.
  • Der Eintrag entsteht beim Einreihen, nicht beim Nachweis von Übertragung oder Empfang; Knoten dürfen ablehnen, Felder zurückhalten, einen früheren Eintrag ersetzen oder keinen Bericht erzeugen.
  • Veränderliche TREB-Kopien lassen sich nur hopweise schützen. Der Entwurf stuft Hop-Records deshalb als Diagnosedaten ein und verbietet ihre Nutzung für Routing- oder Zugriffskontrollentscheidungen.

Der Pfad als Sammlung lokaler Aussagen

Klassisches IP-Traceroute beobachtet Antworten auf schrittweise ablaufende Hop Limits. In einem DTN passt diese Geometrie nicht. Ein Bundle kann auf ein Funk-, Optik- oder Satellitenkontaktfenster warten, gespeichert werden und erst viel später einen Bericht auslösen.

Die Abgangsstelle erzeugt eine traceroute-id. Jeder teilnehmende Knoten notiert seine Node ID, den ausgewählten nächsten Knoten, den Zeitpunkt des Einreihens, den geplanten Sendebeginn und seine lokale Sicht auf Linktyp, nominale Rate, Entfernung, Konvergenzschicht und Warteschlangenlast. Eine Zustellung oder Löschung setzt den Wendepunkt. Danach kann die Berichtskopie auf dem Rückweg weitere Einträge sammeln.

Der Nutzen ist greifbar. Gewöhnliche Statusberichte nennen den berichtenden Knoten, liefern aber keine vergleichbare Linkbeschreibung. Eine Zustellmeldung mit TREB kann den angesammelten Hinweg und den eigenständigen Rückweg in einem Vorgang sichtbar machen.

Revision 01 bleibt dennoch ein individueller Internet-Draft vom 28. September 2026, gültig bis 1. April 2027, mit angestrebtem Experimental-Status. Der beantragte IANA-Blocktyp ist noch keine Zuweisung. Die Implementierungssektion nennt keine Implementierung und keine Messwerte.

Ein Warteschlangeneintrag ist keine Übergabe

Der Weiterleitungsdatensatz entsteht, nachdem der Knoten einen nächsten Hop gewählt und das Bundle in dessen Sendewarteschlange gestellt hat. Er belegt nicht, dass ein Sender aktiv wurde, ein Kontakt stattfand, der Nachbar Bytes empfing oder die Zielanwendung sie verarbeitete.

Scheitert ein Versuch oder ändert sich der nächste Hop, wird der alte Eintrag ersetzt. Die übertragene Kopie enthält damit die jüngste lokale Entscheidung, kein unveränderliches Protokoll aller Fehlversuche. Auch radiate-time ist nur ein Planwert und wird beim tatsächlichen Senden nicht aktualisiert.

event-time stammt aus der lokalen Uhr. BPv7 fordert keine Uhrensynchronisation. Differenzen zwischen Knoten sind daher nicht automatisch Laufzeiten. Die Spanne zum nächsten Eintrag vermischt Übertragungs- und Ausbreitungszeit, deren Trennung der Entwurf ausdrücklich offenlässt.

Null bedeutet ebenfalls nicht zwingend physische Null. Bei Zeit, Rate, Entfernung, Konvergenzschicht und Stau kann sie unbekannt, nicht anwendbar oder zurückgehalten bedeuten. Lokale Offenlegungspolitik steckt somit in der Messstruktur.

Schweigen benennt keine Ursache

Ein Zwischenknoten darf TREB aus Vertrauens-, Topologie-, Ressourcen- oder Politikgründen unverändert weiterreichen. Passt die next-node-id eines Eintrags nicht zur folgenden self-node-id, liegt mindestens ein transparenter Knoten dazwischen. Wie viele es sind und was sie taten, bleibt offen.

Ein korrekt gepflegter Hop Count kann die Zahl transparenter Hops eingrenzen. record-limit begrenzt dagegen nur das Wachstum; es ist kein Schleifenschutz. Ist die Liste voll, läuft das Bundle weiter, und spätere Einträge können als Überlauf in Berichten auftauchen.

Auch ein angeforderter Statusbericht ist nicht erzwungen. BPv7 lässt die Erzeugung im Ermessen des Bundle Protocol Agent. Ein fehlender Bericht kann nie erzeugt, bewusst ausgelassen oder auf dem Rückweg verloren worden sein. Nach Ablauf seines lokalen Timeouts schließt der Ursprung die Rekonstruktion mit dem vorhandenen Material und ignoriert verspätete Berichte.

Schweigen beweist deshalb nur, dass vor der lokalen Frist kein weiterer Beleg eintraf. Es weist dem letzten sichtbaren Knoten keinen Verlust zu.

Der Rückweg ist ein zweiter Versuch

Bei Zustell- und Löschberichten beschreiben die Einträge vor dem Wendepunkt das verfolgte Bundle, die Einträge danach das Berichts-Bundle. Beide Wege müssen nicht symmetrisch sein. Transparente Knoten und volle Limits können auch den Rückweg unvollständig machen.

Weiterleitungsberichte funktionieren anders: Sie tragen genau den Eintrag des Melders und eine Position und werden auf dem Rückweg nicht erweitert. Der Ursprung fügt sie anhand von traceroute-id, Subjekt-Bundle, Position und Knotenverkettung zusammen. Bei Replikation können an derselben Position mehrere Zweige entstehen.

Eine sortierte Tabelle wirkt objektiv. Tatsächlich schrieb jeder dargestellte Knoten seine eigene Zeile unter eigener Offenlegungspolitik, und der Ursprung rekonstruierte die Ordnung. Kohärenz ersetzt keinen neutralen Zeugen.

Integrität reicht nur bis zur nächsten Änderung

TREB offenbart Identitäten, Topologie, Zeiten, Kapazität und Stau. Zugleich wird der Hinweg-Block und die Zustell- oder Löschberichtskopie an jedem teilnehmenden Knoten geändert. Ende-zu-Ende-Integrität oder -Vertraulichkeit ist für diese beweglichen Bytes nicht möglich. BIB oder BCB können sie jeweils nur vom aktuellen Sicherheitsursprung bis zum nächsten Akzeptor schützen.

Ein unveränderlicher Weiterleitungsbericht kann vom meldenden Knoten geschützt werden. Das stärkt die Herkunft einer Aussage, nicht die neutrale Beglaubigung des ganzen Pfads. Folgerichtig erklärt der Entwurf Hop-Records zu nicht Ende-zu-Ende-authentifizierten Diagnosedaten und schließt Routing sowie Zugriffskontrolle als Verwendungszweck aus.

Auch die report-to EID ist kein hinreichender Herkunftsnachweis. Ein gefälschtes Diagnose-Bundle könnte größere Berichte an Dritte lenken. Längenbegrenzung, Ratenlimit, Quellberechtigung und das Auslassen verdächtiger Kopien dämpfen die Verstärkung, ohne die Vertrauenslücke zu schließen.