3. Usage of Time Values in CCNx (CCNx 中时间值的使用)

3.1. Relative Time in CCNx (CCNx 中的相对时间)

CCNx, 如当前在 [RFC8569] 中指定的, 仅将增量时间用于 Interest 消息的生命周期 (请参阅 [RFC8569] 的第 2.1, 2.2, 2.4.2 和 10.3 节)。它是一个逐跳 (hop-by-hop) 头部值, 目前通过 T_INTLIFE TLV 编码为 64 位整数 ([RFC8609] 的第 3.4.1 节)。虽然形式上是可选的 TLV, 但除了某些特殊情况外, 每个 Interest 消息都应该携带 Interest Lifetime TLV; 因此, 拥有紧凑编码对于保持 Interest 消息简短特别有价值。

由于增量时间的当前使用不要求同时具备精度和动态范围, 因此可以考虑对数编码 (logarithmic encoding), 例如在 [IEEE.754.2019] 中指定并在第 4 节中概述的编码。本文档更新 TLV 格式的 CCNx 消息 [RFC8609], 以允许对选定的时间值使用这种替代编码。

3.2. Absolute Time in CCNx (CCNx 中的绝对时间)

CCNx, 如当前在 [RFC8569] 中指定的, 将绝对时间用于各种重要功能。每种绝对时间的使用都对紧凑表示提出了不同的挑战。这些在以下子节中讨论。

3.2.1. Signature Time and Expiry Time (签名时间和过期时间)

Signature Time (签名时间) 是生成内容对象 (Content Object) 签名的时间 (请参阅 [RFC8569] 的第 8.2-8.4 节)。Expiry Time (过期时间) 表示内容对象被认为已过期的时间 ([RFC8569] 的第 4 节)。这两个值都是内容消息 TLV, 表示自 POSIX 纪元以来的绝对时间戳 (以毫秒为单位)。它们目前分别通过 T_SIGTIME 和 T_EXPIRY TLV 编码为 64 位无符号整数 (分别参见 [RFC8609] 的第 3.6.4.1.4.5 节和第 3.6.2.2.2 节)。

这两个时间值可能在过去或将来, 并且可能相差很大。它们还包含在消息的安全封套 (security envelope) 中。因此, 似乎没有实用的方法来定义保留其语义和安全属性的替代紧凑编码; 因此, 不再进一步考虑这种方法。

3.2.2. Recommended Cache Time (推荐缓存时间)

内容对象的 Recommended Cache Time (推荐缓存时间, RCT) ([RFC8569] 的第 4 节) 是一个逐跳头部, 声明缓存的内容对象的过期时间 (自 POSIX 纪元以来的毫秒数)。它目前通过 T_CACHETIME TLV 编码为 64 位无符号整数 (参见 [RFC8609] 的第 3.4.2 节)。

推荐缓存时间可能在遥远的将来, 但不能在过去, 并且很可能是距当前时间相当短的偏移量。因此, 本文档允许将推荐缓存时间解释为相对时间值而不是绝对时间, 因为与绝对时间值相关的语义似乎对该值的效用并不重要。因此, 本文档使用以下规则集更新推荐缓存时间:

按照 [RFC8609] 使用绝对时间
如果使用紧凑时间表示, 则使用相对时间 (参见第 4 节和第 5 节)

如果使用相对时间, 消息中记录的时间偏移量通常不会考虑较低层的驻留时间 (例如, 用于处理, 排队) 以及每一跳的链路延迟。因此, 推荐缓存时间不能像使用绝对时间时那样精确。本文档针对低功耗网络, 在这些网络中, 延迟界限相当宽松或不存在。由于毫秒和秒范围内的传输延迟导致的推荐缓存时间累积误差在这些网络中仍然是可容忍的, 并且不会影响协议性能。

具有严格延迟界限的网络使用专用硬件, 优化的软件例程和流量工程来减少延迟变化。然后可以在每一跳上纠正时间偏移量, 以产生精确的缓存时间。