3. Usage of Time Values in CCNx (Verwendung von Zeitwerten in CCNx)

3.1. Relative Time in CCNx (Relative Zeit in CCNx)

CCNx, wie derzeit in [RFC8569] spezifiziert, verwendet Delta-Zeit nur für die Lebensdauer einer Interest-Nachricht (siehe Abschnitte 2.1, 2.2, 2.4.2 und 10.3 von [RFC8569]). Es ist ein Hop-by-Hop-Header-Wert und wird derzeit über das T_INTLIFE TLV als 64-Bit-Integer kodiert (Abschnitt 3.4.1 von [RFC8609]). Obwohl formal optional, wird erwartet, dass jede Interest-Nachricht das Interest Lifetime TLV in allen außer einigen Sonderfällen trägt; daher ist eine kompakte Kodierung besonders wertvoll, um Interest-Nachrichten kurz zu halten.

Da die aktuellen Verwendungen der Delta-Zeit nicht sowohl Genauigkeit als auch dynamischen Bereich gleichzeitig erfordern, kann man eine logarithmische Kodierung in Betracht ziehen, wie sie in [IEEE.754.2019] spezifiziert und in Abschnitt 4 beschrieben ist. Dieses Dokument aktualisiert CCNx-Nachrichten im TLV-Format [RFC8609], um diese alternative Kodierung für ausgewählte Zeitwerte zu ermöglichen.

3.2. Absolute Time in CCNx (Absolute Zeit in CCNx)

CCNx, wie derzeit in [RFC8569] spezifiziert, verwendet absolute Zeit für verschiedene wichtige Funktionen. Jede dieser absoluten Zeitverwendungen stellt eine andere Herausforderung für eine kompakte Darstellung dar. Diese werden in den folgenden Unterabschnitten diskutiert.

3.2.1. Signature Time and Expiry Time (Signaturzeit und Ablaufzeit)

Signature Time (Signaturzeit) ist der Zeitpunkt, zu dem die Signatur eines Content Object (Inhaltsobjekts) generiert wurde (siehe Abschnitte 8.2-8.4 von [RFC8569]). Expiry Time (Ablaufzeit) gibt die Zeit an, nach der ein Inhaltsobjekt als abgelaufen gilt (Abschnitt 4 von [RFC8569]). Beide Werte sind Inhaltsnachrichten-TLVs und repräsentieren absolute Zeitstempel in Millisekunden seit der POSIX-Epoche. Sie werden derzeit über die T_SIGTIME und T_EXPIRY TLVs als 64-Bit-Ganzzahlen ohne Vorzeichen kodiert (siehe Abschnitte 3.6.4.1.4.5 bzw. 3.6.2.2.2 von [RFC8609]).

Beide Zeitwerte könnten in der Vergangenheit oder in der Zukunft liegen, möglicherweise mit einem großen Delta. Sie sind auch in der Sicherheitshülle der Nachricht enthalten. Daher scheint es keine praktische Möglichkeit zu geben, eine alternative kompakte Kodierung zu definieren, die ihre Semantik und Sicherheitseigenschaften bewahrt; daher wird dieser Ansatz nicht weiter betrachtet.

3.2.2. Recommended Cache Time (Empfohlene Cache-Zeit)

Die Recommended Cache Time (empfohlene Cache-Zeit, RCT) für ein Content Object (Abschnitt 4 von [RFC8569]) ist ein Hop-by-Hop-Header, der die Ablaufzeit für ein zwischengespeichertes Inhaltsobjekt in Millisekunden seit der POSIX-Epoche angibt. Sie wird derzeit über das T_CACHETIME TLV als 64-Bit-Ganzzahl ohne Vorzeichen kodiert (siehe Abschnitt 3.4.2 von [RFC8609]).

Eine empfohlene Cache-Zeit könnte weit in der Zukunft liegen, kann aber nicht in der Vergangenheit liegen und ist wahrscheinlich ein vernünftig kurzer Versatz von der aktuellen Zeit. Daher erlaubt dieses Dokument, dass die empfohlene Cache-Zeit als relativer Zeitwert statt als absolute Zeit interpretiert wird, da die mit einem absoluten Zeitwert verbundene Semantik für den Nutzen dieses Werts nicht kritisch zu sein scheint. Dieses Dokument aktualisiert daher die empfohlene Cache-Zeit mit dem folgenden Regelsatz:

Verwenden Sie absolute Zeit gemäß [RFC8609]
Verwenden Sie relative Zeit, wenn die kompakte Zeitdarstellung verwendet wird (siehe Abschnitte 4 und 5)

Wenn relative Zeit verwendet wird, berücksichtigt der in einer Nachricht aufgezeichnete Zeitversatz typischerweise nicht die Verweilzeiten auf niedrigeren Schichten (z.B. für Verarbeitung, Warteschlangen) und Verbindungsverzögerungen für jeden Hop. Daher kann die empfohlene Cache-Zeit nicht so genau sein wie bei Verwendung absoluter Zeit. Dieses Dokument zielt auf Netzwerke mit geringer Leistung ab, bei denen Verzögerungsgrenzen eher locker sind oder nicht existieren. Ein akkumulierter Fehler aufgrund von Übertragungsverzögerungen im Bereich von Millisekunden und Sekunden für die empfohlene Cache-Zeit ist in diesen Netzwerken noch tolerierbar und beeinträchtigt die Protokollleistung nicht.

Netzwerke mit engen Latenzgrenzen verwenden dedizierte Hardware, optimierte Softwareroutinen und Traffic Engineering, um Latenzschwankungen zu reduzieren. Zeitversätze können dann bei jedem Hop korrigiert werden, um exakte Cache-Zeiten zu erzielen.