跳到主要内容

3. CCNx 中时间值的使用

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

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

按照 [RFC8569] 当前的规定, CCNx 只将增量时间 (delta time) 用于 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 消息短小而采用紧凑编码尤其有价值.

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

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

按照 [RFC8569] 当前的规定, CCNx 将绝对时间用于多种重要功能. 这些绝对时间用法中的每一种, 都会给紧凑表示带来不同挑战. 以下小节对此进行讨论.

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

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

这两个时间值都可能位于过去或未来, 且差值可能很大. 它们还包含在消息的安全封套 (security envelope) 中. 因此, 似乎不存在一种实际可行的方法来定义替代的紧凑编码, 同时保留其语义和安全属性; 因而本文不再进一步考虑这种方法.

Content Object 的 Recommended Cache Time (RCT) ([RFC8569] 第 4 节) 是一个逐跳头部, 用于声明已缓存 Content Object 的过期时间, 单位为自 POSIX epoch 以来的毫秒数. 它目前通过 T_CACHETIME TLV 编码为 64 位无符号整数 (见 [RFC8609] 第 3.4.2 节).

Recommended Cache Time 可能位于很远的未来, 但不能位于过去, 并且很可能只是相对于当前时间的一个合理较短偏移量. 因此, 本文档允许将 Recommended Cache Time 解释为相对时间值而非绝对时间, 因为与绝对时间值相关联的语义似乎并非该值实用性的关键. 因此, 本文档使用以下规则集更新 Recommended Cache Time:

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

如果使用相对时间, 消息中记录的时间偏移通常不会计入每一跳在较低层的驻留时间 (例如处理, 排队) 和链路延迟. 因此, Recommended Cache Time 无法像使用绝对时间时那样准确. 本文档面向低功耗网络, 在这类网络中, 延迟边界相当宽松或并不存在. 对于 Recommended Cache Time 而言, 由毫秒到秒级传输延迟造成的累积误差在这些网络中仍然可以容忍, 且不会影响协议性能.

具有严格延迟边界的网络会使用专用硬件, 优化的软件例程以及流量工程来减少延迟变化. 随后可以在每一跳校正时间偏移, 从而得到精确的缓存时间.

最后于 更新