[要約] RFC 9139は、情報中心ネットワーキング（ICN）を低消費電力無線パーソナルエリアネットワーク（LoWPANs）に適応させる方法について記述しています。この文書の目的は、ICNの利点をリソースが限られたネットワーク環境にもたらすことにあります。利用場面としては、スマートホーム、ウェアラブルデバイス、その他のIoT環境が挙げられます。
Internet Research Task Force (IRTF) C. Gündoğan
Request for Comments: 9139 T. Schmidt
Category: Experimental HAW Hamburg
ISSN: 2070-1721 M. Wählisch
link-lab & FU Berlin
C. Scherb
FHNW
C. Marxer
C. Tschudin
University of Basel
November 2021
Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)
低電力無線パーソナルエリアネットワークへの情報中心ネットワーキング（ICN）適応（LONPAN）
Abstract
概要
This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.
このドキュメントは、IEEE 802.15.4の低電力無線パーソナルエリアネットワーク（LOWPANS）上のコンテンツ中心のネットワーキング（CCNX）および名前付きデータネットワーキング（NDN）の収束層を定義しています。新しいフレームフォーマットは、CCNXおよびNDNパケットをIEEE 802.15.4の小さなMTUサイズに適応させるために指定されます。そのためには、TLVベースのヘッダーフォーマットへの構文と意味的な変更が説明されています。無線媒体に共存する可能性がある他のLowPanテクノロジとの互換性をサポートするために、LowPan（6lowpan）を介してIPv6によって提供されるディスパッチング方式は、CCNXおよびNDNのための新しいディスパッチタイプを含むように拡張されます。さらに、6LOWPANディスパッチングフレームワークのフラグメンテーションコンポーネントは、情報中心のネットワーク（ICN）チャンクに適用されます。その2番目の部分では、文書はステートレスおよびステートフル圧縮方式を定義し、制約付きリンクの効率を向上させます。ステートレス圧縮は、一般的な使用例のためにTLV式を静的ヘッダフィールドに縮小します。ステートフル圧縮方式は、ローパンにローカルをローカルに除外し、データパケット内の名前を短いローカル識別子で置き換えます。
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
この文書はIRTF情報中心のネットワーキング研究グループ（ICNRG）の製品です。
Status of This Memo
本文書の位置付け
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/rfc9139.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9139で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Overview of ICN LoWPAN
3.1. Link-Layer Convergence
3.2. Stateless Header Compression
3.3. Stateful Header Compression
4. IEEE 802.15.4 Adaptation
4.1. LoWPAN Encapsulation
4.1.1. Dispatch Extensions
4.2. Adaptation-Layer Fragmentation
5. Space-Efficient Message Encoding for NDN
5.1. TLV Encoding
5.2. Name TLV Compression
5.3. Interest Messages
5.3.1. Uncompressed Interest Messages
5.3.2. Compressed Interest Messages
5.3.3. Dispatch Extension
5.4. Data Messages
5.4.1. Uncompressed Data Messages
5.4.2. Compressed Data Messages
5.4.3. Dispatch Extension
6. Space-Efficient Message Encoding for CCNx
6.1. TLV Encoding
6.2. Name TLV Compression
6.3. Interest Messages
6.3.1. Uncompressed Interest Messages
6.3.2. Compressed Interest Messages
6.3.3. Dispatch Extension
6.4. Content Objects
6.4.1. Uncompressed Content Objects
6.4.2. Compressed Content Objects
6.4.3. Dispatch Extension
7. Compressed Time Encoding
8. Stateful Header Compression
8.1. LoWPAN-Local State
8.2. En Route State
8.3. Integrating Stateful Header Compression
9. ICN LoWPAN Constants and Variables
10. Implementation Report and Guidance
10.1. Preferred Configuration
10.2. Further Experimental Deployments
11. Security Considerations
12. IANA Considerations
12.1. Updates to the 6LoWPAN Dispatch Type Field Registry
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Estimated Size Reduction
A.1. NDN
A.1.1. Interest
A.1.2. Data
A.2. CCNx
A.2.1. Interest
A.2.2. Content Object
Acknowledgments
Authors' Addresses
The Internet of Things (IoT) has been identified as a promising deployment area for Information-Centric Networking (ICN), as infrastructureless access to content, resilient forwarding, and in-network data replication demonstrates notable advantages over the Internet host-to-host approach [NDN-EXP1] [NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate mapping to link-layer technologies has a large impact on the practical performance of an ICN. This will be even more relevant in the context of IoT communication where nodes often exchange messages via low-power wireless links under lossy conditions. In this memo, we address the base adaptation of data chunks to such link layers for the ICN flavors NDN [NDN] and CCNx [RFC8569] [RFC8609].
インターネットのインターネット（IoT）は、インターキュリコルのないコンテンツへのアクセス、弾力性のない転送、およびネットワーク内のデータ複製がインターネットホストからホストへの注目に値する利点を示しているため、情報中心のネットワーキング（ICN）の有望な展開領域として識別されています。アプローチ[NDN-EXP1] [NDN-EXP2]。最近の研究[NDN-MAC]は、リンク層技術への適切なマッピングがICNの実用的性能に大きな影響を与えることを示した。これは、ノードが損失のある状態で低電力無線リンクを介してメッセージを交換することが多いIoT通信のコンテキストでさらに関連性があります。このメモでは、ICNフレーバーNDN [NDN]とCCNX [RFC8569] [RFC8609]のリンク層へのデータチャンクの基本適応に対処します。
The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and lossy networks (see LLN in [RFC7228]), in which devices are typically battery operated and constrained in resources. Characteristics of LLNs include an unreliable environment, low-bandwidth transmissions, and increased latencies. IEEE 802.15.4 admits a maximum physical-layer packet size of 127 bytes. The maximum frame header size is 25 bytes, which leaves 102 bytes for the payload. IEEE 802.15.4 security features further reduce this payload length by up to 21 bytes, yielding a net of 81 bytes for CCNx or NDN packet headers, signatures, and content.
IEEE 802.15.4 [IEEE802.15.4]リンク層は、低電力および非損失のネットワークで使用されます（[RFC7228]のLLN参照）、そのデバイスは通常バッテリーで動作し、リソース内で制約されています。LLNの特性には、信頼できない環境、低帯域幅の送信、および待ち時間の向上が含まれます。IEEE 802.15.4は、127バイトの最大物理層パケットサイズを認めます。最大フレームヘッダーのサイズは25バイトです。ペイロードには102バイトが残ります。IEEE 802.15.4セキュリティ機能は、このペイロード長を最大21バイト削減し、CCNXまたはNDNパケットヘッダー、シグネチャ、およびコンテンツに81バイトのネットを生成します。
6LoWPAN [RFC4944] [RFC6282] is a convergence layer that provides frame formats, header compression, and adaptation-layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces a dispatching framework that prepends further information to 6LoWPAN packets, including a protocol identifier for payload and meta information about fragmentation.
6lowpan [RFC4944] [RFC6282]は、IEEE 802.15.4ネットワーク内のIPv6パケットのフレームフォーマット、ヘッダー圧縮、および適応層のフラグメンテーションを提供するコンバージェンス層です。6LOWPAN適応は、ペイロードのプロトコル識別子および断片化に関するメタ情報を含む、さらなる情報を6LOWPANパケットに追加するディスパッチフレームワークを導入する。
Prevalent packet formats based on Type-Length-Value (TLV), such as in CCNx and NDN, are designed to be generic and extensible. This leads to header verbosity, which is inappropriate in constrained environments of IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses packet headers of CCNx, as well as NDN, and allows for an increased effective payload size per packet. Additionally, reusing the dispatching framework defined by 6LoWPAN enables compatibility between coexisting wireless deployments of competing network technologies. This also allows reuse of the adaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoWPAN.
CCNXおよびNDNなどのType-Length-Value（TLV）に基づく一般的なパケットフォーマットは、一般的で拡張可能になるように設計されています。これはヘッダーの冗長性をもたらします。これは、IEEE 802.15.4リンクの制約付き環境では不適切です。この文書はICN LowPan、6lowpanによって動機付けられたIEEE 802.15.4の収束層である。ICN LowPanは、NDNと同様にCCNXのパケットヘッダを圧縮し、パケットごとに有効なペイロードサイズの拡大を可能にします。さらに、6LOWPANによって定義されたディスパッチングフレームワークを再利用することで、競合するネットワーク技術の共存する無線展開間の互換性を実現します。これにより、ICN Lowpan for ICN Lowpanによって指定された適応層の断片化方式を再利用することもできます。
ICN LoWPAN defines a more space-efficient representation of CCNx and NDN packet formats. This syntactic change is described for CCNx and NDN separately, as the header formats and TLV encodings differ notably. For further reductions, default header values suitable for constrained IoT networks are selected in order to elide corresponding TLVs. Experimental evaluations of the ICN LoWPAN header compression schemes in [ICNLOWPAN] illustrate a reduced message overhead, a shortened message airtime, and an overall decline in power consumption for typical Class 2 devices [RFC7228] compared to uncompressed ICN messages.
ICN LowPanは、CCNXおよびNDNパケットフォーマットのより多くのスペース効率の高い表現を定義します。この構文変化は、ヘッダフォーマットとTLVの符号化が特に異なるため、CCNXおよびNDNについて説明されている。さらなる削減のために、対応するTLVを除外するために、制約付きIoTネットワークに適したデフォルトのヘッダ値が選択される。[ICNLOWPAN]内のICN LowPanヘッダ圧縮方式の実験的評価は、圧縮されていないICNメッセージと比較して、典型的なクラス2デバイス[RFC7228]のための短縮されたメッセージ放送時間、短縮されたメッセージ放送時間、および全体的な減少を示しています。
In a typical IoT scenario (see Figure 1), embedded devices are interconnected via a quasi-stationary infrastructure using a border router (BR) that connects the constrained LoWPAN network by some gateway with the public Internet. In ICN-based IoT networks, nonlocal Interest and Data messages transparently travel through the BR up and down between a gateway and the embedded devices situated in the constrained LoWPAN.
典型的なIoTシナリオ（図1参照）では、組み込みデバイスは、パブリックインターネットとのいくつかのゲートウェイによって制約されたローパンネットワークを接続するボーダールータ（BR）を使用して、準定常インフラストラクチャを介して相互接続されています。ICNベースのIOTネットワークでは、非局所的な関心とデータメッセージは、ゲートウェイと拘束されたローパンにある組み込み機器との間のBR上下を透過的に移動します。
|Gateway Services|
-------------------------
|
,--------,
| |
| BR |
| |
'--------'
LoWPAN
O O
O
O O embedded
O O O devices
O O
Figure 1: IoT Stub Network
図1：IOTスタブネットワーク
The document has received fruitful reviews by members of the ICN community and the research group (see the Acknowledgments section) for a period of two years. 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.
この文書は、ICNコミュニティのメンバーと研究グループ（謝辞セクションを参照）で2年間実装済みのレビューを受けています。ICNRGの合意は、この文書をRFCシリーズのIRTFストリームに公開する必要があります。この文書は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 [RFC7476], [RFC7927], and [RFC7945] for ICN entities.
この文書では、ICNエンティティの[RFC7476]、[RFC7927]、[RFC7945]の用語を使用しています。
The following terms are used in the document and defined as follows:
以下の用語は文書で使用され、次のように定義されています。
ICN LoWPAN: Information-Centric Networking over Low-Power Wireless Personal Area Network
ICNローパン：低電力無線パーソナルエリアネットワーク上の情報中心ネットワーキング
LLN: Low-Power and Lossy Network
LLN：低消費電力ネットワーク
CCNx: Content-Centric Networking
CCNX：コンテンツ中心のネットワーキング
NDN: Named Data Networking
NDN：名前付きデータネットワーキング
byte: synonym for octet
バイト：オクテットの同義語
nibble: synonym for 4 bits
ニブル：4ビットの同義語
time-value: a time offset measured in seconds
時間値：秒単位で測定された時間オフセット
time-code: an 8-bit encoded time-value
時間コード：8ビット符号化時間値
ICN LoWPAN provides a convergence layer that maps ICN packets onto constrained link-layer technologies. This includes features such as link-layer fragmentation, protocol separation on the link-layer level, and link-layer address mappings. The stack traversal is visualized in Figure 2.
ICN LowPanは、ICNパケットを制約付きリンクレイヤテクノロジにマッピングするコンバージェンス層を提供します。これには、リンク層の断片化、リンク層レベルのプロトコル分離、リンク層アドレスマッピングなどの機能が含まれます。スタックトラバーサルは図2で視覚化されています。
Device 1 Device 2
,------------------, Router ,------------------,
| Application . | __________________ | ,-> Application |
|----------------|-| | NDN / CCNx | |-|----------------|
| NDN / CCNx | | | ,--------------, | | | NDN / CCNx |
|----------------|-| |-|--------------|-| |-|----------------|
| ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN |
|----------------|-| |-|--------------|-| |-|----------------|
| Link Layer | | | | Link Layer | | | | Link Layer |
'----------------|-' '-|--------------|-' '-|----------------'
'--------' '---------'
Figure 2: ICN LoWPAN Convergence Layer for IEEE 802.15.4
図2：IEEE 802.15.4のためのICNローパン収束層
Section 4 of this document defines the convergence layer for IEEE 802.15.4.
このドキュメントのセクション4は、IEEE 802.15.4のコンバージェンスレイヤを定義しています。
ICN LoWPAN also defines a stateless header compression scheme with the main purpose of reducing header overhead of ICN packets. This is of particular importance for link layers with small MTUs. The stateless compression does not require preconfiguration of a global state.
ICN LowPanはまた、ICNパケットのヘッダオーバーヘッドを減らすという主な目的を持つステートレスヘッダー圧縮方式を定義します。これは、小さいMTUSを有するリンク層にとって特に重要である。ステートレス圧縮は、グローバル状態の先入観を必要としません。
The CCNx and NDN header formats are composed of Type-Length-Value (TLV) fields to encode header data. The advantage of the TLV format is its support of variably structured data. The main disadvantage of the TLV format is the verbosity that results from storing the type and length of the encoded data.
CCNXおよびNDNヘッダーフォーマットは、ヘッダーデータをエンコードするためのtype-length-value（TLV）フィールドで構成されています。TLVフォーマットの利点は、その可変構造化データのサポートです。TLV形式の主な欠点は、符号化データの種類と長さを記憶することから生じる冗長性である。
The stateless header compression scheme makes use of compact bit fields to indicate the presence of optional TLVs in the uncompressed packet. The order of set bits in the bit fields corresponds to the order of each TLV in the packet. Further compression is achieved by specifying default values and reducing the range of certain header fields.
ステートレスヘッダー圧縮方式は、圧縮されていないパケット内のオプションのTLVの存在を示すためにコンパクトなビットフィールドを使用します。ビットフィールド内の設定ビットの順序は、パケット内の各TLVの順序に対応します。デフォルト値を指定し、特定のヘッダーフィールドの範囲を短縮することによって、さらなる圧縮が実現されます。
Figure 3 demonstrates the stateless header compression idea. In this example, the first type of the first TLV is removed and the corresponding bit in the bit field is set. The second TLV represents a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the Type and Length fields are removed. The third TLV represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for which the Type, Length, and Value fields are elided.
図3は、ステートレスヘッダ圧縮のアイデアを示しています。この例では、最初のTLVの最初のタイプが削除され、ビットフィールドの対応するビットが設定されます。第2のTLVは、固定長TLV（例えば、NDN内のNDN）を表し、その結果、タイプおよび長さフィールドは削除される。3番目のTLVは、タイプ、長さ、および値のフィールドが照らされているブール値TLV（NDN内の必須セレクタ）を表します。
Uncompressed:
非圧縮：
Variable-length TLV Fixed-length TLV Boolean TLV
,-----------------------,-----------------------,-------------,
+-------+-------+-------+-------+-------+-------+------+------+
| TYP | LEN | VAL | TYP | LEN | VAL | TYP | LEN |
+-------+-------+-------+-------+-------+-------+------+------+
Compressed:
圧縮：
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit Field
+---+---+---+---+---+---+---+---+
| | |
,--' '----, '- Boolean Value
| |
+-------+-------+-------+
| LEN | VAL | VAL |
+-------+-------+-------+
'---------------'-------'
Var-len Value Fixed-len Value
Figure 3: Compression Using a Compact Bit Field -- Bits Encode the Inclusion of TLVs
図3：コンパクトビットフィールドを使用した圧縮 - TLVを含めることを符号化します
Stateless TLV compression for NDN is defined in Section 5. Section 6 defines the stateless TLV compression for CCNx.
NDNのステートレスTLV圧縮はセクション5で定義されています。セクション6は、CCNXのステートレスTLV圧縮を定義します。
The extensibility of this compression is described in Section 4.1.1 and allows future documents to update the compression rules outlined in this document.
この圧縮の拡張性はセクション4.1.1で説明されており、将来の文書をこのドキュメントで概説されている圧縮規則を更新できます。
ICN LoWPAN further employs two orthogonal, stateful compression schemes for packet size reductions, which are defined in Section 8. These mechanisms rely on shared contexts that are either distributed and maintained in the entire LoWPAN or are generated on demand hop-wise on a particular Interest-Data path.
ICN Lowpanはさらに、セクション8で定義されているパケットサイズの削減のための2つの直交状態のステートフル圧縮方式を採用しています。これらのメカニズムは、ローパン全体で配布および維持されている共有コンテキストに依存しています。-データ経路。
The shared context identification is defined in Section 8.1. The hop-wise name compression "en route" is specified in Section 8.2.
共有コンテキスト識別はセクション8.1で定義されています。8.2節では、ホップワイズ名の圧縮「en route」が指定されています。
The IEEE 802.15.4 frame header does not provide a protocol identifier for its payload. This causes problems of misinterpreting frames when several network layers coexist on the same link. To mitigate errors, 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation headers can precede the actual payload, and each encapsulation header is identified by a dispatch type.
IEEE 802.15.4フレームヘッダーは、ペイロードのプロトコル識別子を提供しません。これにより、複数のネットワーク層が同じリンクに共存するときに、フレームの誤解除の問題が発生します。エラーを軽減するために、6LOWPANはIEEE 802.15.4フレームのカプセル化ヘッダーとしてディスパッチを定義します（[RFC4944]のセクション5を参照）。複数のLowPanカプセル化ヘッダーが実際のペイロードの前にあり、各カプセル化ヘッダーはディスパッチタイプによって識別されます。
[RFC8025] further specifies dispatch Pages to switch between different contexts. When a LoWPAN parser encounters a Page switch LoWPAN encapsulation header, all following encapsulation headers are interpreted by using a dispatch Page, as specified by the Page switch header. Pages 0 and 1 are reserved for 6LoWPAN. This document uses Page 14 (1111 1110 (0xFE)) for ICN LoWPAN.
[RFC8025]さらに、異なるコンテキストを切り替えるためのディスパッチページを指定します。ローパンパーサーがページスイッチのローパンカプセル化ヘッダーに遭遇すると、ページスイッチヘッダーで指定されているように、次のすべてのカプセル化ヘッダーがディスパッチ]ページを使用して解釈されます。Pages 0と1は6lowpan用に予約されています。この文書では、ICN Lowpan用のページ14（1111 1110（0xFe））を使用しています。
The base dispatch format (Figure 4) is used and extended by CCNx and NDN in Sections 5 and 6.
BASE Dispatchフォーマット（図4）は、セクション5および6のCCNXおよびNDNによって使用されて拡張されます。
0 1 2 3 ...
+---+---+---+---+---
| 0 | P | M | C |
+---+---+---+---+---
Figure 4: Base Dispatch Format for ICN LoWPAN
図4：ICNローパンのベースディスパッチフォーマット
P: Protocol 0: The included protocol is NDN.
P：プロトコル0：含まれているプロトコルはNDNです。
1: The included protocol is CCNx.
1：含まれているプロトコルはCCNXです。
M: Message Type 0: The payload contains an Interest message.
M：メッセージタイプ0：ペイロードには利子メッセージが含まれています。
1: The payload contains a Data message.
1：ペイロードにデータメッセージが含まれています。
C: Compression 0: The message is uncompressed.
C：圧縮0：メッセージは圧縮されません。
1: The message is compressed.
1：メッセージは圧縮されています。
ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the extended dispatch format in Figure 5.
圧縮CCNXおよびNDNメッセージを含むICNローパンフレーム（C = 1）図5の拡張ディスパッチフォーマットを使用します。
0 1 2 3 ... ...
+---+---+---+---+...+---+---+
| 0 | P | M | 1 | |CID|EXT|
+---+---+---+---+...+---+---+
Figure 5: Extended Dispatch Format for Compressed ICN LoWPAN
図5：圧縮ICNローパンの拡張ディスパッチフォーマット
CID: Context Identifier 0: No context identifiers are present.
CID：コンテキスト識別子0：コンテキスト識別子はありません。
1: Context identifier(s) are present (see Section 8.1).
1：コンテキスト識別子が存在する（セクション8.1参照）。
EXT: Extension 0: No extension bytes are present.
ext：拡張子0：拡張バイトがありません。
1: Extension byte(s) are present (see Section 4.1.1).
1：拡張バイトが存在します（セクション4.1.1参照）。
The encapsulation format for ICN LoWPAN is displayed in Figure 6.
ICN LowPanのカプセル化フォーマットは図6に表示されます。
+------...------+------...-----+--------+-------...-------+-----...
| IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. /
+------...------+------...-----+--------+-------...-------+-----...
Figure 6: LoWPAN Encapsulation with ICN LoWPAN
図6：ICN Lowpanによるローパンカプセル化
IEEE 802.15.4: The IEEE 802.15.4 header.
IEEE 802.15.4：IEEE 802.15.4ヘッダー。
RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 of [RFC4944].
RFC4944 DISP：[RFC4944]のセクション5.1で定義されているオプションの追加送出。
Page: Page switch. 14 for ICN LoWPAN.
ページ：ページスイッチ。ICNローパンの14。
ICN LoWPAN: Dispatches as defined in Sections 5 and 6.
ICN LowPan：セクション5および6で定義されているようなディスパッチ。
Payload: The actual (un-)compressed CCNx or NDN message.
ペイロード：実際の（UN-）圧縮CCNXまたはNDNメッセージ。
Extension bytes allow for the extensibility of the initial compression rule set. The base format for an extension byte is depicted in Figure 7.
拡張バイトは、初期圧縮ルールセットの拡張性を可能にします。拡張バイトの基本フォーマットは図7に示されています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| - | - | - | - | - | - | - |EXT|
+---+---+---+---+---+---+---+---+
Figure 7: Base Format for Dispatch Extensions
図7：ディスパッチ拡張機能の基本フォーマット
EXT: Extension 0: No other extension byte follows.
ext：拡張子0：他の拡張バイトは続行されません。
1: A further extension byte follows.
1：さらなる延長バイトが続きます。
Extension bytes are numbered according to their order. Future documents MUST follow the naming scheme EXT_0, EXT_1, ... when updating or referring to a specific dispatch extension byte. Amendments that require an exchange of configurational parameters between devices SHOULD use manifests to encode structured data in a well-defined format, e.g., as outlined in [ICNRG-FLIC].
拡張バイト数は、その順序に従って番号付けされています。特定のディスパッチ拡張バイトを更新または参照する場合、将来の文書は命名方式のext_0、ext_1、...に従う必要があります。デバイス間で構成パラメータの交換を必要とする修正は、[ICNRG-FLIC]で概説されているように、構造化データを明確に定義されたフォーマットでエンコードするためにマニフェストを使用する必要があります。
Small payload sizes in the LoWPAN require fragmentation for various network layers. Therefore, Section 5.3 of [RFC4944] defines a protocol-independent fragmentation dispatch type, a fragmentation header for the first fragment, and a separate fragmentation header for subsequent fragments. ICN LoWPAN adopts this fragmentation handling of [RFC4944].
LowPanの小さいペイロードサイズは、さまざまなネットワーク層のための断片化を必要とします。したがって、[RFC4944]のセクション5.3は、プロトコルに依存しないフラグメンテーションディスパッチタイプ、最初のフラグメント用のフラグメンテーションヘッダー、およびその後のフラグメントのための別々のフラグメンテーションヘッダーを定義します。ICN Lowpanは[RFC4944]のこの断片化処理を採用しています。
The fragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is defined in Section 5 of [RFC4944]. Figure 8 shows the fragmentation scheme. The reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in Figure 9.
フラグメンテーションローパンヘッダーは他のディスパッチヘッダーをカプセル化できます。ディスパッチタイプの順序は[RFC4944]のセクション5で定義されています。図8は断片化方式を示す。再組み立てされたICN LowPanフレームには、断片化ヘッダーが含まれず、図9に示されています。
+------...------+----...----+--------+------...-------+--------...
| IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload /
+------...------+----...----+--------+------...-------+--------...
+------...------+----...----+--------...
| IEEE 802.15.4 | Frag. 2nd | Payload /
+------...------+----...----+--------...
. . .
。。。
+------...------+----...----+--------...
| IEEE 802.15.4 | Frag. Nth | Payload /
+------...------+----...----+--------...
Figure 8: Fragmentation Scheme
図8：断片化方式
+------...------+--------+------...-------+--------...
| IEEE 802.15.4 | Page | ICN LoWPAN | Payload /
+------...------+--------+------...-------+--------...
Figure 9: Reassembled ICN LoWPAN Frame
図9：ICN Lowpan Frameを再組み立てしました
The 6LoWPAN Fragment Forwarding (6LFF) [RFC8930] is an alternative approach that enables forwarding of fragments without reassembling packets on every intermediate hop. By reusing the 6LoWPAN dispatching framework, 6LFF integrates into ICN LoWPAN as seamlessly as the conventional hop-wise fragmentation. However, experimental evaluations [SFR-ICNLOWPAN] suggest that a more-refined integration can increase the cache utilization of forwarders on a request path.
6lowpanフラグメント転送（6LFF）[RFC8930]は、すべての中間ホップ上でパケットを組み立てることなくフラグメントの転送を可能にする代替アプローチです。6LOWPANディスパッチングフレームワークを再利用することによって、6LFFは従来のホップスフラグメーションとしてシームレスにICNローパンに統合する。しかしながら、実験的評価[SFR - ICNLOWPAN]は、より洗練された統合が要求経路上のフォワーダのキャッシュ利用を増大させる可能性があることを示唆している。
The NDN packet format consists of TLV fields using the TLV encoding that is described in [NDN-PACKET-SPEC]. Type and Length fields are of variable size, where numbers greater than 252 are encoded using multiple bytes.
NDNパケットフォーマットは、[NDN-Packet-Spec]で説明されているTLVエンコーディングを使用したTLVフィールドで構成されています。タイプフィールドとLengthフィールドは可変サイズです。ここで、252を超える数字は複数のバイトを使用してエンコードされます。
If the type or length number is less than 253, then that number is encoded into the actual Type or Length field. If the number is greater or equals 253 and fits into 2 bytes, then the Type or Length field is set to 253 and the number is encoded in the next following 2 bytes in network byte order, i.e., from the most significant byte (MSB) to the least significant byte (LSB). If the number is greater than 2 bytes and fits into 4 bytes, then the Type or Length field is set to 254 and the number is encoded in the subsequent 4 bytes in network byte order. For larger numbers, the Type or Length field is set to 255 and the number is encoded in the subsequent 8 bytes in network byte order.
タイプまたは長さの数が253未満の場合、その数は実際のタイプまたは長さフィールドにエンコードされます。数値が253より大きい場合、および2バイトに適合すると、タイプまたは長さフィールドは253に設定され、数はネットワークバイト順で、すなわち最上位バイト（MSB）から次の2バイトに次の2バイトにエンコードされます。最下位バイト（LSB）に。数値が2バイトより大きい場合は4バイトにフィットしても、[タイプ]フィールドまたは[Length]フィールドは254に設定され、その数はネットワークバイト順に次の4バイトにエンコードされます。より大きな数の場合、[タイプ]フィールドまたは[Length]フィールドは255に設定され、番号はネットワークバイト順に次の8バイトにエンコードされます。
In this specification, compressed NDN TLVs encode Type and Length fields using self-delimiting numeric values (SDNVs) [RFC6256] commonly known from Delay-Tolerant Networking (DTN) protocols. Instead of using the first byte as a marker for the number of following bytes, SDNVs use a single bit to indicate subsequent bytes.
本明細書では、圧縮されたNDN TLVSは、遅延耐性ネットワーキング（DTN）プロトコルから一般的に知られている自己区切り数値（SDNVS）[RFC6256]を使用してタイプと長さのフィールドをエンコードします。最初のバイトをマーカーとして使用する代わりに、次のバイト数のマーカーとして、SDNVSは1ビットを使用して後続のバイトを示します。
+==========+==========================+==========================+
| Value | NDN TLV Encoding | SDNV Encoding |
+==========+==========================+==========================+
| 0 | 0x00 | 0x00 |
+----------+--------------------------+--------------------------+
| 127 | 0x7F | 0x7F |
+----------+--------------------------+--------------------------+
| 128 | 0x80 | 0x81 0x00 |
+----------+--------------------------+--------------------------+
| 253 | 0xFD 0x00 0xFD | 0x81 0x7D |
+----------+--------------------------+--------------------------+
| 2^14 - 1 | 0xFD 0x3F 0xFF | 0xFF 0x7F |
+----------+--------------------------+--------------------------+
| 2^14 | 0xFD 0x40 0x00 | 0x81 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^16 | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^21 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F |
+----------+--------------------------+--------------------------+
| 2^21 | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^28 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F |
+----------+--------------------------+--------------------------+
| 2^28 | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^32 | 0xFF 0x00 0x00 0x00 0x01 | 0x90 0x80 0x80 0x80 0x00 |
| | 0x00 0x00 0x00 0x00 | |
+----------+--------------------------+--------------------------+
| 2^35 - 1 | 0xFF 0x00 0x00 0x00 0x07 | 0xFF 0xFF 0xFF 0xFF 0x7F |
| | 0xFF 0xFF 0xFF 0xFF | |
+----------+--------------------------+--------------------------+
| 2^35 | 0xFF 0x00 0x00 0x00 0x08 | 0x81 0x80 0x80 0x80 0x80 |
| | 0x00 0x00 0x00 0x00 | 0x00 |
+----------+--------------------------+--------------------------+
Table 1: NDN TLV Encoding Compared to SDNVs
表1：SDNVSと比較したNDN TLV符号化
Table 1 compares the required bytes for encoding a few selected values using the NDN TLV encoding and SDNVs. For values up to 127, both methods require a single byte. Values in the range (128...252) encode as one byte for the NDN TLV scheme, while SDNVs require two bytes. Starting at value 253, SDNVs require a less or equal amount of bytes compared to the NDN TLV encoding.
表1は、NDN TLVエンコーディングとSDNVSを使用して、選択した数の値を符号化するための要求バイトを比較します。最大127の値の場合、両方のメソッドには1バイトが必要です。範囲（128 ... 252）の値は、NDN TLV方式の1バイトとしてエンコードし、SDNVSは2バイトを必要とします。値253から、SDNVSはNDN TLV符号化と比較して少ないまたは等しいバイトを必要とする。
This Name TLV compression encodes Length fields of two consecutive NameComponent TLVs into one byte, using a nibble for each. The most significant nibble indicates the length of an immediately following NameComponent TLV. The least significant nibble denotes the length of a subsequent NameComponent TLV. A length of 0 marks the end of the compressed Name TLV. The last Length field of an encoded NameComponent is either 0x00 for a name with an even number of components and 0xYF (Y > 0) if an odd number of components are present. This process limits the length of a NameComponent TLV to 15 bytes but allows for an unlimited number of components. An example for this encoding is presented in Figure 10.
この名前のTLV圧縮は、2つの連続したNameComponent TLVSの長さフィールドを1バイネルに1バイトにエンコードします。最も重要なニブルは、NameComponent TLVの直後の長さを示します。最下位ニブルは、次のNameComponent TLVの長さを表します。0の長さが圧縮名TLVの終わりをマークします。符号化されたNameComponentの最後のフィールドは、奇数個のコンポーネントが存在する場合、偶数のコンポーネントと0xyf（y> 0）の名前の0x00です。このプロセスでは、NameComponent TLVの長さを15バイトに制限しますが、無制限の数のコンポーネントを可能にします。この符号化の例を図10に示します。
Name: /HAW/Room/481/Humid/99
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1|0 1 0 0| H | A | W |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R | o | o | m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1|0 1 0 1| 4 | 8 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H | u | m | i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d |0 0 1 0|0 0 0 0| 9 | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Name TLV Compression for /HAW/Room/481/Humid/99
An uncompressed Interest message uses the base dispatch format (see Figure 4) and sets the C, P, and M flags to 0 (Figure 11). The Interest message is handed to the NDN stack without modifications.
圧縮されていない関心メッセージは、基本ディスパッチフォーマットを使用しており（図4を参照）、C、P、およびMのフラグを0に設定します（図11）。関心のあるメッセージは変更なしでNDNスタックに手渡されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
Figure 11: Dispatch Format for Uncompressed NDN Interest Messages
図11：非圧縮NDN興味メッセージのディスパッチフォーマット
The compressed Interest message uses the extended dispatch format (Figure 5) and sets the C flag to 1 and the P and M flags to 0. If an Interest message contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed.
圧縮関心メッセージは拡張ディスパッチフォーマット（図5）を使用し、Cフラグを1とpフラグとMのフラグを0に設定します。関心事メッセージには、次の圧縮規則に記載されていないTLVが含まれている場合は、次のメッセージが必要です。非圧縮を送った。
This specification assumes that a HopLimit TLV is part of the original Interest message. If such a HopLimit TLV is not present, it will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to the compression.
本明細書は、HopLimit TLVが元の利子メッセージの一部であると仮定しています。そのようなHOPLimit TLVが存在しない場合、圧縮の前にデフォルト値のデフォルト値のデフォルト値で挿入されます。
In the default use case, the Interest message is compressed with the following minimal rule set:
デフォルトのユースケースでは、興味メッセージは次の最小限のルールセットで圧縮されます。
1. The Type field of the outermost MessageType TLV is removed.
1. 最外部のMessageType TLVの型フィールドは削除されます。
2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are expected to be of type GenericNameComponent with a length greater than 0. An ImplicitSha256DigestComponent or ParametersSha256DigestComponent MAY appear at the end of the name. In any other case, the message MUST be sent uncompressed.
2. TLVという名前はセクション5.2に従って圧縮されています。このために、すべてのNameComponentsは、0を超える長さを持つGenericNameComponentの型であると予想されます.InciCitSha256DigestComponentまたはParametersSha256DigestComponentが名前の末尾に表示されることがあります。その他の場合では、メッセージは非圧縮に送信されなければなりません。
3. The Nonce TLV and InterestLifetime TLV are moved to the end of the compressed Interest, as illustrated in Figure 12. The InterestLifetime is encoded as described in Section 7. On decompression, this encoding may yield an InterestLifetime that is smaller than the original value.
3. 図12に示すように、NONCE TLVおよびInterLifetime TLVは圧縮関心の終わりに移動される.ITEXITLIFETIMEは、セクション7で説明されているように符号化されている。減圧時には、この符号化は元の値よりも小さいインテリアリフェートを生成することができる。
4. The Type and Length fields of Nonce TLV, HopLimit TLV, and InterestLifetime TLV are elided. The Nonce value has a length of 4 bytes, and the HopLimit value has a length of 1 byte. The compressed InterestLifetime (Section 7) has a length of 1 byte. The presence of a Nonce TLV and InterestLifetime TLV is deduced from the remaining length to parse. A remaining length of 1 indicates the presence of an InterestLifetime, a length of 4 indicates the presence of a nonce, and a length of 5 indicates the presence of both TLVs.
4. NONCE TLV、HOPLIMIT TLV、およびINTERTLIFETIME TLVのタイプと長さのフィールドが照られています。Nonce値は4バイトの長さを持ち、HOPLIMIT値は1バイトの長さを持ちます。圧縮されたInterialLifetime（セクション7）の長さは1バイトです。NONCE TLVの存在と便利なTLVの存在は、残りの長さから推定されます。1の残りの長さは、インテリアリフェートの存在を示し、4の長さ4は非CCEの存在を示し、そして5の長さは両方のTLVの存在を示す。
The compressed NDN LoWPAN Interest message is visualized in Figure 12.
圧縮されたNDNローパンの関心メッセージは図12で視覚化されています。
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field
+---------+---------+ +---------+
| Msg T | Msg L | | Msg Lc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | | Name Vc |
+---------+---------+---------+ +---------+---------+
: CBPfx T : CBPfx L : : FWDH Lc : FWDH Vc :
+---------+---------+ +---------+---------+
: MBFr T : MBFr L : | HPL V |
+---------+---------+---------+ ==> +---------+---------+
: FWDH T : FWDH L : FWDH V : : APM Lc : APM Vc :
+---------+---------+---------+ +---------+---------+
: NONCE T : NONCE L : NONCE V : : NONCE V :
+---------+---------+---------+ +---------+
: ILT T : ILT L : ILT V : : ILT Vc :
+---------+---------+---------+ +---------+
: HPL T : HPL L : HPL V :
+---------+---------+---------+
: APM T : APM L : APM V :
+---------+---------+---------+
Figure 12: Compression of NDN LoWPAN Interest Message
図12：NDNローパンの興味のメッセージの圧縮
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 13.
さらなるTLV圧縮は、図13のICNローパンディスパッチによって示される。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 |PFX|FRE|FWD|APM|DIG| RSV |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 13: Dispatch Format for Compressed NDN Interest Messages
図13：圧縮されたNDNの興味メッセージのディスパッチフォーマット
PFX: CanBePrefix TLV 0: The uncompressed message does not include a CanBePrefix TLV.
PFX：CANBEPREFIX TLV 0：非圧縮メッセージには、CANBEPREFIX TLVが含まれていません。
1: The uncompressed message does include a CanBePrefix TLV and is removed from the compressed message.
1：非圧縮メッセージにはCanBePrefix TLVが含まれており、圧縮されたメッセージから削除されます。
FRE: MustBeFresh TLV 0: The uncompressed message does not include a MustBeFresh TLV.
Fre：必需品TLV 0：非圧縮メッセージには必須のメッセージが含まれていません。
1: The uncompressed message does include a MustBeFresh TLV and is removed from the compressed message.
1：非圧縮メッセージには必須のメッセージが含まれており、圧縮されたメッセージから削除されます。
FWD: ForwardingHint TLV 0: The uncompressed message does not include a ForwardingHint TLV.
FWD：ForwardingHint TLV 0：非圧縮メッセージにはForwardingHint TLVが含まれていません。
1: The uncompressed message does include a ForwardingHint TLV. The Type field is removed from the compressed message. Further, all link delegation types and link preference types are removed. All included names are compressed according to Section 5.2. If any name is not compressible, the message MUST be sent uncompressed.
1：非圧縮メッセージにはForwardingHint TLVが含まれています。[タイプ]フィールドは圧縮されたメッセージから削除されます。さらに、すべてのリンク委任タイプとリンク嗜好タイプが削除されます。含まれている名前はすべてセクション5.2に従って圧縮されています。いずれかの名前が圧縮可能でない場合、メッセージは非圧縮に送信されなければなりません。
APM: ApplicationParameters TLV 0: The uncompressed message does not include an ApplicationParameters TLV.
APM：ApplicationParameters TLV 0：非圧縮メッセージには、ApplicationParameters TLVが含まれていません。
1: The uncompressed message does include an ApplicationParameters TLV. The Type field is removed from the compressed message.
1：非圧縮メッセージにはApplicationParameters TLVが含まれています。[タイプ]フィールドは圧縮されたメッセージから削除されます。
DIG: ImplicitSha256DigestComponent TLV 0: The name does not include an ImplicitSha256DigestComponent as the last TLV.
Dig：InstricitSha256DigestComponent TLV 0：名前には、InpricitSha256DigestComponentが最後のTLVとして含まれていません。
1: The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and Length fields are omitted.
1：名前には、InplicitSha256DigestComponentが最後のTLVとして含まれています。型と長さのフィールドは省略されています。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
CID: Context Identifier See Figure 5.
CID：コンテキスト識別子図5を参照してください。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: Extension byte EXT_0 follows immediately. See Section 5.3.3.
1：拡張子バイトEXT_0がすぐに続きます。セクション5.3.3を参照してください。
The EXT_0 byte follows the description in Section 4.1.1 and is illustrated in Figure 14.
EXT_0バイトは4.1.1の説明に従い、図14に示されています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+
Figure 14: EXT_0 Format
図14：ext_0形式
NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2).
NCS：名前圧縮戦略00：名称は、デフォルトの名前圧縮戦略で圧縮されています（セクション5.2を参照）。
01: Reserved.
01：予約済み。
10: Reserved.
10：予約済み。
11: Reserved.
11：予約済み。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: A further extension byte follows immediately.
1：さらに延長バイトがすぐに続く。
An uncompressed Data message uses the base dispatch format and sets the C and P flags to 0 and the M flag to 1 (Figure 15). The Data message is handed to the NDN stack without modifications.
非圧縮データメッセージは、ベースディスパッチフォーマットを使用し、CフラグとPフラグを0とMフラグを1に設定します（図15）。データメッセージは変更なしでNDNスタックに手渡されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
Figure 15: Dispatch Format for Uncompressed NDN Data Messages
図15：非圧縮NDNデータメッセージのディスパッチフォーマット
The compressed Data message uses the extended dispatch format (Figure 5) and sets the C and M flags to 1. The P flag is set to 0. If a Data message contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed.
圧縮データメッセージは拡張ディスパッチフォーマット（図5）を使用し、CフラグとMフラグを1に設定します.Pフラグは0に設定されます。データメッセージには、次の圧縮規則に記載されていないTLVが含まれている場合、このメッセージが表示されます。非圧縮を送信する必要があります。
By default, the Data message is compressed with the following base rule set:
デフォルトでは、データメッセージは次の基本ルールセットで圧縮されています。
1. The Type field of the outermost MessageType TLV is removed.
1. 最外部のMessageType TLVの型フィールドは削除されます。
2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are expected to be of type GenericNameComponent and to have a length greater than 0. In any other case, the message MUST be sent uncompressed.
2. TLVという名前はセクション5.2に従って圧縮されています。このために、すべてのNameComponentsはGenericNameComponent型であり、0を超える長さを持つことが期待されています。その他の場合、メッセージは圧縮されない送信されなければなりません。
3. The MetaInfo TLV Type and Length fields are elided from the compressed Data message.
3. MetainFO TLVタイプと長さのフィールドは、圧縮データメッセージから照らされます。
4. The FreshnessPeriod TLV MUST be moved to the end of the compressed Data message. Type and Length fields are elided, and the value is encoded as described in Section 7 as a 1-byte time-code. If the freshness period is not a valid time-value, then the message MUST be sent uncompressed in order to preserve the security envelope of the Data message. The presence of a FreshnessPeriod TLV is deduced from the remaining one-byte length to parse.
4. FreshnessPeriod TLVを圧縮データメッセージの最後に移動する必要があります。タイプフィールドと長さのフィールドが照らされ、値はセクション7に記載されているように1バイトのタイムコードとしてエンコードされます。鮮度期間が有効な時間値ではない場合、データメッセージのセキュリティエンベロープを保持するためにメッセージを圧縮しないで送信する必要があります。FreshnessPeriod TLVの存在は、残りの1バイトの長さから推定されて解析されます。
5. The Type fields of the SignatureInfo TLV, SignatureType TLV, and SignatureValue TLV are removed.
5. SignatureInfo TLV、SignatureType TLV、およびSignatureValue TLVの型フィールドは削除されます。
The compressed NDN LoWPAN Data message is visualized in Figure 16.
圧縮されたNDNローパンデータメッセージは図16で視覚化されています。
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field
+---------+---------+ +---------+
| Msg T | Msg L | | Msg Lc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | | Name Vc |
+---------+---------+---------+ +---------+---------+
: Meta T : Meta L : : CTyp Lc : CTyp V :
+---------+---------+---------+ +---------+---------+
: CTyp T : CTyp L : CTyp V : : FBID V :
+---------+---------+---------+ ==> +---------+---------+
: FrPr T : FrPr L : FrPr V : : CONT Lc : CONT V :
+---------+---------+---------+ +---------+---------+
: FBID T : FBID L : FBID V : | Sig Lc |
+---------+---------+---------+ +---------+---------+
: CONT T : CONT L : CONT V : | SInf Lc | SInf Vc |
+---------+---------+---------+ +---------+---------+
| Sig T | Sig L | | SVal Lc | SVal Vc |
+---------+---------+---------+ +---------+---------+
| SInf T | SInf L | SInf V | : FrPr Vc :
+---------+---------+---------+ +---------+
| SVal T | SVal L | SVal V |
+---------+---------+---------+
Figure 16: Compression of NDN LoWPAN Data Message
図16：NDNローパンデータメッセージの圧縮
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 17.
さらなるTLV圧縮は、図17のICN LowPanディスパッチによって示されている。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 1 |FBI|CON|KLO| RSV |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 17: Dispatch Format for Compressed NDN Data Messages
図17：圧縮NDNデータメッセージのディスパッチフォーマット
FBI: FinalBlockId TLV 0: The uncompressed message does not include a FinalBlockId TLV.
FBI：FinalBlockID TLV 0：非圧縮メッセージには、FinalBlockID TLVが含まれていません。
1: The uncompressed message does include a FinalBlockId, and it is encoded according to Section 5.2. If the FinalBlockId TLV is not compressible, then the message MUST be sent uncompressed.
1：非圧縮メッセージはFinalBlockIDを含み、セクション5.2に従ってエンコードされています。FinalBlockID TLVが圧縮可能でない場合、メッセージは圧縮されない送信されなければなりません。
CON: ContentType TLV 0: The uncompressed message does not include a ContentType TLV.
con：contentType TLV 0：非圧縮メッセージにはContentType TLVが含まれていません。
1: The uncompressed message does include a ContentType TLV. The Type field is removed from the compressed message.
1：非圧縮メッセージにはContentType TLVが含まれています。[タイプ]フィールドは圧縮されたメッセージから削除されます。
KLO: KeyLocator TLV 0: If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a name and is compressed according to Section 5.2. If the name is not compressible, then the message MUST be sent uncompressed.
KLO：KEYLOCORET TLV 0：含まれているSignatureTypeがキーロケータTLVを必要とする場合、Keylocatorは名前を表し、セクション5.2に従って圧縮されます。名前が圧縮可能でない場合は、メッセージを非圧縮に送信する必要があります。
1: If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a KeyDigest. The Type field of this KeyDigest is removed.
1：含まれているSignatureTypeがkeylocator TLVを必要とする場合、keylocatorはKeyDigestを表します。このキーに設定されたタイプフィールドは削除されます。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
CID: Context Identifier See Figure 5.
CID：コンテキスト識別子図5を参照してください。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: Extension byte EXT_0 follows immediately. See Section 5.4.3.
1：拡張子バイトEXT_0がすぐに続きます。セクション5.4.3を参照してください。
The EXT_0 byte follows the description in Section 4.1.1 and is illustrated in Figure 18.
ext_0バイトはセクション4.1.1の説明に従い、図18に示されています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+
Figure 18: EXT_0 Format
図18：ext_0形式
NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2).
NCS：名前圧縮戦略00：名称は、デフォルトの名前圧縮戦略で圧縮されています（セクション5.2を参照）。
01: Reserved.
01：予約済み。
10: Reserved.
10：予約済み。
11: Reserved.
11：予約済み。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: A further extension byte follows immediately.
1：さらに延長バイトがすぐに続く。
The generic CCNx TLV encoding is described in [RFC8609]. Type and Length fields attain the common fixed length of 2 bytes.
一般的なCCNX TLV符号化は[RFC8609]に記載されています。タイプと長さのフィールドは、2バイトの一般的な固定長を達成します。
The TLV encoding for CCNx LoWPAN is changed to the more space-efficient encoding described in Section 5.1. Hence, NDN and CCNx use the same compressed format for writing TLVs.
CCNX LowPan用のTLVエンコードは、セクション5.1で説明されているスペース効率の高いエンコーディングに変更されています。したがって、NDNとCCNXはTLVを書き込むために同じ圧縮形式を使用します。
Name TLVs are compressed using the scheme already defined in Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or organizational TLVs, then the name remains uncompressed.
NAME TLVは、NDNのセクション5.2で既に定義されている方式を使用して圧縮されています。名前TLVにt_ipid、t_app、または組織のTLVが含まれている場合、その名前は圧縮されていません。
An uncompressed Interest message uses the base dispatch format (see Figure 4) and sets the C and M flags to 0. The P flag is set to 1 (Figure 19). The Interest message is handed to the CCNx stack without modifications.
圧縮されていない関心メッセージは、基本ディスパッチフォーマットを使用しており（図4を参照）、CフラグとMフラグを0に設定します.Pフラグは1に設定されています（図19）。関心のあるメッセージは変更なしでCCNXスタックに渡されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
Figure 19: Dispatch Format for Uncompressed CCNx Interest Messages
図19：非圧縮CCNXの関心メッセージのディスパッチフォーマット
The compressed Interest message uses the extended dispatch format (Figure 5) and sets the C and P flags to 1. The M flag is set to 0. If an Interest message contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed.
圧縮関心メッセージは拡張ディスパッチフォーマットを使用しています（図5）、CフラグとPフラグを1に設定します.mフラグは0に設定されます。関心のあるメッセージには、次の圧縮規則に記載されていないTLVが含まれている場合非圧縮を送信する必要があります。
In the default use case, the Interest message is compressed with the following minimal rule set:
デフォルトのユースケースでは、興味メッセージは次の最小限のルールセットで圧縮されます。
1. The version is elided from the fixed header and assumed to be 1.
1. バージョンは固定ヘッダーから除外され、1と想定されています。
2. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the fixed header on decompression.
2. CCNXメッセージTLVのタイプと長さのフィールドは、解凍時に固定ヘッダから取得されます。
The compressed CCNx LoWPAN Interest message is visualized in Figure 20.
圧縮されたCCNX lowpan関心メッセージは図20に視覚化されています。
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field
+-----------------------------+ +-------------------------+
| Uncompr. Fixed Header | | Compr. Fixed Header |
+-----------------------------+ +-------------------------+
+---------+---------+---------+ +---------+
: ILT T : ILT L : ILT V : : ILT Vc :
+---------+---------+---------+ +---------+
: MSGH T : MSGH L : MSGH V : : MSGH Vc :
+---------+---------+---------+ +---------+
+---------+---------+ +---------+
| MSGT T | MSGT L | | Name Vc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | ==> : KIDR Vc :
+---------+---------+---------+ +---------+
: KIDR T : KIDR L : KIDR V : : OBHR Vc :
+---------+---------+---------+ +---------+---------+
: OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V :
+---------+---------+---------+ +---------+---------+
: PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc :
+---------+---------+---------+ +---------+---------+
: VALG T : VALG L : VALG V : : VPAY Lc : VPAY V :
+---------+---------+---------+ +---------+---------+
: VPAY T : VPAY L : VPAY V :
+---------+---------+---------+
Figure 20: Compression of CCNx LoWPAN Interest Message
図20：CCNXローパンの関心事の圧縮
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 21.
さらなるTLV圧縮は、図21のICNローパンディスパッチによって示される。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 21: Dispatch Format for Compressed CCNx Interest Messages
図21：圧縮CCNXの関心メッセージのディスパッチフォーマット
FLG: Flags field in the fixed header 0: The Flags field equals 0 and is removed from the Interest message.
FLG：Flagsフィールド固定ヘッダ0：フラグフィールドは0に等しく、関心メッセージから削除されます。
1: The Flags field appears in the fixed header.
1：Flagsフィールドが固定ヘッダーに表示されます。
PTY: PacketType field in the fixed header 0: The PacketType field is elided and assumed to be PT_INTEREST.
PTY：固定ヘッダー0のPCKETTYPEフィールド0：PacketTypeフィールドは、PT_Interestであると想定されます。
1: The PacketType field is elided and assumed to be PT_RETURN.
1：PacketTypeフィールドがelededとpt_returnと想定されています。
HPL: HopLimit field in the fixed header 0: The HopLimit field appears in the fixed header.
HPL：Fixedヘッダー0のHOPLIMITフィールド：HOPLIMITフィールドが固定ヘッダーに表示されます。
1: The HopLimit field is elided and assumed to be 1.
1：HOPLIMITフィールドは、1であると仮定されている。
FRS: Reserved field in the fixed header 0: The Reserved field appears in the fixed header.
FRS：固定ヘッダの予約フィールド0：予約フィールドが固定ヘッダに表示されます。
1: The Reserved field is elided and assumed to be 0.
1：予約フィールドを除去し、0とする。
PAY: Optional Payload TLV 0: The Payload TLV is absent.
Pay：オプションのペイロードTLV 0：ペイロードTLVが不在です。
1: The Payload TLV is present, and the Type field is elided.
1：ペイロードTLVが存在し、タイプフィールドが照らされます。
ILT: Optional hop-by-hop InterestLifetime TLV See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs.
ILT：オプションのホップバイホップのFettentLifeTime TLVホップバイホップTLVの順序付けに関する詳細については、セクション6.3.2.1を参照してください。
0: No InterestLifetime TLV is present in the Interest message.
0：興味のあるメッセージにTLVが存在しません。
1: An InterestLifetime TLV is present with a fixed length of 1 byte and is encoded as described in Section 7. The Type and Length fields are elided.
1：FITITELIFETIME TLVが1バイトの固定長で存在し、セクション7に記載されているように符号化されている。
MGH: Optional hop-by-hop MessageHash TLV See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs.
MGH：ホップバイホップTLVの順序付けに関する詳細については、セクション6.3.2.1を参照してください。
This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed.
このTLVはT_SHA-256 TLVを含むと予想されます。別のハッシュが含まれている場合は、興味を非圧縮に送信する必要があります。
0: The MessageHash TLV is absent.
0：MessageHash TLVが不在です。
1: A T_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer Message Hash TLV is omitted.
1：T_SHA-256 TLVが存在し、タイプフィールドと長さのフィールドは削除されます。長さフィールドは32バイトを表すと仮定されます。外側のメッセージハッシュTLVは省略されています。
KIR: Optional KeyIdRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed.
KIR：オプションのKeyIdRestriction TLVこのTLVは、T_SHA-256 TLVを含むと予想されます。別のハッシュが含まれている場合は、興味を非圧縮に送信する必要があります。
0: The KeyIdRestriction TLV is absent.
0：keyidRestriction TLVがありません。
1: A T_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer KeyIdRestriction TLV is omitted.
1：T_SHA-256 TLVが存在し、タイプフィールドと長さのフィールドは削除されます。長さフィールドは32バイトを表すと仮定されます。外側のキーディスクレストレーションTLVは省略されています。
CHR: Optional ContentObjectHashRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed.
Chr：オプションのContentObjectHashRestriction TLVこのTLVはT_SHA-256 TLVを含むと予想されます。別のハッシュが含まれている場合は、興味を非圧縮に送信する必要があります。
0: The ContentObjectHashRestriction TLV is absent.
0：ContentObjectHashRestriction TLVが不在です。
1: A T_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer ContentObjectHashRestriction TLV is omitted.
1：T_SHA-256 TLVが存在し、タイプフィールドと長さのフィールドは削除されます。長さフィールドは32バイトを表すと仮定されます。外部ContentObjectHashRestriction TLVは省略されています。
VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 0: No validation-related TLVs are present in the Interest message.
val：オプションのValidationalGorithmとValidationPayLoad TLVS 0：検証関連のTLVが関心事メッセージに存在しません。
1: Validation-related TLVs are present in the Interest message. An additional byte follows immediately that handles validation-related TLV compressions and is described in Section 6.3.2.2.
1：検証関連のTLVが関心事メッセージに存在します。追加のバイトは、検証関連のTLV圧縮を処理する直ちに次のようになり、6.3.2.2項で説明されています。
CID: Context Identifier See Figure 5.
CID：コンテキスト識別子図5を参照してください。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: Extension byte EXT_0 follows immediately. See Section 6.3.3.
1：拡張子バイトEXT_0がすぐに続きます。6.3.3項を参照してください。
Hop-by-hop header TLVs are unordered. For an Interest message, two optional hop-by-hop header TLVs are defined in [RFC8609], but several more can be defined in higher-level specifications. For the compression specified in the previous section, the hop-by-hop TLVs are ordered as follows:
ホップバイホップヘッダーTLVは順序付けられていません。興味のあるメッセージについては、[RFC8609]で2つのオプションのホップごとのヘッダーのヘッダーTLVが定義されていますが、高レベルの仕様ではいくつかあります。前のセクションで指定された圧縮の場合、ホップバイホップTLVは次のように順序付けされています。
1. InterestLifetime TLV
1. 便利なTLV
2. Message Hash TLV
2. メッセージハッシュTLV
Note: All hop-by-hop header TLVs other than the InterestLifetime and MessageHash TLVs remain uncompressed in the encoded message, and they appear after the InterestLifetime and MessageHash TLVs in the same order as in the original message.
注：InterIntrifetimeとMessageHash TLV以外のすべてのホップバイホップヘッダーTLVは、エンコードされたメッセージでは圧縮されていないままであり、元のメッセージと同じ順序でBettimeLifeTimeとMessageHash TLVの後に表示されます。
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ValidationAlg | KeyID | RSV |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 22: Dispatch for Interest Validations
図22：利益検証のための発送
ValidationAlg: Optional ValidationAlgorithm TLV 0000: An uncompressed ValidationAlgorithm TLV is included.
ValidationalG：オプションのValidationalGorithm TLV 0000：非圧縮検証対策TLVが含まれています。
0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included.
0001：T_CRC32C検証Gorithm TLVが想定されていますが、検証対策TLVは含まれていません。
0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a SignatureTime TLV is inlined without a Type and a Length field.
0010：T_CRC32C検証Gorithm TLVが想定されているが、検証対策TLVは含まれていない。さらに、SignatureTime TLVはタイプと長さフィールドなしでインライン化されています。
0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included.
0011：T_HMAC-SHA256検証Gorithm TLVが想定されていますが、検証対策TLVは含まれていません。
0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a SignatureTime TLV is inlined without a Type and a Length field.
0100：T_HMAC-SHA256検証Gorithm TLVが想定されていますが、検証対策TLVは含まれていません。さらに、SignatureTime TLVはタイプと長さフィールドなしでインライン化されています。
0101: Reserved.
0101：予約済み。
0110: Reserved.
0110：予約済み。
0111: Reserved.
0111：予約済み。
1000: Reserved.
1000：予約済み。
1001: Reserved.
1001：予約済み。
1010: Reserved.
1010：予約済み。
1011: Reserved.
1011：予約済み。
1100: Reserved.
1100：予約済み。
1101: Reserved.
1101：予約済み。
1110: Reserved.
1110：予約済み。
1111: Reserved.
1111：予約済み。
KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV 00: The KeyID TLV is absent.
keyID：ValidationalGorithmの内蔵のオプションのキーID TLV TLV 00：キーID TLVがありません。
01: The KeyID TLV is present and uncompressed.
01：KeyID TLVが存在していない。
10: A T_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer KeyID TLV is omitted.
10：T_SHA-256 TLVが存在し、タイプフィールドと長さのフィールドは削除されます。長さフィールドは32バイトを表すと仮定されます。外側キーID TLVは省略されています。
11: A T_SHA-512 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 64 bytes. The outer KeyID TLV is omitted.
11：T_SHA-512 TLVが存在し、タイプと長さのフィールドは削除されます。長さフィールドは64バイトを表すと仮定されます。外側キーID TLVは省略されています。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The Type field is omitted.
ValidationPayload TLVが存在する場合、ValidationPayload TLVが存在します。タイプフィールドは省略されています。
The EXT_0 byte follows the description in Section 4.1.1 and is illustrated in Figure 23.
ext_0バイトはセクション4.1.1の説明に続き、図23に示されています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+
Figure 23: EXT_0 Format
図23：ext_0フォーマット
NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2).
NCS：名前圧縮戦略00：名称は、デフォルトの名前圧縮戦略で圧縮されています（セクション5.2を参照）。
01: Reserved.
01：予約済み。
10: Reserved.
10：予約済み。
11: Reserved.
11：予約済み。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: A further extension byte follows immediately.
1：さらに延長バイトがすぐに続く。
An uncompressed Content Object uses the base dispatch format (see Figure 4) and sets the C flag to 0 and the P and M flags to 1 (Figure 24). The Content Object is handed to the CCNx stack without modifications.
圧縮されていないコンテンツオブジェクトは、基本ディスパッチフォーマット（図4を参照）を使用し、Cフラグを0とMフラグとMのフラグを1に設定します（図24）。コンテンツオブジェクトは変更なしでCCNXスタックに渡されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
Figure 24: Dispatch Format for Uncompressed CCNx Content Objects
図24：非圧縮CCNXコンテンツオブジェクトのディスパッチフォーマット
The compressed Content Object uses the extended dispatch format (Figure 5) and sets the C, P, and M flags to 1. If a Content Object contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed.
圧縮コンテンツオブジェクトは拡張ディスパッチフォーマット（図5）を使用し、C、P、およびMフラグを1に設定します。コンテンツオブジェクトには、次の圧縮規則に記載されていないTLVが含まれている場合、このメッセージは圧縮されないメッセージを送信する必要があります。
By default, the Content Object is compressed with the following base rule set:
デフォルトでは、Contentオブジェクトは次の基本ルールセットで圧縮されています。
1. The version is elided from the fixed header and assumed to be 1.
1. バージョンは固定ヘッダーから除外され、1と想定されています。
2. The PacketType field is elided from the fixed header.
2. PacketTypeフィールドは固定ヘッダから照らされます。
3. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the fixed header on decompression.
3. CCNXメッセージTLVのタイプと長さのフィールドは、解凍時に固定ヘッダから取得されます。
The compressed CCNx LoWPAN Data message is visualized in Figure 25.
圧縮されたCCNX LowPanデータメッセージは図25で視覚化されています。
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field
+-----------------------------+ +-------------------------+
| Uncompr. Fixed Header | | Compr. Fixed Header |
+-----------------------------+ +-------------------------+
+---------+---------+---------+ +---------+
: RCT T : RCT L : RCT V : : RCT Vc :
+---------+---------+------.--+ +---------+
: MSGH T : MSGH L : MSGH V : : MSGH Vc :
+---------+---------+---------+ +---------+
+---------+---------+ +---------+
| MSGT T | MSGT L | | Name Vc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | ==> : EXPT Vc :
+---------+---------+---------+ +---------+---------+
: PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V :
+---------+---------+---------+ +---------+---------+
: EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc :
+---------+---------+---------+ +---------+---------+
: PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V :
+---------+---------+---------+ +---------+---------+
: VALG T : VALG L : VALG V :
+---------+---------+---------+
: VPAY T : VPAY L : VPAY V :
+---------+---------+---------+
Figure 25: Compression of CCNx LoWPAN Data Message
図25：CCNXローパンデータメッセージの圧縮
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 26.
さらなるTLV圧縮は、図26のICN LowPanディスパッチによって示されている。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | 1 |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV|CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 26: Dispatch Format for Compressed CCNx Content Objects
図26：圧縮CCNXコンテンツオブジェクトのディスパッチフォーマット
FLG: Flags field in the fixed header See Section 6.3.2.
FLG：Fixed HeaderのFlagsフィールド6.3.2項を参照してください。
FRS: Reserved field in the fixed header See Section 6.3.2.
FRS：固定ヘッダーの予約フィールドはセクション6.3.2を参照してください。
PAY: Optional Payload TLV See Section 6.3.2.
Pay：オプションのペイロードTLVセクション6.3.2を参照してください。
RCT: Optional hop-by-hop Recommended Cache Time TLV 0: The Recommended Cache Time TLV is absent.
RCT：オプションのホップバイホップ推奨キャッシュタイムTLV 0：推奨キャッシュタイムTLVが不在です。
1: The Recommended Cache Time TLV is present, and the Type and Length fields are elided.
1：推奨キャッシュタイムTLVが存在し、タイプと長さのフィールドが照らされます。
MGH: Optional hop-by-hop MessageHash TLV See Section 6.4.2.1 for further details on the ordering of hop-by-hop TLVs.
MGH：オプションのホップバイホップMessageHash TLVホップバイホップTLVの順序付けの詳細については、セクション6.4.2.1を参照してください。
This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Content Object MUST be sent uncompressed.
このTLVはT_SHA-256 TLVを含むと予想されます。別のハッシュが含まれている場合は、コンテンツオブジェクトを非圧縮に送信する必要があります。
0: The MessageHash TLV is absent.
0：MessageHash TLVが不在です。
1: A T_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer Message Hash TLV is omitted.
1：T_SHA-256 TLVが存在し、タイプフィールドと長さのフィールドは削除されます。長さフィールドは32バイトを表すと仮定されます。外側のメッセージハッシュTLVは省略されています。
PLTYP: Optional PayloadType TLV 00: The PayloadType TLV is absent.
PLTYP：オプションのPayloadType TLV 00：PayloadType TLVが不在です。
01: The PayloadType TLV is absent, and T_PAYLOADTYPE_DATA is assumed.
01：PayloadType TLVが存在しないため、T_PAYLOADTYPE_DATAが想定されています。
10: The PayloadType TLV is absent, and T_PAYLOADTYPE_KEY is assumed.
10：PayloadType TLVが不在で、T_PAYLOADTYPE_KEYが想定されています。
11: The PayloadType TLV is present and uncompressed.
11：PayloadType TLVが存在し、圧縮されています。
EXP: Optional ExpiryTime TLV 0: The ExpiryTime TLV is absent.
exp：オプションのexpiryTime TLV 0：expiryTime TLVが不在です。
1: The ExpiryTime TLV is present, and the Type and Length fields are elided.
1：公開されたTLVが存在し、タイプと長さのフィールドが照らされます。
VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Section 6.3.2.
val：オプションのValidationalGorithmとValidationPayLoad TLVSを参照してください.6.3.2項。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
CID: Context Identifier See Figure 5.
CID：コンテキスト識別子図5を参照してください。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: Extension byte EXT_0 follows immediately. See Section 6.4.3.
1：拡張子バイトEXT_0がすぐに続きます。6.4.3項を参照してください。
Hop-by-hop header TLVs are unordered. For a Content Object message, two optional hop-by-hop header TLVs are defined in [RFC8609], but several more can be defined in higher-level specifications. For the compression specified in the previous section, the hop-by-hop TLVs are ordered as follows:
ホップバイホップヘッダーTLVは順序付けられていません。コンテンツオブジェクトメッセージの場合は、[RFC8609]で2つのオプションのホップバイホップヘッダーTLVが定義されていますが、上位レベルの仕様でもいくつかあります。前のセクションで指定された圧縮の場合、ホップバイホップTLVは次のように順序付けされています。
1. Recommended Cache Time TLV
1. 推奨キャッシュタイムTLV
2. Message Hash TLV
2. メッセージハッシュTLV
Note: All hop-by-hop header TLVs other than the RecommendedCacheTime and MessageHash TLVs remain uncompressed in the encoded message, and they appear after the RecommendedCacheTime and MessageHash TLVs in the same order as in the original message.
注：RecocidedCacheTimeおよびMessageHash TLV以外のすべてのホップバイホップヘッダーTLVは、エンコードされたメッセージでは圧縮されていないままで、元のメッセージと同じ順序で推奨されているCacheTimeとMessageHash TLVの後に表示されます。
The EXT_0 byte follows the description in Section 4.1.1 and is illustrated in Figure 27.
EXT_0バイトはセクション4.1.1の説明に続き、図27に示されています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+
Figure 27: EXT_0 Format
図27：EXT_0フォーマット
NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2).
NCS：名前圧縮戦略00：名称は、デフォルトの名前圧縮戦略で圧縮されています（セクション5.2を参照）。
01: Reserved.
01：予約済み。
10: Reserved.
10：予約済み。
11: Reserved.
11：予約済み。
RSV: Reserved Must be set to 0.
RSV：予約済みは0に設定する必要があります。
EXT: Extension 0: No extension byte follows.
ext：拡張子0：拡張バイトは続行されません。
1: A further extension byte follows immediately.
1：さらに延長バイトがすぐに続く。
This document adopts the 8-bit compact time representation for relative time-values described in Section 5 of [RFC5497] with the constant factor C set to C := 1/32.
この文書は、C：= 1/32に設定されている定数係数Cを持つ、[RFC5497]のセクション5で説明されている相対時間値の8ビットの小時間表現を採用しています。
Valid time offsets in CCNx and NDN range from a few milliseconds (e.g., lifetime of low-latency Interests) to several years (e.g., content freshness periods in caches). Therefore, this document adds two modifications to the compression algorithm.
CCNXおよびNDN内の有効な時間オフセットは、数ミリ秒（例えば、低遅延の利益の寿命）から数年（例えば、キャッシュ内のコンテンツ鮮度期間）からの範囲である。したがって、この文書は圧縮アルゴリズムに2つの修正を追加します。
The first modification is the inclusion of a subnormal form [IEEE.754.2019] for time-codes with exponent 0 to provide an increased precision and a gradual underflow for the smallest numbers. The formula is changed as follows (a := mantissa, b := exponent):
第1の修正は、指数0を有するタイムコードのための下符号[IEEE.754.2019]の包含であり、最小の数に対する精度の向上と漸進的なアンダーフローを提供する。式は次のように変更されます（A：= MANTISSA、B：=指数）。
Subnormal (b == 0): (0 + a/8) * 2 * C
Normalized (b > 0): (1 + a/8) * 2^b * C (see [RFC5497])
This configuration allows for the following ranges:
この設定は次の範囲を可能にします。
* Minimum subnormal number: 0 seconds * 2nd minimum subnormal number: ~0.007812 seconds * Maximum subnormal number: ~0.054688 seconds * Minimum normalized number: ~0.062500 seconds * 2nd minimum normalized number: ~0.070312 seconds * Maximum normalized number: ~3.99 years
* 最小下限数：0秒×2番目の最小下がり数：~0.007812秒×最大の符号数：~0.054688秒*最小正規化数：~0.062500秒*第2最小正規化数：~0.070312秒*最大正規化数：3.99年
The second modification only applies to uncompressible time offsets that are outside any security envelope. An invalid time-value MUST be set to the largest valid time-value that is smaller than the invalid input value before compression.
2番目の変更は、セキュリティエンベロープの外部にある非圧縮可能な時間オフセットにのみ適用されます。無効な時間値は、圧縮前の無効な入力値より小さい最大の有効な時間値に設定する必要があります。
Stateful header compression in ICN LoWPAN enables packet size reductions in two ways. First, common information that is shared throughout the local LoWPAN may be memorized in the context state at all nodes and omitted from communication. Second, redundancy in a single Interest-Data exchange may be removed from ICN stateful forwarding on a hop-by-hop basis and memorized in en route state tables.
ICNローパンのステートフルヘッダー圧縮は、2つの方法でパケットサイズの削減を可能にします。まず、ローカルローパン全体に共有されている共通情報を全ノードのコンテキスト状態に記憶し、通信から省略することができる。第二に、単一の関心データ交換における冗長性をホップバイホップ単位でICNステートフルフォワーディングから削除し、ENルート状態テーブルに記憶させることができる。
A Context Identifier (CID) is a byte that refers to a particular conceptual context between network devices and MAY be used to replace frequently appearing information, such as name prefixes, suffixes, or meta information, such as Interest lifetime.
コンテキスト識別子（CID）は、ネットワークデバイス間の特定の概念的なコンテキストを参照するバイトであり、名前のプレフィックス、サフィックス、またはメタ情報などの頻繁に表示される情報、または興味の生涯などのメタ情報を置き換えるために使用されてもよい。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| X | CID |
+---+---+---+---+---+---+---+---+
Figure 28: Context Identifier
図28：コンテキスト識別子
The 7-bit CID is a locally scoped unique identifier that represents the context state shared between the sender and receiver of the corresponding frame (see Figure 28). If set, the most significant bit indicates the presence of another, subsequent CID byte (see Figure 33).
7ビットCIDは、対応するフレームの送信側と受信機との間で共有されるコンテキスト状態を表すローカルスコープの固有の識別子です（図28を参照）。設定されている場合、最上位ビットは、その後のCIDバイトの存在を示します（図33を参照）。
The context state shared between senders and receivers is removed from the compressed packet prior to sending and reinserted after reception prior to passing to the upper stack.
送信者と受信機との間で共有されるコンテキスト状態は、上部スタックに渡す前に受信後に送信および再挿入される前に圧縮パケットから削除される。
The actual information in a context and how it is encoded are out of scope of this document. The initial distribution and maintenance of shared context is out of scope of this document. Frames containing unknown or invalid CIDs MUST be silently discarded.
コンテキスト内の実際の情報とそれがどのようにエンコードされているかはこの文書の範囲外です。共有コンテキストの初期分布と保守はこの文書の範囲外です。未知のCIDまたは無効なCIDを含むフレームは、黙って破棄されなければなりません。
In CCNx and NDN, Name TLVs are included in Interest messages, and they return in Data messages. Returning Name TLVs either equal the original Name TLV or contain the original Name TLV as a prefix. ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs with single bytes that represent link-local HopIDs. HopIDs are carried as Context Identifiers (see Section 8.1) of link-local scope, as shown in Figure 29.
CCNXとNDNでは、名前TLVSは関心のあるメッセージに含まれており、データメッセージに戻ります。名前を返すTLVSは元の名前TLVと等しいか、元の名前のTLVをプレフィックスとして含めます。ICN LowPanは、Link-Local Hopidsを表す単一バイトと名前TLVを置き換えることで、回答の冗長性を縮小します。図29に示すように、Hopidsはリンクローカルスコープのコンテキスト識別子（セクション8.1参照）として実行されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| X | HopID |
+---+---+---+---+---+---+---+---+
Figure 29: Context Identifier as HopID
図29：Hopidとしてのコンテキスト識別子
A HopID is valid if not all ID bits are set to zero and invalid otherwise. This yields 127 distinct HopIDs. If this range (1...127) is exhausted, the messages MUST be sent without en route state compression until new HopIDs are available. An ICN LoWPAN node that forwards without replacing the Name TLV with a HopID (without en route compression) MUST invalidate the HopID by setting all ID bits to zero.
すべてのIDビットがゼロに設定されていて、そうでない場合は無効になっている場合は、HOPIDが有効です。これにより、127個の異なるHOPIDが得られます。この範囲（1 ... 127）が使い果たされた場合、新しいHopidsが利用可能になるまで、メッセージは途中の状態圧縮なしで送信されなければなりません。名前TLVをHOPID（jaルート圧縮なし）に置き換えずに転送するICNローパンノードは、すべてのIDビットをゼロに設定することによってhopidを無効にする必要があります。
While an Interest is traversing, a forwarder generates an ephemeral HopID that is tied to a Pending Interest Table (PIT) entry. Each HopID MUST be unique within the local PIT and only exists during the lifetime of a PIT entry. To maintain HopIDs, the local PIT is extended by two new columns: HIDi (inbound HopIDs) and HIDo (outbound HopIDs).
興味が横断している間、フォワーダは保留金利テーブル（PIT）エントリに関連付けられているエフェメラルホプリドを生成します。各HOPIDはローカルピット内で一意でなければならず、ピットエントリの存続期間中にのみ存在します。HOPIDを維持するために、ローカルピットは2つの新しい列によって拡張されます：HIDI（Inbound Hopids）とHido（アウトバウンドホプリッド）。
HopIDs are included in Interests and stored on the next hop with the resulting PIT entry in the HIDi column. The HopID is replaced with a newly generated local HopID before the Interest is forwarded. This new HopID is stored in the HIDo column of the local PIT (see Figure 30).
Hopidsは利益に含まれており、結果として得られたピットエントリをHIDI列に格納します。hopidは、関心が転送される前に、新しく生成されたローカルhopidに置き換えられます。この新しいHOPIDは、ローカルピットのHido列に保存されています（図30を参照）。
PIT of B PIT Extension PIT of C PIT Extension
+--------+------++------+------+ +--------+------++------+------+
| Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo |
+========+======++======+======+ +========+======++======+======+
| /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | |
+--------+------++------+------+ +--------+------++------+------+
^ | ^
store | '----------------------, ,---' store
| send v |
,---, /p0, h_A ,---, /p0, h_B ,---,
| A | ------------------------> | B | ------------------------> | C |
'---' '---' '---'
Figure 30: Setting Compression State En Route (Interest)
図30：圧縮状態ENルート（興味）
Responses include HopIDs that were obtained from Interests. If the returning Name TLV equals the original Name TLV, then the name is entirely elided. Otherwise, only the matching name prefix is elided, and the distinct name suffix is included along with the HopID. When a response is forwarded, the contained HopID is extracted and used to match against the correct PIT entry by performing a lookup on the HIDo column. The HopID is then replaced with the corresponding HopID from the HIDi column prior to forwarding the response (Figure 31).
回答には、利益から得られたホプリッドが含まれます。戻り値TLVが元の名前TLVに等しい場合、その名称は完全に照会されます。それ以外の場合は、一致する名前のプレフィックスのみが表示され、hopidと一緒に異なる名前の接尾辞が含まれます。応答が転送されると、HIDO列の検索を実行することで、含まれているHOPIDを抽出し、正しいピットエントリと照合するために使用されます。次に、HOPIDは応答を転送する前にHIDI列から対応するHOPIDと置き換えられます（図31）。
PIT of B PIT Extension PIT of C PIT Extension
+--------+------++------+------+ +--------+------++------+------+
| Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo |
+========+======++======+======+ +========+======++======+======+
| /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | |
+--------+------++------+------+ +--------+------++------+------+
| ^ |
send | '----------------------, ,---' send
v match | v
,---, h_A ,---, h_B ,---,
| A | <------------------------ | B | <------------------------ | C |
'---' '---' '---'
Figure 31: Eliding Name TLVs Using En Route State (Data)
図31：ENルート状態（データ）を使用した名前TLVS
It should be noted that each forwarder of an Interest in an ICN LoWPAN network can individually decide whether to participate in en route compression or not. However, an ICN LoWPAN node SHOULD use en route compression whenever the stateful compression mechanism is activated.
ICNローパンネットワークへの関心の各フォワーダは、ENルート圧縮に参加するかどうかを個別に決定することができることに留意されたい。ただし、ICN LowPanノードは、ステートフル圧縮メカニズムがアクティブになったときはいつでもENルート圧縮を使用する必要があります。
Note also that the extensions of the PIT data structure are required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside of an ICN LoWPAN domain do not need to implement these extensions.
また、ICNローパンノードでのみPITデータ構造の拡張が必要であることにも注意してくださいが、ICNローパンドメインの外部の通常のNDN / CCNXフォワーダはこれらの拡張機能を実装する必要はありません。
A CID appears whenever the CID flag is set (see Figure 5). The CID is appended to the last ICN LoWPAN dispatch byte, as shown in Figure 32.
CIDフラグが設定されているときはいつでもCIDが表示されます（図5を参照）。図32に示すように、CIDは最後のICN LowPanディスパッチバイトに追加されます。
...-------+--------+-------...-------+--...-+-------...
/ ... | Page | ICN LoWPAN Disp.| CIDs | Payload /
...-------+--------+-------...-------+--...-+-------...
Figure 32: LoWPAN Encapsulation with ICN LoWPAN and CIDs
図32：ICNローパンとCIDSによるローパンカプセル化
Multiple CIDs are chained together, with the most significant bit indicating the presence of a subsequent CID (Figure 33). This allows the use of multiple shared contexts in compressed messages.
複数のCIDが一緒に連鎖され、最上位ビットは後続のCIDの存在を示す（図33）。これにより、圧縮メッセージで複数の共有コンテキストを使用できます。
The HopID is always included as the very first CID.
HOPIDは常に最初のCIDとして含まれています。
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1| CID / HopID | --> |1| CID | --> |0| CID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 33: Chaining of Context Identifiers
図33：コンテキスト識別子の連鎖
This is a summary of all ICN LoWPAN constants and variables.
これは、すべてのICNローパン定数と変数の要約です。
DEFAULT_NDN_HOPLIMIT: 255
default_ndn_hoplimit：255
The ICN LoWPAN scheme defined in this document has been implemented as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT version on RIOT [RIOT]. An experimental evaluation for NDN over ICN LoWPAN with varying configurations has been performed in [ICNLOWPAN]. Energy profiling and processing time measurements indicate significant energy savings, and the amortized costs for processing show no penalties.
この文書で定義されているICN LowPanスキームは、暴動のIOTバージョンのNDN / CCNXソフトウェアスタック[CCN-Lite]の拡張として実装されています。[ICNLOWPAN]では、さまざまな構成を持つICN LowPan上のNDNの実験的評価が行われました。エネルギープロファイリングと処理時間の測定値は大きな省エネを示し、処理のための償却費はペナルティを表示しません。
The header compression performance depends on certain aspects and configurations. It works best for the following cases:
ヘッダの圧縮性能は、特定の側面や構成によって異なります。次のような場合に最適です。
* Signed time offsets compress, per Section 7, without the need for rounding.
* 四捨五入を必要とせずに、セクション7ごとに署名された時間オフセット。
* The context state (e.g., prefixes) is distributed such that long names can be elided from Interest and Data messages.
* コンテキスト状態（例えば、接頭辞）は、長い名前が利子およびデータメッセージから照会できるように配布される。
* Frequently used TLV type numbers for CCNx and NDN stay in the lower range (< 255).
* CCNXおよびNDNのための頻繁に使用されるTLVタイプ番号は下の範囲（<255）に留まる。
Name components are of type GenericNameComponent and are limited to a length of 15 bytes to enable compression for all messages.
名前コンポーネントはGenericNameComponent型で、すべてのメッセージの圧縮を可能にするために15バイトの長さに制限されています。
An investigation of ICN LoWPAN in large-scale deployments with varying traffic patterns using larger samples of the different board types available remains as future work. This document will be revised to progress it to the Standards Track, once sufficient operational experience has been acquired. Experience reports are encouraged, particularly in the following areas:
利用可能なさまざまなボードタイプのより大きなサンプルを使用してさまざまなトラフィックパターンを持つ大規模展開におけるICN Lowpanの調査は将来の作業として残ります。この文書は、十分な運用経験が取得されたら、標準トラックに進行するように修正されます。特に以下の分野では、経験報告が奨励されています。
* The name compression scheme (Section 5.2) is optimized for short name components of type GenericNameComponent. An empirical study on name lengths in different deployments of selected use cases, such as smart home, smart city, and industrial IoT can provide meaningful reports on necessary name component types and lengths. A conclusive outcome helps to understand whether and how extension mechanisms are needed (Section 5.3.3). As a preliminary analysis, [ICNLOWPAN] investigates the effectiveness of the proposed compression scheme with URLs obtained from the WWW. Studies on deployments of Constrained Application Protocol (CoAP) [RFC7252] can offer additional insights on naming schemes in the IoT.
* Name Compression Scheme（セクション5.2）は、GenericNameComponentの型の短縮名コンポーネントに最適化されています。スマートホーム、スマートシティ、産業用IOTなど、選択されたユースケースの異なる展開における名前の長さに関する実証的な研究は、必要な名前のコンポーネントの種類と長さに意味のあるレポートを提供できます。決定的な結果は、拡張メカニズムが必要かどうかを理解するのに役立ちます（セクション5.3.3）。予備分析として、[ICNLOWPAN]は、WWWから得られたURLを用いて提案された圧縮方式の有効性を調査する。制約付きアプリケーションプロトコルの展開に関する研究（COAP）[RFC7252]は、IOT内の命名方式に関する追加の洞察を提供できます。
* The fragmentation scheme (Section 4.2) inherited from 6LoWPAN allows for a transparent, hop-wise reassembly of CCNx or NDN packets. Fragment forwarding [RFC8930] with selective fragment recovery [RFC8931] can improve the end-to-end latency and reliability while it reduces buffer requirements on forwarders. Initial evaluations [SFR-ICNLOWPAN] show that a naive integration of these upcoming fragmentation features into ICN LoWPAN renders the hop-wise content replication inoperative, since Interest and Data messages are reassembled end-to-end. More deployment experiences are necessary to gauge the feasibility of different fragmentation schemes in ICN LoWPAN.
* 6lowpanから継承されたフラグメンテーション方式（セクション4.2）は、CCNXまたはNDNパケットの透過的でホップワイザの再構成を可能にします。フラグメント転送[RFC8930]選択的フラグメントリカバリ[RFC8931]では、終了の待ち時間と信頼性を向上させることができます。初期評価[SFR-ICNLOWPAN]は、ICN LowPanへのこれらの次の断片化機能をNAIVE統合することが、利子とデータメッセージが完全に組み立てられたエンドツーエンドであるため、OpenS-Wiseコンテンツの複製を実行できます。ICN Lowpanにおける異なる断片化方式の実現可能性を測定するには、より多くの展開エクスペリエンスが必要です。
* The context state (Section 8.1) holds information that is shared between a set of devices in a LoWPAN. Fixed name prefixes and suffixes are good candidates to be distributed to all nodes in order to elide them from request and response messages. More experience and a deeper inspection of currently available and upcoming protocol features is necessary to identify other protocol fields.
* コンテキスト状態（セクション8.1）は、ローパン内の一連のデバイス間で共有されている情報を保持します。固定名プレフィックスとサフィックスは、要求メッセージと応答メッセージからそれらを除外するために、すべてのノードに配布される優れた候補です。他のプロトコルフィールドを識別するには、現在利用可能で今後のプロトコル機能のより多くの経験とより深い検査が必要です。
* The distribution and synchronization of the context state can potentially be adopted from Section 7.2 of [RFC6775] but requires further evaluations. While 6LoWPAN uses the Neighbor Discovery protocol to disseminate state, CCNx and NDN deployments are missing out on a standard mechanism to bootstrap and manage configurations.
* コンテキスト状態の分布と同期は、[RFC6775]のセクション7.2から採用される可能性がありますが、さらなる評価を必要とします。6LOWPANは、Neighbor Discovery Protocolを使用して状態を普及させますが、CCNXとNDNの展開は標準的なメカニズムでブートストラップと管理の管理に欠落しています。
* The stateful en route compression (Section 8.2) supports a limited number of 127 distinct HopIDs that can be simultaneously in use on a single node. Complex deployment scenarios that make use of multiple, concurrent requests can provide a better insight on the number of open requests stored in the PIT of memory-constrained devices. This number can serve as an upper bound and determines whether the HopID length needs to be resized to fit more HopIDs at the cost of additional header overhead.
* ステートフルENルート圧縮（セクション8.2）は、単一ノードで同時に使用できる127個の異なるホプリッドの限られた数をサポートしています。複数の同時要求を使用する複雑な展開シナリオは、メモリ制約付きデバイスのPITに格納されているオープン要求の数に関するより良い洞察を提供できます。この数は上限として機能し、追加のヘッダーオーバーヘッドのコストでホプリド長をより多くのホプリドに合わせるようにサイズ変更する必要があるかどうかを決定することができます。
* Multiple implementations that generate and deploy the compression options of this memo in different ways will also add to the experience and understanding of the benefits and limitations of the proposed schemes. Different reports can help to illuminate the complexity of implementing ICN LoWPAN for constrained devices, as well as on maintaining interoperability with other implementations.
* さまざまな方法でこのメモの圧縮オプションを生成してデプロイする複数の実装には、提案されたスキームの利点と制限の経験と理解も追加されます。異なるレポートは、ICN LowPanを制約のあるデバイスに実装する複雑さ、ならびに他の実装との相互運用性を維持するのに役立ちます。
Main memory is typically a scarce resource of constrained networked devices. Fragmentation, as described in this memo, preserves fragments and purges them only after a packet is reassembled, which requires a buffering of all fragments. This scheme is able to handle fragments for distinctive packets simultaneously, which can lead to overflowing packet buffers that cannot hold all necessary fragments for packet reassembly. Implementers are thus urged to make use of appropriate buffer replacement strategies for fragments. Minimal fragment forwarding [RFC8930] can potentially prevent fragment buffer saturation in forwarders.
メインメモリは通常、制約付きネットワークデバイスの乏しいリソースです。このメモに記載されているように、断片化は、フラグメントを保持し、パケットが再組み立てされた後にのみそれらを消去し、それはすべてのフラグメントのバッファリングを必要とします。この方式は、独自のパケットのフラグメントを同時に処理することができ、それはパケットの再構成のためのすべての必要なフラグメントを保持できないパケットバッファをオーバーフローする可能性があります。したがって、実装者はフラグメントのための適切なバッファ置換戦略を利用するように促されています。最小限のフラグメント転送[RFC8930]は、フォワーダ内のフラグメントバッファ飽和を潜在的に防止することができます。
The stateful header compression generates ephemeral HopIDs for incoming and outgoing Interests and consumes them on returning Data packets. Forged Interests can deplete the number of available HopIDs, thus leading to a denial of compression service for subsequent content requests.
ステートフルヘッダ圧縮は、着信と発信の利益のための一時的ホプリドを生成し、データパケットを返す上でそれらを消費します。鍛造利益は利用可能なホプリドの数を削除することができ、したがって後続のコンテンツ要求のために圧縮拒否サービスを引き起こす可能性がある。
To further alleviate the problems caused by forged fragments or Interest initiations, proper protective mechanisms for accessing the link layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link or a group of devices.
鍛造されたフラグメントや興味の開始によって引き起こされる問題をさらに軽減するために、リンク層にアクセスするための適切な保護メカニズムを展開する必要があります。IEEE 802.15.4は、フレームを保護し、それらをポイントツーポイントリンクまたはデバイスグループに制限する機能を提供します。
IANA has assigned dispatch values for ICN LoWPAN in the "Dispatch Type Field" subregistry [RFC4944] [RFC8025] of the "IPv6 Low Power Personal Area Network Parameters" registry. Table 2 represents the updates to the registry.
IANAは、「IPv6低電力パーソナルエリアネットワークパラメータ」レジストリの「ディスパッチタイプフィールド」サブリュジスト[RFC4944] [RFC8025]に、ICNローパンのディスパッチ値を割り当てました。表2は、レジストリへの更新を表します。
+=============+======+=========================+===========+
| Bit Pattern | Page | Header Type | Reference |
+=============+======+=========================+===========+
| 00 000000 | 14 | Uncompressed NDN | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 00 01xxxx | 14 | Compressed NDN Interest | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 00 100000 | 14 | Uncompressed NDN Data | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 00 11xxxx | 14 | Compressed NDN Data | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 01 000000 | 14 | Uncompressed CCNx | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 01 01xxxx | 14 | Compressed CCNx | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 01 100000 | 14 | Uncompressed CCNx | RFC 9139 |
| | | Content Object messages | |
+-------------+------+-------------------------+-----------+
| 01 11xxxx | 14 | Compressed CCNx Content | RFC 9139 |
| | | Object messages | |
+-------------+------+-------------------------+-----------+
Table 2: Dispatch Types for NDN and CCNx
表2：NDNおよびCCNXのディスパッチタイプ
[IEEE.754.2019] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2019, <https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html>.
[IEEE.754.2019] IEEE、「浮動小数点演算のためのIEEE規格」、IEEE STD 754-2019、<https：//tandards.ieee.org/content/ieee-standards/en/jptandard/754-2019.html>。
[ieee802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Std 802.15.4-2020, <https://standards.ieee.org/standard/802_15_4-2020.html>.
[IEEE802.15.4] IEEE、「低速無線ネットワークのためのIEEE規格」、IEEE STD 802.15.4-2020、<https://standards.ieee.org/standard/802_15_4-2020.html>。
[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>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G.、Kushalnagar、N.、Hui、J.、およびD.Culler、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https：//www.rfc-editor.org/info/rfc4944>。
[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>.
[RFC5497] Chrausen、T.およびC. Dearlove、「モバイルアドホックネットワーク（MANET）」、RFC 5497、DOI 10.17487 / RFC5497、2009年3月、<https：//www.rfc-編集者。ORG / INFO / RFC5497>。
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 2011, <https://www.rfc-editor.org/info/rfc6256>.
[RFC6256] EDDY、W.およびE.DAVIES、「プロトコルの自己区切りの数値の使用」、RFC 6256、DOI 10.17487 / RFC6256、2011年5月、<https：//www.rfc-editor.org/info/rfc6256>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282] HUI、J.、ED。2011年9月、<https://www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282、<https://www.rfc-editor.org/info/rfc6282>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、ED。、Chakrabarti、S.、Nordmark、E.、およびC. Bormann、「低電力無線パーソナルエリアネットワークにおけるIPv6の近隣探索最適化（6lowpans）」、RFC 6775、DOI 10.17487/ RFC6775、2012年11月、<https://www.rfc-editor.org/info/rfc6775>。
[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>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[CCN-LITE] "CCN-lite, a lightweight implementation of the CCNx protocol and its variations", <https://github.com/cn-uofbasel/ccn-lite>.
[CCN-Lite] "CCN-Lite、CCNXプロトコルの軽量実装とそのバリエーション"、<https://github.com/cn-uofbasel/ccn-lite>。
[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>.
[Icnlowpan]Gündoanan、C.、Kietzmann、P.、Schmidt、T.、およびM.Wählisch、「情報中心のインターネットのためのローパン収束層の設計」、コンピュータ通信、Vol。164、No.1、p。114-123、Elsevier、2020年12月、<https://doi.org/10.1016/j.com.com.2020.10.002>。
[ICNRG-FLIC] Tschudin, C., Wood, C., Mosko, M., and D. Oran, Ed., "File-Like ICN Collections (FLIC)", Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-02, 4 November 2019, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-02>.
[ICNRG-FLIC] TSchudin、C、Wood、C.、Mosko、M.、およびD. Oran、ED。、「ファイルのようなICNコレクション（FLIC）」、進行中の作業、インターネットドラフト、ドラフトIRTF-icnrg-flic-02,2019、<https：//datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-02>
[NDN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking named content", 5th Int. Conf. on emerging Networking Experiments and Technologies (ACM CoNEXT), December 2009, <https://doi.org/10.1145/1658939.1658941>.
[NDN] Jacobson、V.、Smetters、D.、Thornton、J.、Plass、M.、Briggs、N.、およびR. Braynard、「ネットワーキング」、「Networking」、5th Int。conf新興ネットワーキング実験と技術（ACM Conext）、2009年12月、<https：//doi.org/10.1145/1658939.1658941>
[NDN-EXP1] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. Wählisch, "Information centric networking in the IoT: experiments with NDN in the wild", Proc. of 1st ACM Conf. on Information-Centric Networking (ICN-2014) ACM DL, pp. 77-86, September 2014, <http://dx.doi.org/10.1145/2660129.2660144>.
[NDN-EXP1] Baccelli、E.、Mehlis、C.、HAHM、O.、Schmidt、TC、M.Wählisch、「IOTにおける情報中心のネットワーキング：野生のNDNを用いた実験」、PROC。1回目のACM Confの。情報中心のネットワーキング（ICN-2014）ACM DL、PP。77-86、2014年9月、<http://dx.doi.org/10.1145/2660129.2660144>。
[NDN-EXP2] Gündoğan, C., Kietzmann, P., Lenders, M., Petersen, H., Schmidt, TC., and M. Wählisch, "NDN, CoAP, and MQTT: a comparative measurement study in the IoT", Proc. of 5th ACM Conf. on Information-Centric Networking (ICN-2018) ACM DL, pp. 159-171, September 2018, <https://doi.org/10.1145/3267955.3267967>.
[NDN-EXP2]Gündołan、C.、Kietzmann、P.、Lenders、M.、Petersen、H.、Schmidt、Tc。、およびM.Wählisch、 "NDN、CoAP、およびMQTT：IOTにおける比較測定研究「、proc。5回目のACMの収納情報中心のネットワーキング（ICN-2018）ACM DL、PP.159-171、2018年9月、<https：//doi.org/10.1145/3267955.3267967>。
[NDN-MAC] Kietzmann, P., Gündoğan, C., Schmidt, TC., Hahm, O., and M. Wählisch, "The need for a name to MAC address mapping in NDN: towards quantifying the resource gain", Proc. of 4th ACM Conf. on Information-Centric Networking (ICN-2017) ACM DL, pp. 36-42, September 2017, <https://doi.org/10.1145/3125719.3125737>.
[NDN-MAC] Kietzmann、P.、Gündołan、C.、Schmidt、Tc。、HAHM、O.、およびM.Wählisch、「NDNにおけるMACアドレスマッピングへの名前の必要性：リソースゲインの定量化に向けた」Proc。4回目のACM CONFの。情報中心のネットワーキング（ICN-2017）ACM DL、PP。36-42、2017年9月、<https：//doi.org/10.1145/3125719.3125737>。
[NDN-PACKET-SPEC] "NDN Packet Format Specification", <https://named-data.net/doc/NDN-packet-spec/0.3/>.
[NDN-Packet-Spec] "NDNパケット形式仕様"、<https://named-data.net/doc/ndn-packet-spec/0.3/>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C、Eres、M.、およびA。ケラネン、「拘束ノードネットワークの用語」、RFC 7228、DOI 10.17487 / RFC7228、2014年5月、<https：//www.rfc-editor.org/ info / rfc7228>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K.、およびC. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。ORG / INFO / RFC7252>。
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>.
[RFC7476] Pentikousis、K。、ED。、Ohlman、B.、Corujo、D.、Boggia、G.、Tyson、G.、Davies、E.、Molinaro、A.、S. EUM、およびS. EUM、「情報中心」ネットワーキング：ベースラインシナリオ、RFC 7476、DOI 10.17487 / RFC7476、2015年3月、<https：//www.rfc-editor.org/info/rfc7476>。
[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>.
[RFC7927] Kutscher、D.、ED。、EUM、S、Pentikousis、K。、PSARAS、I。、Corujo、D.、Saucez、D.、Schmidt、T.、およびM. Wahlisch、2016年7月、RFC 7927、DOI 10.17487 / RFC7927、<https：//www.rfc-editor.org/info/rfc7927>。
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.
[RFC7945] Pentikousis、K。、ED。、Ohlman、B.、Davies、E.、Spirou、S.、およびG. Boggia、「情報中心のネットワーキング：評価とセキュリティ上の考慮事項」、RFC 7945、DOI 10.17487 / RFC7945、2016年9月、<https：//www.rfc-editor.org/info/rfc7945>。
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, <https://www.rfc-editor.org/info/rfc8025>.
[RFC8025] Thubert、P.、ED。そしてR. Cragie、 "IPv6 over低電力無線パーソナルエリアネットワーク（6lowpan）ページングディスパッチ"、RFC 8025、DOI 10.17487 / RFC8025、2016年11月、<https://www.rfc-editor.org/info/rfc8025>。
[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>.
[RFC8569] Mosko、M.、Solis、I.、およびC. Wood、 "Content-Centric Networking（CCNX）セマンティクス"、RFC 8569、DOI 10.17487 / RFC8569、2019年7月、<https：///www.rfc-編集者.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>.
[RFC8609] Mosko、M.、Solis、I.、C. Wood、 "TLV形式のコンテンツ中心のネットワーキング（CCNX）メッセージ"、RFC 8609、DOI 10.17487 / RFC8609、2019年7月、<https：// www。rfc-editor.org/info/rfc8609>。
[RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, <https://www.rfc-editor.org/info/rfc8930>.
[RFC8930] Watteyne、T.、Ed。、Thubert、P.、Ed。、およびC. Bormann、「マルチホップIPv6ネットワーク上での6lowpanフラグメントの転送」、RFC 8930、DOI 10.17487 / RFC8930、2020年11月、<https://www.rfc-editor.org/info/rfc8930>。
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery", RFC 8931, DOI 10.17487/RFC8931, November 2020, <https://www.rfc-editor.org/info/rfc8931>.
[RFC8931] Thubert、P.、ED。、「低電力無線パーソナルエリアネットワーク（6lowpan）選択フラグメントリカバリの「IPv6」、RFC 8931、DOI 10.17487 / RFC8931、2020年11月、<https：///www.rfc-編集者.org / info / rfc8931>。
[RIOT] Baccelli, E., Gündoğan, C., Hahm, O., Kietzmann, P., Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC., and M. Wählisch, "RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT", IEEE Internet of Things Journal Vol. 5, No. 6, p. 4428-4440, December 2018, <https://doi.org/10.1109/JIOT.2018.2815038>.
[暴動] Baccelli、E.、Gündołan、C、Hahm、O.、Kietzmann、P.、Lenders、MS、Petersen、H.、Sch Leiser、K.、Schmidt、TC、M.Wählisch、 "Riot：IOT内のローエンド埋め込みデバイス用のオープンソースオペレーティングシステム「物事のIEEEインターネットVol。5、No. 6、p。4428-4440、2018年12月、<https：//doi.org/10.1109/jiot.2018.2815038>。
[SFR-ICNLOWPAN] Lenders, M., Gündoğan, C., Schmidt, TC., and M. Wählisch, "Connecting the Dots: Selective Fragment Recovery in ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric Networking (ICN-2020) ACM DL, pp. 70-76, September 2020, <https://doi.org/10.1145/3405656.3418719>.
[SFR - ICNLOWPAN]レンダリング、M.、Gündoğan、C.、Schmidt、Tc。、およびM.Wählisch、「IcnlowPanのドットの接続：選択的フラグメント回復」、PROC。7番目のACMの収納情報中心ネットワーキング（ICN-2020）ACM DL、PP。70-76、2020年9月、<https：//doi.org/10.1145/3405656.3418719>。
[TLV-ENC-802.15.4] Mosko, M. and C. Tschudin, "CCN and NDN TLV encodings in 802.15.4 packets", January 2015, <https://datatracker.ietf.org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-2>.
[TLV-ENC-802.15.4] Mosko、M.およびC.Tschudin、「802.15.4パケットのCCNおよびNDN TLVエンコーディング」、2015年1月、<https：//datatracker.ietf.org/meeting/interim-2015-ICNRG-01 /材料/スライド-Interim-2015-ICNRG-1-2>。
[WIRE-FORMAT-CONSID] Wang, G., Tschudin, C., and R. Ravindran, "CCN/NDN Protocol Wire Format and Functionality Considerations", January 2015, <https://datatracker.ietf.org/meeting/ interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-8>.
[ワイヤフォーマット] wang、G.、Tschudin、C.、R. Ravindran、「CCN / NDNプロトコルワイヤーフォーマットと機能に関する考慮事項」、2015年1月、<https：//datatracker.ietf.org/meeting/INTERIM-2015-ICRG-01 /材料/スライド-Interim-2015-ICNRG-1-8>。
In the following, a theoretical evaluation is given to estimate the gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.
以下では、圧縮されていないCCNXおよびNDNメッセージと比較して、ICN LowPanの利得を推定するために理論的評価が与えられる。
We assume that n is the number of name components; comps_n denotes the sum of n name component lengths. We also assume that the length of each name component is lower than 16 bytes. The length of the content is given by clen. The lengths of TLV components are specific to the CCNx or NDN encoding and are outlined below.
Nは名前成分の数であると仮定します。COMPS_Nは、n個の名前成分長の合計を表します。また、各名前成分の長さが16バイトより低いと仮定します。コンテンツの長さはCLENによって与えられます。TLVコンポーネントの長さはCCNXまたはNDNエンコーディングに固有のものであり、以下に概説されています。
The NDN TLV encoding has variable-sized TLV fields. For simplicity, the 1-byte form of each TLV component is assumed. A typical TLV component therefore is of size 2 (Type field + Length field) + the actual value.
NDN TLVエンコーディングは可変サイズのTLVフィールドを持ちます。簡単にするために、各TLV成分の1バイトの形式が想定されます。したがって、典型的なTLVコンポーネントは、実際の値のサイズ2（フィールド長フィールド）のものです。
Figure 34 depicts the size requirements for a basic, uncompressed NDN Interest containing a CanBePrefix TLV, a MustBeFresh TLV, an InterestLifetime TLV set to 4 seconds, and a HopLimit TLV set to 6. Numbers below represent the amount of bytes.
図34は、CANBEEPREFIX TLV、必需品TLV、InterialLifeTime TLV、4秒に設定されているHopLimit TLVを含む基本的で圧縮されていないNDN関心のサイズ要件を示し、以下の数字を表す。
------------------------------------,
Interest TLV = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' = 21 + 2n + comps_n
CanBePrefix = 2 |
MustBeFresh = 2 |
Nonce = 6 |
InterestLifetime = 4 |
HopLimit = 3 |
------------------------------------'
Figure 34: Estimated Size of an Uncompressed NDN Interest
図34：非圧縮NDNの関心の推定サイズ
Figure 35 depicts the size requirements after compression.
図35は、圧縮後のサイズ要件を示しています。
------------------------------------,
Dispatch Page Switch = 1 |
NDN Interest Dispatch = 2 |
Interest TLV = 1 |
-----------------------, |
Name | |
NameComponents = n/2 + = 10 + n/2 + comps_n
| comps_n |
-----------------------' |
Nonce = 4 |
HopLimit = 1 |
InterestLifetime = 1 |
------------------------------------'
Figure 35: Estimated Size of a Compressed NDN Interest
図35：圧縮されたNDNの推定サイズ
The size difference is 11 + 1.5n bytes.
サイズの違いは11.5nバイトです。
For the name /DE/HH/HAW/BT7, the total size gain is 17 bytes, which is 43% of the uncompressed packet.
名前/ de / hh / haw / bt7の場合、総サイズのゲインは17バイトで、これは非圧縮パケットの43％です。
Figure 36 depicts the size requirements for a basic, uncompressed NDN Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is assumed, and the value is encoded using 1 byte. An HMACWithSha256 is assumed as a signature. The key locator is assumed to contain a Name TLV of length klen.
図36は、MetainFOとしての新鮮さ周期を含む基本的で圧縮されていないNDNデータのサイズ要件を示す。1分の新鮮さを想定し、値は1バイトを使用して符号化されます。HMACWithSha256が署名として想定されています。キーロケータは、長さKLENの名前TLVを含むと仮定されています。
------------------------------------,
Data TLV = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' |
---------------------, |
MetaInfo | |
FreshnessPeriod = 6 |
| = 53 + 2n + comps_n +
---------------------' | clen + klen
Content = 2 + clen |
---------------------, |
SignatureInfo | |
SignatureType | |
KeyLocator = 41 + klen |
SignatureValue | |
DigestSha256 | |
---------------------' |
------------------------------------'
Figure 36: Estimated Size of an Uncompressed NDN Data
図36：非圧縮NDNデータの推定サイズ
Figure 37 depicts the size requirements for the compressed version of the above Data packet.
図37は、上記のデータパケットの圧縮版のサイズ要件を示す。
------------------------------------,
Dispatch Page Switch = 1 |
NDN Data Dispatch = 2 |
-----------------------, |
Name | |
NameComponents = n/2 + |
| comps_n = 38 + n/2 + comps_n +
-----------------------' | clen + klen
Content = 1 + clen |
KeyLocator = 1 + klen |
DigestSha256 = 32 |
FreshnessPeriod = 1 |
------------------------------------'
Figure 37: Estimated Size of a Compressed NDN Data
図37：圧縮NDNデータの推定サイズ
The size difference is 15 + 1.5n bytes.
サイズの違いは15 1.5nバイトです。
For the name /DE/HH/HAW/BT7, the total size gain is 21 bytes.
名前/ de / hh / haw / bt7の場合、総サイズのゲインは21バイトです。
The CCNx TLV encoding defines a 2-byte encoding for Type and Length fields, summing up to 4 bytes in total without a value.
CCNX TLVエンコーディングは、値なしで合計4バイトまでのタイプフィールドの2バイトのエンコーディングを定義します。
Figure 38 depicts the size requirements for a basic, uncompressed CCNx Interest. No hop-by-hop TLVs are included, the protocol version is assumed to be 1, and the Reserved field is assumed to be 0. A KeyIdRestriction TLV with T_SHA-256 is included to limit the responses to Content Objects containing the specific key.
図38は、基本的な非圧縮CCNXの関心のためのサイズ要件を示す。ホップバイホップTLVが含まれていない、プロトコルバージョンは1と想定されており、予約フィールドは0となると想定されています。
------------------------------------,
Fixed Header = 8 |
Message = 4 |
---------------------, |
Name | 4 + = 56 + 4n + comps_n
NameSegments = 4n + |
| comps_n |
---------------------' |
KeyIdRestriction = 40 |
------------------------------------'
Figure 38: Estimated Size of an Uncompressed CCNx Interest
図38：非圧縮CCNXの関心の推定サイズ
Figure 39 depicts the size requirements after compression.
図39は、圧縮後のサイズ要件を示しています。
------------------------------------,
Dispatch Page Switch = 1 |
CCNx Interest Dispatch = 2 |
Fixed Header = 3 |
-----------------------, |
Name | = 38 + n/2 + comps_n
NameSegments = n/2 + |
| comps_n |
-----------------------' |
T_SHA-256 = 32 |
------------------------------------'
Figure 39: Estimated Size of a Compressed CCNx Interest
図39：圧縮CCNXの関心の推定サイズ
The size difference is 18 + 3.5n bytes.
サイズの違いは18 3.5nバイトです。
For the name /DE/HH/HAW/BT7, the size is reduced by 53 bytes, which is 53% of the uncompressed packet.
名前/ de / hh / haw / bt7の場合、サイズは53バイト減少し、これは非圧縮パケットの53％です。
Figure 40 depicts the size requirements for a basic, uncompressed CCNx Content Object containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signature time, and a hash of the shared secret key. In the fixed header, the protocol version is assumed to be 1 and the Reserved field is assumed to be 0
図40は、ExpiryTimeメッセージTLV、HMAC_SHA-256シグネチャ、シグネチャタイム、およびShared Secretキーのハッシュを含む基本的な非圧縮CCNXコンテンツオブジェクトのサイズ要件を示しています。固定ヘッダでは、プロトコルバージョンは1と想定され、予約フィールドは0とされます。
------------------------------------,
Fixed Header = 8 |
Message = 4 |
---------------------, |
Name | 4 + |
NameSegments = 4n + |
| comps_n |
---------------------' |
ExpiryTime = 12 = 124 + 4n + comps_n + clen
Payload = 4 + clen |
---------------------, |
ValidationAlgorithm | |
T_HMAC-256 = 56 |
KeyID | |
SignatureTime | |
---------------------' |
ValidationPayload = 36 |
------------------------------------'
Figure 40: Estimated Size of an Uncompressed CCNx Content Object
図40：非圧縮CCNXコンテンツオブジェクトの推定サイズ
Figure 41 depicts the size requirements for a basic, compressed CCNx Data.
図41は、基本的な圧縮されたCCNXデータのサイズ要件を示しています。
------------------------------------,
Dispatch Page Switch = 1 |
CCNx Content Dispatch = 3 |
Fixed Header = 2 |
-----------------------, |
Name | |
NameSegments = n/2 + |
| comps_n = 89 + n/2 + comps_n + clen
-----------------------' |
ExpiryTime = 8 |
Payload = 1 + clen |
T_HMAC-SHA256 = 32 |
SignatureTime = 8 |
ValidationPayload = 34 |
------------------------------------'
Figure 41: Estimated Size of a Compressed CCNx Data Object
図41：圧縮されたCCNXデータオブジェクトの推定サイズ
The size difference is 35 + 3.5n bytes.
サイズの違いは35 3.5 nバイトです。
For the name /DE/HH/HAW/BT7, the size is reduced by 70 bytes, which is 40% of the uncompressed packet containing a 4-byte payload.
名前/ de / hh / haw / bt7の場合、サイズは70バイト減少します。これは、4バイトのペイロードを含む非圧縮パケットの40％です。
Acknowledgments
謝辞
This work was stimulated by fruitful discussions in the ICNRG and the communities of RIOT and CCNlite. We would like to thank all active members for constructive thoughts and feedback. In particular, the authors would like to thank (in alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, Colin Perkins, and Junxiao Shi. The hop-wise stateful name compression was brought up in a discussion by Dave Oran, which is gratefully acknowledged. Larger parts of this work are inspired by [RFC4944] and [RFC6282]. Special mention goes to Mark Mosko, as well as G.Q. Wang and Ravi Ravindran, as their previous work in [TLV-ENC-802.15.4] and [WIRE-FORMAT-CONSID] provided a good base for our discussions on stateless header compression mechanisms. Many thanks also to Carsten Bormann and Lars Eggert, who contributed in-depth comments during the IRSG review. This work was supported in part by the German Federal Ministry of Research and Education within the projects I3 and RAPstore.
この作品は、ICNRGおよび暴動とCCNLiteの地域社会における実りある議論によって刺激されました。建設的な考えやフィードバックのために活動的なすべてのメンバーに感謝します。特に、著者らは（アルファベット順）Peter Kietzmann、Dirk Kutscher、Martine Lenders、Colin Perkins、およびJunxiao Shiに感謝します。飛び越しのステートフルな名前の圧縮はDave Oranによって議論で育てられました。これは感謝しています。この作品の大部分は[RFC4944]と[RFC6282]に触発されています。Mark Mosko、G.Qの特別に言及しています。[TLV-ENC-802.15.4]の以前の作業として、WangとRavi Ravindranと[Wire-Format-Sonsid]は、ステートレスヘッダー圧縮メカニズムに関する私たちの議論に良い基盤を提供しました。IRSGレビュー中に詳細なコメントを寄稿したBormannとLars Eggertをカースティンしてくれてありがとう。この作品は、プロジェクトI3とRapstore内のドイツ連邦研究教育省によって支えられました。
Authors' Addresses
著者の住所
Cenk Gündoğan HAW Hamburg Berliner Tor 7 D-20099 Hamburg Germany
CenkGündoğanHaw Hamburg Berliner Tor 7 D-20099ハンブルクドイツ
Phone: +4940428758067
Email: cenk.guendogan@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/cenk-gundogan
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 D-20099 Hamburg Germany
Thomas C. Schmidt Haw Hamburg Berliner Tor 7 D-20099ハンブルクドイツ
Email: t.schmidt@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/schmidt
Matthias Wählisch link-lab & FU Berlin Hoenower Str. 35 D-10318 Berlin Germany
MatthiasWählischLink-Lab＆Fu Berlin Hoenower Str。35 D-10318ベルリンドイツ
Email: mw@link-lab.net
URI: https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/
waehlisch.html
Christopher Scherb University of Applied Sciences and Arts Northwestern Switzerland Peter Merian-Str. 86 CH-4002 Basel Switzerland
クリストファー・シェルブ応用科学大学北西部スイスPeter Merian-str。86 CH-4002バーゼルスイス
Email: christopher.scherb@fhnw.ch
Claudio Marxer University of Basel Spiegelgasse 1 CH-4051 Basel Switzerland
Claudio Marxer Basel Spiegelgasse 1 CH-4051バーゼルスイス
Email: claudio.marxer@unibas.ch
Christian Tschudin University of Basel Spiegelgasse 1 CH-4051 Basel Switzerland
Christian Tschudin Basel Spiegelgasse 1 CH-4051バーゼルスイス
Email: christian.tschudin@unibas.ch