Internet Research Task Force (IRTF) C. Gündoğan
Request for Comments: 9510 Huawei
Updates: 8609 TC. Schmidt
Category: Experimental HAW Hamburg
ISSN: 2070-1721 D. Oran
Network Systems Research and Design
M. Wählisch
TU Dresden
February 2024
Content-Centric Networking (CCNx) utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth-constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding. This document updates RFC 8609 ("CCNx messages in TLV Format") to specify this alternative encoding.
コンテンツ中心のネットワーキング（CCNX）は、多くの機能にデルタ時間を利用しています。制約されたノードまたは帯域幅に制約されたネットワークを持つ環境でCCNXを使用する場合、デルタ時間の圧縮表現を持つことが価値があります。そうするためには、精度またはダイナミックレンジのいずれかを犠牲にする必要があります。デルタ時間の現在の使用は両方を同時に必要としないため、対数エンコーディングを考慮することができます。このドキュメントは、RFC 8609（「TLV形式のccnxメッセージ」）を更新して、この代替エンコードを指定します。
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
このドキュメントは、IRTF情報中心のネットワーキング研究グループ（ICNRG）の製品です。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の情報中心のネットワーキング研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9510.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9510で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Terminology
3. Usage of Time Values in CCNx
3.1. Relative Time in CCNx
3.2. Absolute Time in CCNx
4. A Compact Time Representation with Logarithmic Range
5. Protocol Integration of the Compact Time Representation
5.1. Interest Lifetime
5.2. Recommended Cache Time
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Test Vectors
Appendix B. Efficient Time Value Approximation
Acknowledgments
Authors' Addresses
CCNx is well suited for Internet of Things (IoT) applications [RFC7927]. Low-Power Wireless Personal Area Network (LoWPAN) adaptation layers (e.g., [RFC9139]) confirm the advantages of a space-efficient packet encoding for low-power and lossy networks. CCNx utilizes absolute and delta time values for a number of functions. When using CCNx in resource-constrained environments, it is valuable to have a compact representation of time values. However, any compact time representation has to sacrifice accuracy or dynamic range. For some time uses, this is relatively straightforward to achieve; for other uses, it is not. As a result of experiments in bandwidth-constrained IEEE 802.15.4 deployments [ICNLOWPAN], this document discusses the various cases of time values, proposes a compact encoding for delta times, and updates [RFC8609] to utilize this encoding format in CCNx messages.
CCNXは、モノのインターネット（IoT）アプリケーション[RFC7927]に適しています。低電力ワイヤレスパーソナルエリアネットワーク（ローパン）適応レイヤー（[RFC9139]など）は、低電力および損失ネットワーク向けのスペース効率の高いパケットエンコードの利点を確認します。CCNXは、多くの関数に絶対時間値とデルタ時間値を使用します。リソースに制約のある環境でCCNXを使用する場合、時間値をコンパクトに表現することが価値があります。ただし、コンパクトな時間表現は、精度またはダイナミックレンジを犠牲にする必要があります。しばらくの間、これは比較的簡単です。他の用途についてはそうではありません。帯域幅が制約されたIEEE 802.15.4の展開[icnlowpan]の実験の結果として、このドキュメントでは、時間値のさまざまなケースについて説明し、デルタ時間のコンパクトなエンコードを提案し、[RFC8609]を更新して、CCNXメッセージでこのエンコード形式を利用します。
This document has received fruitful reviews by the members of the research group (see the Acknowledgments section). It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series. This document does not constitute an IETF standard.
このドキュメントは、研究グループのメンバーから実り多いレビューを受け取りました（謝辞セクションを参照）。このドキュメントがRFCシリーズのIRTFストリームに公開されるべきであることは、ICNRGのコンセンサスです。このドキュメントは、IETF標準を構成するものではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the terminology of [RFC8569] and [RFC8609] for CCNx entities.
このドキュメントでは、CCNXエンティティに[RFC8569]と[RFC8609]の用語を使用しています。
The following terms are used in the document and defined as follows:
次の用語はドキュメントで使用され、次のように定義されています。
byte:
バイト：
synonym for octet
Octetの同義語
time value:
時間値：
a time offset measured in seconds
数秒で測定されたタイムオフセット
time code:
時間コード：
an 8-bit encoded time value as defined in [RFC5497]
[RFC5497]で定義されている8ビットエンコードされた時間値
CCNx, as currently specified in [RFC8569], utilizes delta time for only the lifetime of an Interest message (see Sections 2.1, 2.2, 2.4.2, and 10.3 of [RFC8569]). It is a hop-by-hop header value, and is currently encoded via the T_INTLIFE TLV as a 64-bit integer (Section 3.4.1 of [RFC8609]). While formally an optional TLV, every Interest message is expected to carry the Interest Lifetime TLV in all but some corner cases; hence, having compact encoding is particularly valuable to keep Interest messages short.
現在[RFC8569]で指定されているCCNXは、関心メッセージの寿命のみにデルタ時間を利用します（[RFC8569]のセクション2.1、2.2、2.4.2、および10.3を参照）。これはホップバイホップヘッダー値であり、現在、T_INTLIFE TLVを介して64ビット整数としてエンコードされています（[RFC8609]のセクション3.4.1）。正式にはオプションのTLVですが、すべての関心メッセージは、一部のコーナーケースを除くすべてのもので利息の生涯TLVを運ぶことが期待されています。したがって、コンパクトなエンコードを使用することは、興味のメッセージを短くするために特に価値があります。
Since the current uses of delta time do not require both accuracy and dynamic range simultaneously, one can consider a logarithmic encoding such as that specified in [IEEE.754.2019] and as outlined in Section 4. This document updates CCNx messages in TLV format [RFC8609] to permit this alternative encoding for selected time values.
デルタ時間の現在の使用は精度とダイナミックレンジの両方を同時に必要としないため、[IEEE.754.2019]で指定されているように、およびセクション4で概説されているような対数エンコードを考慮することができます。]選択した時間値のこの代替エンコードを許可します。
CCNx, as currently specified in [RFC8569], utilizes absolute time for various important functions. Each of these absolute time usages poses a different challenge for a compact representation. These are discussed in the following subsections.
現在[RFC8569]で指定されているCCNXは、さまざまな重要な機能に絶対時間を利用しています。これらの絶対的な時間使用のそれぞれは、コンパクトな表現に対して異なる課題をもたらします。これらについては、以下のサブセクションで説明します。
Signature Time is the time the signature of a Content Object was generated (see Sections 8.2-8.4 of [RFC8569]). Expiry Time indicates the time after which a Content Object is considered expired (Section 4 of [RFC8569]). Both values are content message TLVs and represent absolute timestamps in milliseconds since the POSIX epoch. They are currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit unsigned integers (see Sections 3.6.4.1.4.5 and 3.6.2.2.2 of [RFC8609], respectively).
署名時間とは、コンテンツオブジェクトの署名が生成された時間です（[RFC8569]のセクション8.2-8.4を参照）。有効期間は、コンテンツオブジェクトが期限切れと見なされる時間を示します（[RFC8569]のセクション4）。両方の値はコンテンツメッセージTLVであり、POSIXエポック以来のミリ秒で絶対タイムスタンプを表します。現在、T_SIGTIMEおよびT_EXPIRY TLVを介して64ビットの符号なし整数としてエンコードされています（それぞれ[RFC8609]のセクション3.6.4.1.4.5および3.6.2.2.2を参照）。
Both time values could be in the past or in the future, potentially by a large delta. They are also included in the security envelope of the message. Therefore, it seems there is no practical way to define an alternative compact encoding that preserves its semantics and security properties; therefore, this approach is not considered further.
両方の時間値は、潜在的に大きなデルタによって、過去または将来になる可能性があります。また、メッセージのセキュリティエンベロープにも含まれています。したがって、セマンティクスとセキュリティプロパティを保持する代替コンパクトエンコードを定義する実用的な方法はないようです。したがって、このアプローチはさらに考慮されません。
Recommended Cache Time (RCT) for a Content Object (Section 4 of [RFC8569]) is a hop-by-hop header stating the expiration time for a cached Content Object in milliseconds since the POSIX epoch. It is currently encoded via the T_CACHETIME TLV as a 64-bit unsigned integer (see Section 3.4.2 of [RFC8609]).
コンテンツオブジェクトの推奨キャッシュ時間（RCT）（[RFC8569]のセクション4）は、POSIXエポック以来のミリ秒単位でキャッシュされたコンテンツオブジェクトの有効期限を示すホップバイホップヘッダーです。現在、T_Cachetime TLVを介して64ビットの非署名整数としてエンコードされています（[RFC8609]のセクション3.4.2を参照）。
A Recommended Cache Time could be far in the future, but it cannot be in the past and is likely to be a reasonably short offset from the current time. Therefore, this document allows the Recommended Cache Time to be interpreted as a relative time value rather than an absolute time, because the semantics associated with an absolute time value do not seem to be critical to the utility of this value. This document therefore updates the Recommended Cache Time with the following rule set:
推奨されるキャッシュ時間は将来的にははるかに存在する可能性がありますが、過去には存在できず、現在の時期から合理的に短いオフセットになる可能性があります。したがって、このドキュメントにより、推奨されるキャッシュ時間は、絶対時間値に関連付けられたセマンティクスがこの値の有用性にとって重要ではないように見えるため、絶対時間ではなく相対時間値として解釈できます。したがって、このドキュメントは、次のルールセットで推奨されるキャッシュ時間を更新します。
* Use absolute time as per [RFC8609]
* [RFC8609]に従って絶対時間を使用する
* Use relative time, if the compact time representation is used (see Sections 4 and 5)
* コンパクト時間表現が使用される場合は、相対時間を使用します（セクション4および5を参照）
If relative time is used, the time offset recorded in a message will typically not account for residence times on lower layers (e.g., for processing, queuing) and link delays for every hop. Thus, the Recommended Cache Time cannot be as accurate as when absolute time is used. This document targets low-power networks, where delay bounds are rather loose or do not exist. An accumulated error due to transmission delays in the range of milliseconds and seconds for the Recommended Cache Time is still tolerable in these networks and does not impact the protocol performance.
相対時間を使用すると、メッセージに記録された時間オフセットは、通常、下層層の滞留時間（処理、キューイングなど）とすべてのホップのリンク遅延を考慮しません。したがって、推奨されるキャッシュ時間は、絶対時間を使用するときほど正確ではありません。このドキュメントは、遅延境界がかなり緩んでいるか、存在しない低電力ネットワークをターゲットにしています。推奨されるキャッシュ時間のミリ秒および秒の範囲での伝送遅延による累積エラーは、これらのネットワークで依然として許容され、プロトコルのパフォーマンスに影響を与えません。
Networks with tight latency bounds use dedicated hardware, optimized software routines, and traffic engineering to reduce latency variations. Time offsets can then be corrected on every hop to yield exact cache times.
厳しい遅延境界を持つネットワークは、専用のハードウェア、最適化されたソフトウェアルーチン、トラフィックエンジニアリングを使用して、レイテンシの変動を減らします。その後、時間オフセットをすべてのホップで修正して、正確なキャッシュ時間を生成できます。
This document uses the compact time representation described in "Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)" (see Section 7 of [RFC9139]) that was inspired by [RFC5497] and [IEEE.754.2019]. Its logarithmic encoding supports a representation ranging from milliseconds to years. Figure 1 depicts the logarithmic nature of this time representation.
このドキュメントでは、[RFC5497]および[IEEEに触発された「[RFC9139]のセクション7を参照）（[RFC9139]のセクション7を参照）（[RFC9139]のセクション7を参照））と[IEEE]に「情報中心ネットワーク（ICN）適応（ローパン）への適応」で説明されているコンパクトな時間表現を使用します。754.2019]。その対数エンコードは、ミリ秒から年までの表現をサポートします。図1は、この時間表現の対数性を示しています。
|| | | | | | | | | | |
+-----------------------------------------------------------------+
milliseconds years
Figure 1: A logarithmic range representation allows for higher precision in the smaller time ranges and still supports large time deltas.
図1：対数範囲の表現により、短時間の範囲でより高い精度が可能になり、大規模な時間デルタをサポートします。
Time codes encode exponent and mantissa values in a single byte. In contrast to the representation in [IEEE.754.2019], time codes only encode non-negative numbers and hence do not include a separate bit to indicate integer signedness. Figure 2 shows the configuration of a time code: an exponent width of 5 bits, and a mantissa width of 3 bits.
タイムコードは、単一のバイトで指数とマンティッサ値をエンコードします。[IEEE.754.2019]の表現とは対照的に、時間コードは非陰性の数値のみをエンコードするため、整数の署名を示すために別のビットを含めません。図2は、時間コードの構成：5ビットの指数幅と3ビットのマンティッサ幅を示しています。
<--- one byte wide --->
+----+----+----+----+----+----+----+----+
| exponent (b) | mantissa (a) |
+----+----+----+----+----+----+----+----+
0 1 2 3 4 5 6 7
Figure 2: A time code with exponent and mantissa to encode a logarithmic range time representation.
図2：対数範囲の時間表現をエンコードする指数とマンティッサを備えたタイムコード。
The base unit for time values is seconds. A time value is calculated using the following formula (adopted from [RFC5497] and [RFC9139]), where (a) represents the mantissa, (b) the exponent, and (C) a constant factor set to C := 1/32.
時間値のベースユニットは秒です。時間値は、次の式（[RFC5497]および[RFC9139]から採用された）を使用して計算されます。ここで、（a）はマンティッサを表し、（b）指数を表し、（c）c：= 1/32に設定された定数係数。
Subnormal (b == 0):
サブノーマル（b == 0）：
(0 + a/8) * 2 * C
（0 a/8） * 2 * c
Normalized (b > 0):
正規化（b> 0）：
(1 + a/8) * 2^b * C
（1 a/8） * 2^b * c
The subnormal form provides a gradual underflow between zero and the smallest normalized number. Eight time values exist in the subnormal range [0s,~0.0546875s] with a step size of ~0.0078125s between each time value. This configuration also encodes the following convenient numbers in seconds: [1, 2, 4, 8, 16, 32, 64, ...]. Appendix A includes test vectors to illustrate the logarithmic range.
正常な形式は、ゼロと最小の正規化された数の間の段階的なアンダーフローを提供します。サブノーマル範囲[0S、〜0.0546875S]に8つの時間値が存在し、各時間値の間に〜0.0078125のステップサイズがあります。この構成は、次の便利な数字を数秒でコードします：[1、2、4、8、16、32、64、...]。付録Aには、対数範囲を示すテストベクトルが含まれています。
An example algorithm to encode a time value into the corresponding exponent and mantissa is given as pseudocode in Figure 3. Not all time values can be represented by a time code. For these instances, a time code is produced that represents a time value closest to and smaller than the initial time value input.
対応する指数に時間値をエンコードするアルゴリズムの例が図3に擬似コードとして与えられます。すべての時間値をタイムコードで表すことはできません。これらのインスタンスでは、初期タイム値の入力よりも最も近い時間と小さい時間値を表すタイムコードが生成されます。
input: float v // time value
output: int a, b // mantissa, exponent of time code
(a, b) encode (v):
if (v == 0)
return (0, 0)
if (v < 2 * C) // subnormal
a = floor (v * 4 / C) // round down
return (a, 0)
else // normalized
if (v > (1 + 7/8) * 2^31 * C) // check bounds
return (7, 31) // return maximum
else
b = floor (log2(v / C)) // round down
a = floor ((v / (2^b * C) - 1) * 8) // round down
return (a, b)
Figure 3: Algorithm in pseudocode.
図3：Pseudocodeのアルゴリズム。
For example, no specific time code for 0.063 exists. However, this algorithm maps to the closest valid time code that is smaller than 0.063, i.e., exponent 1 and mantissa 0 (the same as for time value 0.0625).
たとえば、0.063の特定の時間コードは存在しません。ただし、このアルゴリズムは、0.063よりも小さい最も近い有効な時間コード、つまりExponent 1およびMantissa 0（時間値0.0625と同じ）にマップします。
A straightforward way to accommodate the compact time approach is to use a 1-byte length field to indicate this alternative encoding while retaining the existing TLV registry entries. This approach has backward compatibility problems, but it is still considered for the following reasons:
コンパクト時間アプローチに対応する簡単な方法は、1バイトの長さフィールドを使用して、既存のTLVレジストリエントリを保持しながらこの代替エンコードを示すことです。このアプローチには後方互換性の問題がありますが、以下の理由でまだ考慮されています。
* Both CCNx RFCs ([RFC8569] and [RFC8609]) are Experimental and not Standards Track; hence, expectations for forward and backward compatibility are not as stringent. "Flag day" upgrades of deployed CCNx networks, while inconvenient, are still feasible.
* CCNX RFCS（[RFC8569]と[RFC8609]）の両方は実験的であり、標準トラックではありません。したがって、前方および後方の互換性に対する期待はそれほど厳しくありません。展開されたCCNXネットワークの「フラッグデイ」アップグレードは、不便ですが、まだ実行可能です。
* The major use case for these compressed encodings are smaller-scale IoT and/or sensor networks where the population of consumers, producers, and forwarders is reasonably small.
* これらの圧縮エンコーディングの主なユースケースは、消費者、生産者、フォワーダーの人口がかなり小さい小規模のIoTおよび/またはセンサーネットワークです。
* Since the current TLVs have hop-by-hop semantics, they are not covered by any signed hash and hence may be freely re-encoded by any forwarder. That means a forwarder supporting the new encoding can translate freely between the two encodings.
* 現在のTLVにはホップバイホップセマンティクスがあるため、署名されたハッシュでカバーされていないため、フォワーダーによって自由に再エンコードされる場合があります。つまり、新しいエンコードをサポートするフォワーダーは、2つのエンコーディング間で自由に翻訳できます。
* The alternative of assigning new TLV registry values does not substantially mitigate the interoperability problems anyway.
* 新しいTLVレジストリ値を割り当てる代替案は、とにかく相互運用性の問題を実質的に軽減するものではありません。
The Interest Lifetime definition in [RFC8609] allows for a variable-length lifetime representation, where a length of 1 encodes the linear range [0,255] in milliseconds. This document changes the definition to always encode 1-byte Interest Lifetime values in the compact time value representation (see Figure 4). For any other length, Interest Lifetimes are encoded as described in Section 3.4.1 of [RFC8609].
[RFC8609]の関心寿命の定義は、さまざまな長さの寿命表現を可能にします。ここで、1の長さはミリ秒単位で線形範囲[0,255]をコードします。このドキュメントは、定義を変更して、コンパクト時間値の表現で常に1バイトの関心の生涯値をエンコードします（図4を参照）。他の長さについては、[RFC8609]のセクション3.4.1で説明されているように、関心寿命がエンコードされます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_INTLIFE | Length = 1 |
+---------------+---------------+---------------+---------------+
| COMPACT_TIME |
+---------------+
Figure 4: Changes to the definition of the Interest Lifetime TLV.
図4：関心のある生涯tlvの定義の変更。
The Recommended Cache Time definition in [RFC8609] specifies an absolute time representation that is of a length fixed to 8 bytes. This document changes the definition to always encode 1-byte Recommended Cache Time values in the compact relative time value representation (see Figure 5). For any other length, Recommended Cache Times are encoded as described in Section 3.4.2 of [RFC8609].
[RFC8609]の推奨キャッシュ時間定義は、8バイトに固定された長さの絶対時間表現を指定します。このドキュメントは、定義を変更して、コンパクトな相対時間値表現で常に1バイトの推奨キャッシュ時間値をエンコードします（図5を参照）。他の長さについては、[RFC8609]のセクション3.4.2で説明されているように、推奨されるキャッシュ時間がエンコードされます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CACHETIME | Length = 1 |
+---------------+---------------+---------------+---------------+
| COMPACT_TIME |
+---------------+
Figure 5: Changes to the definition of the Recommended Cache Time TLV.
図5：推奨されるキャッシュ時間TLVの定義の変更。
The packet processing is adapted to calculate an absolute time from the relative time code based on the absolute reception time. On transmission, a new relative time code is calculated based on the current system time.
パケット処理は、絶対受信時間に基づいて相対時間コードから絶対時間を計算するように適合しています。伝送では、現在のシステム時間に基づいて新しい相対時間コードが計算されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document makes no semantic changes to [RFC8569], nor to any of the security properties of the message encodings described in [RFC8609]; hence, it has the same security considerations as those two documents. Careful consideration is needed for networks that deploy forwarders with support (updated forwarder) and without support (legacy forwarder) for this compact time representation:
このドキュメントは、[RFC8569]、[RFC8609]で説明されているメッセージエンコーディングのセキュリティプロパティのいずれにも、セマンティックな変更を加えません。したがって、これらの2つのドキュメントと同じセキュリティ上の考慮事項があります。このコンパクトな時間表現のサポート（レガシー転送業者）をサポート（更新された転送者）で展開するネットワークについては、慎重に検討する必要があります。
Interest Lifetime:
興味の生涯：
A legacy forwarder interprets a time code as an Interest Lifetime between 0 and 255 milliseconds. This may lead to a degradation of network performance, since Pending Interest Table (PIT) entries timeout quicker than expected. An updated forwarder interprets short lifetimes set by a legacy forwarder as time codes, thus configuring timeouts of up to 4 years. This leads to an inefficient occupation of state space.
レガシー転送業者は、タイムコードを0〜255ミリ秒の間の利息寿命として解釈します。これは、予想よりも速くタイムアウトをエントリしているため、ネットワークパフォーマンスの低下につながる可能性があります。更新されたフォワーダーは、レガシー転送業者によってタイムコードとして設定された短い寿命を解釈するため、最大4年のタイムアウトを構成します。これは、国家空間の非効率的な占領につながります。
Recommended Cache Time:
推奨キャッシュ時間：
A legacy forwarder considers a Recommended Cache Time with length 1 as a structural or syntactical error and it SHOULD discard the packet (Section 10.3.9 of [RFC8569]). Otherwise, a legacy forwarder interprets time codes as absolute time values far in the past, which impacts cache utilization.
レガシーフォワーダーは、長さ1の推奨キャッシュ時間を構造的または構文的なエラーと見なし、パケットを破棄する必要があります（[RFC8569]のセクション10.3.9）。それ以外の場合、レガシー転送業者は、過去には遠い絶対時間値として時間コードを解釈し、キャッシュの利用に影響を与えます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics", RFC 8569,
DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.
[ICNLOWPAN]
Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch,
"Designing a LoWPAN convergence layer for the Information
Centric Internet of Things", Computer Communications, Vol.
164, No. 1, p. 114-123, Elsevier, December 2020,
<https://doi.org/10.1016/j.comcom.2020.10.002>.
[IEEE.754.2019]
IEEE, "Standard for Floating-Point Arithmetic", IEEE
Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, June 2019,
<https://standards.ieee.org/content/ieee-standards/en/
standard/754-2019.html>.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
DOI 10.17487/RFC5497, March 2009,
<https://www.rfc-editor.org/info/rfc5497>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
[RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C.,
Marxer, C., and C. Tschudin, "Information-Centric
Networking (ICN) Adaptation to Low-Power Wireless Personal
Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139,
November 2021, <https://www.rfc-editor.org/info/rfc9139>.
The test vectors in Table 1 show sample time codes and their corresponding time values according to the algorithm outlined in Section 4.
表1のテストベクトルは、セクション4で概説されているアルゴリズムに従って、サンプル時間コードと対応する時間値を示しています。
+===========+======================+
| Time Code | Time Value (seconds) |
+===========+======================+
| 0x00 | 0.0000000 |
+-----------+----------------------+
| 0x01 | 0.0078125 |
+-----------+----------------------+
| 0x04 | 0.0312500 |
+-----------+----------------------+
| 0x08 | 0.0625000 |
+-----------+----------------------+
| 0x15 | 0.2031250 |
+-----------+----------------------+
| 0x28 | 1.0000000 |
+-----------+----------------------+
| 0x30 | 2.0000000 |
+-----------+----------------------+
| 0xF8 | 67108864.0000000 |
+-----------+----------------------+
| 0xFF | 125829120.0000000 |
+-----------+----------------------+
Table 1: Test Vectors
表1：ベクトルをテストします
A forwarder frequently converts compact time into milliseconds to compare Interest Lifetimes and the duration of cache entries. On many architectures, multiplication and division perform slower than addition, subtraction, and bit shifts. The following equations approximate the formulas in Section 4, and scale from seconds into the milliseconds range by applying a factor of 2^10 instead of 10^3. This results in an error of 2.4%.
フォワーダーは、コンパクト時間をミリ秒に変換して、関心の寿命とキャッシュエントリの期間を比較することがよくあります。多くのアーキテクチャでは、乗算と分割は、加算、減算、ビットシフトよりも遅いパフォーマンスを発揮します。次の方程式は、セクション4の式を概算し、10^3ではなく2^10の係数を適用することにより、数秒からミリ秒の範囲に拡大します。これにより、2.4％のエラーが発生します。
b == 0:
b == 0：
2^10 * a * 2^-3 * 2^1 * 2^-5 = a << 3
2^10 * a * 2^-3 * 2^1 * 2^-5 = a << 3
b > 0:
b> 0：
(2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5 = (1 << 5 + a << 2) << b
（2^10 a * 2^-3 * 2^10） * 2^b * 2^-5 =（1 << 5 a << 2）<< b
We would like to thank the active members of ICNRG for their constructive thoughts. In particular, we thank Marc Mosko and Ken Calvert for their valuable feedback on the encoding scheme and protocol integration. Special thanks also go to Carsten Bormann for his constructive in-depth comments during the IRSG review.
ICNRGのアクティブなメンバーの建設的な考えに感謝したいと思います。特に、エンコードスキームとプロトコル統合に関する貴重なフィードバックについて、Marc MoskoとKen Calvertに感謝します。また、IRSGレビュー中に建設的な詳細なコメントをしてくれたCarsten Bormannにも感謝します。
Cenk Gündoğan
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
D-80992 Munich
Germany
Email: cenk.gundogan@huawei.com
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
D-20099 Hamburg
Germany
Email: t.schmidt@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/schmidt
Dave Oran
Network Systems Research and Design
4 Shady Hill Square
Cambridge, MA 02138
United States of America
Email: daveoran@orandom.net
Matthias Wählisch
TUD Dresden University of Technology
Helmholtzstr. 10
D-01069 Dresden
Germany
Email: m.waehlisch@tu-dresden.de