メインコンテンツまでスキップ

3. Usage of Time Values in CCNx (CCNx における時間値の使用)

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 を参照)。これはホップバイホップのヘッダー値であり, 現在 T_INTLIFE TLV を介して 64 ビット整数としてエンコードされています ([RFC8609] のセクション 3.4.1)。形式的にはオプションの TLV ですが, 一部の特殊なケースを除いて, すべての Interest メッセージは Interest Lifetime TLV を運ぶことが期待されます。したがって, Interest メッセージを短く保つために, コンパクトなエンコーディングを持つことは特に価値があります。

デルタ時間の現在の使用は精度と動的範囲の両方を同時に必要としないため, [IEEE.754.2019] で指定され, セクション 4 で概説されているような対数エンコーディング (logarithmic encoding) を検討できます。本文書は, 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 を参照)。

両方の時間値は, 過去または将来にある可能性があり, 大きなデルタの可能性があります。これらはメッセージのセキュリティエンベロープにも含まれています。したがって, その意味論とセキュリティプロパティを保持する代替のコンパクトエンコーディングを定義する実用的な方法はないようです。したがって, このアプローチはこれ以上検討されません。

Content Object の Recommended Cache Time (推奨キャッシュ時間, RCT) ([RFC8569] のセクション 4) は, POSIX エポックからのミリ秒単位でキャッシュされたコンテンツオブジェクトの有効期限を示すホップバイホップヘッダーです。これは現在, T_CACHETIME TLV を介して 64 ビット符号なし整数としてエンコードされています ([RFC8609] のセクション 3.4.2 を参照)。

推奨キャッシュ時間は遠い将来である可能性がありますが, 過去である可能性はなく, 現在時刻からの適度に短いオフセットである可能性が高いです。したがって, 本文書は, 絶対時間値に関連付けられたセマンティクスがこの値の有用性にとって重要ではないように思われるため, 推奨キャッシュ時間を絶対時間ではなく相対時間値として解釈することを許可します。したがって, 本文書は次のルールセットで推奨キャッシュ時間を更新します:

  • [RFC8609] に従って絶対時間を使用する
  • コンパクト時間表現が使用される場合は相対時間を使用する (セクション 4 および 5 を参照)

相対時間が使用される場合, メッセージに記録された時間オフセットは通常, 下位層での滞在時間 (例: 処理, キューイング) およびすべてのホップのリンク遅延を考慮しません。したがって, 推奨キャッシュ時間は絶対時間が使用される場合ほど正確ではありません。本文書は低電力ネットワークを対象としており, ここでは遅延境界はかなり緩いか, 存在しません。ミリ秒と秒の範囲での伝送遅延による推奨キャッシュ時間の累積エラーは, これらのネットワークではまだ許容可能であり, プロトコルのパフォーマンスに影響しません。

厳格なレイテンシー境界を持つネットワークは, 専用のハードウェア, 最適化されたソフトウェアルーチン, およびレイテンシー変動を減らすためのトラフィックエンジニアリングを使用します。時間オフセットはすべてのホップで修正され, 正確なキャッシュ時間を生成できます。