[要約] RFC 9273は、CCNx/NDNにおけるネットワークコーディングの研究成果と技術的考慮事項、課題をまとめたものであり、NWCRGとICNRGの成果です。
Internet Research Task Force (IRTF) K. Matsuzono
Request for Comments: 9273 H. Asaeda
Category: Informational NICT
ISSN: 2070-1721 C. Westphal
Huawei
August 2022
Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges
コンテンツ中心のネットワーキング /名前のデータネットワーキングのネットワークコーディング：考慮事項と課題
Abstract
概要
This document describes the current research outcomes in Network Coding (NC) for Content-Centric Networking (CCNx) / Named Data Networking (NDN) and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG).
このドキュメントでは、コンテンツ中心のネットワーキング（CCNX） /名前のデータネットワーキング（NDN）のネットワークコーディング（NC）の現在の研究結果について説明し、CCNX / NDNでNCを適用するための技術的な考慮事項と潜在的な課題を明確にします。このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）と情報中心のネットワーキング研究グループ（ICNRG）のコーディングの製品です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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 Coding for Efficient Network Communications 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/rfc9273.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9273で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Definitions Related to NC
2.2. Definitions Related to CCNx/NDN
3. CCNx/NDN Basics
4. NC Basics
5. Advantages of NC and CCNx/NDN
6. Technical Considerations
6.1. Content Naming
6.1.1. Unique Naming for NC Packets
6.1.2. Nonunique Naming for NC Packets
6.2. Transport
6.2.1. Scope of NC
6.2.2. Consumer Operation
6.2.3. Forwarder Operation
6.2.4. Producer Operation
6.2.5. Backward Compatibility
6.3. In-Network Caching
6.4. Seamless Consumer Mobility
7. Challenges
7.1. Adoption of Convolutional Coding
7.2. Rate and Congestion Control
7.3. Security
7.4. Routing Scalability
8. IANA Considerations
9. Security Considerations
10. Informative References
Acknowledgments
Authors' Addresses
Information-Centric Networking (ICN), in general, and Content-Centric Networking (CCNx) [1] or Named Data Networking (NDN) [2], in particular, have emerged as a novel communication paradigm that advocates for the retrieval of data based on their names. This paradigm pushes content awareness into the network layer. It is expected to enable consumers to obtain the content they desire in a straightforward and efficient manner from the heterogenous networks they may be connected to. The CCNx/NDN architecture has introduced innovative ideas and has stimulated research in a variety of areas, such as in-network caching, name-based routing, multipath transport, and content security. One key benefit of requesting content by name is that it eliminates the requirement to establish a session between the client and a specific server, and the content can thereby be retrieved from multiple sources.
情報中心のネットワーキング（ICN）、一般に、コンテンツ中心のネットワーキング（CCNX）[1]または名前付きデータネットワーキング（NDN）[2]は、データの取得を提唱する新しいコミュニケーションパラダイムとして浮上しています。彼らの名前に基づいています。このパラダイムは、コンテンツの認識をネットワークレイヤーに押し込みます。消費者が、接続される可能性のある異種ネットワークから、望むコンテンツを簡単かつ効率的な方法で取得できるようになることが期待されています。CCNX/NDNアーキテクチャは、革新的なアイデアを導入し、ネットワーク内キャッシュ、ネームベースのルーティング、マルチパストランスポート、コンテンツセキュリティなど、さまざまな分野での研究を刺激しました。名前でコンテンツをリクエストする重要な利点の1つは、クライアントと特定のサーバー間のセッションを確立するための要件を排除することであり、コンテンツを複数のソースから取得できることです。
In parallel, there has been a growing interest in both academia and industry for better understanding the fundamental aspects of Network Coding (NC) toward enhancing key system performance metrics, such as data throughput, robustness and reduction in the required number of transmissions through connected networks, and redundant transmission on broadcast or point-to-multipoint connections. NC is a technique that is typically used for encoding packets to recover from lost source packets at the receiver and for effectively obtaining the desired information in a fully distributed manner. In addition, in terms of security aspects, NC can be managed using a practical security scheme that deals with pollution attacks [3] and can be utilized for preventing eavesdroppers from obtaining meaningful information [4] or protecting a wireless video stream while retaining the NC benefits [5] [6].
並行して、データスループット、堅牢性、接続されたネットワークを介した必要な数の削減など、主要なシステムパフォーマンスメトリックを強化するためのネットワークコーディング（NC）の基本的側面をよりよく理解するために、学界と業界の両方に関心が高まっています。、およびブロードキャストまたはポイントツーマルチポイント接続での冗長送信。NCは、通常、受信機の失われたソースパケットから回復し、完全に分散した方法で目的の情報を効果的に取得するためにパケットをエンコードするために使用される手法です。さらに、セキュリティの側面の観点から、NCは汚染攻撃を扱う実用的なセキュリティスキームを使用して管理できます[3]、盗聴者が意味のある情報を取得しないようにし[4]、NCを保持しながらワイヤレスビデオストリームの保護を防ぐことができます。利点[5] [6]。
From the perspective of the NC transport mechanism, NC can be divided into two major categories: coherent NC and noncoherent NC [7] [8]. In coherent NC, the source and destination nodes know the exact network topology and the coding operations available at intermediate nodes. When multiple consumers are attempting to receive the same content, such as live video streaming, coherent NC could enable optimal throughput by sending the content flow over the constructed optimal multicast trees [9]. However, it requires a fully adjustable and specific routing mechanism and a large computational capacity for central coordination. In the case of noncoherent NC, which often uses Random Linear Coding (RLC), it is not necessary to know the network topology nor the intermediate coding operations [10]. As noncoherent NC works in a completely independent and decentralized manner, this approach is more feasible in terms of eliminating such a central coordination.
NC輸送メカニズムの観点から見ると、NCはコヒーレントNCと非コヒーレントNC [7] [8]の2つの主要なカテゴリに分けることができます。コヒーレントNCでは、ソースと宛先ノードは、正確なネットワークトポロジと中間ノードで利用可能なコーディング操作を知っています。ライブビデオストリーミングなど、複数の消費者が同じコンテンツを受け取ろうとしている場合、コヒーレントNCは、構築された最適なマルチキャストツリーにコンテンツフローを送信することにより、最適なスループットを可能にする可能性があります[9]。ただし、完全に調整可能な特定のルーティングメカニズムと、中央調整のための大きな計算能力が必要です。しばしばランダム線形コーディング（RLC）を使用する非コヒーレントNCの場合、ネットワークトポロジまたは中間コーディング操作を知る必要はありません[10]。非コヒーレントNCは完全に独立して分散化された方法で機能するため、このアプローチは、このような中心的な調整を排除するという点でより実現可能です。
NC combines multiple packets together with parts of the same content and may do this at the source and/or at other nodes in the network. Network coded packets are not associated with a specific server, as they may have been combined within the network. As NC is focused on what information should be encoded in a network packet instead of the specific host at which it has been generated, it is in line with the architecture of the CCNx/NDN core networking layer. NC allows for recovery of missing packets by encoding the information across several packets. ICN is synergistic with NC, as it allows for caching of data packets throughout the network. In a typical network that uses NC, the sender must transmit enough packets to retrieve the original data. ICN offers an opportunity to retrieve network-coded packets directly from caches in the network, making the combination of ICN and NC particularly effective. In fact, NC has already been implemented for information/content dissemination [11] [12] [13]. Montpetit et al. first suggested that NC techniques be exploited to enhance key aspects of system performance in ICN [14]. Although CCNx/NDN excels to exploit the benefits of NC (as described in Section 5), some technical considerations are needed to combine NC and CCNx/NDN owing to the unique features of CCNx/NDN (as described in Section 6).
NCは、複数のパケットと同じコンテンツの一部を組み合わせており、ソースやネットワーク内の他のノードでこれを行うことがあります。ネットワークコード化されたパケットは、ネットワーク内で結合されている可能性があるため、特定のサーバーに関連付けられていません。 NCは、生成された特定のホストではなく、ネットワークパケットでエンコードする情報に焦点を当てているため、CCNX/NDNコアネットワーキングレイヤーのアーキテクチャに沿っています。 NCは、いくつかのパケットを介して情報をエンコードすることにより、欠落しているパケットの回復を可能にします。 ICNは、ネットワーク全体のデータパケットのキャッシュを可能にするため、NCと相乗的です。 NCを使用する典型的なネットワークでは、送信者は元のデータを取得するのに十分なパケットを送信する必要があります。 ICNは、ネットワーク内のキャッシュからネットワークコード化されたパケットを直接取得する機会を提供し、ICNとNCの組み合わせを特に効果的にします。実際、NCはすでに情報/内容の普及のために実装されています[11] [12] [13]。 Montpetit et al。最初に、ICNのシステムパフォーマンスの重要な側面を強化するために、NC技術を悪用することを示唆しました[14]。 CCNX/NDNはNCの利点を活用することに優れていますが（セクション5で説明されているように）、CCNX/NDNのユニークな機能（セクション6で説明されている）のために、NCとCCNX/NDNを組み合わせるためにいくつかの技術的な考慮事項が必要です。
In this document, we consider how NC can be applied to the CCNx/NDN architecture and describe the technical considerations and potential challenges for making CCNx/NDN-based communications better using the NC technology. It should be noted that the presentation of specific solutions (e.g., NC optimization methods) for enhancing CCNx/NDN performance metrics by exploiting NC is outside the scope of this document.
このドキュメントでは、NCをCCNX/NDNアーキテクチャに適用する方法を検討し、NCテクノロジーを使用してCCNX/NDNベースの通信をより良くするための技術的な考慮事項と潜在的な課題を説明します。NCを悪用することにより、CCNX/NDNパフォーマンスメトリックを強化するための特定のソリューション（NC最適化方法など）の提示は、このドキュメントの範囲外であることに注意してください。
This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG). This document was read and reviewed by all the active research group members. It is not an IETF product and is not a standard.
このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）と情報中心のネットワーキング研究グループ（ICNRG）のコーディングの共同作業とコンセンサスを表しています。この文書は、すべてのアクティブな研究グループメンバーによって読まれ、レビューされました。IETF製品ではなく、標準でもありません。
This section provides the terms related to NC used in this document, which are defined in RFC 8406 [15] and produced by the NWCRG.
このセクションでは、このドキュメントで使用されるNCに関連する用語を示します。このドキュメントは、RFC 8406 [15]で定義され、NWCRGによって作成されます。
Source Packet: A packet originating from the source that contributes to one or more source symbols. The source symbol is a unit of data originating from the source that is used as input to encoding operations. For instance, a Real-time Transport Protocol (RTP) packet as a whole can constitute a source symbol. In other situations (e.g., to address variable size packets), a single RTP packet may contribute to various source symbols.
ソースパケット：1つ以上のソースシンボルに寄与するソースから発信されるパケット。ソースシンボルは、エンコード操作への入力として使用されるソースから発信されるデータの単位です。たとえば、リアルタイムトランスポートプロトコル（RTP）パケットは、ソースシンボルを構成できます。他の状況（たとえば、可変サイズパケットに対処するため）では、単一のRTPパケットがさまざまなソースシンボルに寄与する場合があります。
Repair Packet: A packet containing one or more coded symbols (also called repair symbol). The coded symbol or repair symbol is a unit of data that is the result of a coding operation, applied either to source symbols or (in case of recoding) source and/or coded symbols. When there is a single repair symbol per repair packet, a repair symbol corresponds to a repair packet.
修理パケット：1つ以上のコード化された記号（修理記号とも呼ばれます）を含むパケット。コード化されたシンボルまたは修理シンボルは、ソースシンボルまたは（再度の再確認の場合）ソースおよび/またはコード化されたシンボルのいずれかに適用されるコーディング操作の結果であるデータの単位です。修理パケットごとに単一の修理シンボルがある場合、修理シンボルは修理パケットに対応します。
Encoding versus Recoding versus Decoding: Encoding is an operation that takes source symbols as input and produces encoding symbols (source or coded symbols) as output. Recoding is an operation that takes encoding symbols as input and produces encoding symbols as output. Decoding is an operation that takes encoding symbols as input and produces source symbols as output.
エンコーディングとリコードとデコード：エンコードは、ソースシンボルを入力として取得し、エンコードシンボル（ソースまたはコード化されたシンボル）を出力として生成する操作です。Recodingは、エンコードシンボルを入力として取得し、エンコードシンボルを出力として生成する操作です。デコードは、エンコードシンボルを入力として取得し、ソースシンボルを出力として生成する操作です。
The terms regarding coding types are defined as follows:
コーディングタイプに関する用語は、次のように定義されています。
Random Linear Coding (RLC): A particular form of linear coding using a set of random coding coefficients. Linear coding performs a linear combination of a set of input symbols (i.e., source and/or coded symbols) using a given set of coefficients and results in a repair symbol.
ランダム線形コーディング（RLC）：ランダムコーディング係数のセットを使用した特定の形式の線形コーディング。線形コーディングは、特定の係数セットを使用して、入力記号のセット（つまり、ソースおよび/またはコード化された記号）の線形組み合わせを実行し、修復記号を作成します。
Block Coding: A coding technique wherein the input flow(s) must be first segmented into a sequence of blocks. Encoding and decoding are performed independently on a per-block basis.
ブロックコーディング：入力フローを最初にブロックのシーケンスにセグメント化する必要があるコーディング手法。エンコードとデコードは、ブロックごとに独立して実行されます。
Sliding Window Coding or Convolutional Coding: A general class of coding techniques that rely on a sliding encoding window. An encoding window is a set of source (and coded in the case of recoding) symbols used as input to the coding operations. The set of symbols change over time, as the encoding window slides over the input flow(s). This is an alternative solution to block coding.
スライドウィンドウコーディングまたは畳み込みコーディング：スライドエンコードウィンドウに依存する一般的なコーディング手法。エンコーディングウィンドウは、コード操作への入力として使用されるソースのセット（およびcoded coded of recoding of recodingの場合）のセットです。エンコードウィンドウが入力フローの上にスライドすると、シンボルのセットが時間とともに変化します。これは、コーディングをブロックするための代替ソリューションです。
Fixed or Elastic Sliding Window Coding: A coding technique that generates coded symbol(s) on the fly, from the set of source symbols present in the sliding encoding window at that time, usually by using linear coding. The sliding window may be either of fixed size or of variable size over time (also known as "Elastic Sliding Window"). For instance, the size may depend on acknowledgments sent by the receiver(s) for a particular source symbol or source packet (received, decoded, or decodable).
固定または弾性スライディングウィンドウコーディング：通常、線形コーディングを使用して、その時点でスライディングエンコードウィンドウに存在するソース記号のセットから、その場でコード化されたシンボルを生成するコーディング手法。スライディングウィンドウは、固定サイズまたは時間の経過とともに可変サイズのいずれかである場合があります（「弾性スライドウィンドウ」とも呼ばれます）。たとえば、サイズは、特定のソースシンボルまたはソースパケット（受信、デコード、またはデコード可能）に対して受信機によって送信された確認に依存する場合があります。
The terms regarding low-level coding aspects are defined as follows:
低レベルのコーディングの側面に関する用語は、次のように定義されます。
Rank of the Linear System or Degrees of Freedom: At a receiver, the number of linearly independent equations of the linear system. It is also known as "Degrees of Freedom". The system may be of "full rank", wherein decoding is possible, or "partial rank", wherein only partial decoding is possible.
線形システムのランクまたは自由度：レシーバーでは、線形システムの線形独立方程式の数。「自由度」としても知られています。システムは「フルランク」であり、デコードが可能であるか、部分的なデコードのみが可能な「部分ランク」があります。
Generation or Block: With block codes, the set of source symbols of the input flow(s) that are logically grouped into a block before doing encoding.
生成またはブロック：ブロックコードを使用すると、エンコードを行う前に論理的にブロックにグループ化された入力フローのソース記号のセット。
Generation Size or Block Size: With block codes, the number of source symbols belonging to a block. It is equivalent to the number of source packets when there is a single source symbol per source packet.
生成サイズまたはブロックサイズ：ブロックコードでは、ブロックに属するソース記号の数。ソースパケットごとに単一のソースシンボルがある場合、ソースパケットの数に相当します。
Coding Coefficient: With linear coding, this is a coefficient in a certain finite field. This coefficient may be chosen in different ways: for instance, randomly, in a predefined table or using a predefined algorithm plus a seed.
コーディング係数：線形コーディングでは、これは特定の有限フィールドの係数です。この係数は、さまざまな方法で選択できます。たとえば、ランダムに、事前に定義されたテーブルで、または定義されたアルゴリズムとシードを使用します。
Coding Vector: A set of coding coefficients used to generate a certain coded symbol through linear coding.
コーディングベクトル：線形コーディングを介して特定のコード化されたシンボルを生成するために使用される一連のコーディング係数。
Finite Field: Finite fields, used in linear codes, have the desired property of having all elements (except zero) invertible for + and *, and no operation over any elements can result in an overflow or underflow. Examples of finite fields are prime fields {0..p^(m-1)}, where p is prime. Most used fields use p=2 and are called binary extension fields {0..2^(m-1)}, where m often equals 1, 4, or 8 for practical reasons.
有限フィールド：線形コードで使用される有限フィールドには、すべての要素（ゼロを除く）を反転可能にし、 *を持つという目的のプロパティがあり、要素を介した動作はオーバーフローまたはアンダーフローにつながる可能性があります。有限フィールドの例は、プライムフィールド{0..p^（m-1）}で、pはプライムです。ほとんどの使用済みフィールドはp = 2を使用し、バイナリ拡張フィールド{0..2^（m-1）}と呼ばれ、実際の理由でmは1、4、または8に等しいことがよくあります。
The terminology regarding CCNx/NDN used in this document is defined in RFC 8793 [16], which was produced by the ICNRG. They are consistent with the relevant documents ([17] [18]).
このドキュメントで使用されているCCNX/NDNに関する用語は、ICNRGによって生成されたRFC 8793 [16]で定義されています。それらは関連する文書と一致しています（[17] [18]）。
We briefly explain the key concepts of CCNx/NDN. In a CCNx/NDN network, there are two types of packets at the network level: interest and data packet (defined in Section 3.4 of [16]). The term "content object", which means a unit of content data, is an alias to data packet [16]. The ICN consumer (defined in Section 3.2 of [16]) requests a content object by sending an interest that carries the name of the data.
CCNX/NDNの重要な概念を簡単に説明します。CCNX/NDNネットワークでは、ネットワークレベルには2種類のパケットがあります：関心とデータパケット（[16]のセクション3.4で定義）。コンテンツデータの単位を意味する「コンテンツオブジェクト」という用語は、データパケットのエイリアスです[16]。[16]のセクション3.2で定義されているICNコンシューマー（[16]のセクション3.2で定義されている）は、データの名前を運ぶ利息を送信することにより、コンテンツオブジェクトを要求します。
Once an ICN forwarder (defined in Section 3.2 of [16]) receives an interest, it performs a series of lookups. First, it checks if it has a copy of the requested content object available in the cache storage, called Content Store (CS) (defined in Section 3.3 of [16]). If it does, it returns the data, and the transaction is considered to have been successfully completed.
[16]のセクション3.2で定義されているICNフォワーダー（[16]のセクション3.2で定義）が関心を抱くと、一連の検索を実行します。まず、コンテンツストア（CS）と呼ばれるキャッシュストレージで利用可能な要求されたコンテンツオブジェクトのコピーがあるかどうかを確認します（[16]のセクション3.3で定義）。もしそうなら、それはデータを返し、トランザクションは正常に完了したと見なされます。
If it does not have a copy of the requested content object in the CS, it performs a lookup of the Pending Interest Table (PIT) (defined in Section 3.3 of [16]) to check if there is already an outgoing interest for the same content object. If there is no such interest, then it creates an entry in the PIT that lists the name included in the interest and the interfaces from which it received the interest. This is later used to send the content object back, as interest packets do not carry a source field that identifies the consumer. If there is already a PIT entry for this name, it is updated with the incoming interface of this new interest, and the interest is discarded.
CSに要求されたコンテンツオブジェクトのコピーがない場合、保留中の関心テーブル（PIT）（[16]のセクション3.3で定義）の検索を実行して、同じものに対してすでに発信されているかどうかを確認します。コンテンツオブジェクト。そのような利益がない場合、それは、関心に含まれる名前と利息を受け取ったインターフェイスをリストするピットにエントリを作成します。これは後でコンテンツオブジェクトを送信するために使用されます。興味のあるパケットには消費者を識別するソースフィールドが含まれていないためです。この名前のピットエントリが既にある場合、この新しい関心の着信インターフェイスで更新され、関心が捨てられます。
After the PIT lookup, the interest undergoes a Forwarding Information Base (FIB) (defined in Section 3.3 of [16]) lookup for selecting an outgoing interface. The FIB lists name prefixes and their corresponding forwarding interfaces in order to send the interest toward a forwarder that possesses a copy of the requested data.
ピットルックアップの後、関心は転送情報ベース（FIB）（[16]のセクション3.3で定義されている）を受け取ります。FIBには、要求されたデータのコピーを所有しているフォワーダーに利息を送信するために、名前のプレフィックスと対応する転送インターフェイスをリストします。
Once a copy of the data is retrieved, it is sent back to the consumer(s) using the trail of PIT entries; forwarders remove the PIT state every time that an interest is satisfied and may store the data in their CS.
データのコピーが取得されると、ピットエントリのトレイルを使用して消費者に送り返されます。フォワーダーは、関心が満たされるたびにピット状態を削除し、データをCSに保存することができます。
Data packets carry some information for verifying data integrity and origin authentication and, in particular, that the data is indeed that which corresponds to the name [19]. This is necessary because authentication of the object is crucial in CCNx/NDN. However, this step is optional at forwarders in order to speed up the processing.
データパケットには、データの整合性と起源の認証を検証するための情報、特にデータが実際に名前[19]に対応するものであることが含まれています。これは、CCNX/NDNではオブジェクトの認証が重要であるため、必要です。ただし、このステップは、処理を高速化するために、フォワーダーではオプションです。
The key aspect of CCNx/NDN is that the consumer of the content does not establish a session with a specific server. Indeed, the forwarder or producer (defined in Section 3.2 of [16]) that returns the content object is not aware of the network location of the consumer, and the consumer is not aware of the network location of the node that provides the content. This, in theory, allows the interests to follow different paths within a network or even to be sent over completely different networks.
CCNX/NDNの重要な側面は、コンテンツの消費者が特定のサーバーでセッションを確立しないことです。実際、コンテンツオブジェクトを返すフォワーダーまたはプロデューサー（[16]のセクション3.2で定義）は、消費者のネットワークの場所を認識しておらず、消費者はコンテンツを提供するノードのネットワーク位置を認識していません。これにより、理論的には、関心がネットワーク内の異なるパスをたどるか、まったく異なるネットワーク上で送信することさえできます。
While the forwarding node simply relays received data packets in conventional IP communication networks, NC allows the node to combine some data packets that are already received into one or several output packets to be sent. In this section, we simply describe the basic operations of NC. Herein, we focus on RLC in a block coding manner that is well known as a major coding technique.
転送ノードは、従来のIP通信ネットワークで受信したデータパケットを単にリレーするだけでなく、NCを使用すると、ノードは既に受信されているいくつかのデータパケットを1つまたは複数の出力パケットに組み合わせて送信できます。このセクションでは、NCの基本操作について簡単に説明します。ここでは、主要なコーディング手法としてよく知られているブロックコーディング方法でRLCに焦点を当てています。
For simplicity, let us consider an example case of end-to-end coding wherein a producer and consumer respectively perform encoding and decoding for a content object. This end-to-end coding is regarded as a special case of NC. The producer splits the content into several blocks called generations. Encoding and decoding are performed independently on a per-block (per-generation) basis. Let us assume that each generation consists of K original source packets of the same size. When the packets do not have the same size, zero padding is added. In order to generate one repair packet within a certain generation, the producer linearly combines K of the original source packets, where additions and multiplications are performed using a coding vector consisting of K coding coefficients that are randomly selected in a certain finite field. The producer may respond to interests to send the corresponding source packets and repair packets in the content flow (called systematic coding), where the repair packets are typically used for recovering lost source packets.
簡単にするために、プロデューサーと消費者がそれぞれコンテンツオブジェクトのエンコードとデコードを実行するエンドツーエンドコーディングの例を考えてみましょう。このエンドツーエンドのコーディングは、NCの特別なケースと見なされています。プロデューサーは、コンテンツを世代と呼ばれるいくつかのブロックに分割します。エンコードとデコードは、ブロックごと（世代ごと）ベースで独立して実行されます。各世代は、同じサイズのK元のソースパケットで構成されていると仮定しましょう。パケットに同じサイズがない場合、ゼロパディングが追加されます。特定の世代内で1つの修理パケットを生成するために、生産者は元のソースパケットのKを直線的に組み合わせます。ここでは、特定の有限フィールドでランダムに選択されたKコーディング係数で構成されるコーディングベクトルを使用して追加と乗算が実行されます。プロデューサーは、対応するソースパケットを送信し、コンテンツフロー（系統的コーディングと呼ばれる）の修理パケットを送信するために興味に応答する場合があります。通常、修理パケットは失われたソースパケットの回復に使用されます。
Repair packets can also be used for performing encoding. If the forwarding nodes know each coding vector and generation identifier (hereinafter referred to as generation ID) of the received repair packets, they may perform an encoding operation (called recoding), which is the most distinctive feature of NC compared to other coding techniques.
修理パケットは、エンコードの実行にも使用できます。転送ノードが、受信した修理パケットの各コーディングベクトルおよび生成識別子（以下では生成IDと呼ばれる）を知っている場合、他のコーディング技術と比較してNCの最も特徴的な機能であるエンコード操作（レコードと呼ばれる）を実行できます。
At the consumer, decoding is performed by solving a set of linear equations that are represented by the coding vectors of the received source and repair packets (possibly only repair packets) within a certain generation. In order to obtain all the source packets, the consumer requires K linearly independent equations. In other words, the consumer must receive at least K linearly independent data packets (called innovative packets). As receiving a linearly dependent data packet is not useful for decoding, recoding should generate and provide innovative packets. One of the major benefits of RLC is that, even for a small-sized finite field (e.g., q=2^8), the probability of generating linearly dependent packets is negligible [9].
消費者では、特定の世代内の受信ソースおよび修理パケット（おそらく修理パケットのみ）のコーディングベクトルによって表される一連の線形方程式を解くことにより、デコードが実行されます。すべてのソースパケットを取得するために、消費者はk線形独立方程式を必要とします。言い換えれば、消費者は少なくともk線形独立したデータパケット（革新的なパケットと呼ばれる）を受け取る必要があります。直線的に依存するデータパケットを受信することはデコードには役に立たないため、革新的なパケットを生成して提供する必要があります。RLCの主な利点の1つは、小型の有限フィールド（q = 2^8など）であっても、線形依存パケットを生成する確率が無視できることです[9]。
Combining NC and CCNx/NDN can contribute to effective large-scale content/information dissemination. They individually provide similar benefits, such as throughput/capacity gain and robustness enhancement. The difference between their approaches is that the former considers content flow as algebraic information that is to be combined [7], while the latter focuses on the content/information itself at the networking layer. Because these approaches are complementary and their combination would be advantageous, it is natural to combine them.
NCとCCNX/NDNを組み合わせることで、効果的な大規模なコンテンツ/情報普及に貢献できます。スループット/容量のゲインや堅牢性の向上など、同様の利点を個別に提供します。彼らのアプローチの違いは、前者がコンテンツの流れを組み合わせた代数情報と見なしていることです[7]、後者はネットワーキング層のコンテンツ/情報自体に焦点を当てています。これらのアプローチは補完的であり、それらの組み合わせは有利であるため、それらを組み合わせるのは自然です。
The name-based communication in CCNx/NDN enables consumers to obtain requested content objects without establishing and maintaining end-to-end communication channels between nodes. This feature facilitates the exploitation of the in-network cache and multipath/ multisource retrieval and also supports consumer mobility without the need for updating the location information/identifier during handover [1]. Furthermore, the name-based communication intrinsically supports multicast communication because identical interests are aggregated at the forwarders.
CCNX/NDNでの名前ベースの通信により、消費者はノード間でエンドツーエンドの通信チャネルを確立および維持することなく、要求されたコンテンツオブジェクトを取得できます。この機能は、ネットワーク内キャッシュとマルチパス/マルチソースの検索の利用を促進し、ハンドオーバー中に位置情報/識別子を更新する必要なく、消費者のモビリティをサポートします[1]。さらに、名前ベースのコミュニケーションは、同じ関心がフォワーダーに集約されているため、マルチキャストコミュニケーションを本質的にサポートしています。
NC can enable the CCNx/NDN transport system to effectively distribute and cache the data associated with multipath data retrieval [14]. Exploiting multipath data retrieval and in-network caching with NC contributes to not only improving the cache hit rate but also expanding the anonymity set of each consumer (the set of potential routers that can serve a given consumer) [20]. The expansion makes it difficult for adversaries to infer the content consumed by others and thus contributes to improving cache privacy. Others also have introduced some use cases of the application of NC in CCNx/NDN, such as the cases of content dissemination with in-network caching [21] [22] [23], seamless consumer mobility [24] [25], and low-latency low-loss video streaming [26]. In this context, it is well worth considering NC integration in CCNx/NDN.
NCは、CCNX/NDNトランスポートシステムがマルチパスデータ取得に関連するデータを効果的に配布およびキャッシュできるようにすることができます[14]。NCを使用したマルチパスデータの検索とネットワーク内キャッシュを利用すると、キャッシュヒット率の改善だけでなく、各消費者の匿名性セット（特定の消費者にサービスを提供できる潜在的なルーターのセット）の拡大にも貢献します[20]。この拡張により、敵は他の人が消費するコンテンツを推測することを困難にし、したがって、キャッシュプライバシーの改善に貢献します。また、ネットワーク内キャッシュとのコンテンツ普及のケース[21] [22] [23]、シームレスな消費者モビリティ[24] [25]、およびCCNX/NDNでのNCの適用のいくつかの使用ケースも導入しています。低遅延低下ビデオストリーミング[26]。これに関連して、CCNX/NDNでのNC統合を検討する価値があります。
This section presents the considerations for CCNx/NDN with NC in terms of network architecture and protocol. This document focuses on NC when employed in a block coding manner.
このセクションでは、ネットワークアーキテクチャとプロトコルの観点から、CCNX/NDNのNCとの考慮事項について説明します。このドキュメントは、ブロックコーディング方法で使用される場合、NCに焦点を当てています。
Naming content objects is as important for CCNx/NDN as naming hosts is in the current-day Internet [19]. In this section, two possible naming schemes are presented.
コンテンツオブジェクトの命名は、namingホストが現在のインターネットにあるのと同じくらいCCNX/NDNにとって重要です[19]。このセクションでは、2つの命名スキームを提示します。
Each source and repair packet (hereinafter referred to as NC packet) may have a unique name, as each original content object has in CCNx/ NDN and as PIT and CS operations typically require a unique name for identifying the NC packet. As a method of naming an NC packet that takes into account the feature of block coding, the coding vector and the generation ID can be used as a part of the content object name. As in [21], when the generation ID is "g-id", generation size is 4, and coding vector is (1,0,0,0), the name could be /CCNx.com/video-A/ g-id/1000. Some other identifiers and/or parameters related to the encoding scheme can also be used as name components. For instance, the encoding ID specifying the coding scheme may be used with "enc-id", such as /CCNx.com/video-A/enc-id/g-id/1000, as defined in the FEC Framework (FECFRAME) [27]. This naming scheme is simple and can support the delivery of NC packets with exactly the same operations in the PIT/CS as those for the content objects.
各ソースと修理パケット（以下NCパケットと呼ばれる）は、各元のコンテンツオブジェクトがCCNX/ NDNにあるため、PITおよびCS操作がNCパケットを識別するために一意の名前を必要とするため、一意の名前を持つ場合があります。ブロックコーディングの特徴を考慮したNCパケットに名前を付ける方法として、コーディングベクトルと生成IDはコンテンツオブジェクト名の一部として使用できます。[21]のように、生成IDが「g-id」の場合、生成サイズは4、コーディングベクトルは（1,0,0,0）です。-id/1000。エンコードスキームに関連する他のいくつかの識別子および/またはパラメーターは、名前コンポーネントとしても使用できます。たとえば、コーディングスキームを指定するエンコードIDは、FECフレームワーク（FECFRAME）で定義されているように、/ccnx.com/video-a/enc-id/g-id/1000などの「enc-id」で使用できます。[27]。この命名スキームはシンプルで、コンテンツオブジェクトの操作とまったく同じ操作でNCパケットの配信をサポートできます。
If a content-naming schema, such as the one presented above, is used, an interest requesting an NC packet may have the full name including a generation ID and coding vector (/CCNx.com/video-A/g-id/1000) or only the name prefix including only a generation ID (/CCNx.com/video-A/g-id). In the former case, exact name matching to the PIT is simply performed at data forwarders (as in CCNx/NDN). The consumer is able to specify and retrieve an innovative packet necessary for the consumer to decode successfully. This could shift the generation of the coding vector from the data forwarder onto the consumer.
上記のようなコンテンツネーミングスキーマが使用されている場合、NCパケットを要求する関心には、生成IDやコーディングベクター（/ccnx.com/video-a/g-id/1000を含むフルネームがあります。）または、生成ID（/ccnx.com/video-a/g-id）のみを含む名前のプレフィックスのみ。前者の場合、ピットに一致する正確な名前は、データフォワーダー（CCNX/NDNのように）で単純に実行されます。消費者は、消費者が正常にデコードするために必要な革新的なパケットを指定および取得することができます。これにより、コーディングベクトルの生成がデータ転送者から消費者にシフトする可能性があります。
In the latter case, partial name matching is required at the data forwarders. As the interest with only the prefix name matches any NC packet with the same prefix, the consumer could immediately obtain an NC packet from a nearby CS (in-network cache) without knowing the coding vectors of the cached NC packets in advance. In the case wherein NC packets in transit are modified by in-network recoding performed at forwarders, the consumer could also receive the modified NC packets. However, in contrast to the former case, the consumer may fail to obtain sufficient degrees of freedom (see Section 6.2.3). To address this issue, a new TLV type in an interest message may be required for specifying further coding information in order to limit the NC packets to be received. For instance, this is enabled by specifying the coding vectors of innovative packets for the consumer (also called decoding matrix) as in [14]. This extension may incur an interest packet of significantly increased size, and it may thus be useful to use compression techniques for coding vectors [28] [29]. Without such coding information provided by the interest, the forwarder would be required to maintain some records regarding the interest packets that were satisfied previously (see Section 6.2.3).
後者の場合、データフォワーダーでは部分名の一致が必要です。プレフィックス名のみが同じプレフィックスを使用してNCパケットと一致するため、消費者は、キャッシュされたNCパケットのコーディングベクトルを事前に知らずに、近くのCS（ネットワーク内キャッシュ）から直ちにNCパケットを取得できます。転送中のNCパケットが転送中に実行されるネットワーク内の再調整により変更された場合、消費者は変更されたNCパケットを受信することもできます。ただし、前者のケースとは対照的に、消費者は十分な自由度を取得できない場合があります（セクション6.2.3を参照）。この問題に対処するために、NCパケットを受信するために、さらなるコーディング情報を指定するには、関心メッセージの新しいTLVタイプが必要になる場合があります。たとえば、これは、[14]のように、消費者向けの革新的なパケットのコーディングベクトル（デコードマトリックスとも呼ばれます）を指定することにより有効になります。この拡張機能は、大きく増加したサイズの関心パケットが発生する可能性があり、したがって、ベクターをコーディングするために圧縮技術を使用すると便利かもしれません[28] [29]。利息によって提供されるこのようなコーディング情報がなければ、フォワーダーは、以前に満たされた関心パケットに関する記録を維持する必要があります（セクション6.2.3を参照）。
An NC packet may have a name that indicates that it is an NC packet and move the coding information into a metadata field in the payload (i.e., the name includes the data type, source, or repair packet). This would not be beneficial for applications or services that may not need to understand the packet payload. Owing to the possibility that multiple NC packets may have the same name, some mechanism is required for the consumer to obtain innovative packets. As described in Section 6.3, a mechanism for managing the multiple innovative packets in the CS would also be required. In addition, extra computational overhead would be incurred when the payload is being encrypted.
NCパケットには、NCパケットであることを示す名前があり、コーディング情報をペイロード内のメタデータフィールドに移動します（つまり、名前にはデータ型、ソース、または修理パケットが含まれます）。これは、パケットペイロードを理解する必要がないかもしれないアプリケーションやサービスには有益ではありません。複数のNCパケットが同じ名前を持っている可能性があるため、消費者が革新的なパケットを取得するには、いくつかのメカニズムが必要です。セクション6.3で説明したように、CSで複数の革新的なパケットを管理するメカニズムも必要です。さらに、ペイロードが暗号化されているときに、追加の計算オーバーヘッドが発生します。
The pull-based request-response feature of CCNx/NDN is a fundamental principle of its transport layer; one interest retrieves, at most, one data packet. This means that a forwarder or producer cannot inject unrequested data packets on its own initiative. It is believed that it is important that this rule not be violated, as 1) it would open denial-of-service (DoS) attacks, 2) it invalidates existing congestion control approaches following this rule, and 3) it would reduce the efficiency of existing consumer mobility approaches. Thus, the following basic operation should be considered for applying NC to CCNx/NDN. Nevertheless, such security considerations must be addressed if this rule were to be violated.
CCNX/NDNのプルベースの要求応答機能は、その輸送層の基本原則です。1つの関心が、せいぜい1つのデータパケットを取得します。これは、フォワーダーまたはプロデューサーが独自のイニシアチブに再リケストされていないデータパケットを注入できないことを意味します。この規則に違反しないことが重要であると考えられています。1）サービス拒否（DOS）攻撃を開くと、2）この規則に従って既存の混雑制御アプローチを無効にし、3）効率を低下させると考えられています。既存の消費者モビリティアプローチの。したがって、NCをCCNX/NDNに適用するために、次の基本操作を考慮する必要があります。それにもかかわらず、この規則に違反する場合、そのようなセキュリティ上の考慮事項に対処する必要があります。
An open question is whether a data forwarder can perform in-network recoding with data packets that are being received in transit or if only the data that matches an interest can be subject to NC operations. In the latter case, encoding or recoding is performed to generate the NC packet at any forwarder that is able to respond to the interest. This could occur when each NC packet has a unique name and interest has the full name. On the other hand, if interest has a partial name without any coding vector information or multiple NC packets have the same name, the former case may occur; recoding occurs anywhere in the network where it is possible to modify the received NC packet and forward it. As CCNx/NDN comprises mechanisms for ensuring the integrity of the data during transfer, in-network recoding introduces complexities in the network that needs consideration for the integrity mechanisms to still work. Similarly, in-network caching of NC packets at forwarders may be valuable; however, the forwarders would require some mechanisms to validate the NC packets (see Section 9).
未解決の質問は、データ転送者が輸送中に受信されているデータパケットでネットワーク内の再調整を実行できるかどうか、または利息と一致するデータのみがNC操作の対象となる可能性があるかどうかです。後者の場合、エンコーディングまたはリコードが実行され、利息に対応できるフォワーダーでNCパケットを生成します。これは、各NCパケットに一意の名前があり、興味がフルネームを持っている場合に発生する可能性があります。一方、利息にはコーディングベクトル情報がないか、複数のNCパケットが同じ名前がない場合、前者のケースが発生する可能性があります。復旧は、受信したNCパケットを変更して転送することができるネットワーク内のどこでも発生します。 CCNX/NDNは、転送中にデータの整合性を確保するためのメカニズムを構成するため、ネットワーク内の再編成は、ネットワークに、整合性メカニズムが機能するために検討する必要がある複雑さを導入します。同様に、フォワーダーでのNCパケットのネットワーク内キャッシュは価値があるかもしれません。ただし、フォワーダーは、NCパケットを検証するためにいくつかのメカニズムを必要とします（セクション9を参照）。
To obtain NC benefits (possibly associated with in-network caching), the consumer is required to issue interests that direct the forwarder (or producer) to respond with innovative packets if available. In the case where each NC packet may have a unique name (as described in Section 6.1), by issuing an interest specifying a unique name with g-id and the coding vector for an NC packet, the consumer could appropriately receive an innovative packet if it is available at some forwarders.
NCの利点（ネットワーク内のキャッシュに関連する可能性が高い）を取得するには、消費者は、先入れがよい場合は、フォワーダー（またはプロデューサー）に革新的なパケットで対応するよう指示する利息を発行する必要があります。各NCパケットが一意の名前を持つ場合（セクション6.1で説明されているように）、G-IDとNCパケットのコーディングベクトルを使用して一意の名前を指定する関心を発行することにより、消費者は革新的なパケットを適切に受け取ることができます。一部のフォワーダーで利用できます。
In order to specify the exact name of the NC packet to be retrieved, the consumer is required to know the valid naming scheme. From a practical viewpoint, it is desirable for the consumer application to automatically construct the right name components without depending on any application specifications. To this end, the consumer application may retrieve and refer to a manifest [17] that enumerates the content objects, including NC packets, or may use some coding scheme specifier as a name component to construct the name components of interests to request innovative packets.
取得するNCパケットの正確な名前を指定するには、消費者は有効な命名スキームを知る必要があります。実用的な観点からは、消費者アプリケーションがアプリケーションの仕様に依存せずに適切な名前コンポーネントを自動的に構築することが望ましいです。この目的のために、消費者アプリケーションは、NCパケットを含むコンテンツオブジェクトを列挙するマニフェスト[17]を取得して参照することができます。または、革新的なパケットを要求するために関心のある名前コンポーネントを構築するために、いくつかのコーディングスキーム指定子を名前コンポーネントとして使用する場合があります。
Conversely, the consumer without decoding capability (e.g., specific sensor node) may want to receive only the source packets. As described in Section 6.1, because the NC packet can have a name that is explicitly different from source packets, issuing interests for retrieving source packets is possible.
逆に、デコード機能（特定のセンサーノードなど）のない消費者は、ソースパケットのみを受信する必要があります。セクション6.1で説明したように、NCパケットにはソースパケットとは明示的に異なる名前があるため、ソースパケットを取得するための関心を発行することが可能です。
If the forwarder constantly responds to the incoming interests by returning non-innovative packets, the consumer(s) cannot decode and obtain the source packets. This issue could happen when 1) incoming interests for NC packets do not specify some coding parameters, such as the coding vectors to be used, and 2) the forwarder does not have a sufficient number of linearly independent NC packets (possibly in the CS) to use for recoding. In this case, the forwarder is required to determine whether or not it can generate innovative packets to be forwarded to the interface(s) at which the interests arrived. An approach to deal with this issue is that the forwarder maintains a tally of the interests for a specific name, generation ID, and the incoming interface(s) in order to record how many degrees of freedom have already been provided [21]. As such a scheme requires state management (and potentially timers) in forwarders, scalability and practicality must be considered. In addition, some transport mechanism for in-network loss detection and recovery [25][26] at a forwarder, as well as a consumer-driven mechanism, could be indispensable for enabling fast loss recovery and realizing NC gains. If a forwarder cannot either return a matching innovative packet from its local content store, nor produce on the fly a recoded packet that is innovative, it is important that the forwarder not simply return a non-innovative packet but instead do a forwarding lookup in its FIB and forward the interest toward the producer or upstream forwarder that can provide an innovative packet. In this context, to retrieve an innovative packet effectively and quickly, an appropriate setting of the FIB and efficient interest-forwarding strategies should also be considered.
転送業者が、非侵害的なパケットを返却することにより、着信の利益に絶えず対応している場合、消費者はソースパケットをデコードして取得することはできません。この問題は、1）NCパケットの着信の関心が、使用するコーディングベクトルなどのいくつかのコーディングパラメーターを指定していない場合に発生する可能性があります。再調整に使用します。この場合、フォワーダーは、関心が届いたインターフェイスに転送する革新的なパケットを生成できるかどうかを判断する必要があります。この問題に対処するためのアプローチは、フォワーダーが特定の名前、生成ID、および着信インターフェイスの利益の集計を維持して、すでに何度自由度が提供されているかを記録することです[21]。そのため、スキームにはフォワーダーの州管理（および潜在的にタイマー）が必要であるため、スケーラビリティと実用性を考慮する必要があります。さらに、転送業者主導のメカニズムと同様に、ネットワーク内の損失の検出と回復のいくつかの輸送メカニズム[25] [26]は、迅速な損失回復を可能にし、NCの利益を実現するために不可欠です。フォワーダーが地元のコンテンツストアから一致する革新的なパケットを返すことも、革新的な復元されたパケットをその場で生産できない場合、転送者が単に非否定的なパケットを返すのではなく、その代わりに転送検索を行うことが重要です革新的なパケットを提供できるプロデューサーまたは上流のフォワーダーにFIBを転送します。これに関連して、革新的なパケットを効果的かつ迅速に取得するには、FIBと効率的な関心のある戦略の適切な設定も考慮する必要があります。
In another possible case, when receiving interests only for source packets, the forwarder may attempt to decode and obtain all the source packets and store them (if the full cache capacity are available), thus enabling a faster response to subsequent interests. As recoding or decoding results in an extra computational overhead, the forwarder is required to determine how to respond to received interests according to the use case (e.g., a delay-sensitive or delay-tolerant application) and the forwarder situation, such as available cache space and computational capability.
別の可能なケースでは、ソースパケットのみを受信する場合、フォワーダーはすべてのソースパケットをデコードして取得し、それらを保存しようとすることができます（完全なキャッシュ容量が利用可能な場合）。計算またはデコードの結果、余分な計算オーバーヘッドが得られるため、転送者は、使用可能なキャッシュなどのユースケース（例：遅延感受性または遅延耐性アプリケーション）に従って受信利息に応答する方法を決定する必要がありますスペースと計算機能。
Before performing NC for specified content in CCNx/NDN, the producer is responsible for splitting the overall content into small content objects to avoid packet fragmentation that could cause unnecessary packet processing and degraded throughput. The size of the content objects should be within the allowable packet size in order to avoid packet fragmentation in a CCNx/NDN network. The producer performs the encoding operation for a set of the small content objects and the naming process for the NC packets.
CCNX/NDNで指定されたコンテンツのNCを実行する前に、プロデューサーは、不必要なパケット処理と分解されたスループットを引き起こす可能性のあるパケットフラグメンテーションを回避するために、全体的なコンテンツを小さなコンテンツオブジェクトに分割する責任があります。コンテンツオブジェクトのサイズは、CCNX/NDNネットワークでのパケットフラグメンテーションを回避するために、許容パケットサイズ内にある必要があります。プロデューサーは、小さなコンテンツオブジェクトのセットのエンコーディング操作と、NCパケットの命名プロセスを実行します。
If the producer takes the lead in determining what coding vectors to use in generating the NC packets, there are three general strategies for naming and producing the NC packets:
プロデューサーが、NCパケットの生成に使用するコーディングベクターを決定する際にリードを握っている場合、NCパケットを命名して生成するための3つの一般的な戦略があります。
1. Consumers themselves understand in detail the naming conventions used for NC packets and thereby can send the corresponding interests toward the producer to obtain NC packets whose coding parameters have already been determined by the producer.
1. 消費者自身は、NCパケットに使用される命名規則を詳細に理解しているため、プロデューサーによってコーディングパラメーターがすでに決定されているNCパケットを取得するために、プロデューサーに対応する利益を生産者に送信できます。
2. The producer determines the coding vectors and generates the NC packets after receiving interests specifying the packets the consumer wished to receive.
2. プロデューサーは、消費者が受け取りたいパケットを指定した関心を受け取った後、コーディングベクトルを決定し、NCパケットを生成します。
3. The naming scheme for specifying the coding vectors and corresponding NC packets is explicitly represented via a "Manifest" (e.g., FLIC [30]) that can be obtained by the consumer and used to select among the available coding vectors and their corresponding packets and thereby send the corresponding interests.
3. コーディングベクトルと対応するNCパケットを指定するための命名スキームは、消費者が取得し、利用可能なコーディングベクターとその対応するパケットの中から選択するために使用できる「マニフェスト」（例：Flic [30]）を介して明示的に表されます。対応する利益を送信します。
In the first case, although the consumers cannot flexibly specify a coding vector for generating the NC packet to obtain, the latency for obtaining the NC packet is less than in the latter two cases. For the second case, there is a latency penalty for the additional NC operations performed after receiving the interests. For the third case, the NC packets to be included in the manifest must be pre-computed by the producer (since the manifest references NC packets by their hashes, not their names), but the producer can select which to include in the manifest and produce multiple manifests either in advance or on demand with different coding tradeoffs, if so desired.
最初のケースでは、消費者はNCパケットを生成するためのコーディングベクトルを取得するためのコーディングベクトルを柔軟に指定することはできませんが、NCパケットを取得するための遅延は後者の2つのケースよりも少ないです。2番目のケースでは、利益を受け取った後に実行される追加のNC操作には潜在的なペナルティがあります。3番目のケースでは、マニフェストに含まれるNCパケットは、プロデューサーによって事前に計算されなければなりません（マニフェストは名前ではなくハッシュでNCパケットを参照するため）が、プロデューサーはマニフェストに含めるものを選択できます。必要に応じて、さまざまなコーディングトレードオフで事前またはオンデマンドで複数のマニフェストを作成します。
A common benefit of the first two approaches to end-to-end coding is that, if the producer adds a signature on the NC packets, data validation becomes possible throughout (as is the case with the CCNx/ NDN operation in the absence of NC). The third approach of using a manifest trades off the additional latency incurred by the need to fetch the manifest against the efficiency of needing a signature only on the manifest and not on each individual NC packet.
エンドツーエンドのコーディングに対する最初の2つのアプローチの一般的な利点は、プロデューサーがNCパケットに署名を追加すると、データ検証が可能になることです（NCがない場合のCCNX/ NDN操作の場合と同様です）。マニフェストを使用する3番目のアプローチは、個々のNCパケットではなく、マニフェストでのみ署名を必要とする効率に対してマニフェストを取得する必要性によって発生した追加のレイテンシをトレードオフします。
NC operations should be applied in addition to the regular ICN behavior and should function alongside regular ICN operations. Hence, nodes that do not support NC should still be able to properly handle packets, not only in being able to forward the NC packets but also to cache these packets. An NC framework should be compatible with a regular framework in order to facilitate backward compatibility and smooth migration from one framework to the other.
NC操作は、通常のICN動作に加えて適用する必要があり、通常のICN操作とともに機能する必要があります。したがって、NCをサポートしていないノードは、NCパケットを転送するだけでなく、これらのパケットをキャッシュできるように、パケットを適切に処理できるはずです。NCフレームワークは、一方のフレームワークから他のフレームワークへの後方互換性とスムーズな移行を促進するために、通常のフレームワークと互換性がある必要があります。
Caching is a useful technique used for improving throughput and latency in various applications. In-network caching in CCNx/NDN essentially provides support at the network level and is highly beneficial, owing to the involved exploitation of NC for enabling effective multicast transmission [31], multipath data retrieval [21] [24], and fast loss recovery [26]. However, there remain several issues to be considered.
キャッシュは、さまざまなアプリケーションでスループットとレイテンシを改善するために使用される有用な手法です。CCNX/NDNでのネットワーク内キャッシュは、ネットワークレベルで本質的にサポートを提供し、効果的なマルチキャスト伝送[31]、マルチパスデータ取得[21] [24]、および高速損失回復を可能にするためのNCの搾取により、非常に有益です。[26]。ただし、考慮すべきいくつかの問題が残っています。
There generally exist limitations in the CS capacity, and the caching policy affects the consumer's performance [32] [33] [34]. It is thus crucial for forwarders to determine which content objects should be cached and which discarded. As delay-sensitive applications often do not require an in-network cache for a long period, owing to their real-time constraints, forwarders have to know the necessity for caching received content objects to save the caching volume. In CCNx, this could be made possible by setting a Recommended Cache Time (RCT) in the optional header of the data packet at the producer side. The RCT serves as a guideline for the CS cache in determining how long to retain the content object. When the RCT is set as zero, the forwarder recognizes that caching the content object is not useful. Conversely, the forwarder may cache it when the RCT has a greater value. In NDN, the TLV type of FreshnessPeriod could be used.
一般に、CS容量には制限があり、キャッシュポリシーは消費者のパフォーマンスに影響します[32] [33] [34]。したがって、フォワーダーがどのコンテンツオブジェクトをキャッシュし、どのコンテンツオブジェクトを破棄するかを決定することが重要です。遅延に敏感なアプリケーションは、リアルタイムの制約により、長期間ネットワーク内キャッシュを必要としないことが多いため、転送者はキャッシュボリュームを保存するために受信したコンテンツオブジェクトのキャッシュの必要性を知る必要があります。CCNXでは、プロデューサー側のデータパケットのオプションヘッダーに推奨キャッシュ時間（RCT）を設定することで、これを可能にすることができます。RCTは、コンテンツオブジェクトを保持する時間を決定する際に、CSキャッシュのガイドラインとして機能します。RCTがゼロとして設定されている場合、転送者はコンテンツオブジェクトのキャッシュが役に立たないことを認識します。逆に、RCTがより大きな値を持っている場合、転送者はそれをキャッシュすることができます。NDNでは、FreshnessperiodのTLVタイプを使用できます。
One key aspect of in-network caching is whether or not forwarders can cache NC packets in their CS. They may be caching the NC packets without having the ability to perform a validation of the content objects. Therefore, the caching of the NC packets would require some mechanism to validate the NC packets (see Section 9). In the case wherein the NC packets have the same name, it would also require some mechanism to identify them.
ネットワーク内キャッシングの重要な側面の1つは、フォワーダーがCSでNCパケットをキャッシュできるかどうかです。コンテンツオブジェクトの検証を実行することなく、NCパケットをキャッシュしている場合があります。したがって、NCパケットのキャッシュには、NCパケットを検証するためのメカニズムが必要です（セクション9を参照）。NCパケットが同じ名前を持っている場合、それらを識別するために何らかのメカニズムも必要になります。
A key feature of CCNx/NDN is that it is sessionless, which enables the consumer and forwarder to send multiple interests toward different copies of the content in parallel, by using multiple interfaces at the same time in an asynchronous manner. Through the multipath data retrieval, the consumer could obtain the content from multiple copies that are distributed while using the aggregate capacity of multiple interfaces. For the link between the consumer and the multiple copies, the consumer can perform a certain rate adaptation mechanism for video streaming [24] or congestion control for content acquisition [35].
CCNX/NDNの重要な特徴は、セッションレスであることです。これにより、コンテンツとフォワーダーは、複数のインターフェイスを同時に非同期に使用することにより、コンテンツの異なるコピーに複数の利益を並行して送信できます。MultiPathデータ検索を通じて、消費者は複数のインターフェイスの総容量を使用している間に配布される複数のコピーからコンテンツを取得できます。消費者と複数のコピーの間のリンクの場合、消費者はビデオストリーミングのために特定のレート適応メカニズムを実行します[24]またはコンテンツの獲得のための混雑制御[35]。
NC adds a reliability layer to CCNx in a distributed and asynchronous manner, because NC provides a mechanism for ensuring that the interests sent to multiple copies of the content in parallel retrieve innovative packets, even in the case of packet losses on some of the paths/networks to these copies. This applies to consumer mobility events [24], wherein the consumer could receive additional degrees of freedom with any innovative packet if at least one available interface exists during the mobility event. An interest-forwarding strategy at the consumer (and possibly forwarder) for efficiently obtaining innovative packets would be required for the consumer to achieve seamless consumer mobility.
NCは、パスの一部でパケット損失の場合でも革新的なパケットを並行してコンテンツの複数のコピーに送信した関心を確実にするためのメカニズムを提供するため、分散および非同期の方法でCCNXに信頼性レイヤーを追加します。これらのコピーのネットワーク。これは、モビリティイベント中に少なくとも1つの利用可能なインターフェイスが存在する場合、消費者が革新的なパケットで追加の自由度を受け取ることができる消費者モビリティイベント[24]に適用されます。消費者が革新的なパケットを効率的に取得するための消費者（および場合によっては、おそらくフォワーダー）の関心戦略は、消費者がシームレスな消費者のモビリティを達成するために必要です。
This section presents several primary challenges and research items to be considered when applying NC in CCNx/NDN.
このセクションでは、CCNX/NDNでNCを適用する際に考慮すべきいくつかの主要な課題と研究項目を提示します。
Several block coding approaches have been proposed thus far; however, there is still not sufficient discussion and application of the convolutional coding approach (e.g., sliding or elastic window coding) in CCNx/NDN. Convolutional coding is often appropriate for situations wherein a fully or partially reliable delivery of continuous data flows is required and especially when these data flows feature real-time constraints. As in [36], on an end-to-end coding basis, it would be advantageous for continuous content flow to adopt sliding window coding in CCNx/NDN. In this case, the producer is required to appropriately set coding parameters and let the consumer know the information, and the consumer is required to send interests augmented with feedback information regarding the data reception and/or decoding status. As CCNx/NDN utilizes the hop-by-hop forwarding state, it would be worth discussing and investigating how convolutional coding can be applied in a hop-by-hop manner and what benefits might accrue. In particular, in the case wherein in-network recoding could occur at forwarders, both the encoding window and CS management would be required, and the corresponding feasibility and practicality should be considered.
これまでにいくつかのブロックコーディングアプローチが提案されています。ただし、CCNX/NDNの畳み込みコーディングアプローチ（例：スライドまたは弾性ウィンドウコーディングなど）の十分な議論と適用はまだありません。畳み込みのコーディングは、継続的なデータフローの完全または部分的に信頼性の高い配信が必要な状況に適していることがよくあり、特にこれらのデータフローがリアルタイムの制約を備えている場合。 [36]のように、エンドツーエンドのコーディングベースでは、CCNX/NDNでスライドウィンドウコーディングを採用するための連続コンテンツフローが有利です。この場合、プロデューサーはコーディングパラメーターを適切に設定し、消費者に情報を知らせる必要があり、消費者はデータ受信および/またはデコードステータスに関するフィードバック情報で増強された利子を送信する必要があります。 CCNX/NDNはホップバイホップ転送状態を利用しているため、ホップバイホップでどのように畳み込みコードを適用できるか、どのような利点が生じるかについて議論し、調査する価値があります。特に、ネットワーク内の再調整がフォワーダーで発生する可能性がある場合、エンコードウィンドウとCS管理の両方が必要であり、対応する実現可能性と実用性を考慮する必要があります。
The addition of redundancy using repair packets may result in further network congestion and could adversely affect the overall throughput. In particular, in a situation wherein fair bandwidth sharing is more desirable, each streaming flow must adapt to the network conditions to fairly consume the available link bandwidth. It is thus necessary that each content flow cooperatively implement congestion control to adjust the consumed bandwidth [37]. From this perspective, an effective deployment approach (e.g., a forwarder-supported approach that can provide benefits under partial deployment) is required.
修理パケットを使用した冗長性を追加すると、さらなるネットワークの輻輳が発生する可能性があり、全体的なスループットに悪影響を与える可能性があります。特に、公正な帯域幅の共有がより望ましい状況では、各ストリーミングフローがネットワーク条件に適応して、利用可能なリンク帯域幅をかなり消費する必要があります。したがって、各コンテンツは、消費された帯域幅を調整するために混雑制御を協力的に実装する必要があります[37]。この観点から、効果的な展開アプローチ（部分的な展開の下で利益を提供できるフォワーダーがサポートするアプローチなど）が必要です。
As described in Section 6.4, NC can contribute to seamless consumer mobility by obtaining innovative packets without receiving duplicated packets through multipath data retrieval, and avoiding duplicated packets has congestion control benefits as well. It can be challenging to develop an effective rate and congestion control mechanism in order to achieve seamless consumer mobility while improving the overall throughput or latency by fully exploiting NC operations.
セクション6.4で説明されているように、NCは、マルチパスデータ取得を通じて重複したパケットを受信せずに革新的なパケットを取得することにより、シームレスな消費者モビリティに貢献できます。NCの運用を完全に活用することにより、全体的なスループットまたはレイテンシを改善しながら、シームレスな消費者モビリティを達成するために、効果的なレートおよび輻輳制御メカニズムを開発することは困難です。
While CCNx/NDN introduces new security issues at the networking layer that are different from the IP network, such as a cache poisoning, pollution attacks, and a DoS attack using interest packets, some security approaches are already provided [19] [38]. The application of NC in CCNx/NDN brings two potential security aspects that need to be dealt with.
CCNX/NDNは、キャッシュ中毒、汚染攻撃、利息パケットを使用したDOS攻撃など、IPネットワークとは異なるネットワークレイヤーに新しいセキュリティ問題を導入しますが、いくつかのセキュリティアプローチはすでに提供されています[19] [38]。CCNX/NDNでのNCの適用は、対処する必要がある2つの潜在的なセキュリティ側面をもたらします。
The first is in-network recoding at forwarders. Some mechanism for ensuring the integrity of the NC packets newly produced by in-network recoding is required in order for consumers or other forwarders to receive valid NC packets. To this end, there are some possible approaches described in Section 9, but there may be a more effective method with lower complexity and computation overhead.
1つ目は、フォワーダーでのネットワーク内復元です。消費者または他のフォワーダーが有効なNCパケットを受け取るには、ネットワーク内復元によって新たに生成されたNCパケットの整合性を確保するためのいくつかのメカニズムが必要です。この目的のために、セクション9で説明されているいくつかのアプローチがありますが、複雑さと計算のオーバーヘッドが低いより効果的な方法があるかもしれません。
The second is that attackers maliciously request and inject NC packets, which could amplify some attacks. As NC packets are unpopular in general use, they could be targeted by a cache pollution attack that requests less popular content objects more frequently to undermine popularity-based caching by skewing the content popularity. Such an attack needs to be dealt with in order to maintain the in-network cache efficiency. By injecting invalid NC packets with the goal of filling the CSs at the forwarders with them, the cache poisoning attack could be effectual depending on the exact integrity coverage on NC packets. On the assumption that each NC packet has the valid signature, the straightforward approach would comprise the forwarders verifying the signature within the NC packets in transit and only transmitting and storing the validated NC packets. However, as performing a signature verification by the forwarders may be infeasible at line speed, some mechanisms should be considered for distributing and reducing the load of signature verification in order to maintain in-network cache benefits, such as latency and network-load reduction.
2つ目は、攻撃者が悪意を持って要求し、NCパケットを注入し、いくつかの攻撃を増幅する可能性があることです。 NCパケットは一般的に使用されていないため、コンテンツの人気を歪めることで人気ベースのキャッシングを損なうために、あまり人気のないコンテンツオブジェクトをより頻繁に要求するキャッシュ汚染攻撃によって標的にされる可能性があります。このような攻撃は、ネットワーク内のキャッシュ効率を維持するために対処する必要があります。フォワーダーでCSSを充填することを目標に無効なNCパケットを注入することにより、NCパケットの正確な整合性カバレッジに応じて、キャッシュ中毒攻撃は効果的になる可能性があります。各NCパケットに有効な署名があると仮定すると、簡単なアプローチは、転送中のNCパケット内の署名を検証し、検証済みのNCパケットのみを送信および保存する転送者を構成します。ただし、フォワーダーによる署名検証を実行することは、ライン速度で実行不可能である可能性があるため、レイテンシやネットワークロードの削減などのネットワーク内キャッシュの利点を維持するために、署名検証の負荷を分配および削減するためにいくつかのメカニズムを考慮する必要があります。
In CCNx/NDN, a name-based routing protocol without a resolution process streamlines the routing process and reduces the overall latency. In IP routing, the growth in the routing table size has become a concern. It is thus necessary to use a hierarchical naming scheme in order to improve the routing scalability by enabling the aggregation of the routing information.
CCNX/NDNでは、解像度プロセスのない名前ベースのルーティングプロトコルがルーティングプロセスを合理化し、全体的なレイテンシを削減します。IPルーティングでは、ルーティングテーブルサイズの成長が懸念されています。したがって、ルーティング情報の集約を可能にすることにより、ルーティングのスケーラビリティを改善するために、階層命名スキームを使用する必要があります。
To realize the benefits of NC, consumers need to efficiently obtain innovative packets using multipath retrieval mechanisms of CCNx/NDN. This would require some efficient routing mechanism to appropriately set the FIB and also an efficient interest-forwarding strategy. Such routing coordination may create routing scalability issues. It would be challenging to achieve effective and scalable routing for interests requesting NC packets, as well as to simplify the routing process.
NCの利点を実現するには、CCNX/NDNのマルチパス検索メカニズムを使用して革新的なパケットを効率的に取得する必要があります。これには、FIBを適切に設定するための効率的なルーティングメカニズムと、効率的な関心のある戦略が必要になります。このようなルーティング調整により、ルーティングスケーラビリティの問題が発生する場合があります。NCパケットを要求する利益のために効果的でスケーラブルなルーティングを達成し、ルーティングプロセスを簡素化することは困難です。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
In-network recoding is a distinguishing feature of NC. Only valid NC packets produced by in-network recoding must be requested and utilized (and possibly stored). To this end, there exist some possible approaches. First, as a signature verification approach, the exploitation of multi-signature capability could be applied. This allows not only the original content producer but also some forwarders responsible for in-network recoding to have their own unique signing key. Each forwarder of the group signs a newly generated NC packet in order for other nodes to be able to validate the data with the signature. The CS may verify the signature within the NC packet before storing it to avoid invalid data caching. Second, as a consumer-dependent approach, the consumer puts a restriction on the matching rule using only the name of the requested data. The interest ambiguity can be clarified by specifying both the name and the key identifier (the producer's public key digest) used for matching to the requested data. This KeyId restriction is built in the CCNx design [17]. Only the requested data packet satisfying the interest with the KeyId restriction would be forwarded and stored in the CS, thus resulting in a reduction in the chances of cache poisoning. Moreover, in the CCNx design, there exists the rule that the CS obeys in order to avoid amplifying invalid data; if an interest has a KeyId restriction, the CS must not reply unless it knows that the signature on the matching content object is correct. If the CS cannot verify the signature, the interest may be treated as a cache miss and forwarded to the upstream forwarder(s). Third, as a certificate chain management approach (possibly without certificate authority), some mechanism, such as [39], could be used to establish a trustworthy data delivery path. This approach adopts the hop-by-hop authentication mechanism, wherein the forwarding-integrated hop-by-hop certificate collection is performed to provide suspension certificate chains such that the data retrieval is trustworthy.
ネットワーク内復元は、NCの際立った特徴です。ネットワーク内の復元によって生成された有効なNCパケットのみを要求し、利用する（そしておそらく保存される）必要があります。この目的のために、いくつかの可能なアプローチが存在します。まず、署名検証アプローチとして、マルチシグネチャ機能の利用を適用できます。これにより、元のコンテンツプロデューサーだけでなく、ネットワーク内の復元を担当する一部のフォワーダーも、独自の独自の署名キーを持つことができます。グループの各フォワーダーは、他のノードが署名でデータを検証できるようにするために、新しく生成されたNCパケットに署名します。 CSは、NCパケットを保存する前にNCパケット内の署名を確認して、無効なデータキャッシュを回避する場合があります。第二に、消費者依存のアプローチとして、消費者は要求されたデータの名前のみを使用して、一致するルールに制限を設けます。関心のあいまいさは、要求されたデータと一致するために使用される名前とキー識別子（プロデューサーの公開キーダイジェスト）の両方を指定することで明確にすることができます。このKeyID制限は、CCNX設計に組み込まれています[17]。 KeyID制限の関心を満たす要求されたデータパケットのみが、CSに転送され、保存され、キャッシュ中毒の可能性が減少します。さらに、CCNX設計では、無効なデータの増幅を避けるためにCSが従うというルールが存在します。利息にKeyID制限がある場合、一致するコンテンツオブジェクトの署名が正しいことがわからない限り、CSは返信してはなりません。 CSが署名を検証できない場合、関心はキャッシュミスとして扱われ、上流の転送者に転送される場合があります。第三に、証明書チェーン管理アプローチ（おそらく証明書権限なし）として、[39]などのいくつかのメカニズムを使用して、信頼できるデータ配信パスを確立することができます。このアプローチでは、ホップバイホップ認証メカニズムが採用されています。このメカニズムでは、データ検索が信頼できるようにサスペンション証明書チェーンを提供するために、転送統合ホップバイホップ証明書コレクションが実行されます。
Depending on the adopted caching strategy, such as cache replacement policies, forwarders should also take caution when storing and retaining the NC packets in the CS, as they could be targeted by cache pollution attacks. In order to mitigate the cache pollution attacks' impact, forwarders should check the content request frequencies to detect the attack and may limit requests by ignoring some of the consecutive requests. The forwarders can then decide to apply or change to the other cache replacement mechanism.
キャッシュ交換ポリシーなどの採用されたキャッシュ戦略に応じて、転送者は、キャッシュ汚染攻撃の対象となる可能性があるため、CSにNCパケットを保存および保持する際にも注意する必要があります。キャッシュ汚染攻撃の影響を緩和するために、フォワーダーはコンテンツ要求の頻度をチェックして攻撃を検出する必要があり、連続した要求の一部を無視してリクエストを制限する場合があります。その後、フォワーダーは、他のキャッシュ置換メカニズムを適用または変更することを決定できます。
The forwarders or producers require careful attention to the DoS attacks aimed at provoking the high load of NC operations by using the interests for NC packets. In order to mitigate such attacks, the forwarders could adopt a rate-limiting approach. For instance, they could monitor the PIT size growth for NC packets per content to detect the attacks and limit the interest arrival rate when necessary. If the NC application wishes to secure an interest (considered as the NC actuator) in order to prevent such attacks, the application should consider using an encrypted wrapper and an explicit protocol.
フォワーダーまたはプロデューサーは、NCパケットの利益を使用して、NCの高い運用を引き起こすことを目的としたDOS攻撃に注意を払う必要があります。このような攻撃を軽減するために、フォワーダーはレート制限アプローチを採用できます。たとえば、コンテンツあたりのNCパケットのピットサイズの成長を監視して、攻撃を検出し、必要に応じて利子到着率を制限できます。NCアプリケーションがそのような攻撃を防ぐために利息（NCアクチュエータと見なされる）を確保することを希望する場合、アプリケーションは暗号化されたラッパーと明示的なプロトコルの使用を検討する必要があります。
[1] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proc. CoNEXT, ACM, DOI 10.1145/1658939.1658941, December 2009, <https://doi.org/10.1145/1658939.1658941>.
[1] Jacobson、V.、Smetters、D.、Thornton、J.、Plass、M.、Briggs、N。、およびR. Braynard、「ネットワーキング名のコンテンツ」、Proc。Conext、ACM、DOI 10.1145/1658939.1658941、2009年12月、<https://doi.org/10.1145/1658939.1658941>。
[2] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, "Named data networking", ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, DOI 10.1145/2656877.2656887, July 2014, <https://doi.org/10.1145/2656877.2656887>.
[2] Zhang、L.、Afanasyev、A.、Burke、J.、Jacobson、V.、Claffy、K.、Crowley、P.、Papadopoulos、C.、Wang、L。、およびB. Zhang、「Damed Data Networking」、ACM Sigcomm Computer Communication Review、Vol。44、いいえ。3、DOI 10.1145/265687.2656887、2014年7月、<https://doi.org/10.1145/2656877.2656887>。
[3] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for Network Coding File Distribution", Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2006.233, April 2006, <https://doi.org/10.1109/INFOCOM.2006.233>.
[3] Gkantsidis、C。およびP. Rodriguez、「ネットワークコーディングファイル分布のための協同セキュリティ」、Proc。Infocom、IEEE、doi 10.1109/infocom.2006.233、2006年4月、<https://doi.org/10.1109/infocom.2006.233>。
[4] Cai, N. and R. Yeung, "Secure network coding", Proc. International Symposium on Information Theory (ISIT), IEEE, DOI 10.1109/ISIT.2002.1023595, June 2002, <https://doi.org/10.1109/ISIT.2002.1023595>.
[4] Cai、N。およびR. Yeung、「Secure Network Coding」、Proc。情報理論に関する国際シンポジウム（ISIT）、IEEE、DOI 10.1109/ISIT.2002.1023595、2002年6月、<https://doi.org/10.1109/isit.2002.1023595>。
[5] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A. Toledo, "Secure Network Coding for Multi-Resolution Wireless Video Streaming", IEEE Journal of Selected Area (JSAC), vol. 28, no. 3, DOI 10.1109/JSAC.2010.100409, April 2010, <https://doi.org/10.1109/JSAC.2010.100409>.
[5] Lima、L.、Gheorghiu、S.、Barros、J.、Medard、M。、およびA. Toledo、「マルチ解像度ワイヤレスビデオストリーミングのセキュアネットワークコーディング」、IEEE Journal of Selected Area（JSAC）、Vol。28、いいえ。3、doi 10.1109/jsac.2010.100409、2010年4月、<https://doi.org/10.1109/jsac.2010.100409>。
[6] Vilea, J., Lima, L., and J. Barros, "Lightweight security for network coding", Proc. ICC, IEEE, DOI 10.48550/arXiv.0807.0610, May 2008, <https://doi.org/10.48550/arXiv.0807.0610>.
[6] Vilea、J.、Lima、L。、およびJ. Barros、「ネットワークコーディングの軽量セキュリティ」、Proc。ICC、IEEE、DOI 10.48550/arxiv.0807.0610、2008年5月、<https://doi.org/10.48550/arxiv.0807.0610>。
[7] Koetter, R. and M. Medard, "An Algebraic Approach to Network Coding", IEEE/ACM Transactions on Networking, vol. 11, no. 5, DOI 10.1109/TNET.2003.818197, October 2003, <https://doi.org/10.1109/TNET.2003.818197>.
[7] Koetter、R。およびM. Medard、「ネットワークコーディングへの代数的アプローチ」、IEEE/ACM Transactions on Networking、Vol。11、いいえ。5、doi 10.1109/tnet.2003.818197、2003年10月、<https://doi.org/10.1109/tnet.2003.818197>。
[8] Vyetrenko, S., Ho, T., Effros, M., Kliewer, J., and E. Erez, "Rate regions for coherent and noncoherent multisource network error correction", Proc. International Symposium on Information Theory (ISIT), IEEE, DOI 10.1109/ISIT.2009.5206077, June 2009, <https://doi.org/10.1109/ISIT.2009.5206077>.
[8] Vyetrenko、S.、Ho、T.、Effros、M.、Kliewer、J。、およびE. Erez、「コヒーレントおよび非密着ネットワークエラー補正の速度領域」、Proc。情報理論に関する国際シンポジウム（ISIT）、IEEE、DOI 10.1109/ISIT.2009.5206077、2009年6月、<https://doi.org/10.1109/isit.2009.52077>。
[9] Wu, Y., Chou, P., and K. Jain, "A comparison of network coding and tree packing", Proc. International Symposium on Information Theory (ISIT), IEEE, DOI 10.1109/ISIT.2004.1365182, June 2004, <https://doi.org/10.1109/ISIT.2004.1365182>.
[9] Wu、Y.、Chou、P。、およびK. Jain、「ネットワークコーディングとツリーパッキングの比較」、Proc。情報理論に関する国際シンポジウム（ISIT）、IEEE、DOI 10.1109/ISIT.2004.1365182、2004年6月、<https://doi.org/10.1109/isit.2004.1365182>。
[10] Ho, T., Medard, M., Koetter, R., Karger, D., Effros, M., Shi, J., and B. Leong, "A Random Linear Network Coding Approach to Multicast", IEEE Trans. on Information Theory, vol. 52, no. 10, DOI 10.1109/TIT.2006.881746, October 2006, <https://doi.org/10.1109/TIT.2006.881746>.
[10] Ho、T.、Medard、M.、Koetter、R.、Karger、D.、Effros、M.、Shi、J。、およびB. Leong、「マルチキャストへのランダム線形ネットワークコーディングアプローチ」、IEEE Trans。情報理論について、Vol。52、いいえ。10、doi 10.1109/tit.2006.881746、2006年10月、<https://doi.org/10.1109/tit.2006.881746>。
[11] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. Ramchandran, "Network Coding for Distributed Storage Systems", IEEE Trans. Information Theory, vol. 56, no.9, DOI 10.1109/TIT.2010.2054295, September 2010, <https://doi.org/10.1109/TIT.2010.2054295>.
[11] Dimarkis、A.、Godfrey、P.、Wu、Y.、Wainwright、M。、およびK. Ramchandran、「分散ストレージシステムのネットワークコーディング」、IEEE Trans。情報理論、Vol。56、No.9、doi 10.1109/tit.2010.2054295、2010年9月、<https://doi.org/10.1109/tit.2010.2054295>。
[12] Gkantsidis, C. and P. Rodriguez, "Network coding for large scale content distribution", Proc. Infocom, IEEE, DOI 10.1109/INFCOM.2005.1498511, March 2005, <https://doi.org/10.1109/INFCOM.2005.1498511>.
[12] Gkantsidis、C。およびP. Rodriguez、「大規模なコンテンツ分布のネットワークコーディング」、Proc。Infocom、IEEE、doi 10.1109/infcom.2005.1498511、2005年3月、<https://doi.org/10.1109/infcom.2005.1498511>。
[13] Seferoglu, H. and A. Markopoulou, "Opportunistic Network Coding for Video Streaming over Wireless", Proc. Packet Video Workshop (PV), IEEE, DOI 10.1109/PACKET.2007.4397041, November 2007, <https://doi.org/10.1109/PACKET.2007.4397041>.
[13] Seferoglu、H。およびA. Markopoulou、「ワイヤレスを超えるビデオストリーミングのための日和見ネットワークコーディング」、Proc。パケットビデオワークショップ（PV）、IEEE、doi 10.1109/packet.2007.4397041、2007年11月、<https://doi.org/10.1109/packet.2007.4397041>。
[14] Montpetit, M., Westphal, C., and D. Trossen, "Network Coding Meets Information-Centric Networking: An Architectural Case for Information Dispersion Through Native Network Coding", Proc. Workshop on Emerging Name-Oriented Mobile Networking Design (NoM), ACM, DOI 10.1145/2248361.2248370, June 2012, <https://doi.org/10.1145/2248361.2248370>.
[14] Montpetit、M.、Westphal、C。、およびD. Trossen、「ネットワークコーディングは情報中心のネットワーキングを満たしています：ネイティブネットワークコーディングによる情報分散のためのアーキテクチャケース」、Proc。新たな名前指向のモバイルネットワーキングデザイン（NOM）、ACM、DOI 10.1145/2248361.2248370、2012年6月、<https://doi.org/10.1145/2248361.2248370>
[15] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[15] Adamson、B.、Adjih、C.、Bilbao、J.、Firoiu、V.、Fitzek、F.、Ghanem、S.、Lochin、E.、Masucci、A.、Montpetit、M-J。、Pedersen、M。Peralta、G.、Roca、V.、Ed。、Saxena、P。、およびS. Sivakumar、「効率的なネットワーク通信のためのコーディング技術の分類法」、RFC 8406、DOI 10.17487/RFC8406、2018年6月、<https：//////www.rfc-editor.org/info/rfc8406>。
[16] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology", RFC 8793, DOI 10.17487/RFC8793, June 2020, <https://www.rfc-editor.org/info/rfc8793>.
[16] Wissingh、B.、Wood、C.、Afanasyev、A.、Zhang、L.、Oran、D。、およびC. Tschudin、「Information-Centric Networking（ICN）：コンテンツ中心のネットワーキング（CCNX）および名前付きデータネットワーキング（NDN）用語 "、RFC 8793、DOI 10.17487/RFC8793、2020年6月、<https://www.rfc-editor.org/info/rfc8793>。
[17] 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>.
[17] Mosko、M.、Solis、I。、およびC. Wood、「コンテンツ中心のネットワーキング（CCNX）セマンティクス」、RFC 8569、DOI 10.17487/RFC8569、2019年7月、<https://www.rfc-editor.org/情報/RFC8569>。
[18] 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>.
[18] Mosko、M.、Solis、I。、およびC. Wood、「TLV形式のコンテンツ中心のネットワーキング（CCNX）メッセージ」、RFC 8609、DOI 10.17487/RFC8609、2019年7月、<https：//www.rfc-editor.org/info/rfc8609>。
[19] 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>.
[19] Kutscher、D.、Ed。、Eum、S.、Pentikousis、K.、Psaras、I.、Corujo、D.、Sauce、D.、Schmidt、T.、M。Waehlisch、「Inform-centric Networking（ICN」）研究の課題」、RFC 7927、DOI 10.17487/RFC7927、2016年7月、<https://www.rfc-editor.org/info/rfc7927>。
[20] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. Xie, "Privacy-Aware Multipath Video Caching for Content-Centric Networks", IEEE Journal on Selected Areas in Communications (JSAC), vol. 38, no. 8, DOI 10.1109/JSAC.2016.2577321, June 2016, <https://doi.org/10.1109/JSAC.2016.2577321>.
[20] Wu、Q.、Li、Z.、Tyson、G.、Uhlig、S.、Kaafar、M。、およびG. Xie、「コンテンツ中心のネットワーク向けのプライバシー認識マルチパスビデオキャッシュ」、IEEEジャーナルコミュニケーション（JSAC）、Vol。38、いいえ。8、doi 10.1109/jsac.2016.2577321、2016年6月、<https://doi.org/10.1109/jsac.2016.2577321>。
[21] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, "NetCodCCN: a network coding approach for content-centric networks", Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2016.7524382, April 2016, <https://doi.org/10.1109/INFOCOM.2016.7524382>.
[21] Saltarin、J.、Bourtsoulatze、E.、Thomos、N。、およびT. Braun、「NetCodccn：コンテンツ中心のネットワークのネットワークコーディングアプローチ」、Proc。Infocom、IEEE、doi 10.1109/infocom.2016.7524382、2016年4月、<https://doi.org/10.1109/infocom.2016.7524382>。
[22] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. Westphal, "An Optimal Cache Management Framework for Information-Centric Networks with Network Coding", Proc. Networking Conference, IFIP/IEEE, DOI 10.1109/IFIPNetworking.2014.6857127, June 2014, <https://doi.org/10.1109/IFIPNetworking.2014.6857127>.
[22] Wang、J.、Ren、J.、Lu、K.、Wang、J.、Liu、S。、およびC. Westphal、「ネットワークコーディングを備えた情報中心ネットワークの最適なキャッシュ管理フレームワーク」、Proc。ネットワーキング会議、IFIP/IEEE、doi 10.1109/ifipnetworking.2014.6857127、2014年6月、<https://doi.org/10.1109/ifipnetworking.2014.6857127>。
[23] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. Westphal, "A Minimum Cost Cache Management Framework for Information-Centric Networks with Network Coding", Computer Networks, Elsevier, DOI 10.1016/j.comnet.2016.08.004, August 2016, <https://doi.org/10.1016/j.comnet.2016.08.004>.
[23] Wang、J.、Ren、J.、Lu、K.、Wang、J.、Liu、S。、およびC. Westphal、「ネットワークコーディングを備えた情報中心ネットワークの最小コストキャッシュ管理フレームワーク」、コンピューターネットワーク、Elsevier、doi 10.1016/j.comnet.2016.08.004、2016年8月、<https://doi.org/10.1016/j.comnet.2016.08.004>。
[24] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive Video Streaming over CCN with Network Coding for Seamless Mobility", Proc. International Symposium on Multimedia (ISM), IEEE, DOI 10.1109/ISM.2016.0054, December 2016, <https://doi.org/10.1109/ISM.2016.0054>.
[24] Ramakrishnan、A.、Westphal、C。、およびJ. Saltarin、「シームレスモビリティのネットワークコーディングを備えたCCNを介した適応ビデオストリーミング」、Proc。マルチメディア（ISM）、IEEE、DOI 10.1109/ISM.2016.0054、2016年12月の国際シンポジウム、<https://doi.org/10.1109/ism.2016.0054>。
[25] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, N., and X. Zeng, "Leveraging ICN In-network Control for Loss Detection and Recovery in Wireless Mobile networks", Proc. of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2984361, September 2016, <https://doi.org/10.1145/2984356.2984361>.
[25] Carofiglio、G.、Muscariello、L.、Papalini、M.、Rozhnova、N。、およびX. Zeng、「ワイヤレスモバイルネットワークの損失検出と回復のためのICN内のネットワーク制御を活用」、Proc。情報中心ネットワーキングに関する第3回ACM会議、DOI 10.1145/2984356.2984361、2016年9月<https://doi.org/10.1145/2984356.2984361>。
[26] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency Low Loss Streaming using In-Network Coding and Caching", Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2017.8057026, May 2017, <https://doi.org/10.1109/INFOCOM.2017.8057026>.
[26] Matsuzono、K。、Asaeda、H。、およびT. Turletti、「ネットワーク内コーディングとキャッシュを使用した低潜伏期低損失ストリーミング」、Proc。Infocom、IEEE、doi 10.1109/infocom.2017.8057026、2017年5月、<https://doi.org/10.1109/infocom.2017.8057026>。
[27] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.
[27] Watson、M.、Begen、A。、およびV. Roca、「フォワードエラー補正（FEC）フレームワーク」、RFC 6363、DOI 10.17487/RFC6363、2011年10月、<https://www.rfc-editor.org/info/RFC6363>。
[28] Thomos, N. and P. Frossard, "Toward One Symbol Network Coding Vectors", IEEE Communications Letters, vol. 16, no. 11, DOI 10.1109/LCOMM.2012.092812.121661, November 2012, <https://doi.org/10.1109/LCOMM.2012.092812.121661>.
[28] Thomos、N。およびP. Frossard、「1つのシンボルネットワークコーディングベクトルに向けて」、IEEE Communications Letters、Vol。16、いいえ。11、doi 10.1109/lcomm.2012.092812.121661、2012年11月、<https://doi.org/10.1109/lcomm.2012.092812.121661>。
[29] Lucani, D., Pedersen, M., Ruano, D., Sørensen, C., Heide, J., Fitzek, F., and O. Geil, "Fulcrum Network Codes: A Code for Fluid Allocation of Complexity", DOI 10.48550/arXiv.1404.6620, April 2014, <https://doi.org/10.48550/arXiv.1404.6620>.
[29] Lucani、D.、Pedersen、M.、Ruano、D.、Sørensen、C.、Heide、J.、Fitzek、F。、およびO. Geil、「Fulcrum Network Codes：A Code for Fluid Arlocation of Complesity」、Doi10.48550/arxiv.1404.6620、2014年4月、<https://doi.org/10.48550/arxiv.1404.6620>。
[30] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File-Like ICN Collections (FLIC)", Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-03, 7 November 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>.
[30] Tschudin、C.、Wood、C。A.、Mosko、M。、およびD. Oran、「ファイルのようなICNコレクション（FLIC）」、Work in Progress、Internet-Draft、Draft-ARTF-ICNRG-FLIC-03、1月7日2021、<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>。
[31] Maddah-Ali, M. and U. Niesen, "Coding for Caching: Fundamental Limits and Practical Challenges", IEEE Communications Magazine, vol. 54, no. 8, DOI 10.1109/MCOM.2016.7537173, August 2016, <https://doi.org/10.1109/MCOM.2016.7537173>.
[31] Maddah-Ali、M。およびU. Niesen、「キャッシュのコーディング：基本的な制限と実用的な課題」、IEEE Communications Magazine、Vol。54、いいえ。8、doi 10.1109/mcom.2016.7537173、2016年8月、<https://doi.org/10.1109/mcom.2016.7537173>。
[32] Perino, D. and M. Varvello, "A reality check for content centric networking", Proc. SIGCOMM Workshop on Information-centric networking (ICN '11), ACM, DOI 10.1145/2018584.2018596, August 2011, <https://doi.org/10.1145/2018584.2018596>.
[32] Perino、D。およびM. Varvello、「コンテンツ中心ネットワーキングの現実チェック」、Proc。情報中心のネットワーキングに関するSigcommワークショップ（ICN '11）、ACM、DOI 10.1145/2018584.2018596、2011年8月、<https://doi.org/10.1145/2018584.2018596>。
[33] Podlipnig, S. and L. Böszörmenyi, "A Survey of Web Cache Replacement Strategies", Proc. ACM Computing Surveys, vol. 35, no. 4, DOI 10.1145/954339.954341, December 2003, <https://doi.org/10.1145/954339.954341>.
[33] Podlipnig、S。およびL.Böszörmenyi、「Webキャッシュ交換戦略の調査」、Proc。ACMコンピューティング調査、Vol。35、いいえ。4、DOI 10.1145/954339.954341、2003年12月、<https://doi.org/10.1145/954339.954341>。
[34] Rossini, G. and D. Rossi, "Evaluating CCN multi-path interest forwarding strategies", Elsevier Computer Communications, vol. 36, no. 7, DOI 10.1016/j.comcom.2013.01.008, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.008>.
[34] Rossini、G。およびD. Rossi、「CCNマルチパスの関心戦略の評価」、Elsevier Computer Communications、Vol。36、いいえ。7、doi 10.1016/j.comcom.2013.01.008、2013年4月、<https://doi.org/10.1016/j.com.2013.01.008>。
[35] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, "MIRCC: Multipath-aware ICN Rate-based Congestion Control", Proc. Conference on Information-Centric Networking (ICN), ACM, DOI 10.1145/2984356.2984365, September 2016, <https://doi.org/10.1145/2984356.2984365>.
[35] Mahdian、M.、Arianfar、S.、Gibson、J。、およびD. Oran、「Mircc：Multipath-Aware ICNレートベースの混雑制御」、Proc。情報中心ネットワーキング（ICN）、ACM、DOI 10.1145/2984356.2984365、2016年9月<https://doi.org/10.1145/2984356.2984365>。
[36] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and V. Roca, "On-the-Fly Erasure Coding for Real-Time Video Applications", IEEE Transactions on Multimedia, vol. 13, no. 4, DOI 10.1109/TMM.2011.2126564, August 2011, <https://doi.org/10.1109/TMM.2011.2126564>.
[36] Tournoux、P.、Lochin、E.、Lacan、J.、Bouabdallah、A。、およびV. Roca、「リアルタイムビデオアプリケーションのためのオンザフライ消去コーディング」、IEEE Transactions on Multimedia、vol。13、いいえ。4、doi 10.1109/tmm.2011.2126564、2011年8月、<https://doi.org/10.1109/tmm.2011.2126564>。
[37] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward Erasure Correction (FEC) Coding and Congestion Control in Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022, <https://www.rfc-editor.org/info/rfc9265>.
[37] Kuhn、N.、Lochin、E.、Michel、F。、およびM. Welzl、「輸送におけるフォワード消去補正（FEC）コーディングと混雑制御」、RFC 9265、DOI 10.17487/RFC9265、2022年7月、<https：//www.rfc-editor.org/info/rfc9265>。
[38] 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>.
[38] 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>。
[39] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric Authentication for Secure In-Network Big-Data Retrieval", IEEE Trans. on Network Science and Engineering, vol. 7, no. 1, DOI 10.1109/TNSE.2018.2872049, September 2018, <https://doi.org/10.1109/TNSE.2018.2872049>.
[39] Li、R.、Asaeda、H。、およびJ. Wu、「Dcauth：安全なネットワーク内ビッグデータ検索のためのデータ中心認証」、IEEE Trans。ネットワークサイエンスアンドエンジニアリング、Vol。7、いいえ。1、doi 10.1109/tnse.2018.2872049、2018年9月、<https://doi.org/10.1109/tnse.2018.2872049>。
Acknowledgments
謝辞
The authors would like to thank ICNRG and NWCRG members, especially Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti, for their valuable comments and suggestions on this document.
著者は、ICNRGとNWCRGのメンバー、特にマリー・ジョセ・モンペティット、デビッド・オラン、ヴィンセント・ロカ、ティエリー・ターレットに感謝したいと思います。この文書に関する貴重なコメントと提案について。
Authors' Addresses
著者のアドレス
Kazuhisa Matsuzono National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Tokyo 184-8795 Japan Email: matsuzono@nict.go.jp
カズヒサ・マツゾノ国立情報通信技術研究所4-2-1ヌクイキタマチ、東京184-8795日本メール：matsuzono@nict.go.jp
Hitoshi Asaeda National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp
Asaeda National Institute of Information And Communications Technology 4-2-1 Nukui-Kitamachi、Tokyo 184-8795日本メール：asaeda@nict.go.jp
Cedric Westphal Huawei 2330 Central Expressway Santa Clara, California 95050 United States of America Email: cedric.westphal@futurewei.com,
Cedric Westphal Huawei 2330 Central Expressway Santa Clara、カリフォルニア95050アメリカ合衆国電子メール：cedric.westphal@futurewei.com