Zusammenfassung

  • RFC 9510 teilt ein Byte in fünf Exponenten- und drei Mantissenbits und rundet nicht darstellbare Zeiten auf den nächstkleineren Wert ab.
  • Die bestehenden TLVs bleiben erhalten. Deshalb können Legacy- und aktualisierte Forwarder demselben Drahtbild völlig unterschiedliche Zustandsdauern geben.
  • Eine prüfbare Kette braucht Rohwert, Softwarefähigkeit, hopweise Umrechnung, PIT- oder Cache-Ereignis und beobachtetes Paketergebnis.

Eine schrittweise Aktualisierung schafft für kurze Zeit zwei Netze am selben Ort. Ein Interest erreicht einen älteren CCNx-Forwarder mit einem ein Byte langen Interest Lifetime. Das Gerät liest 0 bis 255 Millisekunden. Der nächste Forwarder folgt RFC 9510 und zerlegt dieselben acht Bits in Exponent und Mantisse. Aus einem kurzen Zähler kann ein Zeitraum bis in die Größenordnung von Jahren werden.

Die Verdichtung löst ein legitimes Problem. RFC 8569 definiert die CCNx-Semantik, RFC 8609 das TLV-Format. In strom- und bandbreitenarmen Netzen ist ein langer Zeitwert teuer. Die ICN-Anpassung für Low-Power-WPANs liefert die praktische Grundlage, die ICN-Forschungsfragen den weiteren Rahmen.

Das Format lehnt sich an RFC 5497 an. Nahe null sind die Schritte fein; mit wachsender Dauer steigt die Reichweite auf Kosten der Genauigkeit. Der größte Testwert entspricht 125.829.120 Sekunden, knapp vier Jahren. Nicht darstellbare Werte werden nach unten gerundet. Damit enthält die Kodierung neben einem Zeitwert auch eine festgelegte Näherungsentscheidung.

Der Versionshinweis steckt in der Länge

RFC 9510 vergibt keinen neuen Typ. Interest Lifetime und Recommended Cache Time behalten ihre Einträge im IANA-Register für CCNx; die Länge eins kennzeichnet die kompakte Darstellung.

Die Autoren nennen die Rückwärtskompatibilität ausdrücklich als Problem. Sie halten den Kompromiss für vertretbar, weil die CCNx-Dokumente Experimental sind, kleine Sensor- und IoT-Netze koordinierte Umstellungen erlauben können und die Hop-by-Hop-Felder nicht vom signierten Hash geschützt sind. Ein neuer Forwarder darf beim Weiterleiten umkodieren. Diese Begründung gilt für einen beherrschten Upgrade-Bereich, nicht für unbekannten Versionsmix.

Beim Interest Lifetime verkürzt ein Legacy-Gerät einen kompakten Code auf höchstens 255 Millisekunden und kann einen PIT-Eintrag zu früh entfernen. Ein aktualisiertes Gerät kann einen kurzen Legacy-Wert als kompakten Code lesen und Zustand bis zu ungefähr vier Jahre halten. Die eine Richtung erzeugt vorzeitige Zeitüberschreitung, die andere Zustandsbelegung.

Recommended Cache Time bricht anders. Ein neues Gerät behandelt das Byte als relativen Abstand, bildet aus Empfangszeit und Dauer einen absoluten Termin und kodiert vor dem nächsten Hop neu. Das alte Format erwartete acht Byte absolute POSIX-Zeit. Länge eins ist dort ein Struktur- oder Syntaxfehler und sollte zur Verwerfung führen; andernfalls wirkt der Wert wie ein Zeitpunkt weit in der Vergangenheit. Betroffen ist sowohl Cache-Nutzung als auch Paketannahme.

Signierte Zeit bleibt getrennt

Signature Time und Expiry Time sind nicht Teil der Änderung. Sie bleiben absolute Zeitstempel in der Sicherheitsumhüllung des Content Object. RFC 9510 verwirft für sie die Kompaktform, weil Bedeutung und Sicherheit nicht erhalten blieben. Eine Cache-Empfehlung beweist daher keine Frische, ein Expiry Time keinen tatsächlichen Cache-Aufenthalt und eine Signatur keine Interpretation des Hop-by-Hop-Bytes.

Die Beweiskette beginnt mit Paket, TLV-Typ, Länge und Rohwert. Danach folgen Build und Einstellung des Senders, Build und Regel des Empfängers, Empfangszeit, dekodierte Dauer, absoluter Termin und Umkodierung. PIT-Anlage oder -Freigabe sowie Cache-Aufnahme, -Verwerfung und -Entfernung sind eigene Belege. Paketspur und Anwendungsergebnis schließen die Kette.

Die amtlichen Quellen sichern den Text. Der RFC Editor stellt Informationsseite, Textfassung, XML-Quelle und Errata-Suche bereit. Der Datatracker bewahrt Historie, finalen Entwurf und Referenzen. Keiner dieser Nachweise ist Telemetrie eines Produktivnetzes.

RFC 9510 ist ein Experimental RFC des IRTF-Streams und gibt ICNRG-Konsens wieder, keinen IETF-Standard. RFC 7841 erklärt, dass IRTF-Ergebnisse für Untersuchung veröffentlicht werden können, ohne einsatzgeeignet zu sein. Die lokale Freigabe bleibt deshalb eine eigene Entscheidung.

Als offengelegte redaktionelle Linse dienen Heng Lus Texte über Running-Code-Primat, minimale Anfangsspezifikation und freiwillige Übernahme sowie Realitätsschichten. Sie sind keine Protokollnorm. Sie schärfen lediglich die Trennung zwischen Symbol, Softwaredeutung, Gerätezustand und beobachtetem Ergebnis.